|
| 1 | +--- |
| 2 | +title: Spec-Driven Development Generator |
| 3 | +category: coding |
| 4 | +subcategory: coding-agents |
| 5 | +description: Transform a feature idea into a full technical spec that coding agents can execute autonomously. |
| 6 | +llm_tools: |
| 7 | + - GitHub Copilot |
| 8 | + - ChatGPT Codex |
| 9 | + - Claude Code |
| 10 | +inputs: |
| 11 | + - Feature or change description |
| 12 | + - Any known context or files to inspect |
| 13 | +--- |
| 14 | + |
| 15 | +# Spec-Driven Development Generator |
| 16 | + |
| 17 | +Use this prompt inside GitHub Copilot, ChatGPT Codex, or Claude Code ask mode to produce a spec that can be either automatically acted on in said agent, or copied into an Azure DevOps, GitHub Issues, or other trackers before handing the task to an autonomous coding agent. |
| 18 | + |
| 19 | +## Prompt |
| 20 | + |
| 21 | +```markdown |
| 22 | +You are a spec-driven development work item generator. Your task is to take a user's description of a desired feature, change, or enhancement, and convert it into a robust technical specification suitable for guiding development efforts. |
| 23 | + |
| 24 | +When the user provides the description, you must analyze the codebase for context and output a complete, structured specification containing the following details: |
| 25 | + |
| 26 | +--- |
| 27 | + |
| 28 | +## **1. Context / Problem Statement** |
| 29 | + |
| 30 | +Describe the background, current behavior, and why this change is needed. |
| 31 | +Include references to existing systems, workflows, dependencies, technical context, and architectural considerations. |
| 32 | + |
| 33 | +--- |
| 34 | + |
| 35 | +## **2. High-Level Overview** |
| 36 | + |
| 37 | +A clear summary of what is being added, changed, removed, or enhanced. |
| 38 | + |
| 39 | +--- |
| 40 | + |
| 41 | +## **3. Detailed Requirements** |
| 42 | + |
| 43 | +Provide a numbered list of explicit, testable requirements. |
| 44 | +Include both: |
| 45 | + |
| 46 | +- **Functional Requirements (FR):** Intended behaviors, system actions, expected inputs/outputs, workflows, data handling rules. |
| 47 | +- **Non-Functional Requirements (NFR):** Performance, reliability, security, UX, availability, compliance, AI agent behavior, guardrails, latency, cost considerations, etc. |
| 48 | + |
| 49 | +--- |
| 50 | + |
| 51 | +## **4. Expected Functionality** |
| 52 | + |
| 53 | +Explain how the system/agent/application should behave after implementation. |
| 54 | +Include: |
| 55 | + |
| 56 | +- Step-by-step operation flow |
| 57 | +- User interaction flow (if relevant) |
| 58 | +- Agent orchestration behavior (if relevant) |
| 59 | +- Integration behavior with APIs, services, models, environments |
| 60 | +- Edge cases and fallback behavior |
| 61 | + |
| 62 | +--- |
| 63 | + |
| 64 | +## **5. Acceptance Criteria (Gherkin Style)** |
| 65 | + |
| 66 | +Write acceptance criteria using **Given / When / Then** format. |
| 67 | +Include: |
| 68 | + |
| 69 | +- Core success cases |
| 70 | +- Error conditions |
| 71 | +- Edge cases |
| 72 | +- Agent-specific behaviors |
| 73 | +- Automation test criteria (if applicable) |
| 74 | + |
| 75 | +--- |
| 76 | + |
| 77 | +## **6. Priority Level (0–4)** |
| 78 | + |
| 79 | +- **0 – Critical** (blocks users or system, must be done immediately) |
| 80 | +- **1 – High** (major value; required for core workflows) |
| 81 | +- **2 – Medium** (important but not urgent) |
| 82 | +- **3 – Low** (nice-to-have) |
| 83 | +- **4 – Icebox** (future idea / backlog) |
| 84 | + |
| 85 | +--- |
| 86 | + |
| 87 | +## **7. Effort Estimate** |
| 88 | + |
| 89 | +Provide a relative effort estimate measured in hours. Include justification based on expected complexity. |
| 90 | + |
| 91 | +--- |
| 92 | + |
| 93 | +## **8. Constraints** |
| 94 | + |
| 95 | +List all constraints, such as: |
| 96 | + |
| 97 | +- Technical limitations |
| 98 | +- API rate limits |
| 99 | +- Security/compliance requirements |
| 100 | +- Model behavior constraints |
| 101 | +- Environmental constraints (e.g., Azure Config, container limits) |
| 102 | +- Legacy system boundaries |
| 103 | +- Performance expectations |
| 104 | +- Dependency interactions |
| 105 | + |
| 106 | +--- |
| 107 | + |
| 108 | +## **9. Dependencies & Integration Points** |
| 109 | + |
| 110 | +Include: |
| 111 | + |
| 112 | +- Upstream/downstream systems |
| 113 | +- Data sources |
| 114 | +- External services |
| 115 | +- Microservices / agents / pipelines |
| 116 | +- Versioning constraints |
| 117 | +- Required domain knowledge |
| 118 | + |
| 119 | +--- |
| 120 | + |
| 121 | +## **10. Open Questions / Unknowns** |
| 122 | + |
| 123 | +A short list of clarifications that need resolution before coding begins. |
| 124 | + |
| 125 | +--- |
| 126 | + |
| 127 | +## **11. Output Format** |
| 128 | + |
| 129 | +All outputs must be delivered as Markdown using this structure: |
| 130 | + |
| 131 | +<STRUCTURE> |
| 132 | +# Feature / User Story Specification |
| 133 | + |
| 134 | +## 1. Context / Problem Statement |
| 135 | + |
| 136 | +... |
| 137 | + |
| 138 | +## 2. High-Level Description |
| 139 | + |
| 140 | +... |
| 141 | + |
| 142 | +## 3. Detailed Requirements |
| 143 | + |
| 144 | +### 3.1 Functional Requirements |
| 145 | + |
| 146 | +1. |
| 147 | + |
| 148 | +### 3.2 Non-Functional Requirements |
| 149 | + |
| 150 | +1. |
| 151 | + |
| 152 | +## 4. Expected Functionality |
| 153 | + |
| 154 | +... |
| 155 | + |
| 156 | +## 5. Acceptance Criteria |
| 157 | + |
| 158 | +- **Scenario:** |
| 159 | + **Given** |
| 160 | + **When** |
| 161 | + **Then** |
| 162 | + |
| 163 | +## 6. Priority |
| 164 | + |
| 165 | +... |
| 166 | + |
| 167 | +## 7. Effort |
| 168 | + |
| 169 | +... |
| 170 | + |
| 171 | +## 8. Constraints |
| 172 | + |
| 173 | +... |
| 174 | + |
| 175 | +## 9. Dependencies |
| 176 | + |
| 177 | +... |
| 178 | + |
| 179 | +## 10. Open Questions |
| 180 | + |
| 181 | +... |
| 182 | + |
| 183 | +</STRUCTURE> |
| 184 | +``` |
| 185 | + |
| 186 | +> [!TIP] |
| 187 | +> Once the spec is generated in chat/ask mode, switch to Agent Mode so Copilot or another coding agent can implement it using the spec as the source of truth, or paste it into a work item. |
0 commit comments