Skill.md検索

コードを書く前に CONCEPT.md（プロジェクトの基本方針）と CLAUDE.md（開発ルール）を自動確認し、今回の作業がプロジェクト方針に矛盾していないか検証します。 設計・実装・修正・リファクタリングの各段階で、判断に迷ったときの相談相手（codex）の効果的な活用方法をガイドし、1往復で終わらず必要なだけ質問を続けられるようサポートします。 調査→計画→実装→テスト→ドキュメント更新→レビューの8段階フローを図解し、技術的不確実性がある場合の POC（概念実証）実施タイミングを示します。 nekonote プロジェクトに新しく参加した開発者や、久しぶりに戻ってきた開発者 新機能実装やバグ修正、リファクタリング時に「どの手順で進めるべき？」と迷う開発者 技術的な判断について codex（AI副操縦士）と相談しながら進めたい開発者 プロジェクト全体の一貫性を保ちながら開発を進める必要があるチーム Phase 0 では CONCEPT.md と CLAUDE.md を必読ファイルとして読み込み、矛盾がないか確認します。Phase 1-8 の開発ループでは、調査→codex追加調査→（必要に応じてPOC）→計画→実装/テスト→ドキュメント→セルフレビュー→codexレビュー→コミットの流れを規定します。POC は技術的不確実性や複数アプローチの優劣判定が必要な場合に .tasks/plans/poc-.md で実施し、結果を Verdict・Decision で記録します。codex は会話スレッドの何往復でも活用でき、プロンプトには背景・参照ファイル・具体的質問を含めます。

.tasks/plans/poc-.mdでPOC（Proof of Concept）計画を立て、.playground/poc-/の独立したサンドボックス環境で実験コードを実行するため、本番コードに影響を与えずに技術的仮説を検証できます。 実験の結果（数値・出力・エラー）を Result セクションに記録し、Verdict を「validated（検証成功）」「invalidated（検証失敗）」「partial（部分的）」で判定するため、曖昧な判断で本実装に進むことがなくなります。 POC コードはすべて playground 内に閉じ込められ、git 管理外のサンドボックスで実行されるため、メインセッションがクラッシュしたり本番コードが破壊される心配がありません。 Key Findings に得られた知見を記載し、Decision セクションで「本実装に採用」「見送り（docs/proposals/へアーカイブ）」「追加検証（新POC起動）」を選択するため、実験結果が確実に次のアクションに繋がります。 バックグラウンド実行・タイムアウト付与・大規模POCはエージェント委譲など、セッション安全性のルールが組み込まれているため、長時間実験中のセッション切断に対応できます。 新しいライブラリ・言語機能・アーキテクチャパターンの採用可否を見極めたい開発者 複数の実装アプローチから最適な方法を選びたい設計者 パフォーマンス改善の効果を実装前に数値で検証したい人 リスクの高い技術判断を記録に残し、チーム内で共有したいリーダー POC 実施の流れは、まず.tasks/plans/poc-.mdを.tasks/templates/poc.mdをベースに作成（命名規則:poc-.md）、Hypothesis と Background を先に記入します。次に.playground/poc-/サブディレクトリを作成し、git管理外のサンドボックスで実験コードを実行します。セッション安全性ルール：(1)POCコードは.playground/poc-/内に閉じ込める（親ディレクトリ・本番コード非修正）(2)タイムアウト付与（timeoutコマンド利用）(3)大規模・高リスク POC はタスクツールでサブエージェント委譲(4)実行前に Method を記入(5)長時間処理はバックグラウンド+ログ出力(6)後片付け確認。実験完了後、Result セクションに定量的・定性的結果を記載、Verdict を設定（untested/validated/invalidated/partial）、Key Findings に知見を記載します。Decision セクションで後処理を選択：採用→.tasks/plans/にタスク作成・Phase 3へ、見送り→docs/proposals/にアーカイブ、追加検証→新POC作成・Phase 2.5繰り返し。POCノードのフィールド：Status、Owner、Updated、Parent、Hypothesis、Background、Method、Playground、Result/Verdict、Key Findings、Decision、Blockers、NextAction。

Codex MCP ツールを gpt-5.3-codex モデルで呼び出し、推論深度を最大（xhigh）に設定して複雑なコード分析が実行できます Codex はディレクトリ内のファイルを自力で読み込めるため、ファイルパスを指示するだけで正確な情報収集が可能です コード全文をコピペしなくても、差分や特定箇所の指示で問題点や設計判断をインタラクティブに分析できます 突発的な実装の疑問やアクシデント対応を、会話を重ねながら詳細に掘り下げられます 設計判断に迷った際の根拠ある助言を、背景コンテキストを含めて得られます 実装中の複雑な問題を深く分析・デバッグしたい開発者 コードレビューを高い思考深度で実施したい技術リード 設計判断の妥当性を詳細に検討したい アーキテクト dev-flow に基づいた調査・レビュー を効率化したい開発チーム Codex MCP 呼び出し時は以下の必須パラメータを必ず適用：model: gpt-5.3-codex、config.reasoning_effort: xhigh、cwd: 作業ディレクトリ。codex-reply にはモデル指定パラメータがないため、最初の codex 呼び出し時に正しい設定を適用することが重要です。Codex は cwd で指定されたディレクトリ内のファイルを ls、cat、find で自力読み込みできるため、コード全文貼り付けは不要で、ファイルパスやコマンド実行指示だけで十分。ただし Codex は会話コンテキストを共有しないため、プロンプトに背景・経緯を含め、必要に応じて .tasks/plans/ パスも渡す必要があります。dev-flow における調査・レビュー、実装中の突発的疑問、設計判断の迷いなど、codex MCP を利用するあらゆる場面で適用します。

Markdown内の図やフローチャートを自動的にMermaid形式で作成し、GitHub・VS Codeで見やすく表示されるようにする フロー図、シーケンス図、クラス図など様々な種類の図を、構造化されたテキスト形式で管理できる ASCII アート（罫線文字で描いた図）をMermaid形式に置き換えて、メンテナンスしやすくする 図の追加・変更時に図の形が崩れる心配がなく、シンプルなルール（日本語ラベル、camelCase のノードID）で誰でも編集できる 開発フローやシステムアーキテクチャを図解ドキュメントに含める技術者・プロジェクトマネージャー 仕様書や設計書にプロセスフロー・データパイプラインの図を頻繁に追加する人 Markdownドキュメントの見栄えと保守性の両立を重視する開発チーム

.playground/ フォルダで新機能やライブラリを試験的に実装でき、gitに記録されないため本番コードに一切影響しない 小さなスクリプトや動作確認用コードを気軽に置いて、完成後に本体に統合できる POC（概念実証）、プロトタイプ、技術検証を専用の隔離環境で自由に実施でき、後から成果物を本リポジトリに移行できる チームメンバーの他の環境に影響せず、個人の実験環境として独立して使える 新しいライブラリやツールの動作を一度試してから採用判断したい開発者 検証コードやデバッグスクリプトを一時的に保管する場所が必要な人 技術的な不確実性を小さく検証してからメイン実装を始めたいエンジニア