feature-prompt

feature-prompt

次のステップに渡すために必要な最小限の情報を作成します。実装仕様ではありません。grill-with-field が計画を検討し、ドメイン用語を明確にし、GLOSSARY.md を更新します。ADR を提示するのは、重要な判断が必要な場合に限ります。

出力の契約

最終プロンプトは次の形式にします。

Project:
[Full Project Matrix code, repo, path, or context. Use one line.]

What is needed:
[The change to make. One short paragraph or 2-4 bullets.]

Why it is needed:
[The problem, user pain, business reason, or workflow gap — so grill-with-field
can challenge tradeoffs, not just wording — and what happens if nothing is
built.]

Expected end result:
[Observable done state. Prefer user-visible behavior, passing checks, or a
demo flow; seeds the later acceptance criteria. Name the empty, loading,
error, and recovery behavior, each role that sees it, and one thing that must
not happen.]

Known limits:
[Hard constraints, non-goals, compatibility needs, or exclusions
already known. When intake was split, list the deferred slices as explicit
non-goals. Always include the zero-attribution rule.]

Open questions:
[Conditional. Real unresolved questions for grill-with-field to attack.]

最初の5つのセクションは常に含めます。未解決の項目がない場合は、Open questions を省略します。

ルール

帰属情報は一切含めません。出力に共同作成者、AI、またはツールの帰属情報を追加したり、残したりしないでください。このルールをプロンプトの Known limits に含めます。

依頼の受け付けと推論

• 自由形式の依頼から始めます。まず推論し、What is needed が不明確な場合や、プロジェクト／コンテキストを安全に推測できない場合に限って質問します。
• 手間がかからない場合は、リポジトリ内の情報を使います。Project Matrix、cwd、GLOSSARY.md、GLOSSARY-MAP.md、ADR 名を確認します。デフォルトでは、広範なコードスキャンを実行しません。

スコープと分割

• 下書きの前に、霧テストを行います。今すぐ、目的地を1行で述べ、すべての未決事項を明確な質問として挙げられますか。できない場合は作業を止め、/wayfinder を提案します。/wayfinder は未決事項を整理し、1セッションにつき1つずつ解決します。見通しの悪い作業について、PR 規模のプロンプトを書いてはいけません。判定基準は規模ではなく、見通しの悪さです。決めることが何も残っていない大規模な機械的変更は、見通しが悪いとは言えません。
• デフォルトでは、個別にレビューしてマージできる程度に小さな、薄い垂直スライスを1つ作ります。依頼の範囲が広い場合は分割し、このプロンプトはスライス1のみを対象とします。先送りするスライスは Known limits に記録します。非常に長い検討セッションを強いるプロンプトになる場合は、確定前にスコープの分割を依頼します。ユーザーが不在の場合は、自分で分割し、回答の冒頭に分割内容を記載します。
• ユーザーがエージェントのスレッドを並行して進める意図を示している場合は、共有ファイルへの依存を最小限にするようスライスを分割します。

コンテキストと根拠

• Project Matrix が存在する場合は、そのコードを全文そのまま使います。プロジェクトコードを省略したり、略称を独自に作ったりしてはいけません。
• 既存のファイル／モジュール／接続点を参照します。「既存の接続点を再利用するか、新しい接続点を作るか」は、未解決の間のみ Open questions に記載します。解決済みの場合は、新しいセクションを設けず、該当する接続点を記載する契約セクションに、決定内容と根拠を記録します。検索して既存の接続点が見つからなかった場合は、検索した用語を明記します。
• 自明ではないコンテキストだけを含めます。制約、アーキテクチャ上の特性、リポジトリのスキャンだけではモデルが簡単に推測できないドメインルールが対象です。コードからすでに分かる技術スタックの情報は省きます。
• 依存関係の内部実装が重要で、かつ不明確な場合は、深く検討する前の追加コンテキスト取得として、対象を絞ったソースの取得（例：opensrc）を提案します。
• ドメイン用語はそのまま使います。候補となる定義は根拠に基づかせ、以下の承認フローに従います。未解決の定義は grill-with-field に委ねます。

質問と出力の規律

• Domain terms、Decisions、Dependents、Risks、Doc anchors、Integration、Constraints、Acceptance のセクションを作成してはいけません。有用な情報は6つの契約セクションに組み込みます。ユーザーが明示した重要な決定は Known limits に記載します。
• 不明確な決定はすべて Open questions に記載します。検討を進められない項目（「実際に見たり感じたりする必要がある」もの）もここに含め、深い検討を続ける前に /handoff + /prototype に案内します。
• Open questions には、最も重要な未確定事項だけを記載します（通常は1～5件）。実装中に決められる些細な点は省きます。
• 明確な質問に対する曖昧な回答（「できるだけ速く」「すべてのユーザー」など）は回答として扱いません。数値または対象セグメントを指定するよう一度だけ尋ねます。それでも曖昧な場合は、回答の文言のまま Open questions に保留します。
• 機能の実装、仕様の作成、ADR の編集は行いません。GLOSSARY.md の変更は、以下の承認済み候補用語フローを通す場合に限ります。
• 最終プロンプトは簡潔で、直接的な平易な英語にします。これは生成物であり、省略形を並べたメモではありません。

