implementation-skills — Cursor edition

An autonomous implementation toolchain for Cursor: plan vertical slices, shape raw asks into agent-ready work-items, work a backlog issue-by-issue through TDD, verify against acceptance criteria, review adversarially on a different vendor's model, and drive the result through commit, PR, and merge.

This is the Cursor port of implementation-skills-claude. Same pipeline, same hard-won tracker and merge-train details — but where the Claude Code edition names fixed model tiers, this edition reads them from a config file in your project root, because Cursor hosts models from every major vendor and hardcoding tiers would waste that.

isc, in one paragraph

bin/isc — implementation-skills for Cursor — is the repo's install tool. POSIX shell, no dependencies, four verbs: init writes the config, sync generates .cursor/agents/*.md from it, doctor checks it, show/models print the config and the available models. It exists for one reason: Cursor reads a subagent's model from static frontmatter, so something has to write your config choices into those files. That something is isc sync.

Install

Let Cursor do it

Paste this into Cursor's chat, in Agent mode:

Install the implementation-skills bundle into this project.

1. Clone https://git.samaschke.de/ksamaschke/implementation-skills-cursor.git
   to ~/.implementation-skills-cursor (if it already exists, git pull instead).
2. Run: ~/.implementation-skills-cursor/bin/isc init
3. Fill in the two config files isc wrote:
   - .cursor/models.yaml — one model id per lane, using ids this Cursor
     install actually has. Keep implementer lanes and reviewer lanes on
     DIFFERENT vendors.
   - implementation-skills.yaml — gate: the command that runs this project's
     tests and lint.
4. Run: ~/.implementation-skills-cursor/bin/isc sync
5. Run: ~/.implementation-skills-cursor/bin/isc doctor and fix what it reports.
6. Show me the final config and the lane map.

The bundle's README explains the config keys.

Cursor picks the model ids from its own roster, which beats copying the examples below. For every project rather than one, tell it to use isc sync --global.

Or do it yourself

git clone https://git.samaschke.de/ksamaschke/implementation-skills-cursor.git ~/.implementation-skills-cursor

cd /path/to/your/project
~/.implementation-skills-cursor/bin/isc init     # writes implementation-skills.yaml
$EDITOR .cursor/models.yaml                      # one model id per lane
$EDITOR implementation-skills.yaml               # gate, tracker, merge policy
~/.implementation-skills-cursor/bin/isc init --global  # optional: ~/.cursor/models.yaml as your default lane map
~/.implementation-skills-cursor/bin/isc sync     # renders .cursor/{agents,skills,rules}
~/.implementation-skills-cursor/bin/isc doctor   # checks the config and its assumptions

Put bin/ on your PATH to drop the prefix. isc sync --global installs into ~/.cursor instead, for skills you want in every project; --link symlinks instead of copying, which is what you want if you intend to edit the bundle.

After installing

In Cursor: /implement-issues, /prepare-work, /plan-slices, /commit-and-push, /pr-and-merge, /delegate — or just describe the task and let the always-applied rule route it. If they don't show up in the / menu, reload the Cursor window; newly added skills and agents aren't always picked up mid-session.

Don't hand-edit .cursor/agents/*.md — they are generated from the lane map (.cursor/models.yaml) plus the operational config. Edit .cursor/models.yaml and re-run isc sync; edits to implementation-skills.yaml (tracker, gate, policy) are read at runtime and need no sync.

Configuration

The easy way: /configure-models in Cursor. It reads the live model roster, proposes an assignment for all nine lanes, writes the config, re-runs isc sync, and verifies. Use it for "make this cheaper", "put the reviewer on Opus", "stop using OpenAI", or first-time setup.

By hand, the lane map is .cursor/models.yaml — flat, dotted keys, the same schema the Claude Code and Codex variants read, so a lane means the same thing wherever you run it:

implementer_trivial: composer-2.5
implementer_low: composer-2.5
implementer_moderate: gpt-5.6-terra
implementer_high: gpt-5.6-sol[effort=high]
requirements_checker: claude-4.5-haiku
reviewer_default: claude-sonnet-5
reviewer_security: claude-opus-5[effort=high]
dispatcher: claude-4.5-haiku
researcher: gemini-3-flash

Resolution, per key, first hit wins: ./.cursor/models.yaml → ./models.yaml (shared with other harnesses) → ~/.cursor/models.yaml → built-in default. Within a file, harness.cursor.<key> beats a bare <key>. isc show prints what resolved and from where. Full contract, including the optional engine.* / role.* / family.* keys: skills/implement-issues/references/model-config.md.

