Engineering

Skills (34)

Each skill auto-triggers when its description matches what you're doing, or you can invoke explicitly via the slash command.

• /engineering:architecture

  Create or evaluate an architecture decision record (ADR). Use when choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints.

• /engineering:careful-review

  Re-read the code you just wrote (and anything else you modified) with fresh eyes and look hard for bugs, errors, awkward design, dead code, or things that will confuse the next reader. Then fix what you find. Use after a batch of edits, when the user says "careful review", "look it over again", "give it another pass", or before opening a PR.

• /engineering:code-review

  Review code changes for security, performance, and correctness. Trigger with a PR URL or diff, "review this before I merge", "is this code safe?", or when checking a change for N+1 queries, injection risks, missing edge cases, or error handling gaps.

• /engineering:codex-review

  Lowest severity to fix automatically — "p0", "p1" (default), or "p2".

• /engineering:debug

  Structured debugging session — reproduce, isolate, diagnose, and fix. Trigger with an error message or stack trace, "this works in staging but not prod", "something broke after the deploy", or when behavior diverges from expected and the cause isn't obvious.

• /engineering:deploy-checklist

  Pre-deployment verification checklist. Use when about to ship a release, deploying a change with database migrations or feature flags, verifying CI status and approvals before going to production, or documenting rollback triggers ahead of time.

• /engineering:diagnose

  Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.

• /engineering:documentation

  Write and maintain technical documentation. Trigger with "write docs for", "document this", "create a README", "write a runbook", "onboarding guide", or when the user needs help with any form of technical writing — API docs, architecture docs, or operational runbooks.

• /engineering:e2e-test

  Run a comprehensive end-to-end test of an app against real backend + frontend dev servers, with mocks disabled. Hits API endpoints directly, then drives the UI through a browser, and produces a PASS / FAIL summary. Use when user wants to run a full E2E sweep, says "test everything end to end", "smoke test the app", or wants to verify a release before shipping.

• /engineering:find-missing-tests

  Survey a module, file, or PR for missing test coverage. Produce a specific, non-hallucinated list of test cases that should exist, with enough detail that another developer (or agent) can implement them. Optionally open GitHub issues for each gap. Use when user says "find missing tests", "what's not tested?", or wants a test backlog for a piece of code.

• /engineering:git-guardrails-claude-code

  Set up Claude Code hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Claude Code.

• /engineering:grill-me

  Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

• /engineering:grill-with-docs

  Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

• /engineering:implement

  Implement an existing epic as a chain of stacked PRs, one per sub-issue, in order. Use when user wants to implement an epic, build out a planned feature, or execute on a `/spec`-produced plan. Pairs with `/spec` (planning) and `/review` (PR comment handling).

• /engineering:improve-codebase-architecture

  Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.

• /engineering:incident-response

  Run an incident response workflow — triage, communicate, and write postmortem. Trigger with "we have an incident", "production is down", an alert that needs severity assessment, a status update mid-incident, or when writing a blameless postmortem after resolution.

• /engineering:next

  Reset the working tree between tasks. Checks out a clean `dummy` branch rebased on latest `main` so the next task starts from a known good state. Use when user says "next", "start fresh", "reset for the next thing", or wants to clear out a finished branch before starting new work.

• /engineering:prototype

  Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".

• /engineering:review

  Address PR review comments interactively. Fetch comments, group by file, triage each one (fix or decline with reasoning), and post inline replies. Use when user says "address the PR comments", "go through the review", or wants to clear a review queue on an open PR. Distinct from `/code-review`, which reviews code before it's merged.

• /engineering:security-review

  Security-focused review of a code change or module. Covers OWASP top-10 risks (injection, auth bypass, IDOR, SSRF, secrets in code, unsafe deserialization) plus language-specific footguns. Produce a prioritized list of findings with concrete fixes. Use when user says "security review", "is this safe?", "check for vulnerabilities", or before exposing new code to untrusted input.

• /engineering:setup-engineering-skills

  Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.md and `docs/agents/` so the engineering skills know this repo's issue tracker (GitHub or local markdown), triage label vocabulary, and domain doc layout. Run before first use of `to-issues`, `to-prd`, `triage`, `diagnose`, `tdd`, `improve-codebase-architecture`, or `zoom-out` — or if those skills appear to be missing context about the issue tracker, triage labels, or domain docs.

• /engineering:setup-pre-commit

  Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.

• /engineering:ship-pr

  Commit all changes, push the current branch, and open a pull request against the default branch. Stages safely (skips .env / credentials / secrets), writes a commit message that matches the repo's style, runs through pre-commit hooks, and creates the PR with a summary and test plan. Use when user says "ship it", "open a PR", "ship the PR", or has finished a unit of work and wants it reviewed.

• /engineering:spec

  Refine a feature into a tracked epic with ordered sub-issues, each mapping to one PR. Use when user wants to spec a feature, plan a feature, break a feature into issues, or scope a new initiative. Does NOT write code — hand off to `/implement` when ready to build.

• /engineering:standup

  Generate a standup update from recent activity. Use when preparing for daily standup, summarizing yesterday's commits and PRs and ticket moves, formatting work into yesterday/today/blockers, or structuring a few rough notes into a shareable update.

• /engineering:system-design

  Design systems, services, and architectures. Trigger with "design a system for", "how should we architect", "system design for", "what's the right architecture for", or when the user needs help with API design, data modeling, or service boundaries.

• /engineering:tdd

  Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.

• /engineering:tech-debt

  Identify, categorize, and prioritize technical debt. Trigger with "tech debt", "technical debt audit", "what should we refactor", "code health", or when the user asks about code quality, refactoring priorities, or maintenance backlog.

• /engineering:testing-strategy

  Design test strategies and test plans. Trigger with "how should we test", "test strategy for", "write tests for", "test plan", "what tests do we need", or when the user needs help with testing approaches, coverage, or test architecture.

• /engineering:to-issues

  Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

• /engineering:to-prd

  Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.

• /engineering:topr

  Rebase a stacked PR onto the latest origin/main, correctly dropping commits already merged via squash-and-merge. Use when user wants to refresh a stacked PR after an earlier PR in the stack merged, or says "rebase this PR on main".

• /engineering:triage

  Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.

• /engineering:zoom-out

  Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.

Connectors

MCP servers this plugin integrates with, grouped by category. Bundled servers are pre-configured in .mcp.json. Alternatives slot in via the ~~category placeholder pattern.

How MCP and connectors work → · Full CONNECTORS.md on GitHub →

Source

• Path: plugins/engineering
• Author: Anthropic + Pace contributors
• Version: v2.0.0
• License: Apache 2.0
• Upstream: anthropics/knowledge-work-plugins/engineering

Pace imports this plugin verbatim from upstream. We don't edit it here; customize by forking to a new directory (e.g. plugins/engineering-gb/) and registering it separately in the marketplace.