specrails-core 4.12.0 → 5.0.0

package/templates/codex-skills/batch-implement/SKILL.md

@@ -86,60 +86,37 @@ the pipeline yourself):
   > Read `jq '.tickets["<TICKET_ID>"]' .specrails/local-tickets.json`
   > for the full ticket. Follow the `$sr-architect` skill
   > instructions exactly.
-  >
-  > In `design.md`'s `## Context` section, include a
-  > `Scope: <labels>` line drawn from: `frontend`, `backend`,
-  > `both`, `security-sensitive`, `performance-sensitive`.
 
 - `wait_agent`. Parse reply for the plan path. `close_agent`.
-- Open the plan + design.md, parse the `Scope:` line.
+- Open the plan + design.md.
 - If the architect returned `BLOCKED: …`, mark this ticket
   as failed for the batch report and **continue to the next
   ticket** — do not stop the batch.
 
 #### 1.b Developer phase (per ticket)
 
-Routing matrix (mirrors `$implement`):
-
-| scope contains | rails available | spawn |
-|---|---|---|
-| `frontend` only | `sr-frontend-developer` | $sr-frontend-developer |
-| `backend` only | `sr-backend-developer` | $sr-backend-developer |
-| `frontend` only | (no fe specialist) | $sr-developer |
-| `backend` only | (no be specialist) | $sr-developer |
-| `both` + both specialists + tagged tasks.md | — | TWO devs parallel |
-| else | — | $sr-developer |
+One developer rail. Unless a profile routes the ticket to a
+listed `custom-*` developer, spawn `$sr-developer`.
 
 - `spawn_agent`. `send_message`:
 
-  > `$<developer-skill>`
+  > `$sr-developer`
   >
   > Ticket id: `<TICKET_ID>`
   > Plan: `<PLAN_PATH>`
-  > Scope: `<comma-separated labels>`
   >
-  > Follow the `$<developer-skill>` skill instructions exactly.
+  > Follow the `$sr-developer` skill instructions exactly.
 
 - `wait_agent`. Capture file list. `close_agent`.
 - If `BLOCKED: …` → mark ticket as failed in the batch report
   and move to next ticket.
 
-#### 1.c Reviewer phase (per ticket) — parallel where possible
-
-Always spawn `$sr-reviewer`. Additionally if installed AND
-scope matches:
-
-| scope flag | additional rail |
-|---|---|
-| `frontend` | `$sr-frontend-reviewer` |
-| `backend` | `$sr-backend-reviewer` |
-| `security-sensitive` | `$sr-security-reviewer` |
-| `performance-sensitive` | `$sr-performance-reviewer` |
+#### 1.c Reviewer phase (per ticket)
 
-Spawn ALL reviewers in parallel, then `wait_agent` on each.
-`close_agent` each.
+Spawn the single `$sr-reviewer` — it covers correctness, tests,
+security, and performance. `wait_agent`, then `close_agent`.
 
-Aggregate verdicts (same matrix as `$implement`):
+Verdict (same matrix as `$implement`):
 
 - `clean` — every reviewer ≥70, no fix/blocked verdicts.
 - `fix needed` — any "fix needed", OR score <70 with no

package/templates/codex-skills/implement/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: implement
-description: "Implement a single backlog ticket through a multi-phase pipeline: architect plans (OpenSpec proposal+design+tasks+specs), one or more developers code in TDD order, one or more reviewers validate in parallel. Routing is dynamic — the orchestrator inspects which rail skills are installed in .codex/skills/rails/ and spawns the specialists that apply to the change's scope. Reads .specrails/local-tickets.json, closes the ticket in place, reports concisely. Use when the user invokes `$implement #N` or `$implement <free-form>`."
+description: "Implement a single backlog ticket through a multi-phase pipeline: architect plans (OpenSpec proposal+design+tasks+specs), sr-developer codes in TDD order, sr-reviewer validates (correctness, tests, security, performance). A profile may add custom-* rails. Reads .specrails/local-tickets.json, closes the ticket in place, reports concisely. Use when the user invokes `$implement #N` or `$implement <free-form>`."
 license: MIT
 compatibility: "Codex-native. Uses spawn_agent / send_message / wait_agent (full-history forks, no agent_type / model / reasoning_effort). Per-role instructions live in the rail skills; this orchestrator only routes."
 ---
