메뉴
research MDを元に詳細な実装計画（plan MD）をObsidian Vault（my-vault）に生成する。 「実装計画」「plan作成」「計画を書いて」「plan MD作成」「実装プラン」 「計画を立てて」「プランを作って」などのリクエストで使用。 機能実装・リファクタリング・バグ修正の計画を立てる場面で使用する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Gmailの受信トレイ定期メンテナンスを一括実行する。迷惑メール削除＋購入・ソーシャル・プロモーションタブの未読メールをまとめてアーカイブ＆既読化。「受信トレイ整理」「メール整理」「inbox整理」「メールクリーンアップ」「迷惑メールとプロモを片付けて」「ソーシャルとプロモまとめてアーカイブ」「定期メールメンテ」「cleanup-inbox-mail」「Gmail掃除」などのリクエストで必ず使用する。「何通溜まってる？」「どれくらい溜まってる？」のような整理前の件数確認の質問でも必ず使用する（この場合は件数報告のみ行い、実行はしない）。Gmailの一括クリーンアップを希望する場合のデフォルトスキル。複数カテゴリの整理を一度のリクエストでまとめて指示された場合（例: 「迷惑メール削除して、購入とソーシャルとプロモもアーカイブ」）も、個別にgmailスキルを呼び出すのではなくこのスキルを使う。特定カテゴリのみの言及（例:「迷惑メールとプロモを片付けて」）は、言及されたカテゴリのみを対象にする。
既存PRのdescriptionをコードの現状に合わせて更新する。 「PR説明文を更新」「descriptionを更新」「update-pr-description」「PR本文を直して」 「PRの説明文がコードと合ってない」「descriptionを最新にして」「PRのdescription更新して」 「PRの内容を最新にして」などのリクエストで使用。 PRのURLや番号が提示された場合にも、description更新の文脈であればこのスキルを使うこと。
既存スキルをSonnetなど小さいモデルで実行しても品質が下がらないように改善する。 静的分析→ba提案→承認後適用→Sonnet subagentでの改善前後A/B検証まで一気通貫で行う。 「Sonnet向けに改善」「Sonnet対応にして」「小さいモデルでも動くように」「Sonnet耐性」 「improve-skill-for-sonnet」「モデルを下げても品質が落ちないように」「Haiku/Sonnetで実行する予定のskillを改善」 などのリクエストで使用。skillの実行モデルを下位モデルに切り替える予定がある文脈でも必ず使用する。
Automate browser interactions, test web pages and work with Playwright tests.
コードベースを深く調査し、research MDをObsidian Vault（my-vault）に生成する。 「コードベースリサーチ」「codebase research」「深く調査して」「research MD作成」 「コードを調査してresearchにまとめて」「リサーチして」などのリクエストで使用。 既存コードの理解、実装前の調査、アーキテクチャの把握が必要な場面で使用する。
過去のレビュー指摘に基づくセルフチェックを行い、同じ誤りを未然に防ぐ。 「セルフレビュー」「セルフチェック」「self-review」「レビュー前にチェック」 「指摘されそうなところ確認」「フィードバックチェック」などのリクエストで使用。 実装完了後やPR作成前に、過去の指摘と同じパターンがないか確認したい場合に使用。
| 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/ |
以下を確認（不足時は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で検索する。
research MDが存在する場合、Readツールで読み込む。「要約」セクションを優先し、必要に応じて「詳細」も参照する。
research MDがない場合、コードベースを直接調査する（researching-codebaseスキルの使用を案内してもよい）。
research MDは「何が存在して、なぜそうなっているか」を提供するが、plan MDのタスクを具体的に書くには「何をどう変えるか」の詳細が必要になる。以下の観点で不足情報をAgentツールまたはReadツールで補完する。
| 調査観点 | 具体的に見ること | plan MDへの反映先 |
|---|---|---|
| 変更対象の現在の実装 | クラス構造、メソッドシグネチャ、既存コード | 各タスクのコードスニペット（before/afterが書ける精度で読む） |
| 関連テストの書き方 | テストファイルの構造、使用ヘルパー、ファクトリ | テストフェーズのタスク |
| プロジェクト固有の規約 | 対象ディレクトリの AGENTS.md、関連ADR | タスク全体（規約違反を防ぐ） |
| 類似の過去変更 | git log --oneline -10 -- <対象パス> | フェーズ分割、コミット粒度の参考 |
調査の深さの判断: research MDの「詳細」セクションに具体的なファイルパスとコード例が十分にあれば追加調査は最小限でよい。概要レベルにとどまっている場合は、変更対象ファイルを直接Readして正確なコードスニペットを書ける状態にする。
現在日時を date "+%Y-%m-%dT%H:%M" で取得し、Writeツールで以下のテンプレートに従って生成する。
ファイルパス: {my-vault}/065_dev/plan_{プロジェクト名}_{機能名}_{YYYY-MM-DD}.md
plan MDテンプレートの詳細は reference.md を参照。
生成したplan MDのパスを報告し、次のステップを案内:
ユーザーがObsidianでplan MDに注釈を追加し、「注釈を反映して」「計画を更新して」と指示した場合のフロー。Boris Tane式ワークフローの核心であり、計画の質を対話的に高めるために複数回繰り返されることがある。
ユーザーが指定したplan MD（指定がなければ Bash で ls -t {my-vault}/065_dev/plan_*.md | head -1 を実行し、mtime 降順で最新 1 ファイルを対象とする）をReadツールで読み込む。
以下の形式を注釈として認識する:
| 形式 | 例 | 用途 |
|---|---|---|
| Obsidianコメント | %%ここを変更してほしい%% | プレビューでは非表示の注釈 |
| callout | > [!note] フェーズ順序を変えたい | 目立つ注釈 |
| ハイライト | ==この部分は不要== | インラインの指摘 |
| テキスト直接編集 | ユーザーがタスク説明やコードを書き換え | 直接的な修正 |
注釈の有無が不明な場合は、前回生成したplan MDとの差分を確認して変更箇所を特定する。
注釈の内容が新しいコード変更を求めている場合（例: 「エラーハンドリングを追加して」「このAPIも対応して」）、Step 3 と同様にAgentツールまたはReadツールで不足情報を補完する。単純な構成変更（フェーズの入れ替え、タスクの分割・統合）は追加調査不要。
Editツールで以下を反映する:
%%...%%、callout、ハイライト）を除去updated_at を現在日時に更新status が draft の場合のみ reviewing に更新する。すでに reviewing 以降（approved、done）の場合は変更しない変更内容の要約を報告し、次のステップを案内:
status を approved に更新）| 基準 | 詳細 |
|---|---|
| タスクの粒度 | 1タスク = 1つの明確なコード変更。曖昧な「〜を改善」は禁止 |
| コードスニペット | 各タスクに具体的な変更内容のコードを含める（理由: 実装時の判断を最小化し「退屈な実装」を実現するため） |
| ファイルパス | 各タスクに変更対象ファイルのパスを明示（絶対パス・~/ 始まりのホームパス・プロジェクトルート相対パスいずれも可） |
| フェーズ順序 | 依存関係を考慮した実行順序。詳細は reference.md のフェーズ設計ガイドを参照 |
| テストフェーズ | 最終フェーズに必ずテスト作成・検証を含める |
| 変更ファイル一覧 | 冒頭で全体の影響範囲を俯瞰できるようにする |