まずスペック。コードの前に、あなたが読む。

流れ：スペック、レビュー、プラン、レビュー、タスク、実装

大きなプロンプト1つとコードの山の代わりに、作業は文書を通って進み、次が書かれる前にそれぞれをあなたが確認します。

1. スペック：何を、なぜ

   機能が何をするべきか、誰のためか、何をしてはいけないか。ファイル名も、技術の選択もまだ入れません。

2. プラン：どうやって

   進め方。どの部分を、どんな順序で、どんなリスクとともに変えるか。プランはスペックに従います。

3. タスク：小さな手順

   エージェントが順にこなして消し込めるチェックリスト。1つ1つが確認できる小ささにします。

4. 実装

   エージェントがコードを書くのはここからです。すでに読んだ文書に沿って書きます。

短いスペックのテンプレート

スペックは長くなくて構いません。6つの見出しがあれば、ほとんどの食い違いを見つけられます。

# Feature name

## Goal
## Non-goals
## Users
## Requirements
## Edge cases
## Open questions

Non-goalsとOpen questionsは、人が省きがちで、エージェントが最も必要とするものです。作らないものと、まだ決まっていないことを伝えられたエージェントは、推測せずに質問します。

Claude Code、Codex、Cursorで行う

3つとも文書を書けて、計画の段階にはそれぞれプランモードがあります。Claude Codeのプランモード、Codexのプランモード、Cursorのプランモードです。

レビューを自動にするには、CLAUDE.mdかAGENTS.mdに1つルールを入れます。スペックやプランを書いたら、DotMDでrequest_reviewを使って送り、待つ、というルールです。エージェントは文書ごとに止まり、あなたのコメントか承認を待ちます。待っている間、トークンは使いません。DotMDがこのルールを追加することもできます。CLAUDE.mdとAGENTS.mdを参照してください。

規模が大きくなってもできるレビュー

チャットは、文書をレビューするのに向きません。代わりにDotMDで整形されたスペックを読み、間違っている箇所を選んで⌥⌘Mを押します。コメントは行に結び付くので、エージェントは何を指すのか正確に分かります。コメントを全部書いてから、一度に送れます。

エージェントが直したら、変更はすべてファイル上に、古い文は赤、新しい文は緑で、答えたコメントの隣に表示されます。1つずつAcceptするかReopenします。DotMDは、頼んでいない変更も一覧にします。変更のレビューを参照してください。

セカンドオピニオンには、先に別のエージェントにレビューさせます。Claude Codeが書いたスペックにCodexがコメントすれば、明らかな抜けにマークが付いた状態で手元に届き、書いたエージェントにどの指摘を渡すかはあなたが決めます。エージェントが別のエージェントをレビューする。

スペック駆動開発のツール

• リポジトリ内の素のMarkdown。docs/specsフォルダと上のテンプレートで、設定は完結します。
• プランモード。各エージェントが、実装の前に計画を立てるための仕組みです。
• GitHub Spec Kit。手順ごとのコマンドをエージェントに与え、spec.md、plan.md、tasks.mdを書かせるオープンソースのツールキット。GitHub Spec Kit。

どれを選んでも、文書はMarkdownファイルで、DotMDはどれでも読めます。

スペック駆動開発についての質問

その他の質問