New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Spec Driven Implementation

by warpdotdev in warpdotdev/common-skills

Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves.

MITAuto-check passedDevelopment

Install Spec Driven Implementation

skills CLI
$ npx skills add warpdotdev/common-skills --skill spec-driven-implementation -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install warpdotdev/common-skills spec-driven-implementation --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/warpdotdev/common-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/spec-driven-implementation .claude/skills/spec-driven-implementation && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
spec-driven-implementation
GitHub stars
606
Used in
1 other repo
Token cost
~1.5k tokens
SKILL.md length
791 words
Files
1
Skills in repo
28
Repo updated
First seen
Licence
MIT

At a glance

Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves.

  • Works in 6 steps: Decide whether the feature needs specs → Write the product spec first → Write the tech spec when warranted → …
  • Starting a significant feature
  • SKILL.md covers Overview, When specs are required, Workflow and Best Practices, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Spec Driven Implementation is an agent skill from warpdotdev/common-skills. Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.

Its SKILL.md is about 1.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Spec-driven development. The licence is MIT.

When your agent uses it

  • Starting a significant feature
  • Planning agent-driven implementation
  • The user wants product and tech specs checked into source control

Example prompts

  • “/spec-driven-implementation”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Decide whether the feature needs specs
  2. Write the product spec first
  3. Write the tech spec when warranted
  4. Implement approved specs
  5. Keep specs current during implementation
  6. Verify behavior against the spec

What it can do on your machine

Read from SKILL.md and the folder at commit 69b4753. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Spec Driven Implementation loads about 1.5k tokens when it runs. Until then it costs about 92 tokens; SKILL.md has 791 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~92
When it runs · the whole SKILL.md, loaded when a task matches
~1.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from warpdotdev/common-skills at commit 69b4753, republished under its MIT licence (© warpdotdev). 791 words, ~1,521 tokens.

