@azure-id/orc 0.55.0

package/templates/commands/orc-aftermath.md

@@ -0,0 +1,49 @@
+---
+description: Did what we shipped hold up — graded from the repo's own future, with no telemetry and no verdicts
+---
+
+Use the **orc-aftermath** skill. Read-only and report-only: it never edits the
+rubric, the config, the code, or a run.
+
+`/orc-retro` measures the **process** — bands, downgrades, retries, gate bounces. It
+cannot tell you whether any of it was any good. This measures the **result**, and
+together the score→model table can finally be tuned against *what stuck* instead of
+*what ran smoothly*.
+
+Everyone reaches for production telemetry. For a large class of outcomes **the
+repository's own future is the grading signal**, and it is free:
+
+| Signal | What it suggests | Strength |
+|---|---|---|
+| the commit was reverted | obvious | 3 |
+| a test we added no longer exists | our proof was rejected | 3 |
+| a promise anchored in the change is BROKEN | the change leaked | 3 |
+| a test we added now contains a skip | the proof was neutralised | 2 |
+| 3+ shipped files rewritten in the window | the change likely missed | 2 |
+| 1–2 shipped files rewritten | weak — normal iteration looks like this | 1 |
+
+All of it from `git log`, ORC's traces and the pact ledger. No vendor, no
+instrumentation, nothing to install.
+
+**Churn is a signal, not a verdict.** A file being rewritten is a fact; *why* is not
+knowable from git — somebody may have fixed a real miss, extended a good change, or
+reformatted the file. So every run gets three sections: what it **promised**, what
+the repo now **shows** (each row with its files, commits or pact ids), and the
+strongest AND weakest honest reading of that evidence.
+
+It never writes "this change was bad". **It never names a person** — git knows who
+committed and this lane never asks.
+
+Two answers that are answers, not gaps: a run **younger than 7 days** is `too recent
+to grade`, and it keeps its slot. `HELD` always carries its caveat — *no churn signal
+is not proof it worked, only that nothing came back.*
+
+Output: `orc-aftermath/<period>/aftermath.md`, ending with a structured block
+`/orc-retro` aggregates.
+
+Inside `/orc`: **one preflight line, and only when the area about to be touched has a
+recent churn signal.** Never noise on a clean run.
+
+Read it back any time: `orc aftermath status [--since 14d]`.
+
+A run slug, `--since 14d`, or nothing for the last `aftermath_window_days`: $ARGUMENTS

package/templates/commands/orc-analyze.md

@@ -0,0 +1,21 @@
+---
+description: System Analyst — turn a doc (PDF/pasted) into a scope-bounded, code-grounded requirement report before planning
+---
+
+Use the **orc-analyze** skill (System Analyst). Ingest the provided
+document, auto-detect and confirm its mode (prose vs audit), then **run the
+Standard-vs-Deep gate (Phase A′): offer the depth choice and wait for the
+answer** — default standard, deep = wider sweep + verify-every-claim + scouts,
+never auto-escalated. Tell the user they can preset the default with the
+zero-token CLI `orc config set default_analysis_depth deep` (the run still
+confirms). Then bound to the requested scope only (recognize other scopes only
+to exclude them), map each requirement/row to real files and verify against
+code with quote-anchored file:line evidence (absence claims carry the searches
+run), and challenge scope + accuracy issues — blocking ones one at a time,
+advisory ones in one batched round, all recorded. Write the human report +
+derived requirement spec into `analyst_report/{name}/`; the orchestrator
+spot-checks the evidence and lints the report↔spec derivation before offering
+to take it into a build or leave it as a report. The orchestrator dispatches
+the analysis to a subagent.
+
+Document / scope: $ARGUMENTS

package/templates/commands/orc-boundary.md

