@iowarp/clio-coder 0.4.1 → 0.4.3

package/skills/workflow/grill-me/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: grill-me
-description: Use when the user wants a plan, design, or idea stress-tested through a phased one-question-at-a-time interview before any code is written, or when intent is too ambiguous to plan from. Scans available context first, reviews known facts, fills missing decisions, respects stop signals, and ends with a compact decision log. Triggers on "grill me", "interview me", "stress-test this plan", "poke holes in this".
+description: Stress-tests a plan, design, or idea through a phased one-question-at-a-time interview before code is written, ending in a compact decision log. Not for a multi-perspective debate; use design-council.
 triggers:
   - grill me
   - interview me about this plan
   - stress-test this design
   - poke holes in this idea
   - clarify this plan one question at a time
-version: 0.3.3
+version: 0.5.0
 license: Apache-2.0
 allowed-tools:
   - read
@@ -33,9 +33,54 @@ Run a rigorous, repo-aware interview that turns a vague plan into explicit
 decisions. The point is not to interrogate for sport; it is to surface hidden
 branches before anyone writes code.
 
+## Arguments
+
+```text
+grill me on <plan, feature, or idea>
+```
+
+There is no flag syntax; the trigger is conversational — "grill me on X",
+"stress-test this design", "poke holes in this idea". Whatever the user
+names is the subject. A referenced file, doc, or repo path in the same
+request is Step 1's grounding to read first, not a separate argument.
+
+**This run has no back-and-forth.** There is no second turn in which a user
+reads your question and replies to it — whatever you ask, you must also
+answer yourself, in this same turn, before it ends. Do not write a question
+and stop to wait for a reply, in `ask_user` or in plain chat text; nothing
+is coming. Ending the turn on an open question — even one question, even a
+well-posed one — is this skill's single most common failure and worse than
+skipping the interview format entirely.
+
+There is no operator in a headless run. `ask_user` still executes — it is
+registered and the call succeeds — but nothing answers it: every round
+returns `{cancelled: true}` immediately, as an ordinary result, not an
+error, every time, with no exceptions. Calling it again will not produce a
+different result, so one call is enough to confirm it (not required —
+reasoning from this paragraph alone is just as valid as calling it and
+observing the cancellation). Whichever phase this lands in — even round
+1 — switch immediately to the assumed-confirm monologue for every phase
+from here on, in the same turn: state the question you would have asked,
+give your own best/recommended answer with the reasoning behind it, mark
+it `assumed — confirm`, and move to the next phase. Do not re-call
+`ask_user` hoping a later round behaves differently — that only burns the
+`max_rounds` budget without ever converging. Keep working the phase map,
+phase by phase, all the way through Step 5's decision log before ending
+the turn — never end on "Answer 1/2/3" or any other place a reply is
+expected.
+
+The phase map below is the plan; do not open a task list for it. This
+skill's tool surface is exactly `read`, `grep`, `ls`, `find`, `git`,
+`context`, `code_nav`, and `ask_user` (`context` and `ask_user` are always
+available regardless). `tasks` and `bash` both sit outside it and any call
+to either is refused — inspect a file with `read`, not `bash cat`/`bash
+head`/`bash wc`; locate files with `find` or `ls`, not `bash find`/`bash
+ls`; check repo state with the `git` tool, not shell `git`.
+
 ## Operating Contract
 
-- Use `ask_user` for the interview whenever it is active.
+- In a live session, use `ask_user` for the interview and actually wait for
+  the user's answer between rounds. In a headless run, see Arguments above.
 - For every interview round, call `ask_user` with `mode: "single_question"` and
   exactly one question.
 - On the first ask for a normal grill-me run, set `max_rounds` to a bounded
@@ -45,8 +90,6 @@ branches before anyone writes code.
   alternatives with short tradeoff descriptions.
 - The user answers in natural language. You translate answers into compact
   decision keys and rationale when you call `ask_user` with `action: "complete"`.
-- If `ask_user` is unavailable, ask in plain text, still one question at a
-  time, and keep an internal decision log.
 
 ## Phase Map
 
@@ -69,7 +112,11 @@ or "fill" when the decision is genuinely missing.
 
 Read what the user already gave you. If the task references files, plans, code,
 tests, or project conventions, inspect them before asking. Prefer
-`context(scope="workspace")`, `grep`, `read`, and codewiki tools over guessing.
+`context(scope="workspace")`, `grep`, `read`, `code_nav` (symbol and call-graph
+lookups), and codewiki tools over guessing. Use the `git` tool (`status`,
+`log`, not shell `git`) when the plan references repo state — recent
+history, uncommitted changes, what "decided" actually means for this repo
+right now.
 
 Privately build a phase map:
 
