workflow-specify

ワークフローの仕様化

合意内容を、別のエージェントが実装できるチケットに落とし込み、計画の承認を得ます。アプリケーションコードやテストは作成しません。

兄弟ディレクトリ ../workflow/ から「Always」リストを含む共有ポリシーを読みます。見つからない場合は停止してください。インストール済みの別のコピーで代用してはいけません。

開始前に、次を確認してください。ルールがこのスコープを対象としていること（workflow/RULES.md）。チェックポイントの Agreement が合意済みであること、この改訂ではレガシー扱いまたは免除されていること、あるいは両方のゲートを同時に依頼するため、明確化の依頼でこの場の小規模な変更が確定していること（workflow/VISUAL-REVIEW.md）。それ以外の場合は workflow-clarify に進みます。計画を妨げる未決の選択肢がないこと。アプリケーション UI に ui-design モードがあり、その情報源が記録されていること（モードが未記録の場合、UI チケットのみが妨げられます）。このセッションでまだ読んでいない場合は ../ui-design/SKILL.md を読むこと。既存のスタイルでは合意済みのレイアウトを実現できない場合は、design.md のルール 4 の質問をしてください。新しい CSS を提案してはいけません。合意後に変更されたファイルについて、エビデンスを更新してください。

1. 振る舞いの配置

それぞれの振る舞いを、すでにそれを担当しているコードに配置します。インターフェースや境界が問題となる場合は ../codebase-design/SKILL.md を、用語や担当が不明な場合は ../domain-modeling/SKILL.md を読みます。新しいヘルパー、ラッパー、フォールバック、設定はすべて、workflow/AUDIT.md の必要性チェックを通過しなければなりません。実際のリスクに合ったガイダンスを、rule-maker の ENGINEERING.md から選びます。

2. 垂直方向のチケットに分割する

チケットは、必要なすべてのレイヤーを通じたユーザージャーニーの、目に見える一つの範囲を提供します。そのため、単独でテストおよびレビューできます。独自の振る舞いがないチケットは、何を可能にするかを明記した、ラベル付きの前提チケットです。

record.py を使って、workflow/TASK-FOLDER.md の形式（概要テーブル、ラベル付きチケット）で TODO を作成します。Supports、Depends on、Rules は References の下に、それ以外は Technical details の下に記載します。

• Supports：R-ID と A-ID。
• Scope：変更してよいファイルまたは領域と、変更してはならないもの。
• Depends on：先に検証する必要があるチケット。
• What should work：失敗も含め、人が観察できること。
• Test seam：テストが使用する公開インターフェース、検出できること、検出できないこと、およびそのギャップをどう補うか。
• TDD：yes、または no とその理由（ドキュメント、設定、テスト可能な境界がない）。
• How to verify：正確な確認方法とその出力フォルダー（workflow/ARTIFACTS.md）。人だけが実行できる手順（デバイス、アカウント、目視確認）は Human check: what, when（または needs human）と記し、まとめて依頼します。
• Docs and cleanup：更新するドキュメント、置き換えて削除するコード。
• Rules：プロジェクトのルール（チケットのパス上にある各 AGENTS.md または CLAUDE.md）で、変更が従わなければならないもの。ルールで禁止されている隣接コードのパターンは、前例にはなりません。第 2 ゲートで確認してください。

依存グラフに循環がなく、すべての要件と受け入れ項目にチケットがあり、各チケットがいずれかにたどれること、並列に進めるチケット間で同じファイルを共有していないことを完了条件とします。

3. より大きな範囲のチェックを明記する

依存チケットの各グループについてのチェックと、合意内容に照らした機能全体のチェックを列挙します。対象には、ほかの呼び出し元、互換性、失敗時のジャーニーを含めます。チェックできないこととその理由も記載します。テストランナーがなくても、ヘッドレスの Edge または Chrome のプローブページでクリック操作を実行できます（--dump-dom）。各チェックに必要なもの（サーバー、ポート、デバイス、アカウント）を明記し、第 2 ゲートで依頼してください。必要なチェックを納品時に黙って省略してはいけません。

4. 計画を精査する（大規模または高リスクの場合）

新しいコンテキストで plan-review を実行し、指摘事項を解決します。振る舞いに関する質問は workflow-clarify に戻します。ユーザーに見える内容や合意済みの要件（配置、文言、対象となる行）を変更する回答は、合意内容の変更にあたります。その項目について新しい改訂版の合意内容を作成し、第 2 ゲートと同じメッセージで承認を依頼してください。決定事項として記録するだけにしてはいけません。

5. 第2段階のゲート

各チケットを合意内容と1行ずつ照合します（動作、タイミング、データ、失敗、前提）。差異があれば、合意の変更として扱います（ステップ4）。workflow/VISUAL-REVIEW.md の「レポートの準備」の指示に従ってHTML計画を作成し、実装の承認を求めます。照合で差異が見つからなかった場合に限り、「合意した動作を実装します」と伝えます。停止してください。 回答を受け取るまでは、タスク記録とレポートのみを作成します。

このリビジョンのレポートが存在し、そのパスが承認を求める質問に記載されている（1行の変更も含む）、またはユーザーの明示的な「レポート不要」が記録されている場合に完了です。task_report.screen_change を設定します。ユーザーが画面上で確認できる変更（visible）には、レポートの画面図も必要です（ui-design のステップ3）。安全に開ける場合は現在の画面を取得し（ローカルページの場合は ../codebase-map/scripts/screenshot_report.py）、提案する画面をスケッチします。スケッチのみのプレビューは not-needed です。

回答はチェックポイントの Approval 行とDECISIONSに記録します。承認（リビジョン、レポート、チケット、除外事項）、修正（動作または範囲 → workflow-clarify、チケット、継ぎ目、表示 → ここ）、または対象を限定した免除を記録します。

リビジョン

後から変更する場合は、影響を受けるチケットとチェックのみを書き換え、直前に承認されたリビジョンとの差分を示します。その他の承認済みチケットは引き続き有効です。承認済みチケット内のパスまたは順序の修正にリビジョンは不要です。

次の手順

• 承認または免除され、実装が依頼されている場合：workflow-execute。
• 計画のみの依頼の場合：計画を提示して停止します。承認の有無は問いません。
• ブロックされている場合：どのチケットが何によってブロックされているか、また何を引き続き承認できるかを記録します。

ステージング、コミット、ブランチ作成、トラッカーの課題登録、公開は絶対に行わないでください。