Files

T

nntrivi2001 67edda77eb feat(lanes): make the pipeline map track a skill's real progress

A lane's pipeline map only ever moved when a skill remembered to call
`ccam stage`, and the ship-feature template shipped with no detection rules
at all — so a lane driven by Superpowers skills sat at whatever stage it
last declared, and the `gates` node was never declared by anything.

Detection (`detect` rules on each node) now covers the Superpowers skill
invocations and the `ccam`/`gh` commands the ship-feature-lane skill
actually runs. It stays a safety net, not the mechanism: forward-only,
never `done`, never overriding a declaration. Two rules were deliberately
left out — `git diff` on `review` (this repo's own tests record it pinning
a lane at `review` on a real session) and anything on `merged`/`done`.

Stage vocabulary grows to 50 names over the same 16 nodes, following
Shipyard's PHASES shape: sub-states like `migration-collision`,
`e2e-scoped` and `gate-blocked` say WHY a lane sits on a node without the
map growing a node per reason. Every alias has a source — the skill
declares it, `default.json` uses it, or Shipyard's PHASES lists it.

Two silent failures fixed along the way:

- `lane.stages` is keyed by the raw declared string, so a stage declared
  under an alias lost its `--evidence` and rendered amber instead of
  green. `stageRecords` resolves each key onto its node.
- `ccam stage <typo>` stored fine and then rendered nowhere. It now warns
  on stderr while still exiting 0.

`ccam lanes pipeline` closes the gap that made all of this invisible: a
lane could only be assigned a template at creation, and no screen in the
web UI offers the choice, so every lane added from "+ Add lane" was stuck
on `default`'s 8 nodes. An unknown template id is now refused rather than
silently falling back to `default` on read.

Also merges the repo's own `ship-feature` skill into the Superpowers
workflow: it delegates planning/TDD/review/verification instead of
restating them, and declares a stage at each phase.

2026-08-07 09:34:20 +07:00

5.0 KiB

Raw Blame History

name, description

name	description
ship-feature	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.

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

5.0 KiB Raw Blame History