Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/warpdotdev/common-skills/spec-driven-implementationnpx skills add warpdotdev/common-skills --skill spec-driven-implementationgit clone --depth 1 https://github.com/warpdotdev/common-skillsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00061 | $0.01227 |
| Opus 5 | $0.00030 | $0.00613 |
| Sonnet 5 | $0.00012 | $0.00245 |
| Haiku 4.5 | $0.00006 | $0.00123 |
Grade A, and why
spec-driven-implementation scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 144 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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.mdspecs/<linear-ticket-number>/TECH.md
For example:
specs/APP-1234/PRODUCT.mdspecs/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_teamsto find the appropriate teamlist_issue_labelsto inspect the expected labels/tagssave_issueto 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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 144 lines · 61 tokens per session scan A 242028fe3ed0
spec-driven-implementation is a skill published in the GitHub repository warpdotdev/common-skills (413 stars, last pushed 2d ago), licensed MIT. It adds 61 tokens to every session and 1,227 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
next-cache-components-adoption
Turn on Cache Components in a Next.js app and resolve the blocking routes it surfaces. Use when the user wants to enable, adopt, or migrate to Cache Components, flip the cacheComponents flag, work through a flood of blocking-prerender / instant validation errors, run the cache-components-instant-false codemod, or…
babysit-pr
Babysit a GitHub pull request after creation by continuously polling review comments, CI checks/workflow runs, and mergeability state until the PR is merged/closed or user help is required. Diagnose failures, retry likely flaky failures up to 3 times, auto-fix/push branch-related issues when appropriate, and keep…
imagegen
Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output…
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…
next-cache-components-optimizer
Drive a Next.js route to instant navigation by setting up an agentic loop, under Cache Components / PPR, on initial load (hard navigation) and client-side navigation (soft navigation). Encode the goal as a failing @next/playwright instant() e2e and work it to green, one verified route at a time; the shipped test then…