workflow

標準ワークフロー

1. 問題について検討し、関連ファイルを読み、[timestamp] が YYYYMMDDThhmmss 形式、[feature-name] がケバブケースとなる specs/[timestamp]-[feature-name].md に計画を記述します。
2. 最初の画面を有用なものにします。ステータス、担当者、一文での説明、現在の形、目標の形、根拠を含めます。
3. 作業の進捗に合わせてチェックできる、実装タスクのチェックリストを含めます。
4. 小さなチェックポイントに分けて、自律的に実行します。計画に複数のプロダクト上またはアーキテクチャ上の選択肢がある場合、要件が未解決の場合、破壊的な操作がある場合、またはスコープが広くなるリスクがある場合にのみ、ユーザーからの入力を待ちます。
5. 複数の妥当なアプローチがある、3つ以上のファイルに関わる、またはアーキテクチャを変更するなど、重要な変更では、実装前に変更前後の差分と ASCII 図を添えて、複数の選択肢を提示します。change-proposal を参照してください。
6. 作業を進めながらチェックリストの項目を完了済みにし、進捗メモは「変更点」「検証済みの内容」「残作業」「ブロッカー」を高いレベルで記載します。
7. すべてのタスクとコード変更を、可能な限り小さく保ちます。無関係な整理や広範なリファクタリングは避けます。
8. 最終的な引き継ぎの前に、変更したファイルを対象に post-implementation-review を実行します。古くなった抽象化、使われていない処理、不変条件のずれ、命名の問題、検証漏れを見つけるために活用します。
9. 変更の概要、レビューでの指摘事項、検証、関連するフォローアップ作業をまとめたレビューセクションを仕様書に追加します。

このスキルを適用する場面

次のような場合に、このパターンを使用します。

• specs/ にタイムスタンプ付きの計画仕様書を作成して、重要な機能に着手する。
• コードを書く前に、チェックリスト形式の実装計画を作成する。
• 明確な最初の画面と視覚的な流れを備え、メンテナーの時間を尊重する仕様書を作成する。
• 小さく単純なチェックポイントに分けて作業し、進捗を高いレベルで共有する。
• プロダクト上またはアーキテクチャ上の選択肢が未解決の場合、破壊的な操作がある場合、またはスコープが広くなるリスクがある場合にのみ、作業を一時停止する。
• 作業を引き渡す前に、実装後レビューを実施する。
• 仕様書にレビューの概要を追加して作業を締めくくる。

仕様書の配置場所

すべての仕様書はルートの /specs/ ディレクトリに配置します。apps/ や packages/ の下に、入れ子の仕様書を作成しないでください。

トピックに見合う場合は、長い仕様書でもかまいません。行数を理由に分割しないでください。1つのファイルに、アーキテクチャの指針、過去の議論、実装ログ、引き継ぎ用プロンプト、現在の実行経路など、異なる読者の目的が混在している場合に限り、分割する、作業中の範囲を追加する、または実行用の補助仕様書を作成します。

プロンプトや引き継ぎ用の成果物は、.prompt.md、.handoff.md、.execute.md のような明示的なサフィックスを付けて、仕様書と同じ場所に置くことができます。これらは正規の仕様書へのリンクを含める必要があり、サフィックスがそう示していない限り、現在の実装計画として扱わないでください。