メニュー
Implement an approved feature from PRODUCT.md and TECH.md, keeping specs and code aligned in the same PR as implementation evolves. Use after the product and tech specs are approved and the next step is building the feature.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | implement-specs |
| description | Implement an approved feature from PRODUCT.md and TECH.md, keeping specs and code aligned in the same PR as implementation evolves. Use after the product and tech specs are approved and the next step is building the feature. |
Implement an approved feature from PRODUCT.md and TECH.md.
Use this skill after the product and tech specs are approved. The goal is to build the feature described by the specs while keeping the checked-in specs and the implementation aligned as the work evolves.
Approved specs should live directly under a ticket-named directory in specs/, for example specs/APP-1234/PRODUCT.md and specs/APP-1234/TECH.md.
In many cases, the implementation should be pushed in the same PR as the product and tech specs. As the engineer iterates, changes to PRODUCT.md, TECH.md, and the code should all be pushed in that same PR so review stays anchored to the feature that will actually ship.
Before using this skill:
PRODUCT.md existsTECH.md exists when the feature warranted oneTreat:
PRODUCT.md as the source of truth for user-facing behaviorTECH.md as the source of truth for architecture, sequencing, and implementation shapeMake sure you understand the expected behavior, constraints, risks, and validation plan before writing code.
For large or long-running features, optionally offer one of these aids to the user before implementation begins:
PROJECT_LOG.md to track checkpoints, explored paths, partial findings, and current implementation stateDECISIONS.md to capture concrete product and technical decisions made during the PRD and tech design processThese are optional aids, not required deliverables. Offer them when they would reduce confusion or help future agents avoid re-exploring the same paths.
Break the work into concrete implementation steps, then implement the feature against the approved specs.
During implementation:
PRODUCT.mdTECH.mdUse the same PR for the specs and implementation when practical so the full feature evolution is reviewable in one place.
If implementation reveals that the intended behavior or design should change, update the checked-in specs rather than letting them go stale.
In particular:
PRODUCT.md when user-facing behavior, UX, edge cases, or success criteria changeTECH.md when architecture, sequencing, module boundaries, or validation strategy changeThe PR should describe the feature that actually ships, not just the initial draft of the specs.
Before considering the work complete, verify that the code matches the current specs.
Prefer:
spec-driven-implementationwrite-product-specwrite-tech-specProduce 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 — when invoked fresh, e.g. "/readout on how github webhook events are processed" — by sharpening scope with clarifying questions and researching the codebase before documenting. The work runs in a child agent so the main conversation's context stays clean. Use whenever the user invokes /readout, says "write this up", "turn this into a doc/page", "make a readout", or asks for a readable, shareable document capturing findings or explaining how something works.
Scan warpdotdev/warp and warp-server for recently merged PRODUCT.md specs that don't yet have a corresponding docs PR in warpdotdev/docs. When a complete spec is found, auto-generates a full docs draft PR and tags the engineer. When a spec is too thin to draft from, pings the engineer directly. Designed to run as a scheduled Oz ambient agent (e.g., every 2-3 days). Use when setting up the automated docs trigger or running a manual docs coverage sweep.
Draft a complete documentation page for a new Warp feature from its PRODUCT.md and/or TECH.md spec. Use when an engineer has written a spec and needs to produce a first-pass MDX draft for the warpdotdev/docs repo. Also handles features without specs by researching the codebase first. Invoke this skill whenever an engineer mentions writing docs for a feature, drafting a docs page, creating feature documentation, starting the eng-docs workflow, or converting a spec into documentation. Works from warp-internal or warp-server.
Run an autonomous, spec-driven development "saga" for medium-to-large features using an orchestrator agent and a fleet of worker subagents. Use this skill whenever the user invokes /saga, asks to autonomously build a sizable feature end-to-end with minimal human intervention, wants a comprehensive spec broken into milestones and tasks with airtight validation criteria before parallelized implementation, or wants an orchestrator to delegate implementation to worker agents while preserving its own context window. Trigger on phrases like "run a saga", "autonomously implement this feature", "spec it out then build it with subagents", "orchestrate this big feature end-to-end", or "build this with workers and validate each step". Also use this skill when asked to continue, resume, or pick up an existing saga from its saga directory (e.g. under ~/.sagas).
Run a second round on a contested question by circulating each subagent's independent proposal to the other authors and asking for structured pros and cons, then synthesize. Use this skill whenever you have multiple independent proposals or opinions on a contested decision — architecture tradeoffs, code review disagreements, design choices, competing root-cause theories — and want sharper analysis than you'd produce by synthesizing alone. Pairs naturally with the council and research skills; reach for it liberally whenever proposals diverge.
Delegate noisy investigation to one or more subagents so the orchestrator's context stays clean, then work from the distilled answer. Use this skill whenever answering a question would require reading many files, long logs, large diffs, or wide codebase surveys — i.e. when producing the answer generates far more noise than the answer itself. Use it for "how does X work", "where is Y used", "what's the root cause of Z", "summarize this PR/log" style questions, and reach for it liberally before reading a pile of files inline.