codex-orchestrator 2.0.11 → 2.0.13

package/internal-workflow/skills/diagnosing-bugs/SKILL.md

@@ -1,15 +1,15 @@
 ---
 name: diagnosing-bugs
-description: Debug hard, flaky, unclear, or performance bugs through reproduce, minimize, hypothesize, instrument, fix, and regression-test. Trigger for nondeterministic failures, unclear breakage, or performance regressions.
+description: Diagnose hard, flaky, unclear, or performance bugs through reproduction, minimisation, ranked hypotheses, and targeted instrumentation. Stop after proving the root cause and hand the proven signal to Implement; do not fix the bug.
 ---
 
 # Diagnosing Bugs
 
-A discipline for hard bugs. Skip phases only when explicitly justified.
+A diagnosis-only discipline for hard bugs. Skip phases only when explicitly justified. End with a proven root cause or an honest blocker.
 
-Routing precedence: use `$CODEX_ORCHESTRATOR_WORKFLOW_ROOT/docs/agents/bug-workflow-routing.md`. This skill owns the feedback loop; after the loop proves the bug, return to the original intent: diagnosis-only output or implementation through `code-debugger`.
+Routing precedence: use [`../../docs/agents/bug-workflow-routing.md`](../../docs/agents/bug-workflow-routing.md). This skill owns reproduction and root-cause proof. It does not own the regression test or fix, post-fix verification, production mutation, or Git lifecycle. Once the cause is proven, hand the reproducible signal and evidence to `implement` and stop.
 
