dev-workflow

Write a MADR 4.0.0 architecture decision record into the target repo's docs/decisions/. Use when a significant, hard-to-reverse decision needs recording, or when the build workflow surfaces a discovered decision to ratify. Handles next-number scanning, the filename slug, and the index deterministically via a helper script. Not for work-log decisions (reversible chose-A-over-B notes) -- those go to Linear comments.

Run the role-isolated TDD build workflow against an approved plan file. Invokes the build-isolated-tdd Workflow (test-author != implementer != judge). Explicit-only - this is expensive and side-effecting; invoke with /build, never auto-triggered.

Primary orchestrator. Take a Linear ticket through the full deterministic SDLC to a draft PR: ingest -> plan + ADRs -> role-isolated TDD build -> review -> verify -> draft PR, with human gates. Explicit-only - this is the expensive, multi-phase pipeline; invoke with /implement <TICKET>, never auto-triggered.

Turn a Linear ticket (or a feature description) into a thin, committed repo plan file with per-item BDD acceptance criteria. Use at the start of /implement or standalone via /plan. Produces the spec the role-isolated build workflow consumes. Interactive: reads the ticket, proposes a ceremony tier, drafts the plan, and stops for human approval. Does not design implementation/architecture up front -- that emerges in red->green->refactor.

Single-pass, standards-aware, diff-oriented code review. Reviews whatever is in the diff regardless of author (plugin-built or hand-written) against the plugin philosophy plus the resolved standards cascade (external folder/repo -> repo, repo wins). Use for the CI review action and as a light local pass. NOT the heavy multi-agent separation-of-judgment review (that is the build workflow's Review phase, local-only).