Workflow Reference

Invoke a skill as $cadre:<name> in Codex, /cadre:<name> in Claude Code, or /cadre-<name> in the Zed Agent.

create

• Use for: project onboarding and interrupted setup.
• Requires: exact root, greenfield/brownfield classification, approved project context, workflow, styleguides, and Git disposition.
• Approval UX: one final authorization envelope combines concise project context, bundled workflow/styleguide identities, amendments, generated path/hash manifest, Git disposition, digest, commits, and provenance. Full defaults remain available on request.
• Primary MCP: template bundle, styleguide resolution, adaptive project_init_candidate, receipt reconciliation through candidate_apply, validation, and derived tracks index.
• Proposal transport: rendered files live under .cadre/stage/create/; MCP receives only their paths and metadata. Base files are staged directly as product.md, guidelines.md, tech-stack.md, workflow.md, and styleguides/general.md; there is no .cadre/init/ directory.
• Writes: initial .cadre/ state and receipt in one initialization commit.
• Stops when: setup is complete; an initialized project routes to refresh or status.

track

• Use for: a new/resumed feature or bug.
• Requires: substantive scope, acceptance, dependencies, and plan evidence.
• Primary MCP: project status, template bundles, candidate_stage_prepare, candidate_inspect, candidate_apply, state validation, and atomic tracks index rendering.
• Candidate recovery: focused status distinguishes an unapproved staged candidate from canonical track state; resume its exact manifest and plan validation instead of restarting it.
• Approvals: one combined specification-and-plan decision by default; staged review only when explicitly requested.
• Writes: state.json, spec.md, plan.md, learning.md, dependency context and receipt in one combined commit.
• Stops at: planned with recorded spec/plan commits.

implement

• Use for: a planned or in_progress track whose dependencies are done; Autonomous can also resume ready_for_review, including a clean result awaiting approval.
• Scheduling: parallel by default with a global ready queue and clean phase-mode handoffs; sequential only when requested.
• Approvals: track by default for track verification and ordinary review approval; phase adds phase gates; governed adds task gates; autonomous continues through verification, review, and remediation until one final clean-completion approval.
• Primary MCP: execution start/node/status/finish, graph validation, worktree create/integrate/cleanup, project/worktree status, and derived index.
• Writes: execution journal, task commits, plan/learning provenance, and one product commit per cohesive change. After execution_finish, one final cadre(implement): complete <track-id> commit contains only the completed journal, plan markers, track state, derived index, and immutable receipt.
• Implementation handoff: ready_for_review; never completed. Autonomous automatically invokes review after bookkeeping and continues in-scope remediation. It returns to the author only after a clean review or a blocker.

review

• Use for: ready_for_review, or interrupted Autonomous review promotion journaled at in_progress.
• Evidence: recorded implementation range, relevant files/callers, tests, requirements, error/security/compatibility paths, and learning.
• Finding path: exact approved bug/remediation artifacts return the track to implementation.
• Clean path: adaptive review_complete binds approval to execution, plan revision, graph digest, reviewed HEAD, accepted risks, and the server- derived range through reviewed HEAD. Autonomous uses its original review baseline across revisions and remediation; other modes use the execution base. Autonomous cannot complete with accepted risks.
• Final decision: after a clean Autonomous review, summarize verification and remediation and present the exact completion proposal. The author can approve without invoking review again or report additional bugs. Changed product or verification inputs require renewed checks/review.
• Stops at: completed only after explicit approval of a clean cycle.

revise

• Use for: changed desired scope, behavior, acceptance, dependency, or plan.
• Requires: lifecycle routing, worker quiescence, partial-work disposition, and transitive dependent-track impact.
• Approvals: one combined revision and cascading-impact decision when partial-work disposition can be assessed safely in advance.
• Writes: revision record and exact approved artifact/state changes with preserved commit provenance.
• Candidate-only behavior: resume the unapproved track proposal; do not create a revision.
• Completed/archived behavior: propose a linked successor; never reopen or move terminal history.

archive

• Use for: one or more tracks already completed by clean review.
• Primary MCP: archive_batch_candidate for approved promotion and candidate_apply for receipt recovery/reconciliation.
• Writes: track moves/status, consolidated patterns, relevant active-track seeds, immutable receipt and derived index in one commit.
• Selection: omitted track IDs select all eligible completed tracks in dependency order.
• Recovery: one ineligible selection rejects the batch before promotion. Approved writes and moves are journaled and resumable after partial progress.
• Stops at: archived.

refresh

• Use for: drift in product, guidelines, workflow, technology, styleguides, patterns, or completed-track learning.
• Evidence: user input, repository changes since setup/last refresh, completed outcomes, and current code/manifests.
• Writes: approved project context, refresh record/journal, affected seeds, derived index and receipt in one commit.
• Active work: execution-governing changes wait for a safe boundary and affected tracks follow revision impact analysis inside the same refresh approval envelope.

revert

• Use for: additive reversal of a Cadre task, phase, or track.
• Requires: exact commit/merge provenance, overlap analysis, dependent impact, and a clean approved reverse-order proposal.
• Git behavior: git revert; merge commits use the correct mainline parent.
• Writes: revert commits, reconciled plan/state/learning, derived index, and provenance.
• Approvals: one on the clean path; a corrected proposal only for material conflict-resolution changes.
• Stops when: conflicts or mixed/missing provenance require manual recovery.
• Lifecycle routing: staged and drafting tracks have no approved revert provenance. Completed/archived rollback intent becomes a linked successor bug track; the terminal source stays immutable.

status

• Use for: progress, blockers, health, and next legal action.
• Primary MCP: one project_status call using the narrow project, track, or implementation view.
• Writes: nothing.
• Reports: setup/operation checkpoints, tracks, dependencies, execution nodes, worktrees, review/archive readiness, validation, and dirty Cadre state.

wisp

• Use for: questions, exploration, investigation, and disposable spikes.
• MCP: optional read-only project status; availability is not required.
• Writes: no Cadre lifecycle state. .cadre/wisps/ is used only for an initialized project that already ignores it; otherwise disposable output uses an OS temporary directory and never creates .cadre/.
• Promotion: recommend track before durable implementation work.

Lifecycle Ownership