@@ -40,7 +40,7 @@ move on.
 
 **A `clean` run is NOT finished until the change is archived.**
 Archiving (`openspec archive`) is a hard obligation, not an
-optional epilogue — see Phase 5. If you mark a ticket `done`
+optional epilogue — see Phase 4. If you mark a ticket `done`
 without an archived change under `openspec/changes/archive/`,
 you violated this contract.
 
@@ -71,27 +71,14 @@ and gives you a single aggregated report.
     │
     ├─►  PHASE 1: $sr-architect
     │     produces openspec/changes/<slug>/{proposal,design,tasks,specs}
-    │     + a "Scope" tag in design.md
     │
-    ├─►  PHASE 2: developer(s) — routing depends on scope
-    │     scope=frontend → $sr-frontend-developer (if installed)
-    │     scope=backend  → $sr-backend-developer  (if installed)
-    │     scope=both     → spawn BOTH in parallel (tasks.md must be
-    │                       partitioned), OR fall back to $sr-developer
-    │     else           → $sr-developer
+    ├─►  PHASE 2: $sr-developer
+    │     implements every task (tests + docs included per task)
     │
-    ├─►  PHASE 3: reviewer(s) — parallel where installed
-    │     always:  $sr-reviewer  (baseline)
-    │     frontend changes:    $sr-frontend-reviewer  (if installed)
-    │     backend changes:     $sr-backend-reviewer   (if installed)
-    │     security-sensitive:  $sr-security-reviewer  (if installed)
-    │     perf-sensitive:      $sr-performance-reviewer (if installed)
+    ├─►  PHASE 3: $sr-reviewer
+    │     single reviewer — correctness, TDD/spec, security, performance
     │
-    ├─►  PHASE 4 (optional): post-review augmentation
-    │     coverage dropped + $sr-test-writer installed → spawn
-    │     public surface changed + $sr-doc-sync installed → spawn
-    │
-    └─►  PHASE 5: close ticket + report
+    └─►  PHASE 4: close ticket + report
 ```
 
 All spawns are **full-history forks**. NEVER pass `agent_type`,
@@ -109,14 +96,12 @@ the combo and you'll burn a turn on the retry.
    `jq '.tickets["<ID>"]' .specrails/local-tickets.json`
 3. **List the installed rail skills**:
    `ls .codex/skills/rails/`
-   The output drives routing in phases 2-4. Skills that aren't
-   listed are not installed — never spawn them. The three core
-   rails (`sr-architect`, `sr-developer`, `sr-reviewer`) are
-   always present. `sr-merge-resolver` and every layer specialist
-   are optional — spawn them only when listed.
-4. State (≤4 lines) the ticket goal, the stack you detected from
-   a quick `ls`/`find`, and the optional rails that are
-   available. Do NOT plan files-to-touch — that's the
+   The three core rails (`sr-architect`, `sr-developer`,
+   `sr-reviewer`) are always present and are the only first-party
+   rails. A profile may add user-owned `custom-*` rails; spawn a
+   `custom-*` rail only when it is listed.
+4. State (≤4 lines) the ticket goal and the stack you detected from
+   a quick `ls`/`find`. Do NOT plan files-to-touch — that's the
    architect's job.
 
 ### 1. Phase 1 — Architect
@@ -135,161 +120,94 @@ the combo and you'll burn a turn on the retry.
   > for the full ticket. Follow the `$sr-architect` skill
   > instructions exactly.
   >
-  > In `design.md`'s `## Context` section, include a
-  > `Scope: <labels>` line. Labels are a comma-separated set
-  > drawn from: `frontend`, `backend`, `both`, `security-sensitive`,
-  > `performance-sensitive`. Pick the labels that honestly apply
-  > to this change. The orchestrator uses these to route
-  > subsequent phases.
-  >
   > Reply with the one-line summary the skill specifies.
 
 - `wait_agent`. Read the reply. Extract the plan path.
 - `close_agent`. Open the plan file + design.md.
-- **Parse the Scope line** from design.md's Context section.
-  Store the set of labels for use in phases 2-3. If the line is
-  missing, default to scope = `both`.
 
 If the architect replied with `BLOCKED: …`, stop the pipeline,
 write that reason into the final report, and exit without
 updating the ticket.
 
-### 2. Phase 2 — Developer(s)
-
-Routing matrix (`available_rails` is the set from step 0.3,
-`scope` is the parsed set from step 1):
-
-| scope contains   | available_rails has                | spawn |
-|---|---|---|
-| `frontend` only  | `sr-frontend-developer`            | $sr-frontend-developer |
-| `backend` only   | `sr-backend-developer`             | $sr-backend-developer  |
-| `frontend` only  | (no fe specialist)                 | $sr-developer (general) |
-| `backend` only   | (no be specialist)                 | $sr-developer (general) |
-| `both`           | both specialists installed         | TWO devs in parallel (see below) |
-| `both`           | only one or neither specialist     | $sr-developer (general) |
-| neither/unknown  | —                                   | $sr-developer (general) |
+**Design confidence gate.** Read
+`${SPECRAILS_REPO_DIR:-.}/openspec/changes/<slug>/design-confidence.json`
+(the architect writes it as part of its skill). File missing →
+warn and proceed (backward compatible). `high`/`medium` →
+proceed. `low` → **STOP before Phase 2** — implementation is the
+expensive phase and must not run on an unconfident design.
+Report:
 
-**Parallel developer case** (`scope = both` AND both specialists
-installed AND `tasks.md` has tasks tagged `[frontend]` /
-`[backend]`):
+> `BLOCKED: design confidence low — <blocking_question>`
+>
+> Answer the question (edit the ticket description), then re-run
+> `$implement #N`. The OpenSpec artifacts are left in place as a
+> resumable starting point.
 
-- spawn TWO `spawn_agent`s, anonymously named e.g.
-  `developer-fe-#<TICKET_ID>` and `developer-be-#<TICKET_ID>`.
-- `send_message` to the frontend agent: `$sr-frontend-developer
-  ... only run task blocks tagged [frontend] in tasks.md`.
-  Symmetric message to the backend agent.
-- `wait_agent` on BOTH. Aggregate the changed-files list.
-- `close_agent` on both.
+Do NOT update the ticket, do NOT spawn the developer.
 
-If the architect's `tasks.md` doesn't tag task blocks, fall back
-to a single `$sr-developer` invocation — the parallel split
-needs ordered, non-overlapping cycles.
+### 2. Phase 2 — Developer
 
-**Sequential developer case** (default):
+There is one developer rail. Unless an active profile routes the
+ticket to a `custom-*` developer that is listed in step 0.3, spawn
+`$sr-developer`.
 
 - `spawn_agent` (full-history).
 - `send_message`:
 
-  > `$<developer-skill>`
+  > `$sr-developer`
   >
   > Ticket id: `<TICKET_ID>`
   > Plan: `<PLAN_PATH>`
-  > Scope: `<comma-separated labels>`
   >
-  > Follow the `$<developer-skill>` skill instructions exactly.
+  > Follow the `$sr-developer` skill instructions exactly.
 
 - `wait_agent`. Capture file list. `close_agent`.
 
 If the developer returned `BLOCKED: …`, surface it to the user
 in the final report (no review phase, no ticket update).
 
-### 3. Phase 3 — Reviewer(s) in parallel
+### 3. Phase 3 — Reviewer
 
-Always spawn `$sr-reviewer`. In addition, spawn each of the
-following if the rail is installed AND the scope flag applies:
-
-| scope flag                | rail to add (if installed)     |
-|---|---|
-| `frontend`                | `$sr-frontend-reviewer`        |
-| `backend`                 | `$sr-backend-reviewer`         |
-| `security-sensitive`      | `$sr-security-reviewer`        |
-| `performance-sensitive`   | `$sr-performance-reviewer`     |
-
-For each reviewer:
+Spawn the single `$sr-reviewer`. It owns every review dimension —
+correctness, TDD/spec completeness, code quality, security, and
+performance — scaled to what the change touches.
 
 - `spawn_agent` (full-history).
 - `send_message`:
 
-  > `$<reviewer-skill>`
+  > `$sr-reviewer`
   >
   > Ticket id: `<TICKET_ID>`
   > Plan: `<PLAN_PATH>`
   > Changed files:
   > <one per line>
   >
-  > Follow the `$<reviewer-skill>` skill instructions exactly.
-
-**Spawn all reviewers BEFORE waiting** so they run in parallel.
-Then `wait_agent` on each in turn. `close_agent` each as it
-returns.
-
-**Aggregate verdicts**:
-
-- Per reviewer: parse `Score: N/100` and `Verdict: …` from the
-  reply.
-- Overall score = minimum of the reviewer scores (the harshest
-  reviewer is the bound).
-- Overall verdict:
-  - `clean` — every reviewer scored ≥ 70 AND nobody said
-    fix/blocked
-  - `fix needed` — any reviewer said `fix needed: …`, OR any
-    score < 70 with no `blocked: …` verdict, OR any reviewer
-    said `blocked: …` AND the overall score is **in the
-    recoverable range 30-69**. The recoverable-blocked case is
-    the common one where the reviewer used "blocked" because
-    the issue is significant, not because the design itself is
-    wrong — a single developer fix pass can usually clear it
-    (e.g. API surface mismatch, missing JSX component shape,
-    forgotten persistence hook).
-  - `blocked` — any reviewer said `blocked: …` AND overall
-    score is **< 30**, OR every reviewer said `blocked: …`.
-    This is the design-level case where another developer
-    pass won't help — the architect needs to re-engage.
-
-### 4. Phase 4 — Optional augmentation
-
-Run AFTER review is `clean` (or after the single fix-loop pass).
-Skip when the overall verdict is `fix needed` or `blocked` — no
-point sugar-coating an unsound change.
-
-- If `sr-test-writer` is installed AND the reviewer's confidence
-  artefact reports a coverage gap (`tdd_evidence.all_tasks_have_tests`
-  is `false`, or `tdd_evidence.tests_are_non_trivial` is `false`),
-  spawn it with the changed files list. It writes more tests, runs
-  them, reports. (These are the fields the `$sr-reviewer` skill
-  actually writes — do not key on a non-existent "coverage" field.)
-- If `sr-doc-sync` is installed AND the change touches a
-  publicly-documented surface (README mentions a renamed
-  function, AGENTS.md references a removed file, openspec specs
-  drifted), spawn it.
-
-These augment, never block. If they return findings, surface in
-the final report under "Follow-up" rather than reopening the
-ticket.
-
-### 5. Optional fix loop (single pass only)
-
-If phase 3's overall verdict is `fix needed`:
-
-- Spawn ONE follow-up developer (same routing rules as phase 2)
-  with a message that includes every reviewer's `issues[]`
-  array from their confidence artefacts.
+  > Follow the `$sr-reviewer` skill instructions exactly.
+
+- `wait_agent`. `close_agent`.
+
+**Verdict** — parse `Score: N/100` and `Verdict: …` from the reply:
+
+- `clean` — score ≥ 70 AND not fix/blocked.
+- `fix needed` — verdict `fix needed: …`, OR score < 70 with no
+  `blocked: …`, OR `blocked: …` with score **in the recoverable
+  range 30-69** (a single developer fix pass can usually clear it).
+- `blocked` — `blocked: …` with score **< 30**. Design-level; a
+  developer pass won't help — the architect needs to re-engage.
+
+### 4. Optional fix loop (single pass only)
+
+If phase 3's verdict is `fix needed`:
+
+- Spawn ONE follow-up developer (`$sr-developer`, or the same
+  `custom-*` developer used in phase 2) with a message that
+  includes the reviewer's `issues[]` array from its confidence
+  artefact.
 - `wait_agent`. `close_agent`.
-- Re-run phase 3 (same reviewer set). If still `fix needed` or
-  `blocked`, **do not loop again** — surface in the final
-  report.
+- Re-run phase 3. If still `fix needed` or `blocked`, **do not loop
+  again** — surface in the final report.
 
-### 6. Phase 5 — Archive FIRST, then close + report
+### 5. Phase 4 — Archive FIRST, then close + report
 
 > **INVARIANT.** A ticket may be marked `done` ONLY if its change is
 > archived (`openspec/changes/archive/<slug>/` exists). A `clean`

package/templates/codex-skills/rails/sr-architect/SKILL.md

@@ -5,6 +5,12 @@ license: MIT
 compatibility: "Codex-native. Designed to run as a full-history sub-agent fork of the implement orchestrator."
 ---
 
+**Deterministic repo map.** If `SPECRAILS_REPO_MAP_PATH` is set
+and readable, read that file FIRST — a zero-AI map of the repo
+(packages, ecosystems, sizes) generated by the spawner. Use it to
+orient; do not spend turns on top-level discovery. Unset ⇒ explore
+as normal.
+
 You are the **architect** in the specrails implement pipeline. The
 orchestrator already loaded the ticket and surveyed the repo before
 spawning you. Your turn is short, focused, and ends with TWO
