Implement Specs
Build an approved feature from ticket-scoped PRODUCT.md and TECH.md while updating those spec files in the same PR as the code.
Overview
Implement-specs is an agent skill most often used in Build (also Validate when specs are finalized) that implements an approved feature from PRODUCT.md and TECH.md while keeping specs and code aligned in the same PR.
Install
npx skills add https://github.com/warpdotdev/common-skills --skill implement-specsWhat is this skill?
- Treats PRODUCT.md as user-facing behavior truth and TECH.md as architecture and sequencing truth
- Expects specs under specs/<TICKET>/ (e.g. specs/APP-1234/PRODUCT.md and TECH.md)
- Keeps PRODUCT.md, TECH.md, and code changes in one PR so review matches what will ship
- Requires confirmed approved specs before coding; TECH.md optional only when the feature did not warrant one
- Workflow begins with reading approved specs, then implementing while keeping docs and code aligned as work evolves
Adoption & trust: 3.5k installs on skills.sh; 18 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have approved PRODUCT.md and TECH.md but need implementation that does not silently diverge from what reviewers approved.
Who is it for?
Solo builders using ticket-scoped spec directories who want spec-driven implementation with living docs in the implementation PR.
Skip if: Greenfield ideation without approved specs, or throwaway spikes where you intentionally skip checked-in PRODUCT.md and TECH.md.
When should I use this skill?
After product and tech specs are approved and the next step is building the feature from PRODUCT.md and TECH.md.
What do I get? / Deliverables
Feature code ships in sync with updated PRODUCT.md and TECH.md in one PR, so review and release reflect the same behavior and technical plan.
- Implemented feature code on the PR branch
- Updated PRODUCT.md and TECH.md in the same PR as implementation changes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Implementation starts after specs are approved—the canonical shelf is Build where product intent becomes shipped code. The skill coordinates spec-aligned delivery and PM-style traceability (ticket directory under specs/), not a single integration or UI-only task.
Where it fits
You verify PRODUCT.md and TECH.md under specs/APP-1234 are approved before flipping to implementation.
TECH.md defines API sequencing; you implement endpoints and update TECH.md if the sequence changes.
PRODUCT.md defines UX; UI work stays aligned and PRODUCT.md is patched when copy or flows shift.
Reviewers see spec and code diffs together in one PR anchored to the ticket.
How it compares
Spec-anchored implementation in-repo—not ad-hoc coding from chat memory without updating PRODUCT.md and TECH.md.
Common Questions / FAQ
Who is implement-specs for?
Indie developers and small teams who keep PRODUCT.md and TECH.md per ticket under specs/ and want the agent to implement against those files while keeping documentation and code in one reviewable PR.
When should I use implement-specs?
Use it in Build after specs are approved; use it in Validate only to confirm PRODUCT.md and TECH.md are ready before coding; do not use it when specs are missing or still in open debate without approval.
Is implement-specs safe to install?
It guides local spec and code edits in your repository; review the Security Audits panel on this Prism page and treat PRODUCT.md and TECH.md as sensitive product intent before sharing repos with agents.
SKILL.md
READMESKILL.md - Implement Specs
# implement-specs Implement an approved feature from `PRODUCT.md` and `TECH.md`. ## Overview 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. ## Prerequisites Before using this skill: - confirm that `PRODUCT.md` exists - confirm that `TECH.md` exists when the feature warranted one - confirm that the relevant specs have been reviewed and approved enough to start implementation ## Workflow ### 1. Read the approved specs first Treat: - `PRODUCT.md` as the source of truth for user-facing behavior - `TECH.md` as the source of truth for architecture, sequencing, and implementation shape Make sure you understand the expected behavior, constraints, risks, and validation plan before writing code. ### 2. Offer optional implementation aids for large features 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 state - `DECISIONS.md` to capture concrete product and technical decisions made during the PRD and tech design process These are optional aids, not required deliverables. Offer them when they would reduce confusion or help future agents avoid re-exploring the same paths. ### 3. Plan and implement against the specs Break the work into concrete implementation steps, then implement the feature against the approved specs. During implementation: - keep behavior aligned with `PRODUCT.md` - keep architecture and sequencing aligned with `TECH.md` - add or update tests and verification artifacts as the work lands Use the same PR for the specs and implementation when practical so the full feature evolution is reviewable in one place. ### 4. Update specs as the implementation evolves If implementation reveals that the intended behavior or design should change, update the checked-in specs rather than letting them go stale. In particular: - update `PRODUCT.md` when user-facing behavior, UX, edge cases, or success criteria change - update `TECH.md` when architecture, sequencing, module boundaries, or validation strategy change - keep those updates in the same PR as the corresponding code changes The PR should describe the feature that actually ships, not just the initial draft of the specs. ### 5. Verify against the specs Before considering the work complete, verify that the code matches the current specs. Prefer: - unit tests and regression coverage that follow the repository's local testing conventions - integration or end-to-end tests for important user flows ## Best Practices - Keep specs and code synchronized throughout implementation. - Prefer updating the spec immediately when decisions change rather than batching spec cleanup until the end. - Use optional tracking documents only when they add real value for a complex feature. - Keep the same PR coherent: spec updates, code changes, tests, and optional tracking docs should all support the same feature narrative. ## Related Skills - `spec-driven-implementation` - `write-product-spec` - `write-tech-spec`