@@ -0,0 +1,46 @@
+---
+description: Execute, escalate or refuse — what an agent should not try in this repo, and exactly what would change that
+---
+
+Use the **orc-boundary** skill. Standalone — read-only, no code written, no plan.
+
+Every other skill you can install assumes the answer to *"should the agent do
+this?"* is yes. Agents spend 5×–50× longer than human experts on a task, and most
+of the excess goes into attempts that were never going to succeed.
+
+Three verdicts, one card per **area**:
+
+- **EXECUTE** — dispatch normally. The agent can do this and can tell whether it
+  worked.
+- **ESCALATE** — dispatch, but a named human signs off before ship.
+- **REFUSE** — do not dispatch. **And here is the checklist that would change
+  this.**
+
+**A REFUSE always names what would make it a yes.** "No" with no "unless" is a
+shrug, so a REFUSE with no checklist is treated as a malformed card, not rendered as
+an empty one.
+
+The verdict is derived, not guessed — four questions, each answered from something
+already on disk:
+
+| Question | Answered from |
+|---|---|
+| Can the agent verify itself? | is there a test runner, does the build run, is there a smoke gate |
+| Does it know this area? | `orc wiki status` · `orc pattern status` · `orc gotcha list` · past traces |
+| Is it reversible? | migrations, live payments, deletes, published artifacts, outbound sends |
+| Is it a decision, not a fact? | a decision is yours — that is what ESCALATE is for |
+
+Every card records which answers drove the verdict, so a verdict is always arguable,
+and every card also says **what an agent MAY do here today** — most refused areas
+still have plenty of safe work in them.
+
+**It gates ORC's own dispatch, never you.** Tell ORC to change the migration and ORC
+changes the migration; the card is shown, not enforced against you.
+
+Inside `/orc` (`boundary_gate`, default `warn`): a preflight line and a per-task
+verdict. Set it to `block` and a REFUSE task is **lifted out of its wave** — the wave
+still runs the rest, and the lifted task comes back with its checklist.
+
+Read the cards back any time: `orc boundary status [<path>]`.
+
+What to draw a boundary around (a path, a plan, or nothing and it will ask): $ARGUMENTS

package/templates/commands/orc-brainstorm.md

@@ -0,0 +1,51 @@
+---
+description: Generate options for a problem you have not solved yet — candidates against named thinking lenses, clustered into a few directions, stress-tested, and you pick
+---
+
+Use the **orc-brainstorm** skill. It is standalone — no scan, no plan, no build,
+no code written, and no config key changes how it behaves.
+
+Start from a problem, a goal, or a hunch. *"How should we onboard new
+merchants?"* *"Support queue is drowning us."* *"What should this thing even be
+called?"* **Not restricted to code** — the repo is used when it helps and ignored
+when it does not.
+
+Grill converges one idea you already have. This one **diverges first**: it
+proposes, you judge.
+
+How it runs:
+
+1. **Frame.** What is actually wrong, who it is for, what "better" looks like,
+   what is fixed. Facts it can look up (wiki, code pattern, gotchas, a read-only
+   web lookup) it looks up instead of asking you.
+2. **Diverge.** It generates candidates against named thinking lenses — SCAMPER,
+   inversion, Six Thinking Hats, analogy, constraint-flip, first principles, and
+   what this repo already tried. At least 8 across at least 3 lenses, no cap, and
+   **no criticism at all** in this phase.
+3. **Cluster.** The pool collapses into 3–5 real directions, each with its bet,
+   what must be true, what it costs, and what it kills. Every candidate lands in
+   a direction or in the graveyard **with the reason it lost**.
+4. **Stress.** Now the objections come out: a pre-mortem per direction, the
+   honest worst case and the honest best case. Your own ideas get stressed
+   exactly like its own.
+5. **You pick.** It recommends one and argues for it, then waits. It never picks
+   for you.
+
+**Every menu it prints ends with a slot for the user's own words** — "in your
+words", "mix 1 and 2", "none of these". Your idea enters the pool quoted verbatim
+and gets stress-tested exactly like one of its own.
+
+**It stops and asks before writing anything.** When the picture looks complete it
+says why and asks whether to write it up. Only your yes writes the file.
+
+Then ONE question: save it → `orc/brainstorming-session/<slug>/brainstorm-session.md`
+(the problem in your words, every candidate, the directions, the pick, and one
+paragraph per loser explaining why it lost) · continue into `/orc-analyze` (only
+when the direction is concrete enough for the analyst) · continue into
+`/orc-grill` to sharpen it · or stop and save nothing.
+
+If a decision has to be settled before the options even make sense, it offers to
+borrow `/orc-grill` and **come straight back** with your answers carried over —
+a `RETURN-TO` suspend, never a one-way handoff.
+
+The problem (a sentence is enough): $ARGUMENTS