@@ -112,10 +159,26 @@ Good: "Which user should v1 optimize for first?"
 If an answer is vague, ask a follow-up on the same branch. Do not jump to a new
 branch while the current one is still unresolved.
 
+**Headless: there is no reply coming, whether `ask_user` comes back
+`cancelled` or you never call it at all.** Neither is a vague answer to
+follow up on and neither is a signal to try again or to wait — both mean
+there is no operator this run, from round 1 on. Do not call `ask_user`
+again for this or any later phase, and do not phrase a question in plain
+text as if a reply is pending. From here, run every remaining phase
+(including this one) as the assumed-confirm monologue described in
+Arguments, in this same turn, through to the Step 5 decision log. See
+Arguments for the exact treatment.
+
 ### Step 4 - Respect Stop Signals
 
-Stop immediately when the user says "stop", "enough", "later", "done", "next
-time", or cancels the modal. Do not ask another question to confirm stopping.
+This step applies to a live session with a real operator. Stop immediately
+when the user says "stop", "enough", "later", "done", "next time", or cancels
+the modal. Do not ask another question to confirm stopping.
+
+A headless `cancelled` result is not a stop signal from a user — it is the
+absence of an operator (see Step 3). Do not treat it as "the user cancelled
+this session"; treat it as the cue to switch to the assumed-confirm
+monologue and keep going to a complete decision log, not to stop early.
 
 If you have enough decisions to be useful, call:
 
@@ -140,8 +203,11 @@ state the partial decisions and the next unresolved root question.
 
 ### Step 5 - Complete
 
