light-implement

実装

light-implement は、ユーザーが呼び出す、範囲を限定した実行ツールです。明示的な $light-implement のリクエストを受けた場合にのみ実行してください。準備が整った作業項目を 検証済みの成果物にし、レビューに引き渡します。

基本ループ

1. 作業項目を1つに絞ります。 チケット、Spec のセクション、または会話の明示的な範囲を 1つだけ選び、対象として記録します。トラッカーチケットの場合、ほかのファイルを変更する前に Status: claimed に設定します。
2. 関連するコンテキストを確認します。 docs/agents/light-project.md がある場合は、 トラッカー、ドメインコンテキスト、レビュープロファイルの各フィールドを読みます。その後、 項目に関係する用語集、ADR、ファイルだけに目を通し、参照元の場所を記録します。
3. 実質的に役立つ場合は、実行方法の選択肢を提示します。 明確に範囲が限定された単独作業では、 判断を挟まずに振り分けを省略します（WORKFLOW §3A）。それ以外の場合は、 light-decide（任意の機能）を使って、「振り分けは実質的に役立つか」 を「はい」または「いいえ」で判断します。モデルの適正化、推論の労力調整、より強力なレビューを伴う 実装の委任、または実行トポロジーが実質的に役立つ場合は、agent-config を呼び出すか、 直接進めるかをユーザーに提示します。ユーザーが振り分けを明示的にリクエストした場合は、 agent-config を直接呼び出します。ユーザーが振り分けを拒否または無効化した場合、 あるいは範囲が限定された単独作業の場合は、ブロックせずに直接進めます。 agent-config が戻ったら、WORKFLOW.md §3E の説明に従って、その readiness を確認します。NEED_PROJECT_TICKETS が返された場合は 必ず停止し、$project-tickets を推奨します。
4. 範囲を限定した作業を実行し、検証します。 適切な場合はコードに light-tdd を使用し、 コード以外の成果物はそれぞれの契約に従って作成します。ローカルで検証します （テスト、レンダリング、スキーマ、またはドメインチェック）。
5. 対応するレビュアーとともに review-loop に引き渡します。 コードには light-code-review、コード以外には generic-review またはドメインレビュアーを使用します。
6. 実装レポートを作成して停止します。 トラッカーチケットの場合は、チケットの ## Comments の下にレポートを追記します。記載する内容は、スコープ、確定した内容、検証結果、 review-loop が未解決のまま残した指摘事項、Plan gap: です （WORKFLOW.md §7）。 project-review は後のセッションでこのレポートを読みます。

任意の機能

• ステップ3で振り分けが実質的に役立つかを確認します。 明確に範囲が限定された単独作業ではなく、 ユーザーが振り分けをリクエストも拒否もしていない場合 → 質問 ID light-implement/offer-agent-config を指定して light-decide を呼び出します （はい／いいえ）。利用できない場合 → 自分で判断します。
• 計画の不一致（承認済みの SPEC、チケット、または受け入れ項目が現状に合わなくなっている状態）が どのステップでも見つかった場合 → チケットが未クレームならクレームし、作業項目を停止して、 Outcome: BLOCKED と不一致の内容を Plan gap: に記載したレポートを作成し、 チケットのパスを指定して light-redirect を呼び出します。ローカルでの修正が返された場合は 作業項目を続行します。次のレポートがこのレポートに優先します。 SPEC または会話の範囲の場合はクレームを省略し、返却するレポートをトリガーとして渡します。 利用できない場合、または拒否された場合 → 不一致をレポートして停止します。
• .scratch/<feature>/plan.html がある場合 → レポート作成後に light-html-plan を呼び出して 更新します。ページまたは機能がない場合 → 省略します。

構成

light-implement
   ↓
inspect bounded task
   ↓
would routing materially help?
   ├─ no  → execute directly
   └─ yes → offer agent-config
              ├─ accept  → agent-config → consume AgentConfigResult (READY / NEED_INPUT / NEED_PROJECT_TICKETS / BLOCKED / UNSUPPORTED)
              └─ decline → execute directly
   ↓
light-tdd when appropriate
   ↓
review-loop → light-code-review (code) / generic-review (non-code)

light-implement はこれらの機能を組み合わせるものであり、再実装するものではありません。 agent-config は任意の拡張機能です。これを使わない場合や、モデルのルーティング機能を持たないホストで実行する場合でも、実装は妨げられません。ルーティングの問題が任意の拡張機能だけに影響し、現在のセッションが能力と権限を備えていることを確認できており、ユーザーがそのルートを必須としていない場合は、セットアップについて追加で質問せず、範囲を限定した項目を直接続行し、フォールバックについて説明してください。 モデルの制限、設定プレビューの承認、必須の独立レビュー、またはユーザーが指定した実行方法を回避してはなりません。拒否が曖昧な場合やタスクの前提条件が不足している場合は、BLOCKED の引き継ぎギャップとして扱い、診断と、解除に必要な最小限の対応を呼び出し元に返してください。スキルの完了によって返されるのはこの項目のステータスです。より大きなリクエストが完了するわけでも、別の項目が許可されるわけでもありません。 成果物ごとの全手順については WORKFLOW.md を、例については EXAMPLES.md を参照してください。