Triage routes work to a lane; the config decides which model serves it. Two properties are worth being deliberate about:

• Cost curve. Trivial work should not touch a frontier model. The pipeline is designed around a cheap majority and an expensive minority.
• Cross-family review. The reviewer's entire value is independence — a reviewer from the same vendor family as the implementer shares its blind spots. Keep them on different families. isc doctor warns when they aren't; the skills flag it in their reports when they can't avoid it.

Cursor resolves a subagent's model from static frontmatter, so lane→model bindings are baked into .cursor/agents/*.md at install time. Change the lane map → re-run isc sync. isc doctor fails the render-stamp check when you forget; it hashes the lane map as well as the config, so a models-only edit cannot slip through.

implementation-skills.yaml holds everything that is not a model — tracker, token, gate command, base branch, merge strategy, parallelism, deploy gate, split backlog, project notes — and is documented in skills/implement-issues/references/project-config.md. Every key is optional.

What's in the bundle

Skills

Skill	Summary
implement-issues	Works actionable backlog items through triage into compatible delivery lanes, TDD implementation, one combined requirements check and one adversarial review per lane, commit, PR, merge, and any configured deploy gate. Optional parallel execution runs concurrent lanes behind a serial merge queue.
plan-slices	Plans vertical product slices, stores them as decision-complete staged docs, and files a staged slice into the tracker as milestone + epic + contract-shaped stories.
prepare-work	Interactively shapes a raw ask into agent-ready work-items — research first, few decision questions, a "confused implementer" completeness audit, then file or stage.
commit-and-push	Reviews the diff, excludes secrets and junk, writes a conventional commit, pushes via the project's host.
pr-and-merge	Creates or reuses a PR, runs cross-family adversarial review with a 3-iteration fix budget, resolves mergeability, merges, refreshes the base branch.
configure-models	Assigns models to lanes conversationally — reads the live roster, proposes an assignment, writes the config, re-renders the agents, verifies. The easy way to do the configuration below.
delegate	Optional: offloads work to a headless Cursor CLI (agent), Codex, or PI, with isolated-worktree patch-back. Off by default.

Subagents

Rendered from your config into .cursor/agents/:

Agent	Role
implementer-trivial / -low / -moderate / -high	Implementation lanes by triage tier. Leave changes uncommitted, return a structured evidence block.
requirements-checker	Re-runs the gate, reads the diff, returns per-criterion COVERED/PARTIAL/MISSING with evidence. Read-only. Verifies; never fixes.
reviewer / reviewer-security	Hostile adversarial review; the security lane escalates on auth/credential/crypto/sandbox paths and on any diff that executes external commands. Read-only.
dispatcher	Routes a task to a lane when triage isn't obvious. Decides; never executes.
researcher	Read-only sweeps and long-log reading, to keep bulk text out of the orchestrator's context.

How the pipeline holds together

The invariants are the product; the phases are just where they're enforced.

• TDD is not optional for behavior changes: failing test first, confirmed red for the right reason, then green.
• Evidence, not claims. The implementer's "tests pass" is an input, not a verification. A separate cheap model re-runs the gate and reads the diff.
• The reviewer advises; the orchestrator adjudicates. Every finding is classified REAL or REJECT with a rationale, and REJECT decisions are held across rounds so a reviewer can't relitigate a nitpick into a blocker.
• Serial integration. Even at max_parallel: 8, branches merge one at a time, each rebased onto the current base and re-gated green before its turn. No force-pushes, ever.
• Honest reports. Skipped gates, fallback lanes, unverified claims, and a MISSED deploy are reported as such. A pass that ends between "merged" and "deployed" is an incomplete pass, not a success.
• Zero AI attribution in commits and PRs unless the project opts in.

Requirements

• Cursor with subagent and skill support.
• A tracker: gh for GitHub, a token file for Forgejo/Gitea, or a directory of markdown issues for the file backend (see trackers.md).
• POSIX sh and awk for isc. No runtime, no package manager, no network.
• Optional: the Cursor CLI (agent), codex, or pi on PATH for the delegate skill.

Relationship to the Claude Code edition

Both editions are maintained. The Claude Code one is upstream for the pipeline logic; this one adapts it to Cursor's surface and adds the model configuration layer. Porting notes, including what changed and what deliberately did not, are in references/cursor-mapping.md.

Development

tests/ holds acceptance specs for the bundle — the isc tool's config handling and the behavioral properties each skill has to preserve. They are written to be run against a scratch repo, not as unit tests of prose.