-Before final prose, call `ask_user` with `action: "complete"` and a compact
-`decisions` array. Then write the final decision log:
+In a live session, close with `ask_user` `action: "complete"` and a compact
+`decisions` array before final prose. In a headless run where `ask_user`
+already came back cancelled, skip straight to the decision log below — do
+not attempt another `ask_user` call just to close out; it will cancel too
+and adds nothing. Write the final decision log:
 
 ```markdown
 ## Decision Log - <topic>
@@ -189,4 +255,14 @@ Use this ordering when several questions are possible:
 - Asking about facts discoverable from the repo.
 - Letting `ask_user` hit the round limit without completing the interview.
 - Ending with a summary paragraph instead of the decision log.
-- Treating cancellation as permission to keep asking.
+- Re-calling `ask_user` for a later phase after an earlier round already came
+  back `cancelled` — the answer will not be different; that budget is wasted.
+- Ending a turn on "Answer 1/2/3", "let me know which you prefer", or any
+  other wording that expects a reply in a headless run — there is no next
+  turn for a reply to land in. This is the single most common failure mode
+  of this skill and the one to watch hardest for: asking one question, then
+  stopping, instead of running the assumed-confirm monologue through every
+  remaining phase to the decision log in the same turn.
+- Opening a `tasks` list for the phase map; `tasks` is refused.
+- Treating a headless `cancelled` result as the user's stop signal (Step 4)
+  instead of the absence-of-operator cue it actually is.

package/skills/workflow/grill-me/evals.md

@@ -76,3 +76,156 @@ Expected:
 
 One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning
 (30B local, llamacpp on mini), full-auto sandbox. PASS (smoke). Skill loaded and interviewed; judge emitted nothing (truncation).
+
+## Battletest record (2026-09-03)
+
+Fixture: `/home/akougkas/eval-temp/harness/test_grillme.py`, continuing the
+planning category's shared HPC log-triage domain. Seeds the *decided* v1
+architecture doc (`docs/hpc-log-triage-architecture.md`: on-demand reads
+chosen over an always-on pipeline, alerting explicitly listed "Not
+decided"), the partial `src/scanner.py` (`FailureEvent` + OOM-only
+`scan_oom`), and a `pyproject.toml` declaring `pytest` as the test runner
+— a repo fact the interview must find via `read`, not ask about (evals.md
+S2). The prompt is S1's vague-but-grounded feature request: "grill me on
+adding Slack alerting... nothing about notifications or Slack is decided
+yet." `ask_user` in this harness auto-cancels immediately with no operator
+(confirmed by the planning category and reconfirmed here), which makes
+this skill's entire premise — a one-question-at-a-time live interview — the
+thing under test. Graded 10 checks against the reconstructed final
+assistant text and the raw JSONL's tool-call/safety-block stream: zero
+safety blocks; zero `tasks` calls; no wasted `ask_user` retries (<=3
+calls); repo facts (`scan_oom`, `FailureEvent`, on-demand, `click`,
+`pytest`, `scan_ecc`/`scan_xid`, top-3) grounded in the final text; the
+Step 5 decision-log shape present (`Decision Log`/`Deferred`/`Open
+risks`/`Recommended next step`, not a summary paragraph); decisions
+numbered; the `assumed — confirm` monologue used 3+ times; the Question
+Priority order respected (user/problem framing before naming/polish); and
+**the phase map actually completed** (4+ distinct phase numbers named,
+not a stall after phase 0/1). S3 (user defers) and S5 (stop signal) are
+not separately exercised — a headless run cannot produce a live "whatever
+you think" or "stop" reply to react to; by construction, the
+assumed-confirm monologue *is* the "whatever you think" case running for
+every decision, so S3's expected behavior (record the recommendation,
+say so explicitly) is exercised implicitly on every phase, every run.
+S4 (long phased interview, near round-limit closeout) was not exercised
+standalone. Primary model `qwen3.8-27b` on `dynamo` (LM Studio); cross-model
+confirm on `ornith1.5-35b-moe` on `mini` (llama.cpp), required per this
+session's brief because a prior pass in the same mission found fixes tuned
+on one model family did not always transfer to another.
+
+| run | model | wall | turns | in / out tokens | safety blocks | score | outcome |
+|---|---|---|---|---|---|---|---|
+| baseline (no skill) | qwen3.8-27b | 42s | 3 | 32.5k / 3.7k | 0 | 5/10 | never invoked `/skill grill-me`; read both key files and grepped for "alerting", grounded correctly, but produced one live-style question and stopped — no phase map, no decision log (expected: this is what the skill exists to fix) |
+| v1 (frozen 0.4.0) | qwen3.8-27b | 57s | 7 | 91.8k / 5.2k | 2 (1 real: `tasks` refused; 1 benign ENOENT on a fixture-dangling doc path) | 3/10 | opened a `tasks` plan for its own phase map (refused — `tasks` was never called out as off-surface in the frozen body), scanned thoroughly, then asked exactly **one** question in plain text and ended the turn — never called `ask_user` at all, never produced a decision log. This is the exact failure the session was built to catch: the frozen skill's fallback line ("if `ask_user` is unavailable, ask in plain text... keep an internal decision log") reads as permission to have an ordinary single-question live conversation, and the model took it literally |
+| v2 (first hardened cut, 0.5.0) | qwen3.8-27b | 121s | 6 | 78.9k / 11.2k | 1 (benign ENOENT, same dangling doc path) | 9/10 | scanned via `git`/`read`/`ls`, reasoned "ask_user is not in my tool surface" (not quite accurate — it's always exempt — but harmless), and correctly ran the full assumed-confirm monologue through Phases 0-5 to a complete, correctly-shaped decision log, entirely without ever calling `ask_user`. Fixture's dangling PRD reference removed after this run to isolate real vs. benign blocks |
+| v2 re-run (fixture fixed) | qwen3.8-27b | 134s | 7 | 101.0k / 12.1k | 1 real: `bash wc`/`bash head` on the sample log, refused | 9/10 | same strong monologue and decision log; the one new gap was a `bash` reflex the frozen and first-cut bodies never explicitly forbade (grill-me never had `bash` in `allowed-tools`, but nothing told the model not to reach for it) |
+| v3 (bash-refusal added) | qwen3.8-27b | 97s | 5 | n/a | 0 | 6/10 | `bash` reflex gone, but a **regression**: stated "this harness has no `ask_user` tool" (still not quite accurate) and, without ever calling `ask_user`, asked one plain-text question and ended the turn on "Answer 1 / 2 / 3" — the exact frozen-skill failure recurring under the hardened body, proving the earlier fix's trigger ("switch on the first `cancelled` result") had a gap: a model that never calls `ask_user` at all never receives a `cancelled` result to trigger the switch |
+| v4 (no-back-and-forth line added) | qwen3.8-27b | 124s | 6 | 85.1k / 11.0k | 0 | **10/10** | full 9-round monologue (Phases 0-5), correctly-shaped decision log, zero `tasks`/`bash` calls |
+| v5 (stability re-run) | qwen3.8-27b | 95s | 5 | n/a | 0 | **10/10** | repeat of v4's result, confirming v3's regression was not the new steady state |
+| final (cross-model confirm) | ornith1.5-35b-moe (mini) | 64s | 5 | 12.5k / 5.4k | 0 | **10/10** | full monologue and decision log on the second model family too; independently proposed a Slack-message trigger threshold not in the fixture and, in its closing line, distinguished what it would still "press on live" from what it correctly resolved on its own headless — the clearest sign the headless/live distinction actually landed as a real distinction, not just prose the model echoes back |
+
+**Changes** (0.4.0 -> 0.5.0):
+
+1. **`## Arguments` contract**, the section the skill never had — slash-free
+   conversational syntax, and the ported no-operator/`ask_user`-auto-cancels
+   rule from the planning category, adapted for a skill whose entire
+   contract is "one question at a time" rather than a document write.
+2. **The critical fix, found empirically, not guessed up front**: the
+   frozen skill's fallback line ("if `ask_user` is unavailable, ask in
+   plain text... one question at a time... internal decision log") reads,
+   correctly, as "have a normal one-question conversation" — which is
+   exactly wrong when there is no second turn for a reply to land in. The
+   fix that actually held (v4/v5, and the cross-model run) is a **"this run
+   has no back-and-forth" statement that does not gate on receiving a
+   `cancelled` result** from `ask_user` — v3's first attempt gated the
+   switch-to-monologue on "the first round comes back cancelled," which
+   left a real gap: a model that reasons "`ask_user` isn't available" and
+   never calls it at all never receives that trigger, and fell straight
+   back into the frozen skill's exact failure. The held version states the
+   no-reply-coming rule as a fact about the run itself, independent of
+   whether `ask_user` was ever invoked.
+3. **Explicit `tasks` and `bash` refusal**, in Arguments and Red Flags —
+   `tasks` was v1's real safety block (opened a plan for its own phase
+   map); `bash` was a reflex on the v2 re-run (`bash wc`/`bash head` on a
+   file that should have been `read`). Both are outside `allowed-tools`
+   already; the gap was that nothing said so in the body.
+4. **Step 3 and Step 4 rewritten** to name the headless-cancellation
+   handling explicitly at the exact point in the workflow it applies (not
+   only in Arguments): Step 3 states that neither a `cancelled` result nor
+   never calling `ask_user` at all is a reason to wait; Step 4 draws the
+   line between a live stop signal (still respected) and a headless
+   `cancelled` result (not a stop signal, a cue to keep going).
+5. **`git` tool and `code_nav` called out explicitly in Step 1** for repo
+   state and symbol lookups respectively — `code_nav` remains unexercised
+   by every run this session (see Still weak); `git` was used in every
+   hardened run once named.
+6. Five Red Flags entries rewritten or added around the concrete failures
+   observed: `tasks`/`bash` reaches, re-calling `ask_user` after a
+   cancellation, treating `cancelled` as a user stop signal, and — the
+   headline one — ending a turn on "Answer 1/2/3" instead of running the
+   monologue to the decision log.
+
+**Still weak**: `code_nav` (in `allowed-tools`) was never exercised by any
+run this session — this fixture's grounding lived entirely in prose files
+and one Python module small enough that `read`/`grep` sufficed; a fixture
+with a larger call graph might exercise it, but none was built. S3 and S5
+are reasoned about, not directly run (see the fixture note above) — a
+harness that could inject a specific `ask_user` reply (rather than always
+auto-cancelling) would let those two scenarios run for real instead of by
+inference. S4's near-round-limit closeout behavior is unverified; every
+hardened run here converged well under any plausible `max_rounds` value.
+v3's regression is the one data point worth remembering past this session:
+gating a headless-degradation rule on "the first tool result that comes
+back a certain way" is fragile against a model that skips the tool call
+entirely and reasons its way to the same wrong conclusion by a different
+path — the fix needed to be a fact about the run, not a reaction to one
+tool's return value. Two consecutive clean runs on the primary model and
+one clean cross-model run is reasonable but not exhaustive evidence that
+v3's failure mode is fully closed rather than just less frequent; only a
+larger run count would raise that confidence further.
+
+## Live interactive confirmation (2026-09-03, Herdr pane)
+
+The headless harness can only prove the assumed-confirm monologue path; it
+cannot produce a genuine "whatever you think" or "stop" reply because
+`ask_user` always auto-cancels with no operator. To exercise S3 and S5 for
+real, this session ran the hardened 0.5.0 skill interactively: a Herdr pane
+running `clio-coder` (target `mini`, model `ornith1.5-35b-moe`, switched
+in-session via `/model`) against the same fixture repo the battletest used
+(`/home/akougkas/eval-temp/grillme-final`, skill installed project-locally
+at `.clio-coder/skills/grill-me/` so the live session resolved this
+repo's edited SKILL.md rather than the separately npm-installed package
+copy — `/skill grill-me` has no path-override flag the way `clio-coder run
+--skill` does), with a human answering each `ask_user` round live via the
+TUI's modal.
+
+Result: Step 1 scanned the repo before asking anything (architecture doc,
+scanner.py, sample log). Round 1 asked a single root-decision question
+(trigger model) with the recommended option first and real tradeoffs on
+the alternatives. After the human's real answer came back, the model's own
+reasoning explicitly named the distinction the whole hardening pass turned
+on: *"The modal returned round_answered — there is an operator here...
+this is a live interview, not headless. I'll continue with one question
+per round and wait for your answers."* — proof the headless/live branch is
+a real fork in the model's behavior, not just prose it echoes. Five rounds
+ran in priority order (trigger, success measure, non-goals, delivery/
+secrets, payload shape); round 3 was answered "whatever you think is
+best" and recorded the stated recommendation as the decision (S3,
+confirmed live, not just implied by the monologue path); round 5 was
+answered with an appended stop signal ("...; stop") and the model called
+`ask_user` `action: "complete"` immediately, with no confirmation question
+(S5, confirmed live). The final decision log matched the Step 5 shape
+exactly (numbered decisions, Deferred, Open risks, Recommended next step)
+and, unprompted, flagged a real cross-cutting risk the fixture didn't
+spell out: the alerting feature's success measure depends on Phase 2's
+ranking/CLI, which doesn't exist in `scanner.py` yet — a genuine "hole
+poked," not filler. Zero safety blocks; zero `tasks` calls. One aside, not
+a skill defect: the TUI's own usage nudge fired ("9+ read-only exploration
+calls without a successful Scout dispatch") — Step 1's repo scan currently
+reaches for `read`/`grep`/`ls` directly rather than delegating broad
+reconnaissance to a Scout dispatch, worth a look in a future pass but out
+of scope for this one since the scan itself was correct and grounded.
+
+This closes the S3/S5-not-directly-run gap noted above for the specific
+case of a genuine live operator; the headless assumed-confirm path
+remains separately and repeatedly confirmed on its own terms.

