spec-driven-implementation
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.
More from warpdotdev/warp
create-pr
Create a pull request in the warp repository for the current branch. Use when the user mentions opening a PR, creating a pull request, submitting changes for review, or preparing code for merge.
2fix-errors
Fix compilation errors, linting issues, and test failures in the warp Rust codebase. Covers presubmit checks, WASM-specific errors, and running specific tests. Use when the user hits build errors, clippy or fmt failures, test failures, or needs to run or interpret presubmit before a PR.
2review-pr
Review a pull request diff and write structured feedback to review.json for the workflow to publish. Use when reviewing a checked-out PR from local artifacts like pr_diff.txt and pr_description.txt and producing machine-readable review output instead of posting directly to GitHub.
2update-skill
Create or update skills by generating, editing, or refining SKILL.md files in this repository. Use when authoring new skills or revising the structure, frontmatter, or guidance for existing ones.
2add-feature-flag
Add a new feature flag to gate code changes in the Warp codebase.
1add-telemetry
Add telemetry events to track user behavior or system events in the Warp codebase. Use when instrumenting new features, debugging issues, or measuring product metrics.
1