grill-with-docs

grill-with-docs

計画、用語、重要な決定事項が作業に十分なほど明確になるまで、ユーザーに一度に1つずつ質問します。

ワークフロー

1. トピックを理解するために必要なユーザーの計画、リンクされたドキュメント、コード、またはローカルファイルを読みます。
2. 新しいドキュメントを提案する前に、既存の CONTEXT.md、CONTEXT-MAP.md、および docs/adr/ のファイルを確認します。
3. 焦点を絞った質問を一度に1つだけします。次に進む前に、回答を待ちます。
4. コードベースや既存のドキュメントから答えを見つけられる場合は、質問する代わりにそれらを調べます。
5. 各質問には、ユーザーが採用、却下、または調整できるように、おすすめの回答または考えられるトレードオフを含めます。
6. 曖昧な言葉、隠れた前提、エッジケース、決定間の依存関係、可逆性について掘り下げます。
7. 用語が決まったら、すぐに適切な CONTEXT.md を更新します。
8. ADR は、変更を元に戻すのが難しく、背景を知らないと意外に感じられ、実際のトレードオフに基づく決定に限って提案します。

ドキュメントのルール

• CONTEXT.md は、プロジェクト固有の用語と関係を整理したマップであり、仕様書や作業メモではありません。
• リポジトリに複数の境界づけられたコンテキストがある場合に限り、CONTEXT-MAP.md を使用します。
• ドキュメントは必要になってから作成します。実際に解決済みの内容がないうちは、CONTEXT.md や docs/adr/ を追加しないでください。
• 将来のエージェントが実際に読むよう、ドキュメントは簡潔に保ちます。

用語集の形式については、CONTEXT-FORMAT.md を参照してください。 ADR の形式と基準については、ADR-FORMAT.md を参照してください。

質問のパターン

• 「この変更が成功したと判断できる成果は何ですか？」
• 「この動作を担う既存の概念はどれですか？」
• 「設計が機能することを示す最小のシナリオは何ですか？」
• 「この前提が間違っていた場合、何が壊れますか？」
• 「将来のメンテナーが元に戻したくなりそうな点は何ですか？」
• 「正規の用語にする言葉と、避けるべき別名はどれですか？」