package/skills/workflow/workflow-distiller/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: workflow-distiller
-description: Use when a workflow that just happened should become reusable, when the user says "make this a skill", "package what we just did", "turn this into a workflow", or when the same multi-step process has been repeated across sessions. Reconstructs the workflow from the session record, interviews, checks overlap with installed skills, gates on approval, then writes the SKILL.md following skill-craft. Not for authoring a skill from scratch with no prior workflow; write the SKILL.md directly following skill-craft. Not for distilling into an agent recipe; propose that as a follow-up when the workflow is dispatch-shaped.
+description: "Packages a workflow that just happened into a reusable SKILL.md: reconstructs it from the session record, checks overlap with installed skills, gates on approval, then writes it following skill-craft. Not for authoring a skill with no prior workflow; use skill-craft."
 triggers:
   - make this workflow a skill
   - package what we just did
   - turn this into a reusable workflow
   - distill this repeated process
   - create a skill from this session
-version: 0.2.2
+version: 0.4.0
 license: Apache-2.0
 allowed-tools:
   - read
@@ -38,6 +38,37 @@ following skill-craft. skill-craft also governs how every skill this
 distiller produces is written: description, body, and pruning rules live
 there, not here.
 
+## Arguments
+
+```text
+/skill workflow-distiller [<what to distill>]
+```
+
+With arguments, the text names the workflow to distill; without, distill
+whichever workflow just ran in this session. Everything else in the request
+(the conversation so far) is the session record Phase 1 reconstructs from,
+not more arguments.
+
+A live operator can answer Phase 2's interview and Phase 4's design gate for
+real - treat a real, non-cancelled `ask_user` reply as proof an operator is
+present and continue asking one question per round. There is no operator in
+a headless run: `ask_user` is not registered and every call resolves
+`cancelled` immediately, whether or not it is ever called at all. When that
+is the run's condition, do not wait for a reply that cannot come: answer
+every remaining interview question and the Phase 4 gate yourself as an
+assumed-confirm monologue (state the question, give your best-grounded
+answer or design choice, mark it `assumed - confirm`) and proceed straight
+through to Phase 5, the same way as a live "looks fine, write it." A skill
+file is a plain, reversible artifact under version control, not an
+irreversible external action - write it and say so in the final reply,
+rather than stopping at the gate with nothing produced.
+
+`tasks` sits outside this skill's tool surface (`read`, `grep`, `find`,
+`ls`, `context`, `write`, `ask_user`) and any call is refused; the six
+phases above are the plan, not a task list. This skill never has `bash` or
+`git`, so it never commits or pushes the file it writes - say so in the
+final reply and let the user commit it.
+
 ## Phase 1 - Reconstruct From Evidence
 
 Before asking anything, list the concrete steps that visibly executed in this
