workflow-planning

name	workflow-planning
description	非自明なタスク（3ステップ以上、アーキテクチャ判断、複数ファイルにまたがる変更）に取り組む際の計画・実行・検証サイクル。タスクの開始時、実装がうまくいかず再計画が必要な時、バグ修正やリファクタリングの着手時にこのスキルを参照する。「計画を立てて」「TODO を整理して」「この機能を実装して」「バグを直して」といったリクエストや、明らかに複数ステップを要するタスクではこのスキルを使う。ただし、大規模な新機能開発（コードベース探索・アーキテクチャ設計・並列レビューが必要な重量級タスク）には feature-dev プラグイン（/feature-dev）の方が適切。
allowed-tools	Read, Write, Edit, Glob, Grep, Bash, TodoWrite

ワークフロー計画

計画フェーズ

タスクが以下のいずれかに該当する場合、実装前にプランモードに入る。

• 3ステップ以上の作業が見込まれる
• アーキテクチャや設計上の判断を伴う
• 複数ファイルにまたがる変更

計画は tasks/todo.md にチェックリスト形式で書く。

## [タスク名] - YYYY-MM-DD

- [ ] ステップ1: 具体的な作業内容
- [ ] ステップ2: 具体的な作業内容
- [ ] 検証: テスト実行・動作確認

計画を書いたら、実装開始前にユーザーへ共有して確認を取る。

実行フェーズ

• 各ステップ完了時に tasks/todo.md のチェックを更新し、何を変更したかの要約を添える
• うまくいかなくなったら即座に停止して再計画する。無理に突き進まない
• 実装中に当初の計画では不十分だと気づいたら、計画を修正してからユーザーに共有する

検証フェーズ

タスクを完了とする前に、必ず以下を行う。

1. リンター・フォーマッタを実行する（pnpm fix 等、プロジェクトの修正コマンド）
2. テストを実行して通ることを確認する
3. 変更に関連するログやエラー出力を確認する
4. 必要に応じて main ブランチとの挙動差分を確認する
5. tasks/todo.md にレビューセクションを追記する

検証なしにタスクを完了とマークしない。

自律性の境界

以下の場合は確認なしに自律的に進めてよい。

• 明確なバグ修正（ログ・エラー・テスト失敗を自分で特定し、修正する）
• CI の失敗テストの修正
• 計画で合意済みのステップの実行

以下の場合は実行前にユーザーへ確認する。

• 破壊的変更（API の変更、DB スキーマの変更など）
• アーキテクチャレベルの判断（新しいライブラリの導入、設計パターンの変更など）
• 計画にない作業の追加

エレガンスのチェック

非自明な変更では、提示する前に「もっと良い方法はないか」と立ち止まる。修正がハック的に感じたら、今知っていることすべてを踏まえてエレガントな解決策を検討する。

ただし、単純で明白な修正にはこのチェックをスキップする。過剰設計しない。