Pace
Engineering cookbook

← Back to all cookbooks

Engineering cookbook

Two flagship recipes (skill chains) cover most engineering work, followed by the full skill catalog as a reference. Recipes are how skills compose into a finished result; the catalog is what each individual skill does.

Install engineering in Cowork ↗ claude plugin install engineering@pace

Recipes

Skills compose. A real engineering task usually runs three to five skills in order, with the output of one feeding the next. Two recipe shapes cover most work.

Recipe

From idea to first PR, with the thinking captured

Half a day of unstructured exploration becomes a tracked epic with one PR in the queue, ready to review.

When you're starting from something fuzzier than a spec. You'll prototype to learn, grill yourself on what you learned, write the PRD that captures the decision, split it into issues, and TDD the first one.

  1. 1
    prototype

    Prototype

    Build a throwaway version to feel the shape of the design. State, edges, UI variants, whichever is fuzzy.

  2. 2
    grill-me

    Grill yourself

    Force the questions you've been avoiding. Failure modes, partial state, concurrency, scale, telemetry, rollback. Every branch gets an answer.

  3. 3
    to-prd

    Write the PRD

    Turn the prototype and the grilling answers into a PRD: problem, constraints, decisions, non-goals. Saved to your project tracker.

  4. 4
    to-issues

    Split into issues

    Break the PRD into tracer-bullet vertical slices, one per issue. Each issue is sized to land as one PR.

  5. 5
    tdd

    TDD the first slice

    Red-green-refactor on the first issue. Commits at every transition so the loop is visible in the diff.

Discovery kickoff 
I want to build the bulk-CSV import feature. We need to handle 50k rows, validate against the existing user schema, and produce a downloadable error report.

Let's go through the discovery chain:
1. Prototype both the streaming-parse approach and the chunked-batch approach so I can feel the difference.
2. Grill me on the design: failure modes, partial uploads, concurrent users, what error reporting actually looks like.
3. Write the PRD from what we landed on, save it to Linear.
4. Split into issues sized for one PR each.
5. TDD the first issue.

Stop after each step so I can review.

Use when: you have an ask, not a spec. You don't yet know the right design.

Recipe

Stacked-PR shipping, end to end

A planned feature lands as a chain of small reviewable PRs, each rebased cleanly after the previous one merges.

When the spec already exists. You'll plan it as an epic, build it as a stack of PRs, address review comments, rebase the next one when the previous merges, and reset cleanly between tasks.

  1. 1
    spec

    Spec the feature

    Refine the ask into a parent epic with ordered sub-issues. Each sub-issue is scoped to a single PR. No code yet.

  2. 2
    implement

    Implement the stack

    Build the epic as stacked branches, one PR per sub-issue. Stops at PR boundaries so you can review before continuing.

  3. 3
    review

    Address reviews

    Walk PR comments grouped by file. Each one gets a fix-and-reply, a decline-with-rationale, or an ask-for-clarification.

  4. 4
    topr

    Rebase the next PR

    After PR n merges via squash, rebase PR n+1 cleanly. The skill correctly drops the squash-merged commits.

  5. 5
    next

    Reset

    Clean throwaway branch on the latest main. The next task starts from a known good state; the old branch stays in case you need it.

Shipping kickoff 
Spec the bulk-CSV import feature into a tracked epic with ordered sub-issues. Each sub-issue should be scoped to a single PR.

Once the spec is approved, implement it as a stack of PRs. Stop after PR #2 so I can review.

After review, address the comments, rebase the next PR on main, and reset for the following task.

Use when: the design decisions are made. You know what to build and just need it shipped methodically.

Stacked-PR workflow

The opinionated five-skill loop. Plan a feature, ship it as a chain of small reviewable PRs, address review comments, rebase the next PR on top after each merge, then reset cleanly between tasks.

/spec

Refine a feature into a tracked epic. Each sub-issue maps to one PR.

When you say
  • "Spec the new export feature."
  • "Plan this out before we build it."
  • "Break this initiative into issues."
Try it like this
"Spec the bulk-CSV import feature. Should handle 50k rows, validate against the existing user schema, and produce a downloadable error report."
What you get back
A parent epic issue + ordered child issues, each scoped to a single PR. No code yet; hand off to /implement when ready.

Full skill reference →

/implement

Execute a /spec-produced epic as a chain of stacked PRs, one per sub-issue.

