lets-build

一緒に作りましょう

作業を行うのはエージェントです。ユーザーは要件を明確にし、設計を確認します。

イシューは出発点であり、絶対的なものではありません。

使用する場合

• ユーザーが「一緒に作ろう」と言う場合、またはイシューやタスクの説明に基づいて作るよう依頼する場合に使用します。

ユーザーが、独自に判断して単独で作るよう明示的に依頼した場合は、このスキルを使用しないでください。

ワークフロー

次の順序で進めます。コードの作成に先走らないでください。

1. イシューと関連作業を確認する

記述されたイシューまたはタスクを特定します。ユーザーが ID、URL、ファイルパス、または貼り付けたテキストを指定する場合があります。

• 対象がどれかわからない場合は質問します。推測しないでください。
• イシューを最後まで読みます。
• ほかにオープンなイシューがあれば一覧表示するか概要を確認し、関連するイシューを読みます。

目的は、背景、順序、競合の把握です。それらを根拠にスコープを広げないでください。

2. コードを確認する

コードを読んで、現在のシステムの動作を把握します。

イシューとコードの内容が食い違う場合は、現在の事実についてはコードを優先します。重要な不一致はユーザーに伝えます。

問題に対する独自の理解と、妥当な解決策の方向性を考えます。イシューに記載された計画を無批判に採用しないでください。

3. 要件を明確にする

設計に進めるだけの明確さが得られるまで、/grilling スキルを使用します。

• この段階では要件の確認に専念します。設計上の選択肢はステップ 4 で扱います。
• この段階では実装しないでください。

4. 設計の認識を合わせる

単に自由回答を求めるのではなく、選択肢とトレードオフを提示して追加の質問をします。

解決策で判断が必要となる重要な設計上の決定事項を指摘します。それぞれについて、重要なものは少数の選択肢と推奨案を示し、ユーザーの返答を待ちます。

ユーザーの回答はイシューより優先されます。決定が下されたら、必要に応じてイシューを更新し（コメントまたは本文）、新しい情報を反映します。

5. 計画を提案する

十分な背景を得て、自信を持って解決策の概要を示せるようになったら、簡潔な計画を提案します。 アプローチ、主な作業項目、完了の判断方法、未確定の前提を含めます。

完了の判断方法：重要な動作ごとに、次の内容を示します。

• 成功または失敗を確認できるチェック項目
• 結果を示す証拠（テスト、コマンドとその出力、スクリーンショット、測定値など）
• 例として挙げるべきエッジケース

「動作すること」はチェック項目になりません。エージェントが質問せずに検証できるチェック項目を提案します。

重要な UI 変更には必ず人によるレビューが必要です。その点を認め、計画に含めます。

6. 構築する

確認を得てから、合意した計画を実装します。問題を解決するために必要な最小限の変更にとどめます。 次に進む前に完了チェックを実行し、その結果とともに証拠をユーザーに提示します。

実装中に新たな設計上の選択が生じた場合は、作業を止めて質問します。黙って判断しないでください。

7. 振り返る

実装後に reflect スキルを読み込み、適用します。簡単に済ませず、十分に検討してください。現在振り返りを行っていることをユーザーに伝えるメッセージを送ります。 このスキルを読み込むのは実装後に限ります。

作業が当初のイシューの記述から逸れた場合は、イシューを更新します。

ガイドライン

現在のシステムの動作についてはコードが基準です。システムがどう動作すべきかについてはユーザーが基準です。イシューは出発点であり、絶対的なものではありません。

情報や決定事項が変わったらイシューを更新し、古い情報を残さないでください。