-Use `$CODEX_ORCHESTRATOR_WORKFLOW_ROOT/docs/agents/confidence-rubric.md` when deciding whether a hypothesis, root cause, or fix is high-confidence enough to act on. Low-confidence concerns are questions or verification gaps, not proven causes.
+Use [`../../docs/agents/confidence-rubric.md`](../../docs/agents/confidence-rubric.md) when deciding whether a hypothesis or root cause is high-confidence enough to report or hand off. Low-confidence concerns are questions or verification gaps, not proven causes.
 
 When exploring the codebase, read `CONTEXT.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
 
@@ -21,18 +21,18 @@ Spend disproportionate effort here. **Be aggressive. Be creative. Refuse to give
 
 ### Ways to construct one — try them in roughly this order
 
-1. **Failing test** at whatever seam reaches the bug — unit, integration, e2e.
+1. **Existing failing test** at whatever seam reaches the bug — unit, integration, e2e. Do not turn the repro into a new durable regression test in this skill.
 2. **Curl / HTTP script** against a running dev server.
 3. **CLI invocation** with a fixture input, diffing stdout against a known-good snapshot.
 4. **Headless browser script** (Playwright / Puppeteer) — drives the UI, asserts on DOM/console/network.
 5. **Replay a captured trace.** Save a real network request / payload / event log to disk; replay it through the code path in isolation.
 6. **Throwaway harness.** Spin up a minimal subset of the system (one service, mocked deps) that exercises the bug code path with a single function call.
 7. **Property / fuzz loop.** If the bug is "sometimes wrong output", run 1000 random inputs and look for the failure mode.
-8. **Bisection harness.** If the bug appeared between two known states (commit, dataset, version), automate "boot at state X, check, repeat" so you can `git bisect run` it.
+8. **Bisection harness.** If the bug appeared between two known states (snapshot, dataset, version), automate "boot at state X, check, repeat" over read-only states supplied by the active driver. Diagnosis performs no checkout or other Git action.
 9. **Differential loop.** Run the same input through old-version vs new-version (or two configs) and diff outputs.
 10. **HITL bash script.** Last resort. If a human must click, drive _them_ with `scripts/hitl-loop.template.sh` so the loop is still structured. Captured output feeds back to you.
 
-Build the right feedback loop, and the bug is 90% fixed.
+Build the right feedback loop, and most of the diagnostic uncertainty is gone.
 
 ### Tighten the loop
 
@@ -50,13 +50,13 @@ The goal is not a clean repro but a **higher reproduction rate**. Loop the trigg
 
 ### When you genuinely cannot build a loop
 
-Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do **not** proceed to hypothesise without a loop.
+Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) an authorized Implement change that adds the missing diagnostic seam. Do **not** proceed to hypothesise without a loop, and do not edit production source or runtime state from this skill.
 
 ### Completion criterion — a tight loop that goes red
 
 Phase 1 is done when the loop is **tight** and **red-capable**: you can name **one command** — a script path, a test invocation, a curl — that you have **already run at least once** (paste the invocation and its output), and that is:
 
-- [ ] **Red-capable** — it drives the actual bug code path and asserts the **user's exact symptom**, so it can go red on this bug and green once fixed. Not "runs without erroring" — it must be able to _catch this specific bug_.
+- [ ] **Red-capable** — it drives the actual bug code path and asserts the **user's exact symptom**, producing a signal that `implement` can later use for red/green proof. Not "runs without erroring" — it must be able to _catch this specific bug_.
 - [ ] **Deterministic** — same verdict every run (flaky bugs: a pinned, high reproduction rate, per above).
 - [ ] **Fast** — seconds, not minutes.
 - [ ] **Agent-runnable** — you can run it unattended; a human in the loop only via `scripts/hitl-loop.template.sh`.
@@ -69,15 +69,15 @@ Run the loop. Watch it go red — the bug appears.
 
 Confirm:
 
-- [ ] The loop produces the failure mode the **user** described — not a different failure that happens to be nearby. Wrong bug = wrong fix.
+- [ ] The loop produces the failure mode the **user** described — not a different failure that happens to be nearby. Wrong bug = wrong diagnosis.
 - [ ] The failure is reproducible across multiple runs (or, for non-deterministic bugs, reproducible at a high enough rate to debug against).
-- [ ] You have captured the exact symptom (error message, wrong output, slow timing) so later phases can verify the fix actually addresses it.
+- [ ] You have captured the exact symptom (error message, wrong output, slow timing) so later phases can prove what produces it.
 
 ### Minimise
 
 Once it's red, shrink the repro to the **smallest scenario that still goes red**. Cut inputs, callers, config, data, and steps **one at a time**, re-running the loop after each cut — keep only what's load-bearing for the failure.
 
-Why bother: a minimal repro shrinks the hypothesis space in Phase 3 (fewer moving parts left to suspect) and becomes the clean regression test in Phase 5.
+Why bother: a minimal repro shrinks the hypothesis space in Phase 3 and gives `implement` a precise signal to preserve while fixing the bug.
 
 Done when **every remaining element is load-bearing** — removing any one of them makes the loop go green.
 
@@ -102,37 +102,74 @@ Each probe must map to a specific prediction from Phase 3. **Change one variable
 Tool preference:
 
 1. **Debugger / REPL inspection** if the env supports it. One breakpoint beats ten logs.
-2. **Targeted logs** at the boundaries that distinguish hypotheses.
+2. **Targeted logs** in a throwaway harness or an already-authorized diagnostic surface at the boundaries that distinguish hypotheses.
 3. Never "log everything and grep".
 
 **Tag every debug log** with a unique prefix, e.g. `[DEBUG-a4f2]`. Cleanup at the end becomes a single grep. Untagged logs survive; tagged logs die.
 
-**Perf branch.** For performance regressions, logs are usually wrong. Instead: establish a baseline measurement (timing harness, `performance.now()`, profiler, query plan), then bisect. Measure first, fix second.
+If distinguishing the hypotheses requires changing production source or runtime state, stop with that missing instrumentation seam and hand it to `implement`. Diagnosis may describe the smallest observation point, but it does not apply that mutation.
 
-## Phase 5 — Fix + regression test
+**Perf branch.** For performance regressions, logs are usually wrong. Instead: establish a baseline measurement (timing harness, `performance.now()`, profiler, query plan), then bisect. Measure first, isolate the cause second.
 
-Write the regression test **before the fix** — but only if there is a **correct seam** for it.
+## Phase 5 — Prove the root cause and hand off
 
-A correct seam is one where the test exercises the **real bug pattern** as it occurs at the call site. If the only available seam is too shallow (single-caller test when the bug needs multiple callers, unit test that can't replicate the chain that triggered the bug), a regression test there gives false confidence.
+Prove the winning hypothesis against the tight loop before reporting it as the root cause:
 
-**If no correct seam exists, that itself is the finding.** Note it. The codebase architecture is preventing the bug from being locked down. Flag this for the next phase.
+1. Name the exact trigger, owning code path, and mechanism that produces the observed symptom.
+2. Show the probe result that confirmed the winning prediction and the result that ruled out the strongest alternative.
+3. Re-run the unchanged repro after removing or disabling the probe. It must still produce the original symptom; a probe-induced failure is not proof.
+4. Classify confidence with the confidence rubric. If an assumption still changes the conclusion, report the remaining verification gap instead of claiming a proven cause.
+5. Remove all `[DEBUG-...]` instrumentation and unrelated throwaway
+   prototypes. When the red signal depends on a throwaway harness, keep the
+   minimal repro harness and fixture available with the handoff until Implement
+   confirms the same RED and creates the durable regression test. This narrow
+   executable handoff artifact is not production code or a Git action; after
+   confirmation, the active root removes it unless the user authorized it to
+   remain.
 
-If a correct seam exists:
+Then stop. Do not author a regression test, apply or recommend a speculative patch, run post-fix checks, commit, push, open a PR, or update a tracker. Hand `implement`:
 
-1. Turn the minimised repro into a failing test at that seam.
-2. Watch it fail.
-3. Apply the fix.
-4. Watch it pass.
-5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario.
+- the exact unchanged reproduction command and captured pre-fix failing output;
+- the minimal load-bearing fixture, inputs, state, and steps;
+- a signal digest covering the command, fixture bytes, and expected failing verdict;
+- the proven trigger, owner, mechanism, and supporting probe evidence;
+- the strongest alternative ruled out and how it was falsified;
+- any missing test seam, environment dependency, or residual uncertainty that constrains implementation proof;
+- post-mortem observations about what could have prevented the bug, clearly separated from the proven cause and without starting architecture or production work.
 
-## Phase 6 — Cleanup + post-mortem
+The handoff is executable evidence, not narration. Implement must rerun the
+unchanged signal before editing and get the same diagnosed failure. A missing
+fixture, changed digest, different symptom, or unexpectedly green result
+returns to Diagnosis or blocks the fix; Implement must not silently substitute
+a nearby test.
 
-Required before declaring done:
+If the root cause is not proven, do not hand off a guess as implementation input. Return the best red-capable signal, tested hypotheses, and the concrete evidence or access still required.
 
-- [ ] Original repro no longer reproduces (re-run the Phase 1 loop)
-- [ ] Regression test passes (or absence of seam is documented)
-- [ ] All `[DEBUG-...]` instrumentation removed (`grep` the prefix)
-- [ ] Throwaway prototypes deleted (or moved to a clearly-marked debug location)
-- [ ] The hypothesis that turned out correct is stated in the commit / PR message — so the next debugger learns
+## Output Contract
 
-**Then ask: what would have prevented this bug?** If the answer involves architectural change (no good test seam, tangled callers, hidden coupling) hand off to the `$improve-codebase-architecture` skill with the specifics. Make the recommendation **after** the fix is in, not before — you have more information now than when you started.
+Use this shape when reporting back:
+
+```md
+## Reproduction
+
+- Command: `<exact command already run>`
+- Signal: <captured symptom and repeatability>
+- Minimal scenario: <load-bearing inputs, state, and steps>
+
+## Proven root cause
+
+- Trigger: <what activates the bug>
+- Owner: `<path>` — `<function or method>`
+- Mechanism: <how the owner produces the symptom>
+- Evidence: <confirming probe and falsified alternative>
+- Confidence: <high, medium, or low, with any remaining gap>
+
+## Implement handoff
+
+- Preserve this signal: <exact unchanged reproduction command, captured pre-fix failing output, minimal load-bearing fixture, signal digest, and expected failing verdict>
+- Constraints: <missing test seam, environment dependency, or residual uncertainty>
+- Post-mortem observations: <prevention or architecture evidence for later authorized work>
+- Next owner: `implement`
+```
+
+When the cause is not proven, replace `Proven root cause` and `Implement handoff` with `Blocked diagnosis`; list tested hypotheses and the exact missing evidence. Do not route implementation from an unproven diagnosis.

package/internal-workflow/skills/diagnosing-bugs/agents/openai.yaml

@@ -1,6 +1,6 @@
 interface:
   display_name: "Diagnosing Bugs"
-  short_description: "Run a disciplined hard-bug investigation loop"
-  default_prompt: "Use $diagnosing-bugs to reproduce, minimise, diagnose, and verify this difficult bug."
+  short_description: "Prove hard-bug root causes before implementation"
+  default_prompt: "Use $diagnosing-bugs to reproduce and minimise this difficult bug, prove its root cause with targeted evidence, hand the proven signal to $implement, and stop before any regression test or fix."
 policy:
   allow_implicit_invocation: true

package/internal-workflow/skills/diagnosing-bugs/evals/evals.json

@@ -0,0 +1,63 @@
+{
+  "schema_version": 1,
+  "skill": "diagnosing-bugs",
+  "cases": [
+    {
+      "id": "proven-cause-handoff",
+      "prompt": "A deterministic two-second CLI repro is red. Diagnose the hard bug and the strongest competing hypothesis, but do not fix it.",
+      "expected": [
+        "run and minimise the red-capable repro",
+        "test ranked falsifiable hypotheses with targeted probes",
+        "prove the trigger, owner, mechanism, and falsified alternative",
+        "hand the unchanged failing signal to Implement and stop"
+      ],
+      "forbidden": [
+        "author a regression test",
+        "apply the fix",
+        "perform a Git action"
+      ]
+    },
+    {
+      "id": "blocked-without-red-capable-loop",
+      "prompt": "The reported production-only failure has no local repro, captured artifact, or safe observation surface.",
+      "expected": [
+        "list the feedback loops attempted",
+        "request the exact environment access, captured artifact, or authorized diagnostic seam still required",
+        "return an honest blocked diagnosis without guessing"
+      ],
+      "forbidden": [
+        "declare a speculative root cause",
+        "edit production instrumentation",
+        "route an unproven guess to Implement"
+      ]
+    },
+    {
+      "id": "missing-seam-postmortem-handoff",
+      "prompt": "The root cause is proven, but the real caller has no durable test seam and the diagnosis reveals one prevention opportunity.",
+      "expected": [
+        "report the missing test seam as an implementation constraint",
+        "separate the post-mortem observation from the proven cause",
+        "hand both observations and the failing signal to Implement"
+      ],
+      "forbidden": [
+        "create a test-only production abstraction",
+        "start an architecture refactor",
+        "commit diagnostic work"
+      ]
+    },
+    {
+      "id": "red-capable-implement-handoff",
+      "prompt": "The cause is proven and Implement is about to receive the diagnosis.",
+      "expected": [
+        "hand off the exact unchanged command, captured failing output, minimal load-bearing fixture, and signal digest",
+        "retain a required throwaway repro harness until Implement confirms the same RED",
+        "require Implement to reproduce the same diagnosed failure before editing",
+        "block or return to Diagnosis if the signal changed or is unexpectedly green"
+      ],
+      "forbidden": [
+        "replace the signal with a nearby passing test",
+        "start the fix inside Diagnosis"
+      ]
+    }
+  ]
+}

package/internal-workflow/skills/grilling/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: grilling
+description: Grill the user about a plan, decision, or idea through dependency-aware frontier rounds. Use when the user wants to stress-test their thinking or uses a grill trigger phrase.
+---
+
+# Grilling
+
+Interview the user until you reach a shared understanding. Model the subject as
+a **design tree**: each material decision branches into the decisions that
+depend on it.
+
+Root owns every user-facing question, recommendation, wait for feedback, and
+accepted decision. Never delegate or impersonate the dialogue. A bounded
+`explorer` may gather read-only evidence when a fact depends on a cross-module
+path; it returns evidence to root and makes no product decision.
+
+## Frontier rounds
+
+The **frontier** is every unresolved material decision whose prerequisites are
+settled. Ask the whole frontier in one numbered round. For each question:
+
+- state the decision and enough context to answer it;
+- give two or three concrete options when multiple paths are plausible;
+- mark one recommended answer and explain the trade-off briefly;
+- say plainly when evidence leaves only one valid option.
+
+Then wait for the user's answers. Each answer reshapes the design tree: record
+the settled decision, recompute the frontier, and ask the next numbered round.
+A question whose answer depends on a decision still open in the current round
+belongs to a later round. Do not ask it early or guess its prerequisite.
+
+Finding facts is the agent's job, never the user's. Look up facts in the
+environment, codebase, current docs, or authorized external sources. If a fact
+lookup is still running, treat it as an unsettled prerequisite: defer only its
+downstream questions and ask the rest of the current frontier now. The
+decisions remain the user's; put every material decision to them and use their
+answers to resolve only minor follow-ons.
+
+The interview is complete only when the frontier is empty: every material
+branch is settled or explicitly ruled out and no decision is silently assumed.
+Summarize the resulting shared understanding and ask the user to confirm it.
+Do not act on the result until the user explicitly confirms the shared
+understanding. A product plan produced here is input to the active driver; this
+skill does not implement it.
+
+## Mutation boundary
+
+Grilling is write-free. It may read repository domain language to phrase
+questions consistently, but it never creates or edits `CONTEXT.md`,
+`CONTEXT-MAP.md`, or ADRs. Domain-document mutation belongs only to
+`$domain-modeling`, when that discipline is separately active.

package/internal-workflow/skills/grilling/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Grilling"
+  short_description: "Stress-test decisions in frontier rounds"
+  default_prompt: "Use $grilling on root to map the dependency tree, ask each currently unblocked frontier in a numbered round, and stop for explicit shared-understanding confirmation without writing domain docs."
+policy:
+  allow_implicit_invocation: true

package/internal-workflow/skills/grilling/evals/evals.json

@@ -0,0 +1,47 @@
+{
+  "schema_version": 1,
+  "skill": "grilling",
+  "cases": [
+    {
+      "id": "independent-frontier-round",
+      "prompt": "Three material decisions are independent and answerable now. Start the grilling session.",
+      "expected": [
+        "map all three as the current frontier and ask them in one numbered round",
+        "give a recommendation for each decision and wait for the user's answers",
+        "keep every user-facing question on root"
+      ],
+      "forbidden": [
+        "ask only one independent question",
+        "write domain documents",
+        "act on the resulting plan"
+      ]
+    },
+    {
+      "id": "dependent-frontier-deferral",
+      "prompt": "Decision B depends on decision A, while decision C is independent and a repository fact for D is still being looked up.",
+      "expected": [
+        "ask A and C in the current numbered frontier round",
+        "defer B until A settles and defer only D while its fact prerequisite is unresolved",
+        "recompute the frontier after answers and finish only when it is empty"
+      ],
+      "forbidden": [
+        "ask B in the same round as A",
+        "ask the user to find the repository fact",
+        "claim completion before explicit shared-understanding confirmation"
+      ]
+    },
+    {
+      "id": "implicit-grilling-remains-write-free",
+      "prompt": "Without naming a wrapper, grill this terminology choice and tell me whether it deserves an ADR.",
+      "expected": [
+        "run a write-free frontier interview",
+        "discuss terminology and ADR suitability without changing files",
+        "leave domain-document mutation to a separately active domain-modeling discipline"
+      ],
+      "forbidden": [
+        "edit CONTEXT.md",
+        "create an ADR"
+      ]
+    }
+  ]
+}

package/internal-workflow/skills/implement/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: implement
+description: Implement a clear authorized feature, fix, obvious local edit, or executable ticket through observable proof and applicable Review. This is the single coding execution owner.
+---
+
+# Implement
+
+Implement the authorized outcome. Do not reopen settled product decisions or
+create a replacement plan, spec, ticket, workflow state, or compatibility path.
+
+## Kernel
+
+- **Authority:** perform only the requested outcome and authorized delivery
+  actions. Tracker publication is not implementation authority. Normal direct
+  and single-ticket Implement authority includes one scoped local commit after
+  proof and applicable Review unless user or repository policy explicitly
+  forbids or reserves Git. Push and PR are separate and never implicit.
+- **Preservation:** read repository policy and current status before edits.
+  Preserve unrelated work and user-owned runtimes. Stop on overlapping dirty
+  scope or a decision that changes behavior, ownership, or boundaries.
+- **Proof:** prove the final observable outcome through the real caller seam.
+  Authority-defined proof cannot be replaced by weaker tests or a completion
+  claim.
+
+## Context Ownership
+
+Direct non-ticket work remains in the current root context.
+
+For one executable ticket, root launches exactly one fresh `implementer` child.
+The assignment must include:
+
+- the complete ticket;
+- the complete Parent PRD;
+- applicable repository policy;
+- bounded write scope and exclusions;
+- required proof and explicit delivery/Git boundaries.
+
+The assignment begins with `Assigned role: implementer` so the requested role,
+fresh child identity, and completed wait can be verified independently.
+
+The worker performs no Git actions and returns changed files, observable proof,
+skipped checks, risks, decision deltas, overlap, and blockers. Root verifies a
+non-empty fresh child identity, waits for that same child to complete, checks
+the assignment inputs, and integrates only isolated output. A single ticket
+never activates the graph coordinator.
+
+## Execution
+
+1. Confirm authority, repository policy, current status, owner code, caller
+   seam, and the smallest credible proof. Record pre-existing dirty paths; an
+   overlap with owned scope blocks edits, while disjoint dirty paths remain
+   untouched and unstaged.
+2. Use `$tdd` where possible. Otherwise establish direct pre-change evidence
+   when useful and apply the narrowest observable proof after the edit.
+   When a diagnosis handoff exists, rerun the unchanged reproduction command
+   before editing and require the same diagnosed failure, fixture digest, and
+   symptom. Then make the first durable regression test at the natural public
+   seam fail for the diagnosed symptom before applying the fix. If the handoff
+   is stale, incomplete, unexpectedly green, or reproduces another symptom,
+   stop and return the evidence gap to Diagnosis instead of substituting a
+   nearby signal.
+3. Implement the smallest complete change in the existing owner. Delete
+   superseded paths in scope; do not add aliases, wrappers, adapters, fallback
+   routes, or speculative layers.
+4. Run targeted proof and the smallest affected integration check.
+   During substantial work, run the relevant typecheck or single test file as
+   the seam settles. Run a full suite once at the end only when repository
+   policy, risk, or the changed shared contract makes it proportionate.
+5. Classify the settled result by content:
+   - substantial: behavior or contract beyond an obvious local edit, including
+     public API, persistence, auth/payment, concurrency/shared state, or
+     cross-module interaction;
+   - obvious local: docs, copy, formatting, mechanical config, or an obvious
+     local correction with direct proof.
+   A public returned-record shape change remains a substantial contract change
+   even when its implementation is one line or arrives through one ticket.
+6. For substantial work, invoke `$code-review` on the settled proof. The first
+   invocation reviews the complete authorized result with one fresh Spec
+   reviewer and one fresh Standards reviewer in parallel. Obvious local work
+   may skip Review.
+7. Handle each reviewer result:
+   - reviewer findings are evidence, not implementation authority. Before any
+     repair, independently verify **Authority** (the existing authorized
+     obligation being restored), **Trigger** (the concrete failing path or
+     unmet requirement), **Impact** (the observable defect or proof gap in the
+     authorized result), and **Minimal repair** (the least change that restores
+     that obligation). State one short evidence-backed sentence connecting
+     those four facts before editing;
+   - classify the result without collapsing failure paths: a new obligation,
+     changed authorized outcome, ownership or architecture decision, or repair
+     of a neighboring problem is a Decision Delta and stops for authority. A
+     missing Authority, Trigger, or Impact makes the finding unverified and it
+     receives no repair; classify it as an observation unless required proof
+     cannot establish the authorized result, in which case the proof gap blocks
+     completion without authorizing code. Only a finding with all four facts
+     established is a verified blocker eligible for repair. Apply the same gate
+     to UI, backend, persistence, concurrency, infrastructure, and every other
+     change type;
+   - if optional machinery added by the current diff causes the problem,
+     remove it instead of expanding the outcome to support it;
+   - consolidate every verified blocker from the current review into one
+     repair batch. The repair may widen the investigated impact cone and touch
+     necessary neighboring files within explicit exclusions and preservation
+     boundaries, but it must not widen the authorized outcome. The active
+     owner applies it: root for direct work or the ticket's existing
+     `implementer` for single-ticket work. Do not ask for confirmation or
+     create a second implementer when the gate proves the repair is already
+     authorized.
+8. After each repair batch, rerun affected proof and invoke `$code-review` on
+   the new revision. Run only the affected lens: a Spec-only repair returns to
+   Spec, a Standards-only repair returns to Standards, and a mixed or
+   unisolatable repair returns to both lenses. Limit targeted Review to the
+   repair delta, direct impact cone, and affected proof; untouched approval
+   remains valid. Repeat until approval. Reviewer count is not a stop condition;
+   use a complete two-lens Review only when the repair cannot be isolated.
+9. After proof and every applicable review approve, create one scoped local
+   commit for direct and single-ticket Implement when the scope is isolatable.
+   Stage only owned paths and recheck that unrelated dirty paths remain
+   unchanged. If user or repository policy explicitly forbids or reserves Git
+   to another actor, return the proven uncommitted diff.
+
+Missing proof, terminally failed or interrupted review, dirty overlap, or
+unisolatable scope produces no affected staging or commit. Never push or open a
+PR without separate authority.
+
+## Handoff
+
+Return:
+
+- changed and deleted files;
+- observable scenarios proved;
+- exact commands and results;
+- skipped checks and why;
+- residual risks, decision deltas, overlap, and blockers;
+- Git actions performed, or explicit confirmation that none occurred.

package/internal-workflow/skills/implement/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Implement"
+  short_description: "Single owner for authorized coding execution"
+  default_prompt: "Use $implement to deliver the authorized outcome through observable proof and applicable Review."
+policy:
+  allow_implicit_invocation: true