package/templates/commands/orc-budget.md

@@ -0,0 +1,54 @@
+---
+description: What this plan will cost, in the unit you are actually billed in — tokens, dollars, percent of your window, or context risk
+---
+
+Use the **orc-budget** skill. Read-only, deterministic, never blocks a run.
+
+Account-level burn tracking is already solved. What nothing else can answer is the
+only question that changes a decision: **given THIS plan — 14 tasks, 4 waves, top
+score 78 — what will it burn, and what does each lane burn instead?**
+
+**Tokens are the unit of truth, and there are four of them.** They are never blended,
+because they price completely differently:
+
+| | share | price | |
+|---|---|---|---|
+| fresh input | small | 1× | the uncached prompt |
+| cache write | medium | ~1.25× | a real cost |
+| **cache read** | **usually the largest** | ~0.1× | nearly free, and it dominates the raw count |
+| output | small | ~5× | the most expensive tokens in the run |
+
+"407k tokens" hides that 80% of it is cache reads at a tenth of list. "$7.02" hides
+that on Pro or Max **you do not pay per token at all** — you burn a 5-hour window
+and a weekly ceiling. So the same vector is rendered four ways: **tokens · dollars
+(from a dated price table) · percent of your window · context risk**, and `auto`
+picks the one that matches your plan.
+
+**Context risk is the output nobody else has.** A run can hit compaction, which
+silently degrades quality and is invisible in every spend tool. Because ORC composes
+the slice and the corpus records the peak prompt of every past dispatch, a task
+forecast above 90% of its window is reported **before the wave**, with options:
+split it, drop a doc nobody reads from the slice, or raise the band.
+
+Where the numbers come from: Claude Code's own session transcripts give the cost
+(four token counts, model, `isSidechain`, timestamp); ORC's traces give the meaning
+(task, score, band, expected model, requeues). **Neither is enough alone** — the join
+is why a per-plan forecast is possible here and nowhere else.
+
+Five honesty rules it never bends:
+
+- A forecast is a **range with a sample count**. Never one number.
+- **No dollar figure without a dated price table** (older than 90 days gets a
+  staleness warning), and **no quota figure without a known plan** — it asks once and
+  stores it rather than guessing.
+- Tokens it could not attribute to a task are **always printed**, never dropped.
+- Cache reads get their own p50/p90.
+- With no history: it says so and refuses to invent numbers.
+
+**It needs a PLAN, not a sentence.** Forecasting from a request in words is guessing,
+and a guess that looks computed is worse than no answer.
+
+Also: `orc budget actual <run-slug>` for what a finished run really cost, and
+`orc budget rates` for what your corpus says per band.
+
+The plan file (or `actual <run-slug>`, or nothing for the rates): $ARGUMENTS

package/templates/commands/orc-challenge.md