@@ -90,27 +121,47 @@ Validation scenario: <prompt, expected observable behavior>
 ```
 
 No skill file is written before the user approves. "Looks fine, but change X"
-means revise and re-present.
+means revise and re-present. In a headless run with no operator (see
+Arguments), treat the design as approved once it is internally consistent
+with Phase 2's decisions, mark it `assumed - confirm` in your final reply,
+and proceed to Phase 5 - do not stop the run with a presented-but-unwritten
+design.
 
 ## Phase 5 - Create
 
-Write `SKILL.md` under `.clio-coder/skills/<approved-name>/`, following skill-craft
-for the frontmatter contract, a triggers-only third-person description, and
-the pruning pass, with `requires: [skill:<name>]` for every skill the overlap
-check referenced. Confirm it loads with `clio-coder skills validate`. Scope
-defaults to project; use the user skill store only when the user said the
-workflow crosses repositories. Placeholders replace every session-specific
-path, name, and value; distill the pattern, not the incident. Keep the
-generated skill under 120 lines; reference instead of inlining. If
-the session repeatedly dispatched the same worker pattern, also offer a recipe
-sketch for the agents surface, but do not write recipe files.
+Write `SKILL.md` under `.clio-coder/skills/<approved-name>/` with the
+frontmatter contract below - a triggers-only third-person description, and
+the pruning pass - with `requires: [skill:<name>]` for every skill the
+overlap check referenced. Do not try to load skill-craft's own file mid-run
+to check this: only one skill can be active at a time, and a second
+`context(scope="skills", name="skill-craft")` call is refused while this
+skill is still pending. The frontmatter contract, current as of this
+writing: `name`, `description` (third-person triggers, no "I"/"you"),
+`triggers` (a non-empty list), `version` (start `0.1.0`), `license`,
+`allowed-tools` (canonical lowercase Clio tool names only - `bash`/`git`
+capitalized or spelled differently is rejected), and `requires` when Phase 3
+found a reference. If in doubt about the exact shape, `read` an already-
+installed skill's `SKILL.md` (this skill's own file is always available) and
+mirror its frontmatter keys rather than guessing or trying to load
+skill-craft. Scope defaults to project; use the user skill store only when
+the user said the workflow crosses repositories. Placeholders replace every
+session-specific path, name, and value; distill the pattern, not the
+incident. Keep the generated skill under 120 lines; reference instead of
+inlining. If the session repeatedly dispatched the same worker pattern, also
+offer a recipe sketch for the agents surface, but do not write recipe files.
 
 ## Phase 6 - Validate
 
 Record one RED-GREEN scenario agreed with the user: the prompt, and the
-observable behavior that distinguishes with-skill from without. Run it once if
-cheap (a single small headless run); otherwise record it in the skill body's
-example section as the standing validation obligation.
+observable behavior that distinguishes with-skill from without. `clio-coder
+skills validate` needs `bash`, which is outside this skill's tool surface -
+never attempt it; instead `read` the file back and confirm the frontmatter
+contract from Phase 5 by eye (required keys present, `allowed-tools` entries
+canonical lowercase, under the line budget), and say plainly that a real
+`clio-coder skills validate` pass is still owed once bash is available.
+Otherwise record the scenario in the skill body's example section as the
+standing validation obligation. This skill has no `bash`/`git`, so it never
+commits or pushes the file it writes; say so and let the user commit it.
 
 ## Worked Example
 
@@ -128,15 +179,23 @@ script, and verified row counts against the source, three sessions in a row.
    installed; no references.
 4. Gate: summary presented; user approves after tightening the description.
 5. Create: write `.clio-coder/skills/csv-ingest/SKILL.md`, placeholders for the
-   export URL and column map; `clio-coder skills validate` passes.
+   export URL and column map; frontmatter contract confirmed by reading the
+   file back (no `bash`, so no `clio-coder skills validate` this turn).
 6. Validate: scenario "ingest this month's export" must show fetch,
    normalize, count-verify, spot-check in that order; recorded in the body.
 
 ## Red Flags
 
-- Writing any skill before the design gate is approved.
+- Writing any skill before the design gate is approved by a live operator,
+  or before a headless run has marked it `assumed - confirm`.
+- Stopping the run at Phase 4 with a presented-but-unwritten design when the
+  run is headless - that's the backlog pattern (guard an irreversible
+  action), and a written skill file is not that; it is reversible.
 - A reconstruction that lists steps nothing in the session shows.
 - Reimplementing an installed skill's job instead of referencing it.
 - Session-specific paths or values surviving into the generated skill.
 - Batching interview questions or ignoring a stop signal.
 - Distilling a one-off without asking about recurrence.
+- Calling `bash` for `clio-coder skills validate`, or `context` with a
+  second skill's name to consult it mid-run: both are outside this skill's
+  tool surface and refused.

package/skills/workflow/workflow-distiller/evals.md

@@ -105,3 +105,121 @@ prompt; the phases still had to run in order.
 
 One representative scenario via `clio-coder skills eval` against Nemo-3.5-Lightning
 (30B local, llamacpp on mini), full-auto sandbox. PASS. Inline session-trace setup engaged; judge 5/6.
+
+## Battletest record (2026-09-03)
+
+This skill's core loop (a several-turn interview, a live-or-headless design
+gate, a write) is genuinely interactive, so it was tested primarily through
+a live Herdr-driven `clio-coder` pane with a real human answering
+`ask_user` rounds, not only through the headless harness the rest of this
+category used — plus one headless confirm run to exercise the no-operator
+path directly. Fixture: the shared HPC log-triage repo (`test_grillme.py`'s
+`setup_fixture`, `docs/hpc-log-triage-architecture.md` + partial
+`src/scanner.py`/`tests/test_scanner.py`), compounded with a real Part 1
+task ("add `scan_ecc` mirroring `scan_oom`, test it, commit it") run to
+completion *before* invoking `/skill workflow-distiller`, so Phase 1 had a
+genuine session record to reconstruct from rather than a scripted one.
+
+**v1 (frozen 0.3.0), live, `ornith1.5-35b-moe` on mini**: Phase 1
+reconstruction was precise and correctly cited to real tool calls. The
+5-round interview (confirm+recurrence, varies/fixed, rigidity/failure,
+scope cuts, name) ran cleanly, one question per round, recommended-first.
+Phase 3's overlap check correctly found nothing to reference. Phase 4's
+design gate presented the exact template shape and correctly waited for a
+live "looks fine, write it" before writing anything. Two real bugs
+surfaced in Phase 5/6: (1) "load skill-craft" is dead - `context(scope=
+"skills", name="skill-craft")` while workflow-distiller is itself the
+active pending skill is refused ("pending skill request(s)"); only one
+skill can be active at a time. (2) Phase 6's "confirm it loads with
+`clio-coder skills validate`" is dead - `bash` is outside this skill's
+`allowed-tools`, so that command can never run. The model self-recovered
+both times (read its own installed SKILL.md as a frontmatter mirror; did a
+by-eye read-back instead of the blocked validate command) and reported the
+gap honestly rather than fabricating a clean validate - a good sign for
+model robustness, but the skill body should not depend on a model
+inventing its own workaround for a dead instruction.
+
+**Changes (0.3.0 -> 0.4.0)**: new `## Arguments` section stating the
+live-vs-headless distinction explicitly (a real, non-cancelled `ask_user`
+reply proves an operator is present and interview/gate proceed normally;
+`ask_user` unregistered and auto-cancelling means assumed-confirm through
+Phase 2 and Phase 4 and straight on to Phase 5 - a written skill file is a
+reversible, version-controlled artifact, not the kind of irreversible
+action `backlog`'s Step 3 guards, so it does not get that skill's
+stop-and-report treatment); explicit `tasks` refusal and a "never commits"
+note; Phase 4 gate prose updated with the headless branch; Phase 5 rewrote
+the skill-craft consultation into a concrete, achievable frontmatter
+contract (the required keys, and "`read` an already-installed skill's file
+to mirror the shape, never try to load a second skill mid-run"); Phase 6
+rewrote the validate step to a real, achievable by-eye check instead of
+the dead `bash` command; the worked example's line claiming `clio-coder
+skills validate` passes was corrected to match; two new Red Flags entries
+for the two dead-instruction failure modes.
+
+**v2 (hardened 0.4.0), live, `ornith1.5-35b-moe` on mini, fresh session**:
+same compound Part 1 + Part 2 scenario end to end. Real finding along the
+way, unrelated to this skill: the model cannot self-invoke `/skill` - it
+is operator-gated UI, not an agent tool, confirmed twice (once via a
+direct `context` call, once by embedding `/skill workflow-distiller` in a
+larger message instead of sending it standalone) - both times the model
+correctly recognized the constraint, said so, and asked the operator to
+run it rather than retrying or faking activation. Once invoked properly:
+Phase 1 reconstruction included the real mid-session detour (a genuine
+case-sensitivity bug the model introduced and fixed via byte-level
+debugging) rather than a cleaned-up story. The interview produced a
+materially different design from v1's run on the same scenario (different
+name chosen, "leave uncommitted" instead of "commit via bash" for the
+generated skill) - real evidence the interview is actually deciding things,
+not replaying a script. Phase 4 correctly said "this is a live run, so
+I'll hold off writing until you approve" and, when a later `ask_user`
+round had already closed, correctly fell back to a plain-text approval
+request rather than stalling - explicitly restating, unprompted, every
+constraint this session's hardening pass had just added (no commit, no
+`clio-coder skills validate`, `tasks` out of surface). Phase 5 went
+straight to `read`-ing its own installed SKILL.md to mirror the frontmatter
+contract, with zero attempt to load skill-craft - bug #1 confirmed fixed.
+The generated `.clio-coder/skills/add-signature-scanner/SKILL.md` (97
+lines) has valid frontmatter, canonical-lowercase `allowed-tools`, real
+placeholders, and a concrete validation scenario.
+
+**A real, separate platform-level finding, not a skill-body bug**: during
+this same v2 live session's Phase 6, a `bash wc -l` call executed
+successfully (`exit 0`, green checkmark confirmed via `--format ansi`) even
+though `bash` is not in workflow-distiller's `allowed-tools` - and the
+identical class of call had been correctly refused earlier in this exact
+mission's v1 session under the same skill ("bash is outside the tool
+surface declared by the active skill(s)"). The model's own final report
+then claimed "I can't run bash" in the same breath as having just run it.
+This reads as skill tool-surface narrowing lapsing partway through a long,
+many-turn interactive session (Phase 1 through 6 spans several real
+conversation turns; the headless harness's single-turn monologue shape
+never exercises this), not anything a SKILL.md can fix by itself. Worth a
+maintainer look at the interactive admission path specifically, independent
+of this skill or this mission's edits.
+
+**Headless confirm, `qwen3.8-27b` on dynamo, fresh fixture**: single
+`clio-coder run --skill ... --autonomy full-auto --json`. Real fixture
+mismatch, deliberately not corrected: the prompt claimed a prior
+`scan_ecc` commit that does not exist in this fresh fixture (no Part 1 ran
+here). Phase 1 caught the discrepancy against real evidence (`grep` found
+no `scan_ecc`, git log has one seed commit, the docstring still says "not
+yet implemented"), tagged the claim `assumption - unverified`, and
+grounded the distillation in the real architecture doc and `scan_oom`'s
+actual code instead of fabricating verification of a commit that never
+happened - the skill's stated identity ("runtime truth... reconstruction
+wins") holding on a weaker/non-live model under direct pressure to just
+agree. Ran the full assumed-confirm monologue through Phase 2 and Phase 4
+(explicitly marked), wrote `.clio-coder/skills/signature-scanner/SKILL.md`
+(92 lines, valid frontmatter, canonical-lowercase tools, real placeholders,
+a concrete failure-behavior section, a validation scenario naming the still
+-owed real `clio-coder skills validate` pass). Zero safety blocks.
+
+**Still weak**: the skill-craft mid-run-load and dead-`bash`-validate bugs
+are confirmed fixed by re-test, but only against this one fixture shape.
+S2 (overlap with an installed skill) was not exercised this pass - this
+fixture's only installed skill is workflow-distiller itself, so the overlap
+check always correctly found nothing; a fixture with a second installed
+skill covering one step is still owed. S3 (no recurrence, offer to stop)
+was not exercised standalone. The tool-surface-lapse finding above is
+real, reproduced, and unresolved - it is the single biggest risk this pass
+surfaced, and it sits outside this skill (and outside `skills/`) entirely.

package/src/cli/args.ts

@@ -166,12 +166,12 @@ export function parseRunCliArgs(argv: ReadonlyArray<string>): RunCliArgs {
 			if (value !== null) parsed.agentId = value;
 			continue;
 		}
-		if (arg === "--agent-profile" || arg === "--worker-profile" || arg === "--worker") {
+		if (arg === "--agent-profile") {
 			const value = need(arg);
 			if (value !== null) parsed.agentProfile = value;
 			continue;
 		}
-		if (arg === "--agent-runtime" || arg === "--worker-runtime" || arg === "--runtime") {
+		if (arg === "--agent-runtime") {
 			const value = need(arg);
 			if (value !== null) parsed.agentRuntime = value;
 			continue;

package/src/cli/bootstrap-generate.ts

@@ -325,7 +325,7 @@ async function attemptBootstrapDispatch(
 	// and returned zero bytes at 29s. The wiki documenter in this same directory
 	// budgets minutes for the same shape of work. `internalDispatchTimeoutMs` is
 	// the operator's knob for slow targets; nothing here knows better than it does.
-	const deadline = armInternalDispatchDeadline(dispatch, handle.runId, "context bootstrap", process.env);
+	const deadline = armInternalDispatchDeadline(dispatch, handle.runId, "context bootstrap");
 	let text = "";
 	let receipt: RunReceipt | undefined;
 	let parserAttempted = false;