agentleFS
Sign inStart free
AlexisBalayreAlexisBalayre/claude-code-power-config/.claude/skills/implement-spec/SKILL.md

implement-spec

Skill2 starsChanged 28 days agoMITView on GitHub

Implement the result of /to-spec and /to-tickets in code.

  • Reads credentials
  • Commits and pushes

107 other projects use a version of this, 67 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use implement-spec-with-codex, close-spec and 10 more.

Other files people use alongside this one.

Files 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

    implement-spec-with-codex

    Run [implement-spec](../implement-spec/SKILL.md) with Codex doing the implementation passes while you orchestrate, integrate, and review. Use when the user asks to implement a spec with Codex, or to run implement-spec with Codex as the implementer.

    Also in 4 projects that use this

  • 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

  • wolverin0Skill

    audit-decisions

    Standardize remediation decisions, baseline-policy entries, and legal-review banners for accepted, deferred, or policy-blocked audit findings.

    Also in 4 projects that use this

  • saffron-healthSkill

    get-pr-reviews

    Get nicely formatted output of the last review comments on a PR. Used internally by other skills.

    Also in 3 projects that use this

  • saffron-healthSkill

    push-everything

    Stage ALL changes in the repository (not just session changes), commit, and push. Use when you need to commit all pending changes.

    Also in 3 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

  • +5 more from dzhng

The file

We split this skill into the rules it gives an agent

4 rules. 3 are common, 0 are distinctive, and 1 is very specific to this project.

  • 3

    Common

    Most of the 99 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Implementer subagents: should be run in the background where possible for maximum concurrency.

    line 17
  2. Common:

    Read the spec and tickets to understand the task graph.

    line 21
  3. Very specific:

    Use implementer subagents to implement each ticket, each in its own worktree on its own branch: scripts/worktree-create.sh <ticket-slug>, …

    line 27
  4. Common:

    If this changes the frontier of available tickets, kick off more implementer subagents to work on the new tickets.

    line 35

“Common” is measured: kept by at least 6 in 10 of the 99 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.

The tickets live in the configured tracker (IDs from .env), or under docs/plans/<feature-slug>/issues/ when there is no tracker (see /to-tickets). If you can't find them, ask the user. docs/plans/ is never committed, so it exists only in the main checkout: point subagents at it by absolute path.

The goal is the entire spec implemented on a single integration branch, with every ticket resolved the way the issue tracker closes work.

The tickets are not a list of steps. They are a task graph with blocking relationships between them. This means there is always a frontier of tickets which are ready to be grabbed.

Communication to and from subagents should be sparse. Communicate primarily through context pointers: to the spec, tickets, research notes, and previous commits. Don't duplicate information already available via pointers.

Implementer subagents should be run in the background where possible for maximum concurrency.

Steps

  1. Read the spec and tickets to understand the task graph.
  2. (optional) Use an exploration subagent to conduct any exploration required by the tickets - relevant codebase files or external documentation. Ensure the exploration subagent can save files - it should save its markdown notes in a directory outside the repo, accessible by all future subagents. This lets implementer subagents focus on implementation rather than exploration.
  3. Create the integration branch with scripts/worktree-create.sh <spec-slug>. After the first merge in step 5 (a branch with no commits ahead of the trunk can't open a PR), push it and open a draft PR marked as closing the spec and tickets. Call the Skill tool with pr-description for its title and body only, then open it yourself with gh pr create --draft: pr-description's own create step opens a ready PR, which the CI review bills on every push. The CI review skips drafts, so it runs once step 8 marks the PR ready.
  4. Use implementer subagents to implement each ticket, each in its own worktree on its own branch: scripts/worktree-create.sh <ticket-slug>, run from the integration worktree, branches from the integration branch. Each implementer subagent:
    • confirms its worktree is based on the integration branch before starting, and fast-forwards onto it (git merge --ff-only <integration-branch>) if not;
    • calls the Skill tool with tdd to build the ticket;
    • commits its work on its own branch;
    • merges the integration branch tip into its own branch before reporting done
  5. Once an implementer subagent completes, merge its work to the integration branch with a merger subagent, then push the integration branch. Run mergers one at a time: two in the same integration worktree collide.
  6. If this changes the frontier of available tickets, kick off more implementer subagents to work on the new tickets. This allows for maximum concurrency.
  7. Once all tickets are complete, review the integration branch's diff against the spec and tickets yourself: every acceptance criterion met, nothing built beyond them. Fix any gap in a single implementer subagent.
  8. Push the integration branch and mark the draft PR ready for review, which starts the CI review (pr-ci-review). Wait for it (gh pr checks <number> --watch), fix the important findings in the review it posts (that review's, not other comments on the PR) in a single implementer subagent, and push. Then resolve each ticket the way the issue tracker closes work.
  9. From the integration worktree, where their branches are merged, clean up every implementer subagent worktree (git worktree remove) and its branch (git branch -d).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free