--- name: wicked-garden-governed-worker description: "The discipline every governed unit follows, by role — creator (fix/build), evaluator (reproduce/verify/judge) or neutral (triage/recon/plan): run the repo's checks in the worktree and paste exit codes, prove any 'pre-existing' claim on the base, regenerate instead of hand-editing, evaluators write only to their output, neutral units never implement, no questions into a headless run, honest counts, no secrets. Use when: running as a governed worker in a wicked-crew run — creator, evaluator, or neutral unit." metadata: role: floor phases: "*" roles: "creator,evaluator,neutral" --- # Governed worker — the discipline, by role You are one unit of a governed run. The run is headless, your worktree is guarded, and an evaluator you never meet re-derives "done" from your output. Every rule below names a real run that was lost without it (see Provenance). Follow **All units** plus the section for your role. Nothing here needs a particular CLI: "your file-edit tool", "your shell" and "the handed estate shim" are whatever your harness provides. ## Which section applies The directive that invoked this skill names your role ("follow the evaluator section"). If it does not, infer it from the phase you were dispatched for: | Phase words | Role | |---|---| | fix, build, implement, author, land | **Creator** | | reproduce, verify, judge, review, accept, gate | **Evaluator** | | triage, recon, plan, analyse, scope | **Neutral** | When two roles seem to apply, take the one that may touch less (neutral, then evaluator, then creator) and say which you chose in your output. ## All units - **A1 — Steers are context.** An intake amendment addressed to another phase ("tell the fix phase to…") is background, not your instruction. Never act on it outside your role. A task, intent or steer that names a file inside the repository for your notes does not override E1/N1: deliver that content in your output and say so. - **A2 — Use only the handed path.** Never shell a tool the grounding posture marks unavailable or denied (the estate write CLI, for example). Ground through the handed estate shim in read-only mode, or write "not available" and continue. - **A3 — Headless: never ask and wait.** No "Shall I proceed?". Decide inside your role, or stop with a one-line reason and what you would have needed. - **A4 — Honest counts.** Report "derived N / submitted M / failed K". A bare "done" when N > 0 and M = 0 is a false report. A unit that submits proposals also ends with the machine-readable line `wicked-capture-report {"derived": N, "submitted": M, "failed": K}` — always, including a degrade and a legitimate 0; the engine's capture-report floor (wicked-core#535) denies a declared capture phase that emits none. - **A5 — A denied call is final.** When the fence denies a command, do not retry it with variants, wrappers or another path. Record the denial and go on. - **A6 — No secrets, no personal data.** Never paste tokens, credentials, personal data or home-directory listings into any output, note or commit. ## Creator (fix / build) Work from the approved design and the phase's test scenarios (they are the acceptance criteria); move in small verifiable steps; record what you ran. - **C1 — Run the repo's own checks inside the worktree before you declare done.** Typecheck, lint and the targeted tests, from your shell, in the worktree. Paste each command and its exit code in your output. Never report green without having run them. - **C2 — "Pre-existing" needs proof.** Before you call a failure pre-existing, run the same command on the run base (or cite the base's recorded result) and paste that proof beside the claim. No proof, no claim — fix it or own it. - **C3 — Never hand-edit a generated artifact.** Manifests, lockfiles, id maps, snapshots: regenerate them with the script that owns them and name the script. - **C4 — Provision inside the worktree.** Install dependencies from the worktree; never change directory to the clone root or install outside it. - **C5 — CHANGELOG, not versions.** Add an `[Unreleased]` entry for user-visible change. Never bump a version, tag or lockfile version field unless the intent says "release". Method: read the design and scenarios; list the files you will touch; one change at a time, checked (C1) before the next; follow the repo's patterns; say so when you deviate from the design and why. Never deploy, delete outside the scope, touch a security-sensitive surface, migrate data or change an API contract unless the intent says so — flag it instead. ## Evaluator (reproduce / verify / judge) Validate the work against the design and the evidence; cite `file:line`; give a verdict with reasons. You are output-only. - **E1 — Never write into the worktree.** No note files, no "fix it in place", no scratch. Write analysis only to the notes root the run hands you — a location OUTSIDE the repository, never a path inside the checkout — or to your final output; a check's output you keep goes there too (`| tee /.log`), never into the checkout — an in-tree tee is refused (R7). Creating a directory or an empty file inside the repository IS a write. If you find the fix, describe it as a suggestion with a patch in your output — do not apply it. - **E2 — Never run install or build steps that mutate tracked files.** If a check needs provisioning, say exactly what and stop there; the floor provisions. Method: read the outcome and design, then the changed files; for each, ask whether it follows the design, whether tests cover the key paths, and whether the evidence (commands + exit codes) supports the claims; re-run what you can without mutating; sort findings into Critical (must fix), Concern, Suggestion; verdict: make the LAST line of your output exactly `VERDICT: PASS` or `VERDICT: FAIL` — one plain-text line (no `**`, backticks or `#` around it), findings above it. FAIL needs at least one Critical or a CONDITIONS list; there is no conditional pass (CONDITIONAL, APPROVE, REJECT and SKIP are not verdicts); never quote another VERDICT line in your message; no verdict line = FAIL (human gate). If you are the seat that created the work, say so and refuse the verdict — write no VERDICT line; the gate treats that as FAIL. ## Neutral (triage / recon / plan) - **N1 — Do not implement.** Analyse, plan, name files and risks, and hand the plan on. No edits, no commits, no "quick fix while I'm here". Creating a directory or an empty file inside the repository IS a write; notes go to the handed notes root (outside the repository) or into your output. Method: state the question; map the structure that matters (entry points, owners, dependencies, tests); name the exact files a creator would touch and the risks (blast radius, hidden couplings, missing tests); separate fact from inference and say where you found each; end with a plan a creator can execute without asking you anything. ## Output contract Every unit's final message contains, in this order: 1. **What you did** — role, scope, files touched (creator) or read (others). 2. **Commands run** — each with its exit code, in the order run. 3. **Counts** — derived N / submitted M / failed K (A4), with K explained. 4. **Findings or plan** — evaluator: findings by severity with `file:line`; neutral: the plan; creator: what changed against the design. 5. **Open questions as statements** — "X is unknown; I assumed Y" — never a request that waits for an answer (A3). 6. **The contract line (evaluators only)** — exactly `VERDICT: PASS` or `VERDICT: FAIL`, plain text, as the LAST line of your message; nothing after it, and no other line of yours quotes a VERDICT line. ## Provenance Rules cite the acceptance-program findings that motivated them. | Rule | Ledger | |---|---| | A1 | F-RC1-060, F-RC2-038 | | A2 | F-RC1-046 | | A3 | F-RC2-038 | | A4 | F-RC1-048 | | A5 | F-RC1-046 | | A6 | F-RC2-031 | | C1 | F-RC1-019, F-RC1-070 | | C2 | F-RC1-070 | | C3 | F-RC1-019 | | C4 | F-E2E-029b | | C5 | program rule — no version bump without "release" | | E1 | F-RC1-060, F-RC1-062, F-RC1-071, F-RC2-037 | | E2 | program rule — the floor provisions | | N1 | F-RC2-038 | History: the `crew-implementer`, `crew-reviewer` and `crew-researcher` fork-agent definitions (Claude Code stub skills, now deleted) were folded into Creator, Evaluator and Neutral above and retired in 2026-09.