nntrivi2001
f0ae876472
Lets a lane's pipeline template be switched live from the dashboard (the same PATCH /api/lanes/:id the CLI's `ccam lanes pipeline` uses), so lanes created before the picker shipped don't need the terminal. Both ship-feature skills now force their own template before their first `ccam stage` call, so the human never has to pick correctly at lane creation.
107 lines
5.4 KiB
Markdown
107 lines
5.4 KiB
Markdown
---
|
|
name: ship-feature
|
|
description: Implement a feature safely end-to-end in this repository. Use when adding or changing functionality across backend, frontend, or MCP with required verification and documentation updates. Drives the Superpowers workflow skills and declares each phase with `ccam stage` so the dashboard's pipeline map follows along.
|
|
---
|
|
|
|
# Ship Feature
|
|
|
|
Use this workflow for medium or large implementation tasks. It does not restate
|
|
how to plan, test, or review — the Superpowers skills own that. What lives here
|
|
is the phase order, this repository's own rules, and the stage declaration at
|
|
each boundary.
|
|
|
|
For a feature inside a CCAM **lane**, use `ship-feature-lane` instead: it adds
|
|
the branch/e2e/QC/senior-gate/PR half this skill deliberately leaves out.
|
|
|
|
## Declaring the stage
|
|
|
|
Each phase below starts with `ccam stage <node>`, which is what puts the phase
|
|
on the lane's pipeline map. The nodes are the `default` template's:
|
|
`intake → plan → implement → tests → review → gate → ship → done`.
|
|
|
|
Set the template yourself, don't rely on how the lane was created: before your
|
|
first `ccam stage` call, run `ccam lanes pipeline default` (no id needed —
|
|
resolves from `cwd`; a no-op if the lane is already on it). This is what makes
|
|
the choice invisible to the human — whichever of `ship-feature` or
|
|
`ship-feature-lane` actually runs is what decides the template, not a picker
|
|
they have to get right in advance.
|
|
|
|
`ccam stage` needs a lane owning the current directory. If it reports no lane,
|
|
this repo was never adopted (`ccam lanes add --cwd $(pwd)` fixes it) — carry on
|
|
with the workflow and skip the stage calls; they are reporting, not control
|
|
flow. Never skip a phase because its stage call failed.
|
|
|
|
Declaring beats detection. The dashboard also *infers* these stages from the
|
|
Superpowers skill invocations below, but an inference never renders `done` and
|
|
never overrides a declaration — and detection cannot move a lane BACKWARD past
|
|
a declared stage, so a rework loop is invisible unless you re-declare the phase
|
|
you dropped back to.
|
|
|
|
## Phases
|
|
|
|
### intake — understand before touching anything
|
|
- `ccam stage intake --status running`
|
|
- Restate the requirement and its success criteria.
|
|
- Explore the impacted modules: `Explore` agent for breadth, then read the key
|
|
files yourself. Identify which layers are hit (server / client / mcp / docs /
|
|
scripts) — `repo-onboarding` if the area is unfamiliar.
|
|
- Requirement fuzzy or open to more than one reading? **superpowers:brainstorming**.
|
|
|
|
### plan — a written plan, challenged before it is code
|
|
- `ccam stage plan`
|
|
- **superpowers:writing-plans**: approach, files to change, the test strategy
|
|
(which behavior each test pins), and how each success criterion is met.
|
|
- If the task is a bug rather than a feature: **superpowers:systematic-debugging**
|
|
first. Root cause, not symptom — and grep every caller of the function you
|
|
are about to change, not just the path the report names.
|
|
|
|
### implement — smallest coherent diff
|
|
- `ccam stage implementing`
|
|
- **superpowers:test-driven-development**: failing test → minimal code → green.
|
|
- Smallest diff that satisfies the requirement. Every changed line traces to it.
|
|
- **file-headers** applies to every source file you create or edit.
|
|
|
|
### tests — this repo's verification, not a claim
|
|
- `ccam stage tests --status running`
|
|
- Backend changed → `npm run test:server`. Frontend → `npm run test:client`.
|
|
MCP → `npm run mcp:typecheck` + `npm run mcp:build`.
|
|
- A UI snapshot diff is reviewed, never blindly regenerated
|
|
(`cd client && npx vitest run -u` only after you have read the diff).
|
|
- Record the outcome: `ccam stage tests --evidence "<what passed>"`, or
|
|
`--result fail` with what failed. A step you could not run is reported as not
|
|
run, never as passed.
|
|
|
|
### review — a real review pass, not a re-read
|
|
- `ccam stage review`
|
|
- Run the **code-review** skill on the working diff, or
|
|
**superpowers:requesting-code-review** when handing it to an agent.
|
|
- Apply what is worth applying with **superpowers:receiving-code-review**
|
|
judgment: verify each point, neither blind agreement nor blind rejection.
|
|
- Changed code in response? Re-run the `tests` phase.
|
|
|
|
### gate — evidence before the completion claim
|
|
- **superpowers:verification-before-completion**. Commands actually run, output
|
|
actually read. This is the phase that stops "should work" from shipping.
|
|
- `ccam stage gate --evidence "<what was verified>"`
|
|
|
|
### ship — docs, then the user's call
|
|
- `ccam stage ship`
|
|
- **update-project-docs** — mandatory for any change to behavior, config,
|
|
interfaces, events, schema, CLI commands, or features. Not optional, not
|
|
deferred, not "if asked".
|
|
- Commit / push / PR **only when the user asks in this turn**. Finishing an
|
|
implementation is not authorization to commit.
|
|
- `ccam stage done --status passed --evidence "<what shipped>"`
|
|
|
|
## This repository's own rules
|
|
|
|
Not restated here. `CLAUDE.md` is loaded in every session and already binds
|
|
them — backward-compatible API/WebSocket contracts, fail-safe hooks,
|
|
migration-safe schema changes, the destructive-lane and git-argv guards, and
|
|
the lane boundaries (the console never writes a stage; the runtime never writes
|
|
`stage`/`status`/`notes`). A second copy here would only drift out of sync with
|
|
the first. Read `CLAUDE.md` and `.claude/rules/` for the area you are touching.
|
|
|
|
## References
|
|
- Checklist template: `references/feature-checklist.md`
|