@azure-id/orc 1.9.0 → 1.9.2

package/templates/skills/orc/subskills/orc-planner-mini/SKILL.md

@@ -1,121 +1,121 @@
----
-name: orc-planner-mini
-description: >
-  Fast-lane Requirement Planner for ORC-MINI (Sonnet 5, high effort). Turns a
-  detailed request OR a System Analyst requirement-spec into orc's
-  planning-output: right-sized tasks, each with grounded declared_files (incl.
-  tests), explicit depends_on, owns_area, and spec_ref — self-checked for
-  dependency cycles, same-file collisions, and requirement coverage. Use when
-  orc-mini needs a fast plan for a well-scoped request — fires on "plan this
-  quickly", "fast task breakdown", "break this into tasks", or after mini doc
-  analysis. Distinct from the full orc-planner (Opus 5 medium — pick that one
-  when the dependency graph is genuinely complex: >8 tasks, deep chains, or
-  many same-file serializations): single-pass, lighter grounding, deep
-  dependency tracing trimmed. The orchestrator dispatches this to a subagent —
-  it never plans itself.
----
-
-# orc-planner-mini
-
-Fast variant of the Requirement Planner, dispatched by orc-mini as a Sonnet 5
-high subagent. Produces the SAME artifact (orc's `schemas/planning-output.md`)
-and follows the SAME input + grounding + branch rules as `../orc-planner/`, which
-is AUTHORITATIVE for the full procedure; the summary below orients.
-
-## Procedure (summary)
-
-1. **Accept** a detailed request OR an analyst requirement-spec. "Too thin to
-   plan" is defined, not felt: plannable ⇔ the request states (a) an observable
-   outcome AND (b) an identifiable repo area it lands in — failing either, do
-   NOT plan; recommend `orc-analyze-mini` (requirement mode) instead.
-2. **Ground** `declared_files[]` in real paths: standalone → read the repo (+ a
-   non-empty `wiki/` — select via `wiki/INDEX.md` keywords; pull `Contracts &
-   shapes` + `Testing map` from the matching docs; code outranks any wiki
-   claim); from-SA → trust the spec's file map, no repo re-read —
-   but NEW paths beyond the spec (tests, new modules) still get their own
-   parent-dir Glob. Fill each task's `grounding[]` attestation (`{path,
-   disposition: exists|new, evidence}`) — never mark `exists` on a path you
-   didn't confirm; the orchestrator Globs every `exists` path and bounces
-   misses back (one retry).
-3. **Draft** right-sized tasks — anchors, not adjectives: normally **1–5
-   declared files, one `owns_area`** per task; >7 files or two unrelated areas
-   → split; ≤~10-line dependency-bound change → merge; deviation needs a
-   one-line reason. Each task carries `depends_on`, `owns_area`, `spec_ref`,
-   `requirements[]` (the R#/DoD ids it implements — `[]` only for pure-infra
-   with a stated reason), `spec_invariants[]` (load-bearing Context & invariants
-   lines copied verbatim — the orchestrator appends them to the executor
-   slice's constraints[]), a `facets` block (breadth = `len(declared_files)`,
-   novelty/logic/test_surface/uncertainty, cited `risk[]` — the orchestrator
-   scores from these; you never compute the score), and a sliced `acceptance[]`
-   where each line cites its source (`R3` / `DoD#2` — a line with no source is
-   invented). **When the caller's slice says `tdd: on`** (orc-mini asked its
-   one intake question and the user said yes), also author each requirement's
-   `tdd_spec` entry — given/when/then + a runnable skeleton in the project's
-   test framework, or `tdd: exempt — <reason>` (schema: planning-output.md).
-4. **Self-check (always — cheap, prevents broken waves):**
-   - **cycle detection** — no `depends_on` chain loops back on itself;
-   - **same-file collision** — two tasks sharing a `declared_files` entry must be
-     merged, or serialized with a dependency;
-   - **coverage** — every in-scope R# / DoD line appears in ≥1 task's
-     `requirements[]`; an orphan requirement is a MALFORMED plan.
-   On a failed check, FIX the plan (merge/split/add-dep/add-task) before
-   presenting — never emit a plan with a cycle, an unserialized collision, or
-   an orphan. The orchestrator recomputes all three at Phase 1 exit and
-   bounces failures (one retry). Deep dependency tracing is trimmed here.
-5. **Ask clearly; step back when unclear:** set `plan_confidence: high|medium|low`
-   (+ reason) and turn every ambiguity into an `open_questions[]` entry
-   (`{question, proposed_default, blocking}`) — never silently pick a reading.
-   `plan_confidence: low` OR >3 blocking questions → recommend stepping back to
-   `orc-analyze-mini` (the user may override).
-6. **Present** the plan once → approve/edit (breakdown/approach only).
-7. **Branch** → take into build (hand back to orc-mini) or save & stop — checkpoint
-   FIRST either way (never a loose plan file with no checkpoint).
-
-## What's trimmed vs the full planner
-
-- **Lighter grounding:** confirms the main file paths rather than exhaustively
-  tracing every reference (standalone case). From-SA case is identical — trust
-  the spec, no repo re-read (new paths still grounded).
-- **Lighter self-check:** cycle + same-file-collision + coverage checks always
-  run (they're cheap and prevent broken waves); deep dependency tracing is
-  trimmed.
-- **Concrete escalation thresholds** (suggest the full `../orc-planner/`, Opus
-  4.8 medium, and let the user choose — not self-assessed vibes): >8 tasks, OR
-  any dependency chain 3+ deep, OR >2 same-file serializations needed.
-- **Model:** Sonnet 5, high effort.
-
-## Checkpoint + hand-back (same as full)
-
-Checkpoint the plan into `orc/planner/{name}/` before branching (never a loose
-file with no checkpoint). On "take into build", hand back to the orchestrator,
-which runs the full Phase 2–8 (scoring, effort table, wave cap, pauses). The
-mini planner never builds directly.
-
-## Identical
-
-- Accepts detailed request OR analyst requirement-spec; refuses requests below
-  the plannable floor.
-- Grounding provenance recorded only when standalone.
-- Show plan once → approve/edit (breakdown/approach only) → branch
-  (take into build / save plan-{name}.md and stop).
-- Plain-language handoffs, dispatched not self-run.
-
-## Return contract (inlined — do not reconstruct from the full planner)
-
-Produce `../orc-planner/`'s artifact — orc's `schemas/planning-output.md`: every
-task with `declared_files` (incl. tests), `grounding[]` (per-file
-exists|new attestation with evidence), `acceptance[]` (sliced, source-cited
-definition-of-done lines), `requirements[]`, `spec_invariants[]`, `facets`
-(breadth/novelty/logic/test_surface/uncertainty + cited `risk[]`), `depends_on`,
-`owns_area`, `spec_ref`; and at the top level `plan_head`, `plan_confidence`, and
-`open_questions[]`. Checkpoint it into `orc/planner/{name}/` before branching.
-Return exactly:
-
-- the `planning-output` (the plan itself) + a plain-language `summary`.
-- `coverage: {requirements: N, tasks: M, orphans: []}` — self-attested; the
-  orchestrator recomputes it and bounces orphans.
-- `actual_model` — quoted verbatim from your system prompt's "The exact model ID
-  is …" line (`unknown` if absent, never guessed).
-- `actual_effort` — `$CLAUDE_EFFORT`.
-
-Never build or spawn.
+---
+name: orc-planner-mini
+description: >
+  Fast-lane Requirement Planner for ORC-MINI (Sonnet 5, high effort). Turns a
+  detailed request OR a System Analyst requirement-spec into orc's
+  planning-output: right-sized tasks, each with grounded declared_files (incl.
+  tests), explicit depends_on, owns_area, and spec_ref — self-checked for
+  dependency cycles, same-file collisions, and requirement coverage. Use when
+  orc-mini needs a fast plan for a well-scoped request — fires on "plan this
+  quickly", "fast task breakdown", "break this into tasks", or after mini doc
+  analysis. Distinct from the full orc-planner (Opus 5.5 medium — pick that one
+  when the dependency graph is genuinely complex: >8 tasks, deep chains, or
+  many same-file serializations): single-pass, lighter grounding, deep
+  dependency tracing trimmed. The orchestrator dispatches this to a subagent —
+  it never plans itself.
+---
+
+# orc-planner-mini
+
+Fast variant of the Requirement Planner, dispatched by orc-mini as a Sonnet 5
+high subagent. Produces the SAME artifact (orc's `schemas/planning-output.md`)
+and follows the SAME input + grounding + branch rules as `../orc-planner/`, which
+is AUTHORITATIVE for the full procedure; the summary below orients.
+
+## Procedure (summary)
+
+1. **Accept** a detailed request OR an analyst requirement-spec. "Too thin to
+   plan" is defined, not felt: plannable ⇔ the request states (a) an observable
+   outcome AND (b) an identifiable repo area it lands in — failing either, do
+   NOT plan; recommend `orc-analyze-mini` (requirement mode) instead.
+2. **Ground** `declared_files[]` in real paths: standalone → read the repo (+ a
+   non-empty `wiki/` — select via `wiki/INDEX.md` keywords; pull `Contracts &
+   shapes` + `Testing map` from the matching docs; code outranks any wiki
+   claim); from-SA → trust the spec's file map, no repo re-read —
+   but NEW paths beyond the spec (tests, new modules) still get their own
+   parent-dir Glob. Fill each task's `grounding[]` attestation (`{path,
+   disposition: exists|new, evidence}`) — never mark `exists` on a path you
+   didn't confirm; the orchestrator Globs every `exists` path and bounces
+   misses back (one retry).
+3. **Draft** right-sized tasks — anchors, not adjectives: normally **1–5
+   declared files, one `owns_area`** per task; >7 files or two unrelated areas
+   → split; ≤~10-line dependency-bound change → merge; deviation needs a
+   one-line reason. Each task carries `depends_on`, `owns_area`, `spec_ref`,
+   `requirements[]` (the R#/DoD ids it implements — `[]` only for pure-infra
+   with a stated reason), `spec_invariants[]` (load-bearing Context & invariants
+   lines copied verbatim — the orchestrator appends them to the executor
+   slice's constraints[]), a `facets` block (breadth = `len(declared_files)`,
+   novelty/logic/test_surface/uncertainty, cited `risk[]` — the orchestrator
+   scores from these; you never compute the score), and a sliced `acceptance[]`
+   where each line cites its source (`R3` / `DoD#2` — a line with no source is
+   invented). **When the caller's slice says `tdd: on`** (orc-mini asked its
+   one intake question and the user said yes), also author each requirement's
+   `tdd_spec` entry — given/when/then + a runnable skeleton in the project's
+   test framework, or `tdd: exempt — <reason>` (schema: planning-output.md).
+4. **Self-check (always — cheap, prevents broken waves):**
+   - **cycle detection** — no `depends_on` chain loops back on itself;
+   - **same-file collision** — two tasks sharing a `declared_files` entry must be
+     merged, or serialized with a dependency;
+   - **coverage** — every in-scope R# / DoD line appears in ≥1 task's
+     `requirements[]`; an orphan requirement is a MALFORMED plan.
+   On a failed check, FIX the plan (merge/split/add-dep/add-task) before
+   presenting — never emit a plan with a cycle, an unserialized collision, or
+   an orphan. The orchestrator recomputes all three at Phase 1 exit and
+   bounces failures (one retry). Deep dependency tracing is trimmed here.
+5. **Ask clearly; step back when unclear:** set `plan_confidence: high|medium|low`
+   (+ reason) and turn every ambiguity into an `open_questions[]` entry
+   (`{question, proposed_default, blocking}`) — never silently pick a reading.
+   `plan_confidence: low` OR >3 blocking questions → recommend stepping back to
+   `orc-analyze-mini` (the user may override).
+6. **Present** the plan once → approve/edit (breakdown/approach only).
+7. **Branch** → take into build (hand back to orc-mini) or save & stop — checkpoint
+   FIRST either way (never a loose plan file with no checkpoint).
+
+## What's trimmed vs the full planner
+
+- **Lighter grounding:** confirms the main file paths rather than exhaustively
+  tracing every reference (standalone case). From-SA case is identical — trust
+  the spec, no repo re-read (new paths still grounded).
+- **Lighter self-check:** cycle + same-file-collision + coverage checks always
+  run (they're cheap and prevent broken waves); deep dependency tracing is
+  trimmed.
+- **Concrete escalation thresholds** (suggest the full `../orc-planner/`, Opus
+  4.8 medium, and let the user choose — not self-assessed vibes): >8 tasks, OR
+  any dependency chain 3+ deep, OR >2 same-file serializations needed.
+- **Model:** Sonnet 5, high effort.
+
+## Checkpoint + hand-back (same as full)
+
+Checkpoint the plan into `orc/planner/{name}/` before branching (never a loose
+file with no checkpoint). On "take into build", hand back to the orchestrator,
+which runs the full Phase 2–8 (scoring, effort table, wave cap, pauses). The
+mini planner never builds directly.
+
+## Identical
+
+- Accepts detailed request OR analyst requirement-spec; refuses requests below
+  the plannable floor.
+- Grounding provenance recorded only when standalone.
+- Show plan once → approve/edit (breakdown/approach only) → branch
+  (take into build / save plan-{name}.md and stop).
+- Plain-language handoffs, dispatched not self-run.
+
+## Return contract (inlined — do not reconstruct from the full planner)
+
+Produce `../orc-planner/`'s artifact — orc's `schemas/planning-output.md`: every
+task with `declared_files` (incl. tests), `grounding[]` (per-file
+exists|new attestation with evidence), `acceptance[]` (sliced, source-cited
+definition-of-done lines), `requirements[]`, `spec_invariants[]`, `facets`
+(breadth/novelty/logic/test_surface/uncertainty + cited `risk[]`), `depends_on`,
+`owns_area`, `spec_ref`; and at the top level `plan_head`, `plan_confidence`, and
+`open_questions[]`. Checkpoint it into `orc/planner/{name}/` before branching.
+Return exactly:
+
+- the `planning-output` (the plan itself) + a plain-language `summary`.
+- `coverage: {requirements: N, tasks: M, orphans: []}` — self-attested; the
+  orchestrator recomputes it and bounces orphans.
+- `actual_model` — quoted verbatim from your system prompt's "The exact model ID
+  is …" line (`unknown` if absent, never guessed).
+- `actual_effort` — `$CLAUDE_EFFORT`.
+
+Never build or spawn.

package/templates/skills/orc/subskills/orc-review-verify/SKILL.md

@@ -1,76 +1,76 @@
----
-name: orc-review-verify
-description: >
-  Review/verify worker for ORC Phases 5–6 (Opus 5 medium). Two modes: a REVIEW
-  pass — examine the changed files against the code pattern + constraints,
-  create/update tests, and classify EVERY finding on the P0–P3 severity
-  ladder (P0/P1 gate ship, P2/P3 advisory); a VERIFY
-  pass — run the build + full test suite and check each intent-spec
-  definition-of-done criterion PLUS the pattern's enforceable validation-gate
-  lines, reporting pass/fail; or an opt-in SECURITY pass — sweep the changed
-  files against a supplied OWASP/STRIDE checklist. Returns findings[] with
-  severity, a tests tally, and a verify result — it reports; the orchestrator
-  owns the auto-fix-once loop. Dispatched in-pipeline after execution; distinct
-  from the standalone /orc-verify (which checks only git-modified changes with no
-  orchestrator). ALWAYS a spawned subagent — not for direct user invocation.
----
-
-# orc-review-verify
-
-One entry point: spawned via the Task tool with `subagent.md` framing + the
-slice, which points to `core.md`. `core.md` is the AUTHORITATIVE spec (full input
-slice, both procedures, return contract); the summary below orients — on any
-conflict, `core.md` wins.
-
-## What the worker does (summary)
-
-- **phase=review:** examine `changed_files[]` against `code_pattern` + `constraints[]`;
-  create/update tests for the changed surface; independently re-check each
-  `invariants[]` rule AND each enforceable `validation_gate[]` line against the
-  diff (a violation is P0), plus any `fe_rules[]` pack rules on FE diffs
-  (file:line findings, P1–P3 by impact, never auto-P0); classify EVERY
-  finding on the ladder — **P0** (failing tests/build, unmet acceptance
-  criteria, runtime errors, invariant violations — caller auto-fixes, no ask),
-  **P1** (correctness/security risk, constraint violations — caller asks the
-  user before fixing), **P2** (maintainability — advisory fix-batch offer),
-  **P3** (cosmetic — advisory, counted). Never fix P2/P3; P0/P1 fixes are the
-  caller's call. **Evidence-or-advisory:** every P0–P2 finding carries
-  `file:line` + the offending line(s) quoted VERBATIM; an unanchored finding is
-  AUTO-P3 (never gates, never triggers a fix) — the caller spot-checks quotes
-  before acting on P0/P1.
-- **phase=verify (two halves, v0.33.0):** FIRST the **TDD gate** — run the
-  plan's TDD suite (`tdd_suite[]` in the slice) plus the build + full test
-  suite; green is the definition-of-done for non-exempt requirements, and each
-  red TDD test is a P0 tied to its requirement (the caller owns the
-  `tdd_loop_max` repair loop). THEN the **adversarial review** — attack the
-  green implementation: edge cases the spec missed, error paths, contract
-  violations, race/ordering, workflow breaks (dead wiring, broken commands) —
-  findings on the same P0–P3 ladder. Also fold the enforceable
-  `validation_gate[]` lines into the criteria set, then check EACH criterion
-  individually (pass/fail, nothing invented; an unmet gate line = unmet
-  criterion = P0), each with per-criterion `evidence` (the test/output line or
-  file:line that proves it); report failures precisely. You don't fix — the
-  caller owns the auto-fix-once loop.
-- **phase=security (opt-in):** sweep only `changed_files[]` against the supplied
-  `security_checklist[]` (wrap Semgrep if installed, never install it); findings
-  on the same ladder (exploitable-in-diff = P0, hardening gap = P1,
-  defense-in-depth = P2/P3). Report-only, no `result` verdict.
-
-## Return shape (summary — full contract in `core.md`)
-
-`{ phase, findings[]{severity: P0|P1|P2|P3, location "file:line", quote (verbatim,
-required P0–P2; unanchored ⇒ AUTO-P3), description, criterion},
-criteria[] (verify only){criterion, result, evidence}, tests{added,updated,passing},
-result (verify only): passed|failed, actual_model, actual_effort, failure_reason }`
-
-**Validation checkpoint before returning:** every finding carries a `severity`
-from the P0–P3 ladder; every P0–P2 finding carries `file:line` + a VERBATIM
-`quote` (else downgrade it to P3 yourself);
-verify sets `result` + per-criterion `evidence`; `actual_model` is quoted
-VERBATIM (never inferred). A
-malformed return is treated as failure by the caller.
-
-Fixed models (from `../../references/effort-and-mode.md`): review on the OpenSpec/self
-path = Opus 5 medium; review on the Superpowers path is delegated to the
-Superpowers review skill instead (Sonnet 4.6 medium). Verify = Opus 5 medium,
-always this subskill.
+---
+name: orc-review-verify
+description: >
+  Review/verify worker for ORC Phases 5–6 (Opus 5.5 medium). Two modes: a REVIEW
+  pass — examine the changed files against the code pattern + constraints,
+  create/update tests, and classify EVERY finding on the P0–P3 severity
+  ladder (P0/P1 gate ship, P2/P3 advisory); a VERIFY
+  pass — run the build + full test suite and check each intent-spec
+  definition-of-done criterion PLUS the pattern's enforceable validation-gate
+  lines, reporting pass/fail; or an opt-in SECURITY pass — sweep the changed
+  files against a supplied OWASP/STRIDE checklist. Returns findings[] with
+  severity, a tests tally, and a verify result — it reports; the orchestrator
+  owns the auto-fix-once loop. Dispatched in-pipeline after execution; distinct
+  from the standalone /orc-verify (which checks only git-modified changes with no
+  orchestrator). ALWAYS a spawned subagent — not for direct user invocation.
+---
+
+# orc-review-verify
+
+One entry point: spawned via the Task tool with `subagent.md` framing + the
+slice, which points to `core.md`. `core.md` is the AUTHORITATIVE spec (full input
+slice, both procedures, return contract); the summary below orients — on any
+conflict, `core.md` wins.
+
+## What the worker does (summary)
+
+- **phase=review:** examine `changed_files[]` against `code_pattern` + `constraints[]`;
+  create/update tests for the changed surface; independently re-check each
+  `invariants[]` rule AND each enforceable `validation_gate[]` line against the
+  diff (a violation is P0), plus any `fe_rules[]` pack rules on FE diffs
+  (file:line findings, P1–P3 by impact, never auto-P0); classify EVERY
+  finding on the ladder — **P0** (failing tests/build, unmet acceptance
+  criteria, runtime errors, invariant violations — caller auto-fixes, no ask),
+  **P1** (correctness/security risk, constraint violations — caller asks the
+  user before fixing), **P2** (maintainability — advisory fix-batch offer),
+  **P3** (cosmetic — advisory, counted). Never fix P2/P3; P0/P1 fixes are the
+  caller's call. **Evidence-or-advisory:** every P0–P2 finding carries
+  `file:line` + the offending line(s) quoted VERBATIM; an unanchored finding is
+  AUTO-P3 (never gates, never triggers a fix) — the caller spot-checks quotes
+  before acting on P0/P1.
+- **phase=verify (two halves, v0.33.0):** FIRST the **TDD gate** — run the
+  plan's TDD suite (`tdd_suite[]` in the slice) plus the build + full test
+  suite; green is the definition-of-done for non-exempt requirements, and each
+  red TDD test is a P0 tied to its requirement (the caller owns the
+  `tdd_loop_max` repair loop). THEN the **adversarial review** — attack the
+  green implementation: edge cases the spec missed, error paths, contract
+  violations, race/ordering, workflow breaks (dead wiring, broken commands) —
+  findings on the same P0–P3 ladder. Also fold the enforceable
+  `validation_gate[]` lines into the criteria set, then check EACH criterion
+  individually (pass/fail, nothing invented; an unmet gate line = unmet
+  criterion = P0), each with per-criterion `evidence` (the test/output line or
+  file:line that proves it); report failures precisely. You don't fix — the
+  caller owns the auto-fix-once loop.
+- **phase=security (opt-in):** sweep only `changed_files[]` against the supplied
+  `security_checklist[]` (wrap Semgrep if installed, never install it); findings
+  on the same ladder (exploitable-in-diff = P0, hardening gap = P1,
+  defense-in-depth = P2/P3). Report-only, no `result` verdict.
+
+## Return shape (summary — full contract in `core.md`)
+
+`{ phase, findings[]{severity: P0|P1|P2|P3, location "file:line", quote (verbatim,
+required P0–P2; unanchored ⇒ AUTO-P3), description, criterion},
+criteria[] (verify only){criterion, result, evidence}, tests{added,updated,passing},
+result (verify only): passed|failed, actual_model, actual_effort, failure_reason }`
+
+**Validation checkpoint before returning:** every finding carries a `severity`
+from the P0–P3 ladder; every P0–P2 finding carries `file:line` + a VERBATIM
+`quote` (else downgrade it to P3 yourself);
+verify sets `result` + per-criterion `evidence`; `actual_model` is quoted
+VERBATIM (never inferred). A
+malformed return is treated as failure by the caller.
+
+Fixed models (from `../../references/effort-and-mode.md`): review on the OpenSpec/self
+path = Opus 5.5 medium; review on the Superpowers path is delegated to the
+Superpowers review skill instead (Sonnet 4.6 medium). Verify = Opus 5.5 medium,
+always this subskill.

package/templates/skills/orc/subskills/orc-testgen/SKILL.md

@@ -1,45 +1,45 @@
----
-name: orc-testgen
-description: >
-  Worker subskill for ORC's opt-in Phase 6.5 (Test Authoring). Fires when the user
-  opts into writing tests ("write test cases", "generate tests", "author test
-  cases for these changes"). Writes test cases as a deliverable — automated test
-  files, a manual TEST-PLAN.md, and (for HTTP/API backends) a Postman-importable
-  curl bundle. It NEVER runs tests and NEVER gates the ship; the user tests
-  manually. ALWAYS invoked as a spawned subagent by the orchestrator. Not for
-  direct user invocation.
----
-
-# orc-testgen
-
-One entry point: spawned via the Task tool with `subagent.md` framing + the
-slice, which points to `core.md` — the AUTHORITATIVE procedure + return contract;
-the summary below orients.
-
-## What the worker does (summary)
-
-1. Take the slice: changed surface (`actual_files`), the intent-spec's
-   definition-of-done (acceptance criteria), touched flows, constraints, detected stack.
-2. Write **automated test files** in the project's framework, covering the changed surface.
-3. Write a manual **TEST-PLAN.md** with two separated sections — "run the automated
-   suite" (exact CLI command) and "exercise the real running service" (manual/curl steps).
-4. For an HTTP/API backend, write a Postman-importable **test-cases.http** curl bundle
-   (env-var placeholders — never real secrets).
-5. Run NOTHING. Advisory `notes[]` may flag a case the code likely won't satisfy.
-
-The manual deliverables (TEST-PLAN.md + test-cases.http) are pinned to
-**`test-generator/<change-slug>/` at the project root** — a visible user
-deliverable, never inside `.claude/` or the run folder (see `core.md`).
-
-**Validation checkpoint before returning:** confirm each promised deliverable
-actually exists on disk **at the pinned path** (test files in the project's
-conventions; TEST-PLAN.md and — when the stack exposes HTTP — test-cases.http
-under `test-generator/<change-slug>/`) before emitting the return contract in `core.md`.
-
-Fixed model: `orc-test-author-opus-5-med` (Opus 5 medium — authoring good
-integration tests is a judgment task). Opt-in: the orchestrator dispatches this
-only when the user accepts the offer, defaulted from `config.generate_tests`. The
-full lane runs it as Phase 6.5 (after Verify, confirmed at intake); **orc-mini
-also offers it** as an end-of-run ask (only on a GREEN smoke gate). Either lane,
-it never runs tests and never gates the ship. orc-mini still skips full
-review/verify.
+---
+name: orc-testgen
+description: >
+  Worker subskill for ORC's opt-in Phase 6.5 (Test Authoring). Fires when the user
+  opts into writing tests ("write test cases", "generate tests", "author test
+  cases for these changes"). Writes test cases as a deliverable — automated test
+  files, a manual TEST-PLAN.md, and (for HTTP/API backends) a Postman-importable
+  curl bundle. It NEVER runs tests and NEVER gates the ship; the user tests
+  manually. ALWAYS invoked as a spawned subagent by the orchestrator. Not for
+  direct user invocation.
+---
+
+# orc-testgen
+
+One entry point: spawned via the Task tool with `subagent.md` framing + the
+slice, which points to `core.md` — the AUTHORITATIVE procedure + return contract;
+the summary below orients.
+
+## What the worker does (summary)
+
+1. Take the slice: changed surface (`actual_files`), the intent-spec's
+   definition-of-done (acceptance criteria), touched flows, constraints, detected stack.
+2. Write **automated test files** in the project's framework, covering the changed surface.
+3. Write a manual **TEST-PLAN.md** with two separated sections — "run the automated
+   suite" (exact CLI command) and "exercise the real running service" (manual/curl steps).
+4. For an HTTP/API backend, write a Postman-importable **test-cases.http** curl bundle
+   (env-var placeholders — never real secrets).
+5. Run NOTHING. Advisory `notes[]` may flag a case the code likely won't satisfy.
+
+The manual deliverables (TEST-PLAN.md + test-cases.http) are pinned to
+**`test-generator/<change-slug>/` at the project root** — a visible user
+deliverable, never inside `.claude/` or the run folder (see `core.md`).
+
+**Validation checkpoint before returning:** confirm each promised deliverable
+actually exists on disk **at the pinned path** (test files in the project's
+conventions; TEST-PLAN.md and — when the stack exposes HTTP — test-cases.http
+under `test-generator/<change-slug>/`) before emitting the return contract in `core.md`.
+
+Fixed model: `orc-test-author-opus-5-med` (Opus 5.5 medium — authoring good
+integration tests is a judgment task). Opt-in: the orchestrator dispatches this
+only when the user accepts the offer, defaulted from `config.generate_tests`. The
+full lane runs it as Phase 6.5 (after Verify, confirmed at intake); **orc-mini
+also offers it** as an end-of-run ask (only on a GREEN smoke gate). Either lane,
+it never runs tests and never gates the ship. orc-mini still skips full
+review/verify.

package/templates/skills/orc-analyze/SKILL.md

@@ -17,7 +17,7 @@ description: >
 # ORC-ANALYZE (System Analyst)
 
 The orchestrator stays on top and **dispatches a System Analyst subagent
-(Opus 5, high)** to do this work — it never analyzes itself, keeping its own
+(Opus 5.5, high)** to do this work — it never analyzes itself, keeping its own
 context lean. This skill defines what that subagent does, how the orchestrator
 runs the standard/deep gate + scout dispatch, and how it relays challenges and
 branches on the result.
@@ -33,7 +33,7 @@ the user meant.
 ## Hard rules
 
 1. **Dispatched, not self-run.** The orchestrator coordinates; the Analyst
-   subagent (Opus 5 high) reads the source, reads the code, and reconciles.
+   subagent (Opus 5.5 high) reads the source, reads the code, and reconciles.
 2. **Evidence-or-mark (never hallucinate) — quote-anchored.** Every
    requirement interpretation and code claim carries `file:line — "verbatim
    snippet"` evidence (≤1 line, quoted not paraphrased; no quote →

package/templates/skills/orc-analyze/examples/analyze-mock.md

@@ -1,42 +1,42 @@
-# Example — Annotated System Analysis (dry run)
-
-A: = analyst (Opus 5 high) · U: = user. Nothing real. Bounds the DELIVERABLE to
-the asked scope; every claim is grounded with file:line evidence OR marked an
-assumption and turned into a question. The orchestrator dispatches this — it never
-analyzes itself.
-
-U: /orc-analyze  security-audit.pdf — implement the AUTH findings only
-
-## Mode + scope
-A: [reads the PDF] Mode: AUDIT (structured findings sheet). Scope X = auth.
-   Payments and logging findings exist in the doc — recognized only to EXCLUDE them
-   (they never become tasks). Depth gate: standard or deep? (default standard)
-U: standard
-
-## Ground against real code (evidence-or-mark)
-A: Finding A1 "login lacks rate-limit" → CONFIRMED, auth/login.py:33 has no limiter.
-   Finding A2 "JWT uses HS256, should be RS256" → auth/token.py:12 uses HS256 ✓ real.
-   Finding A3 "missing UUID check on /reset" → ⚠ STALE: reset.py:20 renamed that field
-     to `token_id` and DOES validate it. Marking A3 UNVERIFIED → question.
-
-## Challenge (recommended options, one at a time)
-A: A3 looks stale against the code. Options:
-   (a) Drop A3 — code already validates (RECOMMENDED: evidence at reset.py:20).
-   (b) Keep A3 — you know of a gap the diff doesn't show.
-U: (a) drop it
-
-## Adjacent context (anchored, do-not-build)
-A: A2's RS256 switch depends on the key-loading in config/keys.py — captured as
-   "Additional context (do not build)", anchored to A2, so the build respects it
-   without treating it as a task.
-
-## Artifacts + branch
-A: Writes orc/analyzer/auth-audit/report.md (Evidence column + Assumptions & Open
-   Questions) + derived requirement-spec.md. handoff_ready: true.
-   Keep as report, or take into build?
-U: take into build   → hands both files to /orc, which plans from the spec (no
-   re-questioning of scope — it's already settled).
-
-## (Phase F) Another related doc?
-A: You could analyze a related doc in this same scope; once 2+ related analyses
-   exist I'll offer context-combiner to merge them into one spec. [not needed here]
+# Example — Annotated System Analysis (dry run)
+
+A: = analyst (Opus 5.5 high) · U: = user. Nothing real. Bounds the DELIVERABLE to
+the asked scope; every claim is grounded with file:line evidence OR marked an
+assumption and turned into a question. The orchestrator dispatches this — it never
+analyzes itself.
+
+U: /orc-analyze  security-audit.pdf — implement the AUTH findings only
+
+## Mode + scope
+A: [reads the PDF] Mode: AUDIT (structured findings sheet). Scope X = auth.
+   Payments and logging findings exist in the doc — recognized only to EXCLUDE them
+   (they never become tasks). Depth gate: standard or deep? (default standard)
+U: standard
+
+## Ground against real code (evidence-or-mark)
+A: Finding A1 "login lacks rate-limit" → CONFIRMED, auth/login.py:33 has no limiter.
+   Finding A2 "JWT uses HS256, should be RS256" → auth/token.py:12 uses HS256 ✓ real.
+   Finding A3 "missing UUID check on /reset" → ⚠ STALE: reset.py:20 renamed that field
+     to `token_id` and DOES validate it. Marking A3 UNVERIFIED → question.
+
+## Challenge (recommended options, one at a time)
+A: A3 looks stale against the code. Options:
+   (a) Drop A3 — code already validates (RECOMMENDED: evidence at reset.py:20).
+   (b) Keep A3 — you know of a gap the diff doesn't show.
+U: (a) drop it
+
+## Adjacent context (anchored, do-not-build)
+A: A2's RS256 switch depends on the key-loading in config/keys.py — captured as
+   "Additional context (do not build)", anchored to A2, so the build respects it
+   without treating it as a task.
+
+## Artifacts + branch
+A: Writes orc/analyzer/auth-audit/report.md (Evidence column + Assumptions & Open
+   Questions) + derived requirement-spec.md. handoff_ready: true.
+   Keep as report, or take into build?
+U: take into build   → hands both files to /orc, which plans from the spec (no
+   re-questioning of scope — it's already settled).
+
+## (Phase F) Another related doc?
+A: You could analyze a related doc in this same scope; once 2+ related analyses
+   exist I'll offer context-combiner to merge them into one spec. [not needed here]