Spec Driven Implementation

This enforces a spec-first workflow for substantial features, creating PRODUCT.md and TECH.md files under specs/<ticket-number>/ before you write code. It's pragmatic about when specs actually help: think 1k+ LOC changes, cross-cutting work, or anything with meaningful ambiguity where an agent or reviewer benefits from reading the plan before the implementation. The workflow ties directly into Linear for issue tracking and keeps specs updated in the same PR as code changes, so they don't go stale. Skip it for small bug fixes or straightforward refactors. The honest take: this is useful if you're working in a team context where checked-in specs become the shared source of truth, less so if you just want to move fast on solo work.

skills.sh installs: 28.9K
GitHub stars: 684
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add warpdotdev/common-skills --skill spec-driven-implementation --agent claude-code

Installs into .claude/skills of the current project.

Files

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: