regent-code 3.0.0

package/.opencode/skills/ship/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: ship
+description: "Evidence-gated delivery lane of the Publisher: verify fresh, check scope, commit, push, open the PR, and hand the merge decision to the sovereign. Use when the orchestrator's Phase 5 hits Done, or on /regent/ship. Stacks on verification-before-completion."
+---
+
+# Ship — Publisher (布官)
+
+The Publisher's delivery lane. Evidence first, judgement after. Stacks on `verification-before-completion`: a ship is the last completion claim, and no completion claim stands without fresh evidence.
+
+Invoked by the orchestrator at Phase 5 (Done → ship) and by `/regent/ship`.
+
+## 1. Evidence gate first
+
+Run the project's verification commands **fresh, yourself**: format:check, lint, typecheck, tests — or the repo's `npm run verify`. Then run `verify` (requirements from Phase 1) and `changed-files` (what subagents actually touched).
+
+**Block ship** on: any unverified change (evidence-gate warning in `verify`, or `changed-files` listing work with no verification step), or stale verified evidence (`freshness.stale > 0`). No fresh evidence, no ship. Re-run, don't rationalize.
+
+## 2. Scope check
+
+`git status` + `git diff --stat` against the plan's task list (`docs/superpowers/plans/<slug>/tasks.md`). Confirm only intended files changed. Anything unplanned: either it genuinely belongs to this ship (justify it, note it) or it's scope you didn't command — stop and ask. Principle III: surgical precision.
+
+## 3. Commit
+
+One clean single-concern commit: imperative subject, body answering "what and why", no co-authored-by theater. Never `--amend` after push; never force-push (the Regent guardrail blocks it anyway); never commit over uncommitted unrelated work — stash or commit it separately first.
+
+## 4. Push + PR
+
+Push, then open the PR. Body lists:
+
+- requirements the work satisfies (from the spec in `docs/superpowers/specs/`),
+- fresh evidence cited (command + output, `verify` result, `code-review` verdict),
+- pending issues (review findings, task concerns, unresolved items).
+
+## 5. Stay human
+
+**Never merge, never deploy.** Land/merge stays the sovereign's call. The report ends with an explicit "merge is your call" — the publisher publishes; the sovereign decides.
+
+## 6. WIP discipline for long runs
+
+During long runs, checkpoint WIP with a `[regent-context]` block in a commit or scratch file: decisions made, remaining work, failed approaches. A crash resumes from that block via `handoff` — without it, the run's memory dies with the session.
+
+**Completion criterion:** evidence fresh (stale = 0, gates green), scope intentional (diff matches the plan), commit + push + PR created, sovereign informed with "merge is your call". `/regent/status` reports lane state; run `/regent/review` before `/regent/ship` on non-trivial work.