Download SKILL.mdSave it as .claude/skills/spec-driven-implementation/SKILL.md (or your agent's skills folder).
name
spec-driven-implementation
description
Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves. Use when starting a significant feature, planning agent-driven implementation, or when the user wants product and tech specs checked into source control.

spec-driven-implementation

Drive a spec-first workflow for substantial features in Warp.

Overview

Use this skill for significant features where a written spec will improve implementation quality, reduce ambiguity, or make review easier. Be pragmatic: not every change needs specs.

Specs should usually live in:

  • specs/<linear-ticket-number>/PRODUCT.md
  • specs/<linear-ticket-number>/TECH.md

For example:

  • specs/APP-1234/PRODUCT.md
  • specs/APP-1234/TECH.md

specs/ should contain only ticket-named directories as direct children. Do not create engineer-named subdirectories or feature-slug directories there.

If a relevant Linear issue does not already exist, create one before writing specs. Use the Linear MCP tools directly:

  • list_teams to find the appropriate team
  • list_issue_labels to inspect the expected labels/tags
  • save_issue to create the issue with the appropriate team and labels

If the correct team or labels are not obvious from the request and surrounding context, use ask_user_question to clarify rather than guessing.

These specs should largely be written by agents, not by hand, and should be checked into source control so they can be reviewed and kept current with the code.

When specs are required

Strongly prefer specs when the change is substantial, such as:

  • product or architectural ambiguity
  • expected implementation size around 1k+ LOC
  • deep or cross-cutting stack changes
  • risky behavior changes where regressions would be expensive
  • work where agent quality will improve materially from clearer inputs

Specs are often unnecessary for:

  • small, local bug fixes
  • straightforward refactors
  • narrow UI tweaks with little ambiguity

For pure UI changes, the product spec is often useful while the tech spec may be unnecessary.

Workflow

1. Decide whether the feature needs specs

Evaluate the size, ambiguity, and risk of the feature. If specs will not meaningfully improve execution or review, skip them and focus on verification instead.

2. Write the product spec first

Before implementation, create PRODUCT.md describing the desired user-facing behavior.

Use the write-product-spec skill to produce it. The product spec should define:

  • what problem is being solved
  • the desired user experience
  • invariants and edge cases
  • success criteria
  • how the behavior will be validated

If the feature has UI or interaction design, ask for a Figma mock if one exists. If there is no mock, continue but call that out explicitly in the product spec.

Reference the Linear issue in the spec when one exists. Because specs live under specs/<linear-ticket-number>/..., this should usually be straightforward.

3. Write the tech spec when warranted

Use the write-tech-spec skill for substantial or ambiguous implementation work.

Prefer a tech spec when:

  • the implementation spans multiple subsystems
  • architecture or extensibility matters
  • there are meaningful tradeoffs to document
  • reviewers will benefit more from reviewing the plan than the raw code

It is acceptable to write the tech spec after an e2e prototype if that leads to a more accurate implementation plan. Do not force a premature tech spec when the implementation details are still too uncertain.

Show full SKILL.md (332 more words)Show less
4. Implement approved specs

After the specs are approved, use the implement-specs skill to build from the approved PRODUCT.md and TECH.md.

The implementation can often be pushed in the same PR as the product and tech specs. As the engineer iterates, keep PRODUCT.md, TECH.md, code changes, and tests in that same PR so the review reflects the feature that will actually ship.

For large features, the implementer may optionally offer:

  • PROJECT_LOG.md to track explored paths, checkpoints, and current implementation state
  • DECISIONS.md to capture concrete product and technical decisions made during design and implementation

These are optional aids, not required outputs.

5. Keep specs current during implementation

If implementation changes from the spec, update the spec rather than leaving it stale.

Update PRODUCT.md when:

  • user-facing behavior changes
  • success criteria change
  • UX details or edge cases change

Update TECH.md when:

  • the implementation approach changes
  • architectural boundaries move
  • risks, dependencies, or rollout details change
  • the testing or validation plan changes

The checked-in specs should describe the feature that actually ships, not just the initial intent. Keep those spec updates in the same PR as the related code changes whenever practical.

6. Verify behavior against the spec

Before considering the work complete, make sure verification maps back to the specs. Prefer tests and artifacts that validate the product behavior directly:

  • unit tests and regression coverage that follow the repository's local testing conventions
  • integration tests for critical user flows
  • loom walkthroughs or equivalent feature demonstrations when appropriate
  • screenshots or videos when useful for UI-heavy work

Best Practices

  • Be pragmatic above all else.
  • Write specs to improve input quality for agents, not as ceremony.
  • Keep product specs behavior-oriented and implementation-light.
  • Keep tech specs implementation-oriented and grounded in current codebase patterns.
  • When a spec references relevant code chunks, include the inspected commit SHA in the file reference when possible and link the reference to the exact GitHub blob/<sha>/...#Lx-Ly lines.
  • Use review time to validate specs and behavior, not to over-index on code style nits.
  • implement-specs
  • write-product-spec
  • write-tech-spec

© warpdotdev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/spec-driven-implementation of warpdotdev/common-skills.

Open the folder on GitHubat commit 69b4753

Used in 1 other repository

We found 1 copy of this SKILL.md (exact, near-identical or edited) in other folders, from 1 other GitHub owner. This page covers the copy in warpdotdev/common-skills, which our catalogue first saw on October 7, 2026.

Compare with similar skills

Spec Driven Implementation next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Spec Driven Implementation compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Spec Driven Implementation this skillwarpdotdev/common-skills6061 repos~1.5kAutomated safety check: PassMIT
SPARC Development Methodologyruvnet/ruflo74k2 repos~829Automated safety check: PassMIT
Ss SpecSerial-Studio/Serial-Studio7.2k—~766Automated safety check: PassCustom licence
Spec Driven Developzhu1090093659/spec_driven_develop983—~5.1kAutomated safety check: PassMIT
Bulletproof Workflowartemiimillier/bulletproof153—~3.5kAutomated safety check: PassMIT
Develop Feature Builderjsmastery-pro/skills1.4k—~3.8kAutomated safety check: NotesMIT

Similar skills

  • SPARC Development Methodology

    ruvnet/ruflo

    Applies the SPARC method (specification, pseudocode, architecture, refinement, completion) with 17 specialized modes and multi-agent orchestration, from research to deployment.

    74k GitHub starsUsed in 2 repos~829 tokens
    DevelopmentAuto-check passed

  • Ss Spec

    Serial-Studio/Serial-Studio

    Phase 1 of Serial Studio's spec-driven workflow: capture WHAT a feature must do and WHY, with no implementation detail.

    7.2k GitHub stars~766 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Spec Driven Develop

    zhu1090093659/spec_driven_develop

    Automates pre-development workflow for large-scale complex tasks.

    983 GitHub stars~5.1k tokensUpdated 2 mo ago
    DevelopmentAuto-check passed

  • Bulletproof Workflow

    artemiimillier/bulletproof

    Applies a 12-stage verified workflow, from research to deploy, to non-trivial coding tasks, scaled to lightweight, standard or full mode by task size.

    153 GitHub stars~3.5k tokensUpdated 6 mo ago
    DevelopmentAuto-check passed

  • Develop Feature Builder

    jsmastery-pro/skills

    Builds a feature, page, component, API or data layer from an approved spec and AGENTS.md, and sends you back to /architect when a key decision is missing.

    1.4k GitHub stars~3.8k tokensUpdated 1 mo ago
    DevelopmentAuto-check: notes

  • PRP Plan

    Wirasm/prp

    Writes an implementation-ready plan for a feature, bug fix, refactor or chore from a PRD, issue or description, grounded in codebase evidence, and can post it back to the source issue.

    2.3k GitHub stars~4k tokensUpdated 5 days ago
    DevelopmentAuto-check passed

More from warpdotdev/common-skills

All 28 skills in this repo

  • Skill Doctor

    warpdotdev/common-skills

    Grades agent skills by scoring agent conversations for efficiency, code quality, procedure compliance, and verbosity, then drafts concrete skill edits and a shareable report.

    606 GitHub starsUsed in 2 repos~2.6k tokens
    Auto-check passed

  • Readout

    warpdotdev/common-skills

    Produce a polished, self-contained HTML "readout" document under ~/.readouts (with an auto-maintained index page), either by snapshotting the findings accumulated in the current conversation or —…

    606 GitHub stars~2k tokensUpdated 6 days ago
    Auto-check passed

  • Resolve Merge Conflicts

    warpdotdev/common-skills

    Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context.

    606 GitHub stars~733 tokensUpdated 6 days ago
    Auto-check passed

  • Review PR

    warpdotdev/common-skills

    Review a pull request diff and write structured feedback to review.json for the workflow to publish.

    606 GitHub stars~2.6k tokensUpdated 6 days ago
    Auto-check passed

  • Saga

    warpdotdev/common-skills

    Run an autonomous, spec-driven development "saga" for medium-to-large features using an orchestrator agent and a fleet of worker subagents.

    606 GitHub stars~4.1k tokensUpdated 6 days ago
    Auto-check passed

  • PR Walkthrough

    warpdotdev/common-skills

    Generate a static interactive D3 walkthrough of a pull request.

    606 GitHub starsUsed in 1 repo~7.2k tokens
    Auto-check passed

Categories

Questions about Spec Driven Implementation

What does Spec Driven Implementation do?

Drive a spec-first workflow for substantial features by writing PRODUCT.md before implementation, writing TECH.md when warranted, and keeping both specs updated as implementation evolves. Spec Driven Implementation is an agent skill from warpdotdev/common-skills.md when warranted, and keeping both specs updated as implementation evolves.

When should I use Spec Driven Implementation?

Spec Driven Implementation fits situations like: starting a significant feature; planning agent-driven implementation; the user wants product and tech specs checked into source control.

How do I install Spec Driven Implementation in Claude Code?

Run `npx skills add warpdotdev/common-skills --skill spec-driven-implementation -a claude-code`. Or copy the skill folder (.agents/skills/spec-driven-implementation in warpdotdev/common-skills) into .claude/skills/spec-driven-implementation in your project. Claude Code loads it when a task matches its description.

How do I install Spec Driven Implementation in Codex?

Run `npx skills add warpdotdev/common-skills --skill spec-driven-implementation -a codex`. Or copy the skill folder (.agents/skills/spec-driven-implementation in warpdotdev/common-skills) into .agents/skills/spec-driven-implementation in your project. Codex loads it when a task matches its description.

Can I use Spec Driven Implementation in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add warpdotdev/common-skills --skill spec-driven-implementation -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/spec-driven-implementation, .gemini/skills/spec-driven-implementation, .github/skills/spec-driven-implementation and .opencode/skills/spec-driven-implementation in your project.

What does Spec Driven Implementation need to run?

SKILL.md names no scripts, command-line tools or credentials: Spec Driven Implementation is instructions for the agent only.

Does Spec Driven Implementation access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Spec Driven Implementation safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Spec Driven Implementation use?

Spec Driven Implementation is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Spec Driven Implementation use?

About 1.5k tokens (SKILL.md is roughly 6.1k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Spec Driven Implementation?

Skills that share tags, products or a category with Spec Driven Implementation: SPARC Development Methodology (ruvnet/ruflo, 74k stars), Ss Spec (Serial-Studio/Serial-Studio, 7.2k stars), Spec Driven Develop (zhu1090093659/spec_driven_develop, 983 stars) and Bulletproof Workflow (artemiimillier/bulletproof, 153 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Spec Driven Implementation?

warpdotdev (a GitHub organization) maintains it in warpdotdev/common-skills, which has 606 GitHub stars. The repository holds 28 skills in this directory. The repository was last updated on September 30, 2026.

Source: warpdotdev/common-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.