When you say
  • "Implement epic #142."
  • "Build out the spec we wrote."
  • "Start on issue #143."
Try it like this
"Implement epic #142. Stop after PR #2 so I can review."
What you get back
A branch per sub-issue stacked on the previous one, each with a focused PR. Stops cleanly so you can review before continuing.

Full skill reference →

/review

Address PR review comments interactively. Fix or decline with reasoning, post inline replies.

When you say
  • "Address the PR comments on #156."
  • "Go through the review queue."
  • "Clear the comments on this PR."
Try it like this
"Walk me through the review on PR #156. Fix the obvious ones, push back on the ones you disagree with."
What you get back
Comments grouped by file, each triaged with an action: fix-and-reply, decline-with-rationale, or ask-for-clarification. Inline replies posted.

Full skill reference →

/topr

Rebase a stacked PR onto the latest origin/main after an earlier PR in the stack merged.

When you say
  • "Rebase PR #157 on main."
  • "Refresh this PR after #156 merged."
  • "Top of stack, rebase."
Try it like this
"PR #156 just merged via squash-and-merge. Rebase #157 on main."
What you get back
A clean rebase that correctly drops the commits that came in via the squash-merge of the earlier PR. No duplicate commits, no manual conflict-resolution where the rebase tool gets it wrong.

Full skill reference →

/next

Reset between tasks. Checks out a clean throwaway branch on the latest main so the next task starts fresh.

When you say
  • "Next."
  • "Reset for the next thing."
  • "Done with this, what's next?"
Try it like this
"Next."
What you get back
Switch to a clean dummy branch rebased on latest main. Old branch left intact in case you need to come back.

Full skill reference →

Plan + pressure-test

Skills for the part of the work before the code: sharpen the design, find the gaps in your reasoning, understand how a chunk of code fits into the larger system.

/grill-me

Interview yourself relentlessly about a plan or design until every decision branch has an answer.

When you say
  • "Grill me on this design."
  • "Stress-test the plan."
  • "Poke holes in this."
Try it like this
"Grill me on the bulk-CSV import design. I think we should stream parse, you tell me what I'm missing."
What you get back
A back-and-forth Q+A where Claude pushes on the design: what about partial failures, what about huge files, what about concurrent uploads, what does the user see on error. Stops when every branch has a concrete answer.

Full skill reference →

/grill-with-docs

Same as grill-me, but checks your plan against the existing CONTEXT.md, ADRs, and inline domain language.

When you say
  • "Grill this against our docs."
  • "Pressure-test using project context."
Try it like this
"Grill me on the bulk-CSV import. Make sure I'm using the same vocabulary we use in CONTEXT.md."
What you get back
A grilling session that catches inconsistencies between your plan and what the project already documents. Updates docs inline as decisions firm up.

Full skill reference →

/zoom-out

Ask Claude to step back and give the higher-level shape of the code you're looking at.

When you say
  • "Zoom out, what is this doing at a system level?"
  • "Give me the architecture view of this module."
Try it like this
"I'm in the payment-retry code and I don't see the larger flow. Zoom out."
What you get back
A description of how the current code fits the larger system: who calls it, what state it depends on, what comes after, what failure modes exist at the boundary.

Full skill reference →

/careful-review

Re-read what you just wrote with fresh eyes and look hard for bugs, dead code, or confusing patterns. Then fix them.

When you say
  • "Careful review."
  • "Look it over again."
  • "Give it another pass before I commit."
Try it like this
"I just rewrote the auth middleware. Careful review before I push."
What you get back
A pass through the diff with concrete findings: edge case not handled, variable name that misleads, error that swallows instead of surfacing, test that doesn't actually assert anything. Fixes applied.

Full skill reference →

/codex-review

Run an OpenAI Codex code review for a structured second opinion. Confirms P0/P1 findings against the code, fixes confirmed ones, commits.

When you say
  • "Codex review."
  • "Get a second opinion."
  • "Run Codex on this branch."
Try it like this
"Run Codex review against main on this branch before I open the PR."
What you get back
A summary of Codex's findings, separated into "real bug, fixed" vs. "false positive, ignored" with the rationale per finding. Confirmed fixes committed.

Full skill reference →

TDD + coverage

Disciplined testing skills. Write the failing test first, find what's missing in an existing module, smoke-test the whole app before a release.

/tdd

Test-driven development with red-green-refactor. Write the failing test first, then minimal code to make it pass, then refactor.

