القائمة
実装計画（Plan）ファイルを作成する。TDD・コミット分割・自動テスト一覧・工数見積もりを含む再現性の高い Plan を生成する。機能追加・バグ修正・リファクタリング等の実装計画策定時に使用。トリガー: 「Planを作って」「計画を立てて」「実装計画を」
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
PRレビューコメント対応ワークフロー（レビュー抽出→修正→CIチェック→コミット→サマリーまで一括実行）
A skill to break down ambiguous requests into small, immediately implementable requirement definitions through strategic questioning. Focus on WHY and WHAT, excluding HOW. This is used when ambiguous requests such as 'I want to add a feature like XX,' 'I want to fix XX,' or 'I did XX' are made outside of Plan Mode.
CodeRabbit CLIでコードレビューを受け取り、指摘に対応するスキル。コミット済み・未コミットの両方に対応。
Generic tmux-based API debugging workflow for cases like HTTP 4xx/5xx from an upstream provider, intermittent API failures, or when local reproduction is needed. Use when you need to run a backend in a tmux session, reproduce a request (including streaming), capture logs, iterate on minimal fixes, and shut down cleanly.
Github worktreを安全に作成するためのSkill。Github worktree作って、WT作って、などの指示で起動
Use when working on EgoPulse itself implementation, architecture, config, channels, tools, MCP, Web UI/API, storage, deployment, security, system prompts, sleep batch, or docs. Also use for requests about EgoPulse internals, "自分の体", "内部実装" or runtime behavior.
| name | implementation-plan |
| description | 実装計画（Plan）ファイルを作成する。TDD・コミット分割・自動テスト一覧・工数見積もりを含む再現性の高い Plan を生成する。機能追加・バグ修正・リファクタリング等の実装計画策定時に使用。トリガー: 「Planを作って」「計画を立てて」「実装計画を」 |
実装者がそのまま着手できる Plan を作成する。Plan は、What を守りながら How を固定しすぎず、TDD の短いフィードバックループで実装・検証・コミット・PR 作成まで進められる粒度にする。
t-wada が紹介・実践している TDD の核は、テスト件数のノルマではなく、実装前に不安をテストリストへ書き出し、そこから小さく 1 つ選んで Red → Green → Refactor を回すことにある。
Red では、次に確認したい振る舞いを失敗するテストとして表現する。Green では、そのテストを通すための最小実装に集中する。Refactor では、全テストが通る状態を保ったまま設計を整える。途中で新しい不安に気づいたら、その場で実装に混ぜず、テストリストへ戻して次のサイクルで扱う。
Plan 作成前に以下を確認する。足りない情報があれば、コードベース・docs・既存テストを先に調べる。調べても判断できない場合だけユーザーに確認する。
AGENTS.md、CLAUDE.md、docs 配下の関連仕様docs/plan/plan-<topic>.md に作成する。実装済みの Plan は docs/plan/archived/ に移動する。
Plan では、TDD Cycle の単位を明確にするために以下を区別する。
T1, T2 のような、まだコードではない振る舞い・不安のメモtest_name のようなテストコード各 TDD Cycle では、テストリストから次に扱う テストリスト項目を 1 つだけ 選ぶ。Red ではそれに対応する自動テストを 1 つだけ書き、Green と Refactor を終えてから次の項目へ進む。
ここでいう「1 つだけ」は、1 回の Red で扱う変更を小さく保つための制約であり、1 つのテストリスト項目に必要な自動テスト総数を 1 件へ制限するものではない。1 項目に複数の入力条件、状態遷移、境界値、失敗地点が含まれる場合は、同じ項目を複数の TDD Cycle に分け、各 Cycle で自動テストを 1 件ずつ追加する。
Plan に記載された自動テスト一覧を上限やノルマとして扱わず、実装中に新しい不安を発見した場合はテストリストへ追加し、必要な Cycle を続ける。テストリスト項目の完了は「予定したテストを 1 件通したこと」ではなく、その項目が表す振る舞いと主要な失敗境界への不安が解消されたことで判断する。
テストリスト / 不安リストは Plan 全体の設計メモではなく、TDD Cycle の元データである。
T1, T2 のように Plan 全体で一意にする対応するCycle を必ず持たせる今回対象外理由 を書く複数の独立した期待結果を Then に並べなければ表現できない項目や、複数のstatus・障害地点を一度に扱う項目は、そのまま自動テスト 1 件へ押し込めない。項目自体を分割するか、同じ項目に対応する Cycle を複数用意する。
観点漏れの確認だけに references/test-coverage.md を使う。この参照は、Red で大量のテストを書くためのものではない。
各 Cycle には以下を必ず含める。
Plan には以下をこの順序で含める。詳細な書式は assets/plan-template.md に従う。
Plan 完成前に以下を確認する。
WT作成 → 実装(TDD) → コミット(意味ごとに分離) → PR作成 が含まれているsleep 15m して pr-review-back-workflow Skill を実行する Step がある。レビューがまだ無い場合は sleep 5m して再実行し、最大 2 回まで追加待機するsleep 15m して pr-review-back-workflow Skill を実行する Step がある。レビューがまだ無い場合は sleep 5m して再実行し、最大 2 回まで追加待機するcargo fmt --check, cargo test, cargo check, cargo clippy --all-targets --all-features -- -D warnings が動作確認に含まれている