plan-implementation

name	plan-implementation
description	research MDを元に詳細な実装計画（plan MD）をObsidian Vault（my-vault）に生成する。 「実装計画」「plan作成」「計画を書いて」「plan MD作成」「実装プラン」 「計画を立てて」「プランを作って」などのリクエストで使用。 機能実装・リファクタリング・バグ修正の計画を立てる場面で使用する。

実装計画作成

research MDを元に詳細な実装計画をObsidian Vault（my-vault）の 065_dev/ にplan MDとして保存する。Boris Tane式ワークフロー（リサーチ → 計画 → 注釈サイクル → 実装）の計画フェーズを担う。

生成されるplan MDは、Claude Codeが「このplan MDに沿って実装して」と指示されたときに機械的に消化できる構造になっている。

定数

定数	値
my-vaultパス	~/ghq/github.com/shifumin/my-vault
出力先	{my-vault}/065_dev/

処理フロー

1. 入力の確認とモード判定

以下を確認（不足時はAskUserQuestionで質問）:

項目	必須	例
実装する機能・要件	必須（新規時）	「通知システムのリファクタ」
プロジェクト名	必須（cwdから推定可）	hanica
research MDのパス	任意	065_dev/2026-03-05_hanica_research_通知システム.md
既存plan MDのパス	任意（更新時）	065_dev/plan_hanica_xxx_2026-03-06.md

モード判定: 「注釈を反映して」「計画を更新して」など既存plan MDの更新を求められた場合は Step 6（注釈の反映） に進む。新規作成の場合は Step 2 に進む。

research MDが指定されない場合、065_dev/ から該当プロジェクトの最新research MDをGlobで検索する。

2. research MDの読み込み

research MDが存在する場合、Readツールで読み込む。「要約」セクションを優先し、必要に応じて「詳細」も参照する。

research MDがない場合、コードベースを直接調査する（researching-codebaseスキルの使用を案内してもよい）。

3. コードベースの追加調査

research MDは「何が存在して、なぜそうなっているか」を提供するが、plan MDのタスクを具体的に書くには「何をどう変えるか」の詳細が必要になる。以下の観点で不足情報をAgentツールまたはReadツールで補完する。

調査観点	具体的に見ること	plan MDへの反映先
変更対象の現在の実装	クラス構造、メソッドシグネチャ、既存コード	各タスクのコードスニペット（before/afterが書ける精度で読む）
関連テストの書き方	テストファイルの構造、使用ヘルパー、ファクトリ	テストフェーズのタスク
プロジェクト固有の規約	対象ディレクトリの AGENTS.md、関連ADR	タスク全体（規約違反を防ぐ）
類似の過去変更	git log --oneline -10 -- <対象パス>	フェーズ分割、コミット粒度の参考

調査の深さの判断: research MDの「詳細」セクションに具体的なファイルパスとコード例が十分にあれば追加調査は最小限でよい。概要レベルにとどまっている場合は、変更対象ファイルを直接Readして正確なコードスニペットを書ける状態にする。

4. plan MDの生成

現在日時を date "+%Y-%m-%dT%H:%M" で取得し、Writeツールで以下のテンプレートに従って生成する。

ファイルパス: {my-vault}/065_dev/plan_{プロジェクト名}_{機能名}_{YYYY-MM-DD}.md

plan MDテンプレートの詳細は reference.md を参照。

5. 完了報告

生成したplan MDのパスを報告し、次のステップを案内:

• ユーザーがObsidianでplan MDを開いてレビュー
• 注釈（inline notes）を追加
• 「注釈を反映して計画を更新して。実装はしないで」と指示
• 満足したら「このplan MDに沿って実装して」と指示

6. 注釈の反映（注釈サイクル）

ユーザーがObsidianでplan MDに注釈を追加し、「注釈を反映して」「計画を更新して」と指示した場合のフロー。Boris Tane式ワークフローの核心であり、計画の質を対話的に高めるために複数回繰り返されることがある。

6a. 注釈付きplan MDの読み込み

ユーザーが指定したplan MD（指定がなければ Bash で ls -t {my-vault}/065_dev/plan_*.md | head -1 を実行し、mtime 降順で最新 1 ファイルを対象とする）をReadツールで読み込む。

6b. 注釈の特定

以下の形式を注釈として認識する:

形式	例	用途
Obsidianコメント	%%ここを変更してほしい%%	プレビューでは非表示の注釈
callout	> [!note] フェーズ順序を変えたい	目立つ注釈
ハイライト	==この部分は不要==	インラインの指摘
テキスト直接編集	ユーザーがタスク説明やコードを書き換え	直接的な修正

注釈の有無が不明な場合は、前回生成したplan MDとの差分を確認して変更箇所を特定する。

6c. 追加調査（必要に応じて）

注釈の内容が新しいコード変更を求めている場合（例: 「エラーハンドリングを追加して」「このAPIも対応して」）、Step 3 と同様にAgentツールまたはReadツールで不足情報を補完する。単純な構成変更（フェーズの入れ替え、タスクの分割・統合）は追加調査不要。

6d. plan MDの更新

Editツールで以下を反映する:

• 注釈に基づくタスク・フェーズの修正（追加・削除・変更・順序入れ替え）
• コードスニペットの更新（追加調査で得た情報を反映）
• 変更ファイル一覧の更新（タスク変更に伴う影響範囲の変動）
• 処理済みの注釈（%%...%%、callout、ハイライト）を除去
• updated_at を現在日時に更新
• status が draft の場合のみ reviewing に更新する。すでに reviewing 以降（approved、done）の場合は変更しない

6e. 更新報告

変更内容の要約を報告し、次のステップを案内:

• 追加の注釈がある場合 → 再度 Step 6 を繰り返す
• 計画に満足した場合 → 「承認する」と伝えてもらう（status を approved に更新）
• 実装に進む場合 → 「このplan MDに沿って実装して」と指示

plan MDの品質基準

基準	詳細
タスクの粒度	1タスク = 1つの明確なコード変更。曖昧な「〜を改善」は禁止
コードスニペット	各タスクに具体的な変更内容のコードを含める（理由: 実装時の判断を最小化し「退屈な実装」を実現するため）
ファイルパス	各タスクに変更対象ファイルのパスを明示（絶対パス・~/ 始まりのホームパス・プロジェクトルート相対パスいずれも可）
フェーズ順序	依存関係を考慮した実行順序。詳細は reference.md のフェーズ設計ガイドを参照
テストフェーズ	最終フェーズに必ずテスト作成・検証を含める
変更ファイル一覧	冒頭で全体の影響範囲を俯瞰できるようにする