候補となるコンテキスト用語

リポジトリの証拠を簡単に確認した場合、またはユーザーが探索を依頼した場合に限り、GLOSSARY.md にない、または古くなっているドメイン用語を対象にします。これを埋めるためだけに、追加の探索を実行してはいけません。対象となる用語、提示方法、応答がない場合のフォールバック、承認の適用方法を含む共通フローは、references/context-terms.md に記載されています。プロンプトを確定する前に候補を提示し、承認された更新のみを適用して、保存前に編集したパスを報告してください。引き続き確認が必要な用語は Open questions に残します。

エージェントの使用

サブエージェント：独立した作業にはローカルのレーンを自動的に割り当てます。クラウドエージェントは使用しません。割り当て時にレーン数を伝え、各レーンの完了時に報告してください。レーンは、コンテキストをすばやく独立して確認するためだけのものです。ワーカーエージェントやコード編集は使用しません。

最終出力

1. 最終プロンプトのドラフトを作成します。
2. 複雑なプロンプトや推論を含むプロンプトの場合は、修正のために一度提示し、推論した事実（プロジェクト、スライスの境界、最終成果）とユーザーが述べた内容を別々に列挙します。ユーザーから返答がない場合は、ドラフトのまま保存し、未確認であることを先頭に記載します。
3. 候補となるコンテキスト用語が見つかった場合は、共通の承認フローを実行します。
4. 保存前チェックリストを確認して、以下のパスに保存します。その後、保存したファイルを再度開き、承認済みのドラフト（またはユーザーから返答がない場合は、未確認であることを明示したドラフト）とセクションおよびパスが一致することを確認してから、報告します。
5. 追加するのは以下のみです。

Context updated: <relative GLOSSARY.md path> [only if edited]
Saved to: <relative path written>
Next: pass this final prompt to the `grill-with-field` skill.
Suggested next skills (optional):

- /grill-with-field: challenge assumptions, sharpen domain terms, and confirm decisions.
- /handoff + /prototype: when open questions are ungrillable and need a higher-fidelity spike.
- /to-spec: if this needs a formal spec (PRD) after grilling.

ファイル出力

パス

<artifacts-root>/specs/prompts/NNNN-<feature-slug>-prompt.md

<artifacts-root> の解決方法：*.code-workspace ディレクトリが存在する場合はそのディレクトリ、そうでない場合はコンテキストごとのルート（リポジトリルートの GLOSSARY-MAP.md、またはレガシーの CONTEXT-MAP.md）、それもない場合はリポジトリルートです。

• NNNN — <artifacts-root>/specs/adr/ と specs/prompts/ を調べ、既存の4桁の番号のうち最大のものに1を加えます。これにより、プロンプトの作成時に使用済みの番号を避けられます。ADRには独立した番号系列があり、後でプロンプトの番号を再利用する場合があります。記録されたプロンプトのパスがリンクになります。
• <feature-slug> — What is needed をもとに、最大4語のASCIIケバブケースで作成します。
• -prompt — 成果物の種類を示す固定の接尾辞です。

競合への対応

• specs/prompts/ は必要になった時点で作成します。他の成果物が使用している番号を上書きしてはいけません。無関係なファイルを削除してはいけません。
• 同じスラッグの既存プロンプトは、このセッションで行ったものではないコミットや作業ツリーの変更がgitで確認された場合、手編集済みとして扱います。gitで判断できない場合（未追跡ファイル）は、手編集済みとみなします。
• このセッションで作成され、その後変更されていない同じスラッグのプロンプトは、同じファイルを更新します。手編集済みの場合は、差分を提示し、上書き、新しい番号の改訂版の作成、中止のいずれにするか尋ねます。ユーザーから返答がない場合は、新しい番号の改訂版を書き込み、未確認の手編集を上書きしてはいけません。

ファイル本文

最終プロンプトの本文だけを正確に記述します。前置きや自動生成のヘッダーは付けず、そのまま grill-with-field への入力として使える形式にします。

保存前チェックリスト

• 許可された6つのセクション見出しのみが、規定の順序で記載されている
• Project: に、Project Matrix のコード全体が（存在する場合は）そのまま記載されている
• 新規ファイルの場合、NNNN は specs/adr/ と specs/prompts/ 全体で一意である。既存ファイルを更新する場合は、その番号を維持する。スラッグは4語以下のASCIIケバブケースで、接尾辞は -prompt
• 分割して受け付けた内容：延期したスライスは Known limits に記録され、帰属ゼロのルールが含まれている
• プレースホルダーテキスト（TBD、TODO、[...]）が残っておらず、2つのセクションが矛盾していない
• ファイル本文はプロンプトのみで、そのまま入力として使える。前置きはない