| name | implement |
| description | Implement a feature from a spec, plan, or ticket — design, build, test, self-review via the code-reviewer agent, then prep a PR. Manual-invoke only: /implement-workflow:implement <spec, plan, or ticket>. |
Feature Implementation Workflow
Implement the feature described in $ARGUMENTS against this codebase. Work through the steps below as a tracked to-do list, following your project's own conventions — before you start, read whatever convention, architecture, and testing docs the repo provides (e.g. CLAUDE.md, a backend/frontend styleguide, a TESTING.md, an ONBOARDING.md).
If anything about the design, requirements, scope, or review feedback is unclear, stop and ask before proceeding. When a task is unclear or you're unsure which approach to use, ask for clarification rather than assuming.
Step 1 — Understand
- Read the spec and the relevant parts of the codebase. Identify the area/module involved, the layers it touches, and the existing patterns to follow.
- Note the constraints: authorization/permissions, external-system boundaries, and any schema/migration impact.
Step 2 — Design
- Outline your approach: which files change, new data/validation schemas, DB schema + migrations, API surface, and frontend pieces.
- For anything non-trivial, share the plan and get alignment before building. Reuse existing utilities, schemas, and shared UI components rather than introducing new ones.
Step 3 — Implement
- Build the change respecting the project's architecture and its module/import boundaries.
- Route configuration through the project's settings/config layer rather than reading environment variables ad hoc (and update the example env file). Prefer the project's established frontend config, path aliases, and shared styles. Keep types strict — no escape-hatch
any.
- For schema changes: generate a named migration, hand-edit it to be idempotent if your project requires that, then run the migration.
Step 4 — Test
- Write and run tests per your project's testing guide: prefer behavior tests (HTTP status, response shape, persisted state, side effects) over implementation tests, and cover real-world scenarios and edge cases.
- Never write to production or shared external systems in tests. Keep external writes off and mock at the SDK/client boundary. Use synthetic data only — no PII.
Step 5 — Self-review
- Spin up the
implement-workflow:code-reviewer agent (bundled with this plugin) to review your changes against the main branch. Use the plugin-qualified name so a project's own code-reviewer agent doesn't shadow the bundled one.
Step 6 — Address feedback
- Work through the review. For each finding, decide deliberately: fix it, push back with a reason, defer it to a future PR, or raise it with a human. Consider the rationale behind each comment rather than reflexively complying.
Step 7 — Update docs
- Update any affected documentation — convention docs, testing/architecture guides, onboarding, or package READMEs. Skip if nothing structural changed.
Step 8 — Prep the PR
- Get the branch green: run the
ready-to-push skill (tests → lint → build) and fix anything it surfaces.
- Produce a PR title and description in the
suggest-pr format (conventional-commit title, a short Description, and a Changelist), rendered in the conversation — do not create files for it.
- Follow your project's commit/PR rules (conventional commits; honor any co-author / auto-comment policy).
Adapting this workflow to your stack
This skill ships intentionally generic, so each step defers to your repo's own conventions. It was originally tuned for one team's stack — see references/example-profile-trackframe.md for a complete worked example (four-layer architecture, a typed settings layer, idempotent migrations, a multi-track database, and external-system test guards). Use it as a template: copy the parts that fit and replace the specifics with your project's conventions, or wire each step to the docs your repo already has.
