workflow-clarify

ワークフローの明確化

依頼を、ユーザーが確認する動作合意に変換します。まずコードを読み、コードからは分からないことだけを質問します。チケットもコードも作成しません。

この SKILL.md と同じ場所にある ../workflow/ の共有ポリシーを読みます。見つからない場合は、作業を止めて、その旨を伝えます。別のスキルルートにある workflow のコピーは決して使わないでください。その SKILL.md の「Always」リストもここで適用されます（各ターンの最後に状態行を記載してください）。

開始前に、次を確認してください。ルールが READY であるか、記録済みの LIMITED_EXCEPTION がこのフェーズを制限内でカバーしていること（workflow/RULES.md）、タスクが特定され、チェックポイントに記録されていること（workflow/TASK-FOLDER.md）。または、ルーターがタスクの識別だけを未確定のまま残している場合は、「別のタスクですか、それとも修正ですか？」を最初の質問ラウンドの Q1 として尋ね、別のタスクなら新しいチャットで始めるのが最善だと伝えます。他の質問はどちらの回答でも成り立つようにし、TASK-FOLDER.md の「identity pending」行の指示に従ってラウンドを保存してください。この質問を承認に関する質問と一緒に尋ねてはいけません。また、依頼が説明のみ、または軽微な編集ではなく、実際の作業であることも確認してください。すでに合意でこの修正がカバーされている場合は、workflow-specify に進みます。アプリケーションの UI、つまりユーザーが画面上で目にするもの（順序、テキスト、表示される行や項目、レイアウト。スタイルだけではありません）に関わる場合は、まず ../ui-design/SKILL.md と ../rule-maker/rules/design.md を読み、その後で追跡します。提示する選択肢に新しい CSS を含めてはいけません。例外として一度だけ追加する場合も同様です。

1. ユーザーの行動経路を追跡する

行動経路とは、1 人のアクターが 1 つの結果を得るまでの流れです。トリガー → 手順 → アクターに見える内容。依頼が関わる各アクターについて、コードを追跡し、FINDINGS に記録してください（J-ID、E-ID）。

1. 所有者と呼び出し元：動作を管理するコード、そのコードに到達する他のすべての呼び出し元やエントリーポイント、読み込むデータと設定。どの行動経路でも説明できない呼び出し元は、質問事項です。
2. 失敗時の動作：不正な入力、権限不足、オフライン、依存先の障害やタイムアウト、キャンセル、再試行時にアクターに何が見えるか。
3. 互換性：保存データ、古い呼び出し元、公開インターフェース、バージョン。変更が既存の動作を拡張するのか、置き換えるのか。
4. 状態とタイミング：終了後やデバイス間で状態が保持されるか。今すぐ適用されるのか、次の操作時に適用されるのか。
5. 制限：許可される依存関係やコスト、対象環境、プライバシー、明示された対象外事項。
6. 画面（UI のみ）：新しい各要素、対応する既存の要素（file:line、タグ、クラス）、および python -X utf8 -I ../ui-design/scripts/class_rules.py <project-root> <classes> の出力内容。[needs context] ルールがある場合、または --compare <from-parent> <into-parent> でレイアウトの差異が示される場合は、一致していません。design.md ルール 4 の質問をしてください。

コードの読み方と根拠の記録方法については、workflow/GROUNDING.md を参照してください。

すべての行動経路について、所有者と呼び出し元を追跡するか、アクセスできない範囲を記録した時点で完了です。質問に必要な箇所を、質問する前に追跡してください。方向性の確認やアクセスを妨げる問題はすぐに尋ね、残りの追跡は続けてください。

2. 厳しく検討する

質問を書く前に、今すぐ ../grilling/SKILL.md を読み、ステップ 1 で見つかった内容に適用してください。これをせずに質問すると、判断チェックを省略することになります。

「Break it before stopping」の停止ルールを満たした時点で完了です。

3. 合意を書く

workflow/WRITING.md のルールに従い、workflow/scripts/record.py replace-section を使って PLAN に ## Agreement を作成します。

• 各要件（R-ID）と、その要件の出どころ。
• 失敗時を含む、各アクターの動作。
• 変更されない内容と対象外の内容。
• 観察可能な事柄として記述する受け入れ条件（A-ID）。
• ユーザーが拒否できる前提と、誰が決めるかを保留している選択肢。

動作と受け入れ条件を記述してください。チケット、実装ファイルの一覧、テストコマンドは workflow-specify まで作成しません。

4. 第 1 のゲート

合意内容を、各担当者に何が起こるか、何が変わらないか、何が対象外か、どの前提を拒否できるか、そして PLAN の進め方を含め、チャットでわかりやすく要約します。そのうえで、次のように尋ねます。

「これは構築すべき内容を表していますか？同意するか、変更したい点を教えてください。同意いただければ詳細な計画を作成します。その計画を承認いただくまで、コードは変更しません。」

停止してください。 質問への回答、沈黙、または一般的な「進めてください」は同意ではありません。ユーザーがまだ確認していない計画への承認を求めてはなりません。また、別のタスクや以前の改訂で使った近道を持ち込んではなりません。

未解決事項がなく、変更が小さい場合（workflow/VISUAL-REVIEW.md の「Both gates in one message」）、まだ何も尋ねず、今すぐ workflow-specify を呼び出してください。これはチケットと HTML レポートを作成し、両方のゲートについて一度に尋ねます。Clarify は計画の承認を求めません。後のセッションであっても、両方に明示的に「はい」と答えた場合は、両方の行を記録して workflow-execute に進みます。

回答をチェックポイントの Agreement 行に記録し、次のアクションを更新します。また、DECISIONS に、同意（改訂、日付）、部分的な同意（再開した項目は手順 2 に戻す）、拒否、または対象範囲を明記した明示的な免除を記録します。ゲートのルールについては workflow/VISUAL-REVIEW.md を参照してください。

次のステップ

• 同意済みまたは免除済み：workflow-specify。
• 調査：調査結果と未決定の選択肢を記録して終了します。計画のみの場合：workflow-specify まで進めてから終了します。コードの変更には実装の依頼も必要です。
• ブロック中：妨げとなっている質問や不足しているアクセス権と、引き続き進められる内容を記録します。

後から変更があった場合は、該当項目のみをここに戻します。それ以外の項目の合意は維持されます。