@@ -87,18 +93,6 @@ writing code.
 <one paragraph: the system state today, the constraints the
 change must respect, the assumptions you are making.>
 
-Scope: <comma-separated labels — pick honestly from:
-        frontend, backend, both, security-sensitive,
-        performance-sensitive>
-        Examples:
-        - "Scope: frontend"
-        - "Scope: backend, security-sensitive"
-        - "Scope: both, performance-sensitive"
-        The implement orchestrator parses this line to route
-        the developer + reviewer phases. A missing or wrong
-        label means the wrong specialists get spawned (or
-        none at all).
-
 ## Goal
 <one sentence: what observable behaviour you are adding /
 changing.>
@@ -155,12 +149,13 @@ the table.
 
 ## 1. <First testable behaviour>
 - [ ] 1.1 Write a failing test in `<test-path>` that asserts
-       <behaviour>. Run the test runner; the new test MUST fail.
+       <behaviour>. Run that test file (scoped); the new test
+       MUST fail.
 - [ ] 1.2 Implement the minimum production code in `<src-path>`
-       to make the test pass. Run the test runner; ALL tests
-       MUST pass.
-- [ ] 1.3 Refactor if needed without changing behaviour. Run
-       the test runner; all tests still pass.
+       to make the test pass. Re-run that test file (scoped);
+       it MUST pass.
+- [ ] 1.3 Refactor if needed without changing behaviour. Re-run
+       the test files covering the touched files; still green.
 
 ## 2. <Next testable behaviour>
 - [ ] 2.1 Write a failing test...
@@ -272,13 +267,36 @@ written:
    If validation reports structural errors, fix the offending
    artefact and re-run until it passes. Do not hand off a change
    that fails `openspec validate`.
-2. Reply with two lines:
+2. **Emit design confidence** (mandatory). Write
+   `${SPECRAILS_REPO_DIR:-.}/openspec/changes/<slug>/design-confidence.json`:
+   ```json
+   {
+     "schema_version": "1",
+     "change": "<slug>",
+     "agent": "architect",
+     "scored_at": "<ISO 8601>",
+     "confidence": "high | medium | low",
+     "reason": "<1-2 concrete sentences>",
+     "blocking_question": "<one focused question when low, else null>"
+   }
+   ```
+   Rubric — **high**: evidence conclusive, exact files/identifiers
+   located, design unambiguous. **medium**: likely correct but one
+   non-obvious assumption remains (name it in `reason`). **low**:
+   multiple plausible designs and you cannot choose without
+   information you don't have — `blocking_question` is the SINGLE
+   most blocking unknown, phrased so a human can answer it. Never
+   inflate: a `low` with a sharp question is a successful output —
+   it saves the whole implementation cost of building the wrong
+   thing.
+3. Reply with three lines:
    ```
    OpenSpec change: openspec/changes/<slug>/
    Plan written to <plan-path>; files to touch: <comma-separated list>
+   Design confidence: <high|medium|low>[ — blocking question: <question>]
    ```
-3. End your turn. The orchestrator will read your plan + the
-   tasks.md and spawn the developer next.
+4. End your turn. The orchestrator will read your plan + the
+   tasks.md and spawn the developer next (or halt on `low`).
 
 If you cannot produce a plan (ticket is too ambiguous, repo
 state is corrupt, etc.), instead reply with:

package/templates/codex-skills/rails/sr-developer/SKILL.md

@@ -72,9 +72,10 @@ note it in your reply — do not block on the architect.
    a. **RED — write the failing test (step N.1).**
       - Open the test file the task names. Create it if missing.
       - Add the test asserting the behaviour the task names.
