Spec-Driven Development (SDD)

概要

Spec-Driven Development（SDD）は、意図を捉え、それに基づいてエージェントの作業を進めるためのものです。現在、作業の実行に必要な背景情報は、Issue、コメント、デザインファイル、コード、そして人々の頭の中に分散しています。構造化された入力なしにワークアイテムに取り組むエージェントは、なぜ、どのように、何を行うかという情報が不足しているため、一貫性のない結果を生み出します。

SDD は、人が主導する作業と自律的な作業を支援します。 私たちの取り組みは、Software Factory を支援すると同時に、より幅広い顧客ニーズに応えます。多くのお客様は、実行の過程で人が意思決定を導くなど、人による相当な関与を必要としています。Software Factory は自律性を重視しており、Workplan とそれを支える機能は、その方向性にも対応できます。

準備状況のレベルは、実行に向けた準備の程度を示します。将来的には、しきい値を設けて実行の可否を判断し、トークンコストの管理に役立てられる可能性があります。意思決定ログは、ワークアイテムから実行に至るまでの、人と AI の決定を記録するように設計されています。

この設計ドキュメント全体で、次の用語を使用します。

• 仕様は、ワークアイテムの説明です。なぜ（動機）と何を（要件）を記載します。
• Workplan は、ワークアイテム上の独立したアーティファクトです。どのように（実装のアプローチ）を記載し、Duo Developer などの下流のエージェントが使用します。

私たちは、この機能のすべての部分を、エージェントと人の両方が使えるように構築します。SDD は、エージェントによって加速される、ドキュメント中心の開発方法です。

製品の背景情報については、親エピック、SDD の Wiki（GitLab チームメンバーのみ）、Workplan のユーザードキュメントを参照してください。

用語

エンドツーエンドのフロー

flowchart LR
    subgraph intent["Intent"]
        Chat[Duo Chat] -->|creates| WI[Work item]
        Backlog[Existing work item] --> WI
    end

    subgraph planning["Refinement and planning"]
        Flow["Async workplan flow (workplan/v1)"]
        Questions[Clarifying questions in discussions]
        WP[Workplan]
        Score[Readiness]
        DL[Decision log]
    end

    subgraph implementation["Implementation"]
        DD["Duo Developer (developer/v1)"] -->|opens| MR[Merge request]
    end

    WI -->|user selects Plan| Flow
    Flow -->|pauses and asks| Questions
    Questions -->|user selects Continue with eligible replies| Flow
    Questions -.->|record and resolve decisions when available| DL
    Flow -->|writes| WP
    Flow -->|scores after writing the plan| Score
    WP -->|user selects Implement| DD
    MR -->|linked in Development section| WI

1. ユーザーは Duo Chat で意図を示すことから始めるか、既存のワークアイテムを開きます。
2. ユーザーがワークアイテムで Plan を選択します。これにより、ワークアイテムの AI 計画が有効になり、バックグラウンドで非同期 Workplan フローが始まります。フローの実行中、ユーザーはページを離れられます。
3. フローは、ワークアイテムを詳細化し、プロジェクトを調査します。エージェントが判断すべきではない決定が必要な場合、フローはワークアイテムのディスカッションに明確化のための質問を投稿し、ユーザーに通知して一時停止します。説明が少なすぎて調査できない場合は、代わりにユーザーに説明の追加を求めます。
4. ユーザーは質問に回答してそのスレッドを解決するか、背景情報のリクエストを受けて説明を更新した後、Continue を選択します。質問間の移動機能では、スレッドの解決状況を使って未解決の質問を追跡します。再開サービスには、プロジェクトで Guest より上のロールを持つユーザーの返信のみを含めます。再開にスレッドの解決は必要ありません。背景情報のリクエスト後に再開すると、元の目標で調査をやり直します。
5. フローは Workplan を作成し、準備状況のスコアリングが利用可能な場合は、同じフロー内で準備状況を算出します。明確化のための質問は未解決の決定として記録され、意思決定ログが利用可能な場合、ワークアイテムの UI でそのスレッドを解決すると、それらの決定も解決されます。人の関与を参照してください。
6. ユーザーは Workplan をレビューし、Implement を選択します。Duo Developer は Workplan を主要な仕様として使用し、マージリクエストを作成します。マージリクエストは、ワークアイテムの Development セクションにリンクされます。

ワークストリーム

作業は、親エピックの下でワークストリームに分かれています。時期と現在の状況については、そのエピックと各ワークストリームのエピックを参照してください。

Duo Developer への引き渡しについては、下流の利用者で説明しています。

テストとフィードバック

WS-7は、フィードバック用の Issueを使い、ドッグフーディングでの発見を他のワークストリームの作業につなげます。現在のフォローアップには、実装の進捗の可視化、クローズされたワークアイテムでの動作、利用状況の指標が含まれます。

測定では、API を介した Workplan の読み取りと、保存済み Workplan の UI での表示を区別します。計画の保存は、バックエンドでの読み取りとして集計しなくなりました（マージリクエスト 257324）。また、保存済みの計画の表示は、別のイベントで追跡します（マージリクエスト 258352）。意思決定ログのパネル表示と決定の解決にも、専用のイベントがあります。意思決定ログを参照してください。

先送りされた設計

これらの設計は、現在のエピックには含まれません。背景情報として残しています。

制約

• リアルタイムの共同チャットはありません。ワークアイテムのコメントやスレッドを通じて非同期にコラボレーションします。
• Workplan は Issue とタスクで利用できます。
• 1 つのワークアイテムで同時に実行できる Workplan フローは 1 つだけです。
• そもそも複雑度の低い Issue を見つけるために工数を見積もるバックログのリファインメントループは、対象範囲外です。

決定

リンク

• 親エピック
• 以前の親エピック
• SDD の Wiki（GitLab チームメンバーのみ）
• SDD のフィーチャーフラグの概要：セットアップと展開の詳細（GitLab チームメンバーのみ）。
• Workplan のユーザードキュメント
• プロトタイプ
• 最新のウォークスルー
• 非同期のリファインメントと Workplan 生成のフィードバック用 Issue
• AI パネルのアーキテクチャ
• Duo Agent Platform のメモリ設計提案。メモリと背景情報の投入は、SDD ではなくこちらで設計します。
• ワークショップのメモ

ページのソースコードを見る - ページの編集 - please contribute.