package/.opencode/skills/spec/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: spec
+description: Produce the Regent specification artifact (docs/superpowers/specs/YYYY-MM-DD-<topic>.md) from the clarified conversation. Use when the orchestrator Phase 1 reaches design capture or when /regent/spec is invoked.
+---
+
+# Spec — Strategist (谋官)
+
+Phase 1 artifact producer. Synthesizes what `grilling` settled into the durable spec the whole pipeline verifies against. Governed by CONSTITUTION.md Principle I (Think Before Decree).
+
+## When invoked
+
+- Orchestrator Phase 1 — after `grilling` empties the frontier and the user confirms shared understanding, before the design gate.
+- `/regent/spec`.
+
+## Process
+
+### 1. Domain awareness (before writing anything)
+
+- Read `CONTEXT.md`, `docs/adr/`, `UBIQUITOUS_LANGUAGE.md` for vocabulary. Use the project's domain language throughout.
+- Respect ADRs in the area. Recorded decisions are not relitigated.
+- Create lazily per Regent convention: `CONTEXT.md` when a term is resolved, `docs/adr/` when a decision is made.
+- Unknown codebase? Run `zoom-out` or `explore(query="project structure")`; run `research(...)` for external patterns.
+
+### 2. Sketch the test seams
+
+- Prefer existing seams. Use the highest seam possible. Fewer seams across the codebase is better — the ideal number is one.
+- Propose new seams at the highest point you can.
+- Check with the user that the seams match their expectations before writing.
+
+### 3. Write the artifact
+
+Path: `docs/superpowers/specs/YYYY-MM-DD-<topic>.md` (today's date; topic slug from the goal). Sections, in order:
+
+**Problem Statement** — the problem, from the user's perspective.
+
+**Solution** — the solution, from the user's perspective.
+
+**User Stories** — a long, numbered list in the format "As an <actor>, I want a <feature>, so that <benefit>". Exhaustive: cover every aspect of the feature.
+
+**Implementation Decisions** — modules built or modified, their interfaces, architectural decisions, schema changes, API contracts, specific interactions, technical clarifications. Do NOT include file paths or code. Exception: a decision-rich snippet from a `prototype` (state machine, reducer, schema, type shape) may be inlined within its decision, trimmed to the decision only, and noted as prototype-derived.
+
+**Testing Decisions** — what makes a good test (external behavior only, never implementation details), which modules are tested, prior art (similar tests already in the codebase), and the chosen seam.
+
+**Out of Scope** — what this spec deliberately excludes.
+
+**Further Notes** — anything that fits nowhere above.
+
+### 4. Self-review
+
+- [ ] No TBD / TODO / placeholder
+- [ ] No contradictions between sections
+- [ ] No scope creep beyond the user's goal
+- [ ] Vocabulary matches the project's domain language
+
+### 5. Gate
+
+Ask the Strategist gate: **"Is this design correct?"** Do not proceed without user confirmation. On approval, this spec becomes the `requirements` source for `verify` (Phase 4) and the input to `tickets` (Phase 2).
+
+## Completion criteria
+
+The artifact exists at the spec path, the self-review passes, and the gate question is answered yes. This phase produces the spec only — no planning, ticketing, or implementation.

package/.opencode/skills/tdd/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: tdd
+description: Use when writing production code, fixing bugs, refactoring, or when the user requests TDD or red-green-refactor.
+---
+
+# TDD — Fleet Commander (舰官)
+
+Iron Law of the Fleet Commander: NO CODE WITHOUT FAILING TEST FIRST. Governed by CONSTITUTION.md Principles II (Simplicity) and IV (Goal-Driven).
+
+## The Iron Law
+
+**NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST.**
+
+If you wrote production code before a test, delete it. Start over. No exceptions. Not "keep it as reference." Not "well, the test would be awkward." Not "this is different because it's simple." Delete it.
+
+## Red-Green-Refactor
+
+Each cycle tackles exactly one behavior. Do not batch behaviors into one cycle.
+
+### RED — Write one failing test
+
+- One behavior per test. Clear test name that describes the behavior.
+- Use real code where possible. Mock only at system boundaries: external APIs, databases, time, randomness.
+- Do NOT mock your own code, your own modules, or internal collaborators.
+- The test should demonstrate the API you wish you had.
+
+### VERIFY RED — Mandatory
+
+Run the test. Watch it fail. Confirm:
+
+- The failure message matches what you expect ("expected X but got undefined", not "cannot read property of undefined")
+- It fails because the feature is missing, not because of a typo in the test itself
+
+**If you did not watch the test fail, you do not know whether it tests the right thing.**
+
+### GREEN — Write minimal code to pass
+
+- Write the simplest, most direct code that makes the test pass.
+- No extra features. No YAGNI. No "while I'm here."
+- Duplication is acceptable at this stage. Refactor comes next.
+
+### VERIFY GREEN — Mandatory
+
+Run the test. Watch it pass. Confirm:
+
+- The new test passes
+- All existing tests still pass
+
+### REFACTOR — Clean up
+
+- Remove duplication. Extract helpers. Improve names.
+- Keep tests green throughout.
+- If refactoring breaks a test, you changed behavior, not structure.
+
+## Anti-pattern: Horizontal slices
+
+Do NOT write all tests first and then implement. That is not TDD — it's test-after with extra steps. You lose the feedback loop that makes TDD valuable. Each test validates the specific code you just wrote. Write one test. Make it pass. Write the next test. One behavior at a time.
+
+## Good tests
+
+| Property         | What it means                                                                   |
+| ---------------- | ------------------------------------------------------------------------------- |
+| **Minimal**      | Tests exactly one thing. If it fails, you know what broke.                      |
+| **Clear**        | Test name = behavior description. Reader knows intent without reading the body. |
+| **Shows intent** | Demonstrates the desired API. Callers read tests as documentation.              |
+
+## When to mock
+
+Only at **system boundaries**: the seam where your code meets something you don't control.
+
+```
+YOUR CODE → [ Mock Here ] → External API
+YOUR CODE → [ Mock Here ] → Database
+YOUR CODE → [ Mock Here ] → Time / Randomness
+```
+
+Do NOT mock:
+
+- Your own functions, classes, or modules
+- Internal collaborators within the same module
+- Code you own and control
+
+## Red Flags
+
+| Behavior                           | Problem                                                     |
+| ---------------------------------- | ----------------------------------------------------------- |
+| Writing implementation before test | Violates Iron Law. Delete it.                               |
+| Writing all tests then all code    | Horizontal slices. Not TDD.                                 |
+| Test passes immediately            | You wrote a test for existing code. That's test-after.      |
+| Can't think of how to test         | Write the API you wish you had. The test shapes the design. |
+| Mocking everything                 | Your code is too coupled. Simplify.                         |
+| "Let me skip verification"         | Skipping verification voids the guarantee.                  |
+
+## Rationalization Prevention
+
+| Excuse                                             | Reality                                                        |
+| -------------------------------------------------- | -------------------------------------------------------------- |
+| "I'll just write the code first as a reference"    | The reference becomes the implementation. Delete it.           |
+| "This is too simple to need TDD"                   | Simple things have hidden edge cases. TDD finds them.          |
+| "I'm being pragmatic"                              | "Pragmatic" = rationalization for skipping discipline.         |
+| "Deleting the code is wasteful"                    | Keeping untested code is more wasteful. You'll debug it later. |
+| "The test is obvious, I don't need to see it fail" | You do. Always.                                                |

package/.opencode/skills/tickets/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: tickets
+description: Break an approved spec into an ordered task plan under docs/superpowers/plans/<slug>/ (plan.md + tasks.md) with explicit blocking edges. Use when the orchestrator Phase 2 builds the task plan or when /regent/plan is invoked.
+---
+
+# Tickets — Architect (构官)
+
+Phase 2 artifact producer. Turns the approved spec into a dependency graph of tracer-bullet tasks the Fleet Commander can dispatch as-is. Governed by CONSTITUTION.md Principle II (Simplicity is Sovereign).
+
+## When invoked
+
+- Orchestrator Phase 2, after the spec gate passes.
+- `/regent/plan`.
+
+## Process
+
+### 1. Gather context
+
+Read the spec at `docs/superpowers/specs/YYYY-MM-DD-<topic>.md`, or the path the user passes. Work from the conversation. Use the project's domain vocabulary from `CONTEXT.md` / `UBIQUITOUS_LANGUAGE.md`; respect ADRs.
+
+### 2. Explore for prefactoring
+
+Use `explore()` (and `delegate()` or `zoom-out` for deep dives) to understand the files and modules that will be touched. Look for prefactors that make the change easy: "make the change easy, then make the easy change." Prefactoring lands as its own first task, ahead of the slices it enables.
+
+### 3. Draft vertical slices
+
+Tracer-bullet rules:
+
+- Each task cuts a narrow but COMPLETE path through every layer (schema → API → UI → tests). Vertical, never one layer.
+- A completed task is demoable or verifiable on its own.
+- Each task fits a single fresh context window.
+- Blocking edges are explicit: every task lists which tasks must finish before it starts; `blocked_by: None` means it can start immediately.
+
+**Wide refactors are the exception.** One mechanical change with codebase-wide blast radius cannot land as a green slice. Sequence it as expand–contract: expand (add the new form beside the old, nothing breaks) → migrate call sites in batches sized by blast radius (each batch its own task, CI green batch to batch) → contract (delete the old form once no caller remains, blocked by every migrate batch). When even batches cannot stay green alone, they share an integration branch behind a final integrate-and-verify task; green is promised only there.
+
+### 4. Quiz the user
+
+Present the breakdown: task id, title, blocked by, what it delivers. Ask:
+
+- Does the granularity feel right? (too coarse / too fine)
+- Are the blocking edges correct — does each task depend only on what genuinely gates it?
+- Should any tasks be merged or split?
+
+Iterate until the user approves. No approval, no plan.
+
+### 5. Write the artifacts
+
+`docs/superpowers/plans/<slug>/plan.md`:
+
+- Dependency levels (Level 1 = no deps, parallel; Level N = sequential)
+- Parallelization strategy — Level 1 tasks go to `delegate_many`, Level N to `delegate` as blockers resolve
+- Files to create/modify — concrete paths allowed here, and only here
+
+`docs/superpowers/plans/<slug>/tasks.md`, one entry per task:
+
+- `T<N>` id and title
+- What it delivers — the end-to-end behavior from the user's perspective, NOT a layer-by-layer implementation list
+- Blocked by — task ids, or None
+- Acceptance criteria — executable binary checks (a command to run, a test scenario, a visible result), each pass/fail with no interpretation
+
+Avoid specific file paths and code snippets inside task entries: they go stale fast. Exception: a prototype snippet that encodes a decision more precisely than prose (state machine, schema, type shape) may be inlined, prototype-credited, and trimmed to the decision.
+
+**No placeholders.** Every task concrete enough to `delegate`: exact boundaries, exact verification. "Add appropriate error handling" is not a task. Each task should sit inside the orchestrator's sizing: 1-3 files, 2-15 minutes. Code tasks follow `tdd` (failing test first); tasks inside a buggy area may need `diagnose` first; tasks testing an unknown design may need `prototype`.
+
+### 6. The frontier
+
+The frontier is every task whose blockers are all done. That set is exactly what the Fleet Commander's `delegate_many` consumes in Phase 3. If tasks remain but the frontier is empty, the graph is disconnected — fix the edges.
+
+## Completion criteria
+
+plan.md and tasks.md exist at the paths above; the user approved the breakdown; no placeholders; every acceptance criterion is a binary check; the frontier is computable from tasks.md alone. This phase produces the plan only — do not execute or modify source.

package/.opencode/skills/using-regent/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: using-regent
+description: Regent bootstrap instructions for regent-code; use when explaining or debugging Regent orchestration behavior.
+---
+
+# Regent Bootstrap
+
+Read `CONSTITUTION.md` at repo root. It defines:
+
+- Court identity and 6 roles (Strategist, Architect, Fleet Commander, Inspector, Publisher, Mentor)
+- 4 Karpathy principles (Think Before Decree, Simplicity is Sovereign, Surgical Precision, Goal-Driven Execution)
+- Chain of command with sequential gated phases
+- 5 Iron Laws with enforcement rules
+
+## Tool Catalog
+
+| Tool                                                                 | What It Does             | When                                    |
+| -------------------------------------------------------------------- | ------------------------ | --------------------------------------- |
+| `delegate({ task, context, expected_output, agent? })`               | Single focused subagent  | Well-defined independent task           |
+| `delegate_many({ tasks: [{ id, task, context, expected_output, agent? }] })` | Parallel subagents       | Multiple independent tasks              |
+| `research({ questions: [{ id, question, scope?, agent? }] })`        | Parallel research agents | Need information from multiple angles   |
+| `explore({ query, focus? })`                                         | Codebase analysis        | Need to understand project structure    |
+| `verify({ requirements, implementation_context, session_id? })`      | Compliance check         | Need to confirm work meets requirements |
+| `changed-files({ session_id?, task_id? })`                           | View files changed by subagent dispatches | Track what each worker touched |
+
+## Command Catalog
+
+| Command          | Routes To                            | Purpose                            |
+| ---------------- | ------------------------------------ | ---------------------------------- |
+| `/regent/orchestrate` | orchestrator skill               | Full pipeline from goal to shipped |
+| `/regent/delegate`    | delegate tool                    | Single subagent task               |
+| `/regent/research`    | research tool                    | Parallel research                  |
+| `/regent/tdd`         | tdd skill                        | Red-green-refactor cycle           |
+| `/regent/diagnose`    | diagnose skill                   | Systematic debugging               |
+| `/regent/verify`      | verification-before-completion skill | Evidence gate                  |
+| `/regent/review`      | code-review skill                | Two-axis adversarial review        |
+| `/regent/spec`        | spec skill                       | Write the spec artifact            |
+| `/regent/plan`        | tickets skill                    | Break plan into ordered tickets    |
+| `/regent/ship`        | ship skill                       | Evidence-gated commit/push/PR      |
+| `/regent/status`      | (inline)                         | Pipeline state + next action       |
+| `/regent/accept`      | orchestrator Phase 5 gate        | Human acceptance of completed work |
+
+## Skills Map (closed loop)
+
+Every skill sits on the pipeline; each phase invokes its ministers' skills, and each skill hands off to the next:
+
+| Phase | Roles | Skills invoked | Artifact |
+| ----- | ----- | -------------- | -------- |
+| 1 Clarify | Strategist | `grilling` → `spec` | `docs/superpowers/specs/YYYY-MM-DD-<topic>.md` |
+| 2 Plan | Architect | `tickets`, `worktrees` (parallel scopes) | `docs/superpowers/plans/<slug>/plan.md` + `tasks.md` |
+| 3 Execute | Fleet Commander | `tdd`, `prototype`, `diagnose`, `worktrees`, `wizard`, `merge-conflicts`, `code-review` | code + tests + evidence |
+| 4 Verify | Inspector | `verification-before-completion`, `code-review` verdict | `verify()` result, `compliant: true` |
+| 5 Report | Publisher | `ship`, `handoff` | report; shipped or handed off |
+| Anytime | Mentor | `zoom-out` | orientation |
+
+Artifact conventions: spec under `docs/superpowers/specs/`, plan under `docs/superpowers/plans/`, run state at `docs/superpowers/run/state.json` (phase, spec, plan, acceptance). The Regent shell guardrail blocks destructive commands (`rm -rf` on root/home, force-push, `git clean -f`, `git reset --hard`, DB drop/truncate) before they execute.
+
+`agent` is an optional child-capable agent ID override on dispatching tools. V2 `subtask: true` metadata does not create child sessions; Regent dispatch creates real child sessions through the plugin API. Worker routing falls back to the built-in `general` when no configured child-capable worker is available.
+
+## Red Flags
+
+| Thought                             | Reality                                             |
+| ----------------------------------- | --------------------------------------------------- |
+| "This is just a simple question"    | Questions are tasks. Check for skills.              |
+| "I need context before deciding"    | Skills tell you how to gather context. Check first. |
+| "Let me explore the codebase first" | Skill check comes before exploration.               |
+| "This doesn't need a formal skill"  | If a skill exists, use it.                          |
+| "The skill is overkill for this"    | The skills exist because the alternative is worse.  |
+| "I'll just do this one thing first" | No. Check first.                                    |
+| "I remember what the skill says"    | Skills evolve. Read the current version.            |
+| "This feels productive"             | Undisciplined action is waste. Skills prevent this. |

package/.opencode/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: verification-before-completion
+description: Use before claiming work is done, fixed, ready, passing, complete, or successful; requires fresh verification evidence.
+---
+
+# Verification Before Completion — Inspector (监官)
+
+Iron Law of the Inspector: NO COMPLETION WITHOUT FRESH EVIDENCE. Governed by CONSTITUTION.md Iron Law 4.
+
+## The Iron Law
+
+**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.**
+
+Fresh means run right now, not "it was working earlier." Verification means you have the output in front of you, not "I remember it passing." Evidence means test output showing 0 failures, not "seems fine."
+
+## The Gate Function
+
+### 1. IDENTIFY
+
+What command proves the claim?
+
+- "Tests pass" → requires test output showing 0 failures
+- "Linter clean" → requires linter output showing 0 errors
+- "Build succeeds" → requires build command with exit code 0
+- "Bug is fixed" → requires the original reproducing scenario to pass
+- "Feature is complete" → requires the acceptance criteria to be met
+
+### 2. RUN
+
+Execute the full command. Not a subset. Not "the relevant tests." Not a dry run. The actual command that proves the claim.
+
+### 3. READ
+
+Read the full output. Check the exit code. Count failures, errors, warnings, and any unexpected output.
+
+### 4. VERIFY
+
+Does the output confirm the claim?
+
+- Tests: "Tests: 12 passed, 0 failed" → verified
+- Linter: "No errors found" → verified
+- Build: exit code 0 → verified
+
+### 5. CLAIM
+
+Only now may you say it works, it's done, or proceed to the next step.
+
+## Common Failures
+
+| Claim               | Required Evidence                      | Not Sufficient                   |
+| ------------------- | -------------------------------------- | -------------------------------- |
+| Tests pass          | Full test output: "X passed, 0 failed" | "All tests should pass now"      |
+| Linter clean        | Linter output: "0 errors, 0 warnings"  | "I fixed the lint issues"        |
+| Build succeeds      | Build command exit code 0              | "Build was working earlier"      |
+| Bug fixed           | Original repro scenario passes         | "I changed the relevant code"    |
+| Feature complete    | Acceptance criteria met, one by one    | "I implemented the main parts"   |
+| Coverage sufficient | Coverage report above threshold        | "I added tests for the new code" |
+
+## Red Flags
+
+| Says                    | Actually Means                     |
+| ----------------------- | ---------------------------------- |
+| "should pass now"       | Not verified                       |
+| "probably works"        | Not verified                       |
+| "seems correct"         | Not verified                       |
+| "I think it's fixed"    | Not verified                       |
+| "it was working before" | Not fresh evidence                 |
+| "the tests look right"  | Not run                            |
+| "the change is trivial" | Most likely to break something     |
+| "just this once"        | The exception that proves the rule |
+
+## When to apply
+
+- Before saying "it works"
+- Before saying "it's done"
+- Before committing
+- Before creating a PR
+- Before marking a task complete
+- Before moving to the next task
+- Before expressing satisfaction with results
+
+Every time. No exceptions. No shortcuts. Fresh evidence or it did not happen.

package/.opencode/skills/wizard/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: wizard
+description: "Generate an interactive bash wizard that walks a human through steps only they can perform: provisioning infrastructure, credentials or CI secrets, unfamiliar third-party dashboards, one-off migrations or cutovers. Use when the orchestrator's Phase 1 clarify asks how secrets will be provisioned, when Phase 3 execution is blocked on human steps, or during /regent/plan planning. Do not invoke for steps the agent can perform itself."
+---
+
+# Wizard — Strategist (谋官) / Fleet Commander (舰官)
+
+A **wizard** is a bash script that walks a human step by step through a manual procedure that's tedious to do by hand and tedious to re-explain to an AI every time. It opens each URL, says exactly what to click and copy, captures the values, writes them where they belong (`.env`, GitHub secrets), confirms at every stage, and shows how many stages are left.
+
+The delightful UX is already solved by `template.sh` — the library above the `STAGES` marker is identical in every wizard; that consistency is the point: **never hand-edit it**. Helpers: `stage`, `say`/`step`, `open_url`, `ask`/`ask_secret`, `write_env`, `set_secret`/`set_var`, `pause`/`confirm`, `TOTAL_STAGES`. Your job is only to scope the procedure and author its stages.
+
+A wizard is ephemeral by default: built for one run, saved to a scratch or `scripts/` path, deleted when the job's done. Commit it only when the sovereign wants a repeatable setup path that should live in the repo.
+
+## Process
+
+### 1. Scope the procedure
+
+Work out every manual step the human must take and every value captured along the way. Read the repo first, don't ask cold:
+
+- For setup: `.env`, `.env.example`, `.env.*`, `README`, `docker-compose*`, framework config, and `.github/workflows/*` (every `secrets.*` / `vars.*` reference is a value the wizard must produce).
+- For a migration or transition: the current state, the target state, and the irreversible actions between them.
+
+Then show the sovereign the ordered list of stages and the values each produces, and confirm: they may add, drop, or reorder.
+
+**Done when:** every stage is named in order, and for each captured value you know (a) where the human gets it, (b) where it's written (`.env`, a GitHub secret, both, or nowhere; some stages are pure actions), and (c) whether it's secret (hidden entry) or public.
+
+### 2. Map each stage's journey
+
+For each stage, write the precise path a human follows: which URL to open, what to do there, where a value is shown, which variable it fills: e.g. "Dashboard → Developers → API keys → Reveal test key → copy". Where you don't actually know the current UI or the exact command, say so and ask the sovereign or check the docs: **never invent steps that may not exist.**
+
+**Done when:** every stage traces to concrete instructions a stranger could follow.
+
+### 3. Author the wizard
+
+Copy `template.sh` to the target path. Replace the example stage with one `stage` per step, in dependency order. Set `TOTAL_STAGES` to the number of stages you wrote. Hold the bar the template sets: open the URL before asking for its value, `ask_secret` for anything secret, `write_env` every persisted value, `set_secret` only the values CI actually needs, and `confirm` before any irreversible action. Each `stage` clears the screen so only the current step is visible: keep a stage to one focused task so nothing the human needs scrolls away. Don't touch the library above the marker.
+
+### 4. Verify and hand off
+
+- `bash -n <script>`; run `shellcheck` if available; `chmod +x <script>`.
+- Don't run it end-to-end yourself: it opens browsers and blocks on human input. Trace it statically instead: every value from step 1 is captured and lands where step 1 said, and every `set_secret` name exactly matches a `secrets.*` reference in CI.
+- Hand to the sovereign with run instructions. If it's a repeatable setup path, commit it and link it from the README so the next person runs the script instead of asking an AI.
+
+## Regent frame
+
+Invoked by the orchestrator in Phase 1 clarify ("how will secrets be provisioned?"), Phase 3 execute (blocked-on-human steps, provisioning dashboards, one-off migrations/cutovers), and `/regent/plan` planning. While the wizard runs, the lane pauses: mark the stage in `docs/superpowers/run/state.json`; once the human returns the values, resume via `handoff` and feed them into the run.

package/.opencode/skills/worktrees/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: worktrees
+description: "Parallel-isolation protocol for the Fleet Commander: run Level-1 plan tasks with disjoint file scopes in separate git worktrees, then integrate one at a time. Use in the orchestrator's Phase 2 planning (when the plan has two or more parallelizable tasks) and Phase 3 execution (before delegate_many dispatch)."
+---
+
+# Worktrees — Fleet Commander (舰官)
+
+Parallel isolation: every parallel task runs in its own worktree, so no subagent steps on another's working tree. One task, one branch, one checkout.
+
+## When to isolate
+
+Two or more **Level-1** tasks (no dependencies) with **disjoint file scopes** in `docs/superpowers/plans/<slug>/tasks.md`. If two tasks share or overlap any file, they never run in parallel — sequence them. Overlap first, parallelism second.
+
+## How
+
+1. **Create**: from the repo root, `git worktree add .worktrees/<taskId> -b regent/<taskId>` where `<taskId>` is the plan's `T<N>` id. Never inside another worktree. The repo root's `.worktrees/` is git-ignored. **Cap: at most 3 concurrent worktrees** — the plan's Level-1 set must fit it.
+2. **Bootstrap** each worktree: copy `.env*` if the task needs them, install dependencies, run the repo's setup. A worktree that can't build is not dispatchable.
+3. **Dispatch**: `delegate`/`delegate_many` with `location.directory` (or tool context directory) pointing at the worktree. The subagent commits onto `regent/<taskId>`; it never touches the main checkout's branch. Feed it the task text from the plan.
+
+## Overlap oracle
+
+Before any parallel dispatch, compare the per-task file lists (each task's scope, straight from the plan) side by side. Any overlap → sequence those tasks, however small the overlap. Run the oracle once, before dispatch — not after conflicts appear.
+
+## Integrate
+
+1. On the main worktree, merge each branch back: `git merge regent/<taskId>`.
+2. Run the project's checks after each merge.
+3. Any conflict → load `merge-conflicts`. Resolve, never discard.
+4. **Serialize the finish.** Parallel work only: integration and PR creation are a queue of one.
+
+## Cleanup
+
+After a green merge, `git worktree remove .worktrees/<taskId>` (with `--force` only after confirming the merge landed). **Crash safety:** never delete a worktree with uncommitted work — commit or stash first, or the subagent's output is lost.
+
+## Evidence
+
+Record per task: worktree id, branch, commits, merge result. `changed-files` confirms what each lane touched; `verify` re-checks the merged tree; the Inspector's `code-review` reviews the integrated diff against the spec.
+
+**Completion criterion:** every parallel task ran in isolation on its own branch, merged green onto the main worktree, worktrees removed, evidence recorded for Phase 4.

package/.opencode/skills/zoom-out/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: zoom-out
+description: Use when entering an unfamiliar code area or when broader structure, dependencies, and data flow need explanation.
+---
+
+# Zoom Out — Mentor (教官)
+
+Regent court's senior engineer on orientation duty. Builds mental models, transfers codebase literacy. Governed by CONSTITUTION.md Principle I (Think Before Decree).
+
+## What to look for
+
+Answer these questions, in order:
+
+1. **What does this directory contain?** Read the top-level files and subdirectories. Look for README, package.json, index files.
+
+2. **What is the entry point?** How is the code in this area invoked? Find the callers, the exports, the route registrations.
+
+3. **What are the key modules and their responsibilities?** For each module in the area, summarize its purpose in one sentence. If you cannot do that in one sentence, the module may need splitting.
+
+4. **How do they communicate?** Direct calls? Events? Shared state? A database? Network?
+
+5. **What are the data flows?** Trace a complete request/operation through the modules. Where does data enter, transform, persist, and exit?
+
+6. **What tests exist?** Check `*.test.*`, `*.spec.*`, `__tests__/`, `test/`. The test files tell you what the authors considered important.
+
+## Techniques
+
+- **Start broad, then narrow.** Read the top-level directory first. Then the relevant subdirectory. Then the relevant file. Do not dive into a single file until you know where it sits.
+
+- **Follow the imports.** Start at the entry point (route handler, main function, exported API). Follow the imports to understand the dependency graph.
+
+- **Run the tests.** If tests exist, run them. They confirm your understanding of expected behavior.
+
+- **Check the docs.** Read CONTEXT.md for domain vocabulary, `docs/adr/` for architectural decisions, any README files in the area.
+
+## Output
+
+Provide a structural summary: the directory layout, the key modules, the data flow, and where tests live. Use the project's domain language from CONTEXT.md. Cover only what the immediate task needs — do not write a full architectural document for a small change.

package/.prettierignore

@@ -0,0 +1,2 @@
+node_modules/
+package-lock.json

package/.prettierrc

@@ -0,0 +1,7 @@
+{
+  "semi": true,
+  "singleQuote": true,
+  "trailingComma": "all",
+  "printWidth": 100,
+  "tabWidth": 2
+}

package/AGENTS.md

@@ -0,0 +1,38 @@
+# Regent — Agent Guide
+
+Before any work: read [`CONSTITUTION.md`](CONSTITUTION.md) — it defines Regent identity, court roles, principles, and iron laws.
+
+## Quick start
+
+```bash
+cd .opencode
+npm install
+node --test tests/regent.test.js tests/regent.live-test.js tests/regent.v2.test.js tests/regent.hybrid.v2.6.1.test.js tests/regent.runtime.v2.6.1.test.js
+```
+
+All 108 tests across the five suites must pass before committing.
+
+## Development
+
+- **Plugin entry:** `.opencode/plugins/regent.js` — default `Plugin.define` export; `setup` registers 6 custom tools, the destructive-command shell guardrail hook, and the v2 context hook; runtime-registers packaged skills and `/regent/...` commands; scopes bootstrap/evidence state (including freshness fingerprints) to root sessions; hides orchestration tools in worker contexts; Regent does not select or require a named root agent — the host's configured primary agent remains authoritative, with dispatch using available child-capable workers or built-in `general` fallback
+- **Plugin API:** OpenCode v2 beta with `@opencode-ai/plugin@0.0.0-beta-18155`; server-side compaction mutation and `client.tui.showToast` are unavailable
+- **Skills:** `.opencode/skills/<name>/SKILL.md` with frontmatter (`name:`, `description:`); file-discovered by OpenCode v2 and added at runtime when absent
+- **Commands:** `.opencode/commands/<name>.md` with static frontmatter (`description:`, `subtask:`, `agent:`) for file-discovery compatibility; runtime registration is namespaced under `/regent/...`
+- **Agents:** `.opencode/agents/<name>.md` with frontmatter (`description:`, `mode:`, `color:`); auto-discovered by OpenCode v2
+- **Tests:** `.opencode/tests/` — `regent.test.js`, `regent.live-test.js`, `regent.v2.test.js`, `regent.hybrid.v2.6.1.test.js`, and `regent.runtime.v2.6.1.test.js` (108 tests total)
+
+## Code style
+
+- ESM only (`import`/`export`, no `require`)
+- No comments — let code speak
+- Error paths produce structured JSON, never throw
+- `context.directory` → `process.cwd()` fallback
+
+## Verdict gates
+
+Before committing:
+1. Run `npm run verify` — format, lint, typecheck, all unit tests pass
+2. Read `CONSTITUTION.md` — ensure changes align with identity and iron laws
+3. Add new skill? Update `README.md` skill table. Add new tool or command? Update tool/command tables.
+4. Adding features? Update project-level dispatch, rate-limit, circuit-breaker, and evidence state in regent.js.
+5. No phase skip. No gate bypass.