-      - Run the test runner. The new test MUST fail. If it
-        unexpectedly passes, your test is wrong (it isn't
-        actually asserting the new behaviour) — rewrite it.
+      - Run **only that test file** (scoped run — e.g.
+        `npx vitest run <file>`, `pytest <file>`). The new test
+        MUST fail. If it unexpectedly passes, your test is wrong
+        (it isn't actually asserting the new behaviour) — rewrite it.
       - Tick `- [x] N.1` in `tasks.md` only when you have
         observed the test fail.
 
@@ -83,16 +84,27 @@ note it in your reply — do not block on the architect.
         modify it.
       - Write the minimum code to make the failing test pass.
         Resist adding code unrelated to the test.
-      - Run the test runner. ALL tests must pass — the new
-        one AND every prior one.
+      - Re-run **only that test file** (`npx vitest run
+        <file>`, `pytest <file>`, …). It must pass. The full
+        suite runs once, at the validation gate — not after
+        every task.
       - Tick `- [x] N.2`.
 
    c. **REFACTOR — clean up (step N.3, if present).**
       - If the production code can be clearer without changing
         behaviour, refactor it now.
-      - Re-run the test runner. All tests still pass.
+      - Re-run the test files covering the files you touched.
+        Still green.
       - Tick `- [x] N.3`.
 
+   **Test-execution economy (MANDATORY):** the full project
+   suite runs exactly ONCE — at the validation gate below.
+   Never run it inside a task cycle. When a scoped run fails,
+   carry forward only the failing test names and the relevant
+   error excerpt (≤50 lines), never a full runner log. If you
+   run the same command 3 times with no intervening code
+   change, STOP re-running and change the code or the test.
+
 3. **Honour the design's invariants and edge cases.** When the
    design's `Public API / surface` says a function takes `(x, y)`
    and returns `Result<Z>`, your code must match that signature
@@ -115,15 +127,22 @@ The final task block in `tasks.md` is always the validation gate
 (`## N. Validation gate`). Run it:
 
 - Full project test suite (e.g. `npm test`, `pytest`,
-  `cargo test`). MUST pass.
+  `cargo test`). MUST pass. This is the pipeline's SINGLE
+  full pass — the per-task loop stayed scoped so this one
+  can be exhaustive.
 - Project build if present (e.g. `npm run build`,
   `cargo build`). MUST succeed.
 - A grep for debug breadcrumbs (`console.log`, `print(`, etc.)
   in the files you touched — none should remain.
 
-If the gate fails, the offending file is your responsibility:
-fix it before handing off. Do not push the gate problem onto
-the reviewer.
+If the gate fails, the offending file is your responsibility.
+Fix it, re-running **only the failing test files** between
+fixes — you have a budget of 2 fix cycles, then ONE final
+full-suite run to confirm. If failures persist after that,
+reply `"BLOCKED: validation gate failing — <failing tests,
+verbatim>"` and end your turn. Never keep looping, never
+weaken or skip tests to force green, never hand a known
+failure silently to the reviewer.
 
 ## What you must NOT do
 

package/templates/codex-skills/rails/sr-reviewer/SKILL.md

@@ -109,16 +109,27 @@ a screenshot/manual-check note in the design's
 "Open questions". A criterion with **no** mapping is a
 blocker finding.
 
-### 5. Re-run the full validation gate
-
-Use the command from the design's `Validation` section in the
-plan artefact (or the final block of `tasks.md`):
-
-- Project test suite (`npm test`, `pytest`, `cargo test`, …).
-  Confirm it passes. Capture the count.
-- Project build if present (`npm run build`, …). Confirm it
-  succeeds.
-- If neither runner exists, run whatever fallback the design
+### 5. Verify the gate — scoped-first
+
+The developer's validation gate already ran the full suite
+green; re-running the whole thing on an untouched tree
+re-buys information the pipeline already has. So:
+
+- Run the tests SCOPED to the diff — the test files covering
+  every changed source file, per-file (`npx vitest run
+  <file>`, `pytest <file>`, `cargo test <name>`, …). Confirm
+  green; capture the count.
+- Run the full suite yourself ONLY when: you modified
+  production code in this review, the diff touches
+  build/config/test infrastructure, or a scoped failure has
+  an unclear blast radius. Then finish with ONE clean full
+  pass (plus the build if present) — never repeated full
+  passes between fixes.
+- If you changed nothing and the scoped runs are green,
+  record the developer's gate as the pass of record — in the
+  confidence artefact set `tests.ran` to the scoped command
+  and say so in `tests.details`.
+- If no test runner exists, run whatever fallback the design
   named (`node --check`, etc.).
 
 ### 6. Write the confidence artefact

package/templates/commands/specrails/doctor.md

@@ -35,7 +35,7 @@ Each check is displayed as ✅ (pass) or ❌ (fail with fix instruction).
 
 On all checks passed:
 ```
-All 6 checks passed. Run /specrails:get-backlog-specs to get started.
+All 6 checks passed. Run /specrails:implement to get started.
 ```
 
 On failure: