implement-spec

We split this skill into the rules it gives an agent

9 rules. 0 are common, 6 are distinctive, and 3 are very specific to this project.

• 0

  Common

  Most of the 78 edited versions we read keep these.

• 6

  Distinctive

  This author's own choices. Worth a look.

• 3

  Very specific

  Tied to their project's names, files or tools. Probably skip.

• Common
• Distinctive
• Very specific

1. Distinctive:

   Read the entire spec file.

   line 12
2. Very specific:

   Read every file listed in the "Important files/docs/websites for implementation" section of the spec.

   line 16
3. Very specific:

   Run pnpm run typecheck, pnpm test, and pnpm run lint after implementation to catch issues.

   line 22
4. Distinctive:

   When you're done, do not stage or commit your changes.

   line 34
5. Distinctive:

   If the user asks for changes, implement them.

   line 38
6. Distinctive:

   Check downstream phases: If your spec changes affect later phases, ask the user whether you should update those phases too.

   line 45
7. Distinctive:

   If during implementation you identify work that is not blocking but would be valuable later (big features, refactors, cleanup), propose …

   line 50
8. Distinctive:

   If the work is blocking (the app is broken without it), it should be done as part of the current spec — either in this phase or added to a …

   line 52
9. Very specific:

   When the user asks you to hand off to the next phase, include in the handoff summary a note to load the implement-spec skill.

   line 56

“Common” is measured: kept by at least 6 in 10 of the 78 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

• Other versions86 projects use a version of this.

  Word for word · 2

  1. saffron-health/libretto★ 883100% same
  2. saffron-health/opencode-gui★ 59100% same

  Edited · 0

  None found.

  Wrote their own version · 84

  1. mattpocock/skills★ 303ksame name
  2. formbricks/formbricks★ 13ksame name
  3. ArcReel/ArcReel★ 6ksame name
  4. vinvcn/mattpocock-skills-zh-CN★ 5.3ksame name
  5. withcoral/coral★ 4.9ksame name
  6. dzhng/jevgrep★ 2.9ksame name
  7. dzhng/skills★ 1.4ksame name
  8. a16z/jolt★ 1.1ksame name
  9. epam/ketcher★ 911same name
  10. devcxl/mattpocock-skills-zh★ 508same name

  74 more not listed

  How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

• Used alongsideProjects with it also use close-spec, design-with-images and 7 more.

  Other files people use alongside this one.

  How we pick theseFiles found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.

  • dzhngSkill

    close-spec

    When a spec under specs/<feature>/ is done shipping (a write-spec build, or any planned task that produced a spec), archive it to specs/done/ and rewrite it from a build-plan into a durable rationale — the why, the principles, the invariants — pointing back to the real code for the how. Use when implementation has landed and the plan no longer matches what shipped, or the user says a feature/spec is finished. Pairs with [write-spec](../write-spec/SKILL.md) (the plan this closes) and [review](../review/SKILL.md) (run before closing).

    Also in 4 projects that use this

  • dzhngSkill

    design-with-images

    Explore UI and visual design with image generation, then iterate the real implementation against the user-selected concept. Use when brainstorming visual directions, offering mockup variants, or implementing an approved generated design; do not stop at the mockups or the first code approximation.

    Also in 4 projects that use this

  • transitive-bullshitSkill

    compare-screenshots

    Compare screenshots against the intended design, distinguishing approved references from historical baselines. Use for iterative implementation matching, before/after visual review, objective image telemetry, or checking a lone capture for flat, empty, or badly framed content.

    Also in 4 projects that use this

  • LucasMatuszewskiSkill

    audit-agents

    Audit and maintain agent configuration files (.claude/agents, AGENTS.md, CLAUDE.md, agent-memory). Checks for duplicates, outdated info, naming conflicts, wrong technical facts, and files over 200 lines. Fixes all issues and commits.

    Also in 4 projects that use this

  • rhnfzlSkill

    explore-unknowns

    Walk the user through mapping the unknowns of a task before, during, and after they build it, and hand them a four-quadrant map (settled ground, open decisions, taste, and landmines) they keep. Reach for this eagerly whenever a request is ambiguous or underspecified, the codebase or domain is unfamiliar, the user will "know it when they see it", a reference implementation must be understood before porting, a build-queue or architecture-changing task is about to start, a mid-build deviation needs capturing, or a finished change needs buy-in or verified understanding before merge. Trigger even when the skill is not named: "do a blindspot pass", "find my unknown unknowns", "interview me about this change", "brainstorm the approach for a task I am about to build", "help me scope this", "what am I missing here", "plan this before I build", "I know nothing about X in this codebase". When a territory profile is present it reads memory and the graph first and feeds the map into the build pipeline; without one it degrades to a plain general map. Not for trivial or mechanical tasks with clear acceptance criteria, single-fact lookups, pure debugging of a known symptom, or pure code review, those have their own tools. Do not use it to run the build itself; the map is the deliverable and implementation remains a separate task, whether it has not started or is already underway.

    Also in 4 projects that use this

  • +4 more from dzhng
• In this repository30 other files it gives its agents.

  • AGENTS.mdAGENTS.md
  • .deepsec/AGENTS.mdAGENTS.md
  • docs/AGENTS.mdAGENTS.md
  • .opencode/AGENTS.mdAGENTS.md
  • CLAUDE.mdCLAUDE.md
  • docs/CLAUDE.mdCLAUDE.md
  • address-reviewSkill
  • cli-developmentSkill
  • erroreSkill
  • external-electron-appsSkill
  • fix-merge-conflictsSkill
  • generate-specSkill
  • generate-spec-v2Skill
  • get-pr-reviewsSkill
  • glimpse-changesSkill
  • improve-codebase-architectureSkill
  • libretto-readonlySkill
  • librettoSkill
  • promptingSkill
  • push-everythingSkill
  • pushSkill
  • reviewSkill
  • spec-reviewSkill
  • summarizeSkill
  • technical-writingSkill
  • turborepoSkill
  • update-docsSkill
  • writing-testsSkill
  • libretto-readonlySkill
  • librettoSkill