Spec driven development
Skill Bosh-Kuo/awesome-agent-toolkit/skills/spec-driven-development
An "AI-Spec-Driven" workflow for complex tasks, triggered ONLY when explicitly requested. It aligns agent execution with rigorous planning (Spec -> Implementation -> Task Tracking) to mimic Antigravity planning mode.From its SKILL.md
npx -y skills add Bosh-Kuo/awesome-agent-toolkit --skill spec-driven-developmentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.6 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
Spec Driven Development
This skill implements an AI-Spec-Driven Development workflow that emulates "Antigravity Planning Mode". Ideally suited for complex, multi-step engineering tasks, it drastically reduces "hallucinated" solutions by forcing a structured "Think, Plan, then Act" lifecycle.
Trigger
IMPORTANT: This skill is ONLY triggered when the AI model is explicitly requested by the user (e.g., "Use spec-driven-development", "Activate planning mode", "Create a spec for this").
- Do NOT auto-trigger this skill for simple Q&A or minor bug fixes.
- It is designed for tasks requiring architectural thought, multiple file changes, or a defined implementation strategy.
Directory Structure
The workflow isolates its artifacts in a hidden directory to keep the workspace clean.
<PROJECT_ROOT>/
├── .spec-driven-development-tasks/ # Hidden directory for all tasks
│ ├── {YYYYMMDD}-{TASK_TITLE}/ # Specific task folder
│ │ ├── spec.md # "The WHAT": Requirements, Context, Scope
│ │ ├── implementation.md # "The HOW": Architecture, File Changes, Steps
│ │ ├── task.md # "The WHEN": Real-time checklist & logs
│ │ └── walk-through.md # "The SUMMARY": Verification Guide, Handover
│ └── ...
├── .gitignore # Excludes .spec-driven-development-tasks
└── ...
Workflow Diagram
graph TD
Start((Start)) -->|User Request| Phase1[1. Initialization Phase<br/>Run init_task.sh]
Phase1 -->|AUTO-PROCEED| Phase2[2. Research & Planning Phase<br/>Analyze, Scan Code, Draft Docs]
Phase2 --> Docs[Drafted Docs:<br/>spec.md, implementation.md, task.md]
Docs -->|STOP & REPORT| Review{User Review}
Review -->|2.1 Direct Execute| Phase3[3. Execution Phase<br/>Implement & Update task.md]
Review -->|2.2 Adjust & Execute| AdjustDirect[Adjust Docs]
AdjustDirect -->|AUTO-PROCEED| Phase3
Review -->|2.3 Adjust & Review| AdjustConfirm[Adjust Docs]
AdjustConfirm -->|STOP & REPORT| Review
Phase3 --> AllDone{All Tasks Done?}
AllDone -->|No: Continue Work| Phase3
AllDone -->|Yes: AUTO-PROCEED| Phase4[4. Completion Phase<br/>Write walk-through.md]
Phase4 -->|STOP & REPORT| End((Task Complete))
End -.->|New Requirements| Phase2
Workflow Phases
1. Initialization Phase
Input: The user's natural language request (e.g., "Help me refactor the authentication module"). The user does not provide a specific task title; the Agent must analyze the request to generate one.
Process:
- Generate a Task Title (e.g.,
refactor-auth-module). - Run Script: Call
skills/spec-driven-development/scripts/init_task.sh <TASK_TITLE>.- Ensures
.spec-driven-development-tasksexists and is added to.gitignore. - Note: The user must have "Gitignore Access" enabled for the AI tool to modify
.gitignoreand files within ignored directories. - Creates
{YYYYMMDD}-{TASK_TITLE}directory with 4 empty template files.
- Ensures
Output: A clean, isolated workspace for the task.
Transition: AUTO-PROCEED to Phase 2. Do not stop to report "Initialization Complete".
2. Deep Research & Planning Phase
Input: The initialized workspace and user requirements.
Process:
- Deep Research: Scan relevant code/docs to understand the current system (avoid blind full-repo scans).
- Draft Documentation: Fill the empty files using templates:
spec.md: Context, Requirements, Scope (fromtemplates/spec-template.md).implementation.md: Architecture, Implementation Steps (fromtemplates/implementation-template.md).task.md: TODO Checklist (fromtemplates/task-template.md).
Output: Drafted specification and planning documents.
Transition: STOP & REPORT. Present the plan to the user with exactly these 3 options:
- 2.1. Execute Immediately: User agrees -> Proceed to Phase 3.
- 2.2. Adjust & Execute: User gives minor feedback -> Update docs -> Proceed to Phase 3 (no second confirmation).
- 2.3. Adjust & Review: User gives major feedback -> Update docs -> STOP & REPORT (ask for confirmation again).
3. Execution Phase
Input: Approved spec.md, implementation.md, task.md.
Process:
- Execute: Write code according to
implementation.md. - Real-time Update: Mark items in
task.mdas[x]immediately upon completion. - Check Completion: Continue until all items in
task.mdare checked.
Output: Completed implementation and updated task.md.
Transition: AUTO-PROCEED to Phase 4 immediately after all tasks are done. Do not stop to ask "Ready for next phase?".
4. Completion & Archiving Phase
Input: Finished code and completed task.md.
Process:
- Summarize: Create
walk-through.mdusingtemplates/walk-through-template.md. - Iterative Requirement Handling:
- If user provides New Requirements after this phase:
- Return to Phase 2 (Option 2.2 Trigger) workflow.
- Retain old content in docs.
- Append new scope to docs.
- Resume at Phase 3.
Output: Final project summary.
Transition: STOP & REPORT. Inform the user the task is fully complete and present the walk-through.md.
What ships with it: 5 files
5.7 KB alongside SKILL.md, 1 of them executable
scripts/
- init_task.shruns1.5 KB
templates/
- implementation-template.md1.2 KB
- spec-template.md1.0 KB
- task-template.md879 B
- walk-through-template.md1.1 KB
Gives 0 of the 12 instructions most plan spec skills give in ~1.3k tokens
Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07
- Ask one question at a timein 51 of 1099
- Break plans into vertical slicesin 29 of 1099, across 11 files
- Publish issues in dependency orderin 27 of 1099, across 9 files
- Iterate until user approves the breakdownin 25 of 1099, across 7 files
- Explore the repository to understand the codebase statein 24 of 1099, across 7 files
- Use domain glossary vocabularyin 23 of 1099, across 5 files
- Apply correct triage labels to published issuesin 23 of 1099, across 5 files
- Prefer AFK slices over HITLin 22 of 1099, across 7 files
- Write a specification before writing any codein 22 of 1099, across 14 files
- Write failing tests before implementation codein 22 of 1099, across 20 files
- Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
- Respect existing architecture decision recordsin 20 of 1099, across 5 files
Said here and by no other author read
- generate a concise task title
- run the initialization script
- add the task directory to gitignore
- update task checklist items upon completion
- append new requirements to existing documents
- report immediately after initialization
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.