@@ -0,0 +1,58 @@
+---
+description: Grade a finished artifact against a goal you state — then stop, so you fix it somewhere else
+---
+
+Use the **orc-challenge** skill. Standalone — no plan, no build, no code written.
+
+Every other ORC lane produces something. This one grades a finished thing, writes
+down what is wrong, and then **stops and makes you go and fix it in a different
+session**. The stopping is the point:
+
+> **ORC judges, you fix, ORC re-judges — and ORC never fixes what it judged.**
+
+A session that just wrote the fix will grade its own homework, and it will always
+pass. The separation is the measuring instrument.
+
+**It never guesses what "good" means here.** Intake asks — in one round — what the
+artifact must achieve, who reads it, what you would accept as finished, and what
+template it follows. Those are frozen to disk, and every finding must name which
+of them it serves. A finding that cannot is dropped, because a *defensible*
+finding about the wrong thing is worse than an obviously wrong one.
+
+One iteration:
+
+1. **Lint** — `orc challenge lint` counts what a computer can count: missing
+   sections, sentences over 25 words, undefined acronyms, idioms, `TBD`s,
+   unresolved links. Deterministic, and it costs zero model tokens.
+2. **Cold read** — an agent with `Read` and nothing else answers questions from
+   the artifact alone. It is the only honest way to measure whether a reader with
+   no context can follow it.
+3. **Judge** — grades it against your frozen template and goal, and returns
+   anchored findings, each with a consequence and an acceptance line ("fixed when
+   §4.2 names the retry budget"). **It cannot declare a pass** — the CLI computes
+   that from the findings.
+4. **Advise** (only on a fail) — twelve findings are usually three causes. It
+   groups them, orders them with the reason, and flags the ones that are really
+   unmade decisions.
+5. **Stop** — it writes a fix brief with a paste-ready prompt for a fresh session,
+   and ends the turn.
+
+Then you fix, in a new session, and run `/orc-challenge <slug>` again. Every
+finding from last time gets exactly one outcome and a reason — nothing quietly
+evaporates.
+
+Two ways out of the loop, because a loop with no exit is a trap:
+`orc challenge accept <slug> <id> "reason"` (a known gap: it stops blocking and
+stays visible forever) and `orc challenge rebut <slug> <id> "reason"` (the judge
+is wrong: the next one must answer you).
+
+There is no iteration cap. Each turn is a separate human sitting down to work, so
+it measures instead — `stalled` after three iterations with no progress, with
+three honest options.
+
+It never stages and never commits. Read the state back any time without this
+lane: `orc challenge status <slug>`.
+
+Kinds: `tsd` `prd` `adr` `api-contract` `readme` `runbook` `plan` `code` `mixed`.
+
+The artifact to challenge, or a slug to reopen (or nothing, and it will ask): $ARGUMENTS

package/templates/commands/orc-claude.md

@@ -0,0 +1,14 @@
+---
+description: Build/update/refresh the LOCAL project's CLAUDE.md — scanned facts, fenced sections, 0.0.1 version bumps, zero questions
+---
+
+Use the **orc-claude** skill independently (no orchestrator): build, update,
+or refresh the **local repo's** `CLAUDE.md` from verified repo facts. Auto
+mode: meta header present → section-scoped REFRESH (+0.0.1 bump, DD-MM-YYYY);
+foreign CLAUDE.md → back up to `CLAUDE.md.bak` and merge without trimming a
+single user line; missing → create fresh. Fully non-interactive — P0/Gotchas/
+Glossary are placeholders the user fills themself. Default generated-content
+budget 400 lines (`budget=N` to override, persisted). Never touches the
+orc-wiki block.
+
+Optional arguments (e.g. `budget=600`): $ARGUMENTS

package/templates/commands/orc-diy.md

@@ -0,0 +1,13 @@
+---
+description: Run your CLI-composed custom ORC flow (hard-gated — needs `orc diy init` + `orc diy compile` first; stale/unconfigured offers plain /orc)
+---
+
+Use the **orc-diy** skill. Start at Step 0/1: if the argument is `compile`
+(or `status`), route it to the `orc diy` CLI and relay. Otherwise run the
+hard gate (`orc diy status`): UNCONFIGURED or STALE → explain the CLI fix and
+offer the regular /orc lane (one question, never silent); READY → dispatch
+the compiled flow at `.claude/orc/diy/FLOW-COMPILED.md` as the orchestrator
+spine. Flow shape is configured only via the `orc diy` CLI — never
+in-session.
+
+Request: $ARGUMENTS

package/templates/commands/orc-doc.md

@@ -0,0 +1,128 @@
+---
+description: Write a PRD, TSD, collaboration agreement, report or workflow as portable Markdown — resumable across sessions
+---
+
+Use the **orc-doc** skill. Standalone — no plan, no build, no code written.
+
+You arrive with a context: what you want written down, and about what. You leave
+with a finished Markdown document that imports cleanly into Notion, Obsidian,
+Google Docs, Coda, Craft and GitHub — plus one line that resumes the work months
+later in a brand-new session.
+
+> **The orchestrator never reads the document body.**
+
+That is half the architecture. A 900-line TSD is about 30k tokens; read it three
+times and the session is over. So nothing that holds context ever holds the
+document: the CLI derives a section map (heading, line range, hash), each writer
+owns **exactly one file**, each checker reads **one bounded part**, and the
+orchestrator holds the map and the returns. A 10,000-line document costs the
+orchestrator about 750 lines of context instead of 20,000.
+
+> **`sections/` is the source of truth. `document.md` is a build artifact.**
+
+That is the other half. Every section lives in its own file you can open, edit
+and diff in a pull request — `sections/04-goals-and-metrics.md`, and a big section splits
+into sub-parts underneath without the reader ever knowing. `orc doc compile`
+rebuilds the document from those files, for **zero model tokens**, whenever you
+ask. So a resumed session, an update and a re-check never touch the 10,000-line
+file at all.
+
+Five base templates, and each one is a floor rather than a cage — bring your own
+and its headings become the outline:
+
+`prd` · `tsd` · `collaboration` · `report` · `workflow`
+
+It asks four things, in this order, and the first one blocks:
+
+1. **What do you want this document to say?** No context, no document — it stops
+   and points at `/orc-brainstorm` rather than inventing one.
+2. **Any files I should read first?** "none" is a complete answer. It never reads
+   them itself: one dispatch per file returns anchored claims, not content.
+3. **Do you have your own template?** Otherwise it shows you the shipped section
+   list before writing a word.
+4. **What is it for, who reads it, and what must they be able to do afterwards?**
+   Plus language, type, where it will end up, and how long. Every field has a
+   recommended default; accepting one counts as answering.
+
+Then the outline, confirmed before anything is written — because changing the
+outline after a write wave is what costs money. And one more question: **how much
+do you want written at once?** `partial` writes ONE wave and stops, so you can
+read those section files and redirect before the rest is paid for. That is the
+single biggest saving in the lane.
+
+**Every wave is a stop you can walk away from.** At each boundary you get every
+file path it wrote, a free way to see it as one document, and the one line that
+resumes the work — written to disk *before* anything that needs a subagent. If a
+usage limit kills the run, `orc resume` finds it, and the next session starts at
+the following wave and re-reads nothing it already wrote.
+
+**The document carries content only.** No "Open:" blockquotes, no "Assumption:"
+notes, no ORC bookkeeping of any kind — not in `document.md` and not in a section
+file. It still never invents a fact: what it was not given comes back as a gap,
+lands in `gaps.md`, and is raised with you.
+
+**Your project gets its own house rules.** A plain text file
+(`.claude/orc/doc-house-rules.md`) with three headings — P0, P1, P2 — and as much
+text under each as you want: *"open with a one-paragraph summary"*, *"money
+always carries its currency"*. Stored in your words and read FIRST in every
+dispatch, above ORC's own rules. Each document freezes the text it started with,
+so a rule you change halfway through cannot silently invalidate what is already
+written; `orc doc rules <slug>` names every block that moved since. House rules
+govern what the document SAYS — they can never change how this lane runs, and ORC
+declares that boundary rather than pretending to detect it.
+
+**You never have to remember where you were.** Every stop rewrites
+`RESUME.md` — plain English, the state, and the one line to paste into a brand
+new session — and every question ORC asks you ends by pointing at it.
+
+**Four rules it applies to every document, all free.** No questions or `TBD`s in
+the body (a section your outline calls *open questions* is exempt); what is
+missing is `N/A` plus one short line, never filler; a section well over its
+planned length is a finding; and no `src/foo.ts:42`, no `./relative`, no
+`localhost` — whoever reads a PRD has no repository. Code examples are always
+exempt. A template YOU supply is a cage, not a suggestion: a heading it never had
+is an error, and a part that grew one is refused rather than recorded.
+
+**You are told what it will cost before you pay for it.** Once, before the first
+write wave: how many sections, how many waves, **how many times it will stop**,
+and a token range with its sample count. With no history it refuses to invent
+numbers and offers a price-table floor instead. Afterwards, `orc doc cost <slug>`
+answers "what did this document cost" across **every session it spanned** — per
+role and per section, with a `—` (never a `0`) for anything it cannot join.
+
+**Where it will end up is a real setting, not a nicety.** `orc doc lint` enforces
+that target's actual limits: Notion has three heading levels, so an H4 is an
+error there; Docusaurus needs YAML front matter, so its absence is an error
+there and its presence is an error everywhere else. A hard-wrapped paragraph is
+an error everywhere, because a wrap at 80 columns becomes a line break inside a
+Notion paragraph. The lint is deterministic and costs zero model tokens, and it
+always runs before anything paid.
+
+**Your edits are sacred.** Edit `sections/<id>.md` yourself whenever you like —
+the lane detects it by hash, tells you which sections you touched, and never
+rewrites one unless you name it. And it will not ship a `document.md` that is
+behind its own sections: it refuses and names what moved.
+
+Coming back, in any session:
+
+```
+/orc-doc resume                  lists every document
+/orc-doc resume prd-checkout     a prefix is enough
+```
+
+The new session reads the frozen context, says what you changed, and **stops and
+asks what should change**. It never re-asks what you already answered.
+
+It never edits source, never stages, never commits — it prints the `git add`
+command. And it never grades its own output: at handoff it offers
+`/orc-challenge`, to run in a separate session.
+
+Read the state back any time without this lane: `orc doc status <slug>` for where
+it stands, `orc doc parts <slug>` for what is written — which works before a
+single compile has ever run.
+
+A document started on an older release migrates the first time you touch it.
+`document.md` is split into `sections/` and **never deleted**, a pending edit
+wins, and an unparseable file is refused rather than guessed at.
+
+What you want written, or a slug to reopen (or nothing, and it will ask): $ARGUMENTS

package/templates/commands/orc-explain.md

@@ -0,0 +1,20 @@
+---
+description: Say that again so it lands — re-pitch the last ORC message with the background it assumed and every ORC-only term defined
+---
+
+Use the **orc-explain** skill.
+
+You just read something from ORC that did not land. This says it again properly:
+the point first in one sentence, then the background the message assumed, then a
+plain definition of every ORC-only word it used (band, facet, disposition,
+P0–P3, freshness tier, wave, slice, gate, lane) in this project's own terms —
+and finally what, if anything, is now yours to decide.
+
+**This is not "make it shorter".** It reports that the message did not land, and
+the fix for that is usually more context, not less. A summary of something you
+did not understand is the same thing you did not understand.
+
+Nothing about the run changes: no re-plan, no re-score, no undo. When it is done,
+the run picks up exactly where it was.
+
+Which message (leave empty for the last one): $ARGUMENTS

package/templates/commands/orc-export.md

@@ -0,0 +1,46 @@
+---
+description: Compile everything ORC knows into a portable AGENTS.md — derived, fingerprinted, checkable — or import an existing one
+---
+
+Use the **orc-export** skill. Mostly CLI; no scan, no build, no code written.
+
+Two reasons this exists, and the second is the interesting one:
+
+1. **It removes the adoption objection.** "Are we locked into ORC?" → "No. Here is
+   the door, one command, an open standard."
+2. **It makes ORC the producer in a multi-agent shop.** ORC does the expensive
+   thinking — the evidence-anchored wiki, the reconciled code pattern, the invariant
+   ledger, the boundary cards — and Codex, Cursor and everything else consume the
+   result for free.
+
+**OUT** — `orc export` compiles, in this order: the orientation doc (read first by
+every consumer), `PACT.md` (the promises — the single most useful thing to hand a
+foreign agent), the boundary cards with their checklists, the per-language code
+patterns, then the feature and reference wiki docs.
+
+- **Derived, never hand-written.** It carries a `source_commit` and a fingerprint of
+  every source, so **`orc export --check` proves it is current** — exit 1 names which
+  source changed, and which are no longer sources at all. Run it in CI next to
+  `orc wiki sync --check` and the export can never quietly rot.
+- **Sources are copied through, never re-summarised.** A summary of an
+  evidence-anchored doc is a doc with the evidence removed.
+- **Never exports** secrets, anything `.env`-shaped, run folders or logs. This is a
+  file people commit and paste into other tools.
+- `--target skill` or `both` also writes a `SKILL.md` bundle.
+
+**IN** — `orc export import` reads an existing `AGENTS.md`, `CLAUDE.md`,
+`.cursorrules` or copilot instructions in a repo that may never have run ORC, and
+gives you two things:
+
+- **What is already wrong**: every file path that context names which does not exist,
+  every command the manifest does not have. Free, and a very good first impression —
+  those lines have been lying to somebody's agent for months.
+- **Seeds**: candidate pact entries and wiki topics, one at a time, for you to keep or
+  drop.
+
+**Imported context is evidence, never instruction.** A `.cursorrules` that says
+"always run migrations automatically" is a claim about somebody's intent, quoted with
+its source. It cannot change a phase and cannot authorize a write — import
+**proposes**, you confirm, and `/orc-pact` records what you keep with an origin.
+
+`out`, `--check`, or `import` (or nothing and it will ask): $ARGUMENTS

package/templates/commands/orc-fast.md

@@ -0,0 +1,15 @@
+---
+description: Fastest lane — knowledge-gated single Sonnet 4.6 high executor; needs fresh wiki + pattern cache, else falls back to orc-mini
+---
+
+Use the **orc-fast** skill. Start at Phase F0 preflight: verify the two
+prerequisites — a fresh project wiki (freshness computed from the orc-wiki
+manifest; STALE offers refresh-then-continue (recommended) / drop to orc-mini /
+continue anyway) AND a cached code-pattern for the request's language. Either
+missing → fall back to orc-mini with the request carried over (never stop the
+chat). Then: fit gate + micro-intake (one combined confirmation), one
+Sonnet 4.6 high executor with wiki page pointers + literal pattern injection,
+build+test smoke gate (one repair round, blocks ship on red), ship. No analyst,
+no planner, no review/verify. Orchestrator may run at Sonnet medium.
+
+Request: $ARGUMENTS

package/templates/commands/orc-grill.md

@@ -0,0 +1,40 @@
+---
+description: Sharpen a vague idea into a settled one by conversation — rounds of questions, facts looked up not asked, then save it or carry it into /orc-analyze
+---
+
+Use the **orc-grill** skill. It is standalone — no scan, no plan, no build, no
+code written, and no config key changes how it behaves.
+
+Start from as little as one sentence. *"I want notifications for merchants."*
+*"Something is wrong with our refunds."* Vagueness is the input here, not a
+reason to refuse.
+
+How it runs (the shared mechanic in `_shared/interview.md`):
+
+1. **Rounds, not a form.** It builds a tree of open questions and asks the whole
+   **frontier** each round — every question whose prerequisites are already
+   settled, and nothing that depends on an answer it does not have yet. Each
+   question carries a recommendation, so "1, 3, default the rest" moves the round
+   along.
+2. **Facts are looked up, not asked.** The wiki, the cached code-pattern, the
+   gotcha list, and — last, and announced — a read-only recon dispatch. You are
+   never made to recite your own codebase.
+3. **Decisions are yours.** It recommends and argues, then waits. It never
+   answers its own question and never adopts a default in silence.
+4. **You end it, not an empty question list.** It plays the idea back in plain
+   words and asks whether that is what you meant. Only your yes ends it.
+
+Then ONE question, three answers:
+
+- **Stop here — save it** → `orc-grill/<slug>/grill-context.md` at the project
+  root: what it is in your words, every decision with the reason it was settled,
+  what was ruled out, and the questions talking cannot settle (each pointed at
+  the instrument that can — a mock, or `/orc-analyze`).
+- **Continue into `/orc-analyze`** → the saved doc IS the input, so the analyst
+  spends its tokens grounding the idea in code instead of re-asking scope.
+- **Stop, save nothing.**
+
+There is no question cap. Say "stop asking, just save it" whenever you want, and
+use `/orc-explain` if a round gets dense.
+
+The idea (one sentence is enough): $ARGUMENTS

package/templates/commands/orc-handoff.md

@@ -0,0 +1,52 @@
+---
+description: Change something small yourself — screen text, content, a safe setting — with the check and the undo shown first
+---
+
+Use the **orc-handoff** skill. It is written in simple English on purpose.
+
+You want to change something small, and you should not have to ask an engineer for
+it: the words on a page, a title, a label, a document, a setting with a safe list of
+values, a feature switch.
+
+You do not need to read code. You need two things before you change anything: **will
+something catch my mistake**, and **how do I undo it**. This lane always tells you
+both, before it edits.
+
+**The grade does not come from the file type. It comes from whether a cheap check
+exists.** A settings file with a validator is green; the same file with no validator
+is amber. That is what makes this a real rule and not a feeling.
+
+- 🟢 **GREEN** — change it. A check runs after, and it will catch a mistake.
+- 🟡 **AMBER** — change it. But the check is a person, not a program, and here it is.
+- 🔴 **RED** — this looks like content. It is not. ORC will not touch it, and it says
+  who to ask.
+
+Two modes:
+
+**MAP** — find every file a non-engineer can own, grade each one, and record the
+exact check and the exact undo command for each. Written to
+`orc-handoff/surfaces.md`.
+
+**DO** — change one value:
+
+1. It finds the file and shows the value as it is now.
+2. **One confirmation message**: this is the file, this is the check I will run, this
+   is the command that undoes it. You say yes.
+3. It changes one value, through `orc handoff set` — the same single writer the
+   browser panel uses, so there is only ever one set of rules.
+4. It runs the file's own check and tells you what happened in plain words.
+5. It writes a numbered entry to `orc-handoff/<slug>/handoff-log.md` so you can find
+   it again later.
+
+Things it never does: touch a red file · commit or stage anything (it prints the git
+command) · create a new setting that did not exist · call an amber change "verified"
+when only a person can verify it · change a grade to make an edit possible.
+
+If the job turns out to be bigger than one value, it **offers** `/orc-quick`. An
+offer, never a redirect.
+
+Set `handoff_write` to `false` and this becomes map-only — no writes at all.
+
+Read the map back any time: `orc handoff surfaces`.
+
+What you want to change (or nothing, and it will ask): $ARGUMENTS

package/templates/commands/orc-learn.md

@@ -0,0 +1,17 @@
+---
+description: Generate per-feature onboarding docs (learning.md + knowledge.md) into a git-ignored learning-docs/ — wiki-topic scoped, function-level deep; `refresh` regenerates picked features
+---
+
+Use the **orc-learn** skill independently (no orchestrator): teach a
+developer ONE feature of this repo by generating
+`learning-docs/<feature>/learning.md` (mental model, guided walkthrough,
+change recipes, FAQ) + `knowledge.md` (anchored functions & flow, contracts,
+fingerprints). Topics come from the wiki when it is fresh (then deepened to
+function level); otherwise a targeted scan of the files you point at. Output
+is local and git-ignored — each dev regenerates their own. One question per
+mode: which feature (default), or which features to regenerate (`refresh` —
+full list shown with computed freshness flags, multi-select). The skill
+dispatches the pinned orc-learn-writer agent; it never writes the docs
+itself.
+
+Optional arguments (`refresh`, `focus=<dir-or-hint>`): $ARGUMENTS

package/templates/commands/orc-mini.md

@@ -0,0 +1,12 @@
+---
+description: Lightweight orchestrator — one Sonnet 5 high subagent, skips review/verify/summary
+---
+
+Use the **orc-mini** skill for fast implementation: same intake (lighter — Q1–Q4,
+soft sign-off), intent-spec, planning, run folder, and ship as the full skill, but
+skip full review, verify, and summary. Dispatch ONE Sonnet 5 high-effort subagent
+for implementation (still write tests if the project has them), then run a
+build+test **smoke gate** (blocks ship on red) and an **opt-in test-authoring ask**
+before ship. Switchable to full flow on request.
+
+Request: $ARGUMENTS