| name | autonomous-dev |
| description | 方針合意後の実装を自律的に進め、テストを丁寧に書き、セルフレビューを徹底するスキル。
実装タスク全般で使うこと。機能追加、バグ修正、リファクタリング、テスト追加など、
コードを書く作業が発生したら必ずこのワークフローを通す。
「実装して」「作って」「追加して」「直して」「書いて」といった依頼はもちろん、
ユーザーが方針を決めて「進めて」「お任せ」「どんどんやって」と言った場合にも使う。
確認を挟まず自律的に完成まで持っていくためのワークフロー。
|
Autonomous Dev - 自律実装スキル
方針が固まったら、確認を挟まず一気に完成まで持っていく。品質はセルフレビューの反復で担保する。
ユーザーが方針に合意した後の逐次確認は、作業を中断させるだけで価値を生まない。代わりに、自分自身で何度もレビューと改善を回すことで、ユーザーの時間を奪わずに高い品質を実現する。
ワークフロー
Phase 1: 方針確認（ここだけユーザーと対話）
実装の方向性が不明確な場合のみ、ユーザーに確認する。
- 何を作るか / 何を直すか
- 設計上のトレードオフがある場合の判断
方針が明確なら（ユーザーが「進めて」と言っている、要件が自明、など）、この Phase はスキップして即座に Phase 2 に入る。
Phase 1 を抜けたら、以降はユーザーに確認を求めない。 完成するまで自律的に進める。
Phase 2: 全体像の把握
設計やUXの判断は、局所的なコードだけ見ていると的外れになる。実装に入る前に、変更が影響する範囲の全体像を掴む。
UI が絡む変更の場合
devtools（Chrome DevTools MCP）で関係する画面を渡り歩いて、現状のUIを把握する。
- 変更対象の画面をスクリーンショットで確認
- 関連する画面（遷移元・遷移先、同じコンポーネントを使っている画面）も確認
- 既存のレイアウト、間隔、色使いのパターンを目で見て理解する
コードだけ読んでも、実際の見た目やユーザーの操作感は分からない。画面を見ることで「ここに追加すると狭くなる」「この色は周囲と合わない」といった判断ができる。
UI が絡まない変更の場合
主要ユースケースを洗い出し、データの流れや呼び出し関係を把握する。
- 変更対象の関数・モジュールがどこから呼ばれているか
- 入力されるデータのバリエーション
- 必要に応じてストーリーテスト（ユースケース単位の統合テスト）を設計に組み込む
共通
- 既存の関連テストを読んで、どこまでカバーされているか把握する
- 変更の影響範囲を特定し、Phase 3 のテスト設計に反映する
Phase 3: テストを先に書く
実装コードより先にテストを書く。テストが実装の仕様書になる。
-
テスト設計 - 何をテストするか洗い出す
- 正常系: 主要なユースケース
- 境界値: エッジケース、空入力、最大値
- 異常系: エラーパス、不正入力
- 既存テストとの整合性を確認する
-
テスト実装 - 丁寧に書く
- テスト名は「何が」「どうなるべきか」を日本語で明確に
- 1テスト1アサーションの原則（複雑なケースは例外OK）
- テストデータは意図が分かるものを選ぶ（
"test" ではなく具体的な値）
- プロジェクトの
testing.md ルールに従う
-
テスト実行 - 全テストがFAIL（未実装なので）することを確認
Phase 4: 実装
テストを通すための最小限の実装を書く。
- プロジェクトのルールファイル（
error-handling.md, robustness.md, ts-pattern.md 等）に従う
- 実装したら
pnpm lint:fix && pnpm lint && pnpm test を実行
- テストが通らなければ、テストか実装を修正（テストの期待値が間違っている場合もある）
Phase 5: セルフレビュー（ここが核心）
実装が動いたら、ここから品質を磨き上げる。改善点が見つからなくなるまでレビューと修正を繰り返す。
各ラウンドで以下の観点をチェックし、問題を見つけたら即座に修正してから次のラウンドに進む。
レビュー観点
- 正しさ - ロジックに穴はないか。エッジケースを見落としていないか
- プロジェクト規約 - neverthrow, ts-pattern, Zod, デザイントークン等のルールに従っているか
- テストの十分さ - カバーすべきケースが漏れていないか。テスト自体が正しいか
- コードの意図 - WHY のコメントが必要な箇所に書かれているか（
code-intent-documentation.md）
- シンプルさ - 不要な抽象化、過剰なエラーハンドリング、YAGNI違反がないか
- 型安全性 - any/unknown の安易な使用、型アサーション（as）の濫用がないか
- 既存コードとの一貫性 - 周辺コードのスタイルやパターンと調和しているか
レビューの進め方
ラウンド N:
1. 変更した全ファイルを読み直す（差分ではなくファイル全体）
2. 上記7つの観点でチェック
3. 問題を発見 → 修正 → lint & test 実行
4. 修正があった → ラウンド N+1 へ
5. 修正がなかった → 最終確認へ
修正が発生しなくなるまで回す。目安は3ラウンド程度。1ラウンド目で粗い問題、2ラウンド目で細かい問題、3ラウンド目で確認、という流れになることが多い。
最終確認
レビューが収束したら、最後に一度だけ全体を通して確認する。
pnpm lint:fix && pnpm lint && pnpm test
全パスを確認してから Phase 6 に進む。
Phase 6: 報告
完了したら、ユーザーに簡潔に報告する。
報告に含めるもの:
- 何を実装したか（1-2行）
- セルフレビューで見つけて修正した主な問題（あれば）
- テスト結果
報告に含めないもの:
- 各ステップの詳細な経緯
- 「〜しました」の羅列
- 自明な情報の繰り返し
アンチパターン
| やりがち | なぜダメか | 代わりに |
|---|
| 実装の途中で「この方針でいいですか？」 | ユーザーの時間を奪う | 方針は Phase 1 で合意済み。迷ったら自分で判断 |
| セルフレビュー1回で完了 | 最初のレビューでは構造的な問題を見落としやすい | 目安3ラウンド、収束するまで回す |
| diff だけ見てレビュー | 文脈を見失い、周辺との不整合を見逃す | ファイル全体を読み直す |
| テストを後から書く | 実装に引きずられて甘いテストになる | テストを先に書く |
| 「完了しました」だけ報告 | ユーザーが変更内容を把握できない | 何を変えたかと、レビューで直した点を簡潔に |
