agentsclimarketplace

Spec driven development

Skill Bosh-Kuo/awesome-agent-toolkit/examples/.claude/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

Install
npx -y skills add Bosh-Kuo/awesome-agent-toolkit --skill spec-driven-development

Assembled 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:

  1. Generate a Task Title (e.g., refactor-auth-module).
  2. Run Script: Call skills/spec-driven-development/scripts/init_task.sh <TASK_TITLE>.
    • Ensures .spec-driven-development-tasks exists and is added to .gitignore.
    • Note: The user must have "Gitignore Access" enabled for the AI tool to modify .gitignore and files within ignored directories.
    • Creates {YYYYMMDD}-{TASK_TITLE} directory with 4 empty template files.

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:

  1. Deep Research: Scan relevant code/docs to understand the current system (avoid blind full-repo scans).
  2. Draft Documentation: Fill the empty files using templates:
    • spec.md: Context, Requirements, Scope (from templates/spec-template.md).
    • implementation.md: Architecture, Implementation Steps (from templates/implementation-template.md).
    • task.md: TODO Checklist (from templates/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:

  1. Execute: Write code according to implementation.md.
  2. Real-time Update: Mark items in task.md as [x] immediately upon completion.
  3. Check Completion: Continue until all items in task.md are 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:

  1. Summarize: Create walk-through.md using templates/walk-through-template.md.
  2. 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/

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.

Keep looking

Skills are one crate of 326,851. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.