When you say
  • "TDD this feature."
  • "Red-green-refactor."
  • "Test-first."
Try it like this
"TDD the discount-rule engine. Write the failing tests for the percentage discount first, then make them pass."
What you get back
A test file with red tests, then a minimal implementation that makes them green, then refactoring with the tests staying green throughout. Commits at each transition so you can see the loop.

Full skill reference →

/find-missing-tests

Survey a module, file, or PR for missing coverage. Produces a specific test backlog. Optionally opens GitHub issues for each gap.

When you say
  • "Find missing tests."
  • "What's not tested in this module?"
  • "Test backlog for src/billing."
Try it like this
"Find missing tests in src/billing. Open issues for anything that should exist but doesn't."
What you get back
A list of specific test cases that should exist, each detailed enough that another agent (or developer) can implement it. Not "test the validator" but "test that validator rejects negative amounts with a specific error code."

Full skill reference →

/e2e-test

Run a full end-to-end test against real backend + frontend dev servers, with mocks disabled. Verifies a release before shipping.

When you say
  • "E2E sweep."
  • "Smoke test the app."
  • "Test everything end to end before I deploy."
Try it like this
"E2E sweep. Start the dev servers, drive the full signup → first-purchase flow, give me a PASS/FAIL summary."
What you get back
A PASS or FAIL summary of the critical user flows, with logs and screenshots of any failure. No mocks, no stubs, real network.

Full skill reference →

Diagnose + secure

When something is broken or risky. Disciplined diagnosis loops for tricky bugs and performance regressions. Security passes that find what a casual review misses.

/diagnose

Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce, minimize, hypothesize, instrument, fix, write the regression test.

When you say
  • "Diagnose this bug."
  • "Debug this perf regression."
  • "Something is broken in prod, walk through it methodically."
Try it like this
"The /checkout endpoint is 10x slower than yesterday's build. Diagnose."
What you get back
A reproducible minimal case, a hypothesis with evidence, the actual fix, and a regression test that would have caught it. The methodical version of a bug hunt.

Full skill reference →

/debug

Structured debugging session for a specific error message, stack trace, or "works locally, broken in prod" situation.

When you say
  • "Debug this stack trace."
  • "This works in staging but not prod."
  • "Why is this throwing?"
Try it like this
"Getting `TypeError: cannot read properties of undefined (reading 'tokenize')` in the lexer. Debug."
What you get back
A walkthrough: where the value should have been set, why it wasn't, what the fix is, what test would have caught it.

Full skill reference →

/security-review

Security-focused review covering OWASP top-10 + language-specific footguns. Prioritized findings with concrete fixes.

When you say
  • "Security review."
  • "Is this safe to expose?"
  • "Check for vulnerabilities before we ship."
Try it like this
"Security review the new file-upload endpoint. It accepts user-controlled filenames."
What you get back
A prioritized list of findings: P0 (must fix), P1 (should fix), P2 (worth noting), each with a concrete patch. Covers injection, auth bypass, IDOR, SSRF, secrets in code, unsafe deserialization, plus language-specific traps.

Full skill reference →

Prototype + ship

Build something throwaway to learn from, then ship the real thing safely.

/prototype

Build a throwaway prototype to learn from before committing to a design. Runnable terminal app for logic questions, or several UI variants on one route for design questions.

When you say
  • "Prototype this."
  • "Let me play with the data model."
  • "Try a few designs."
Try it like this
"Prototype three different ways the empty state for the dashboard could look. Toggle between them with a query param."
What you get back
A working throwaway you can run and feel: not pretty code, but something you can play with for an hour to learn whether the underlying design is right.

Full skill reference →

/ship-pr

Commit all changes safely, push the branch, and open a pull request with a summary and test plan.

When you say
  • "Ship it."
  • "Open the PR."
  • "Ship the PR."
  • "Done, push it up."
Try it like this
"Ship the PR. Title: feat: bulk-CSV import (rule engine)."
What you get back
Staged commit (skipping .env / credentials / secrets), commit message matching the repo's style, pre-commit hooks passing, PR opened against the default branch with a description and a test-plan checklist.

Full skill reference →

Want the full menu?

The skill catalog lists every one of the 34 engineering skills with the SKILL.md frontmatter, trigger phrases, and source files.

Not on engineering? The main cookbook has the per-team marquee recipes, including the sales pipeline brief and the marketing Monday report.