@iowarp/clio-coder 0.4.6 → 0.4.8

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

@@ -0,0 +1,204 @@
+---
+name: workflow-distiller
+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.4.2
+license: Apache-2.0
+allowed-tools:
+  - read
+  - grep
+  - find
+  - ls
+  - context
+  - write
+  - ask_user
+requires:
+  - skill:skill-craft
+clio-coder:
+  registry-id: iowarp/clio-coder
+  source-url: https://github.com/iowarp/clio-coder/tree/main/library/skills/workflow/workflow-distiller
+  audit: pass
+  provenance: designed
+  eval-status: scenarios-recorded
+  model-size: large
+---
+
+# Workflow Distiller
+
+Turn a workflow that actually ran into a reusable skill. The distiller's
+identity is runtime truth: it reconstructs what happened from the visible
+session record, not from anyone's memory of it. Skip the ceremony when there
+is no prior workflow; a from-scratch skill is a SKILL.md written directly,
+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, answered `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, so any call is refused as an
+unregistered tool rather than answered. 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
+session, in order: tools called, commands run, files touched, dispatches made,
+skills activated. Cite the conversation record for each step. Anything the
+user describes that did not visibly run is tagged `assumption` and becomes an
+interview question. This grounding step is mandatory and comes first; when the
+reconstruction and the user's memory disagree, the reconstruction wins and the
+disagreement is worth a question.
+
+## Phase 2 - Interview
+
+Use `ask_user` with `mode: "single_question"`, one question per round, bounded
+rounds (default 8, max 12), following the grill-me operating contract:
+recommended answer first when options are natural, stop signals ("stop",
+"enough", "later", cancel) respected immediately, answers translated into
+compact decisions. Question bank, roots before leaves:
+
+1. Confirm the reconstruction and resolve tagged assumptions.
+2. Inputs and outputs: what varies between runs, what is fixed.
+3. Recurrence: how often has this actually happened? A workflow that ran once
+   is usually not worth a skill; ask early and offer to stop.
+4. Per-step rigidity: must-match versus any-reasonable-approach.
+5. Failure behavior per step: ask the user, retry an alternative, or fail
+   loudly.
+6. Scope cuts: what the skill should refuse to do.
+7. Name (lowercase-hyphen).
+
+## Phase 3 - Overlap Check
+
+Call `context(scope="skills")` with no name to list installed skills. Judge
+overlap per step, not per workflow: if an installed skill's triggers cover a
+step, that step is referenced by name in the new skill body, never
+reimplemented, with a one-line rationale for the dependency. A different end
+goal does not excuse reimplementing a covered step. Record each reference as
+a `requires: [skill:<name>]` entry in the generated skill's frontmatter in
+Phase 5, so the loader warns when the dependency is missing.
+
+## Phase 4 - Design Gate
+
+Present a compact design summary and wait for explicit approval:
+
+```markdown
+## Skill Design - <name>
+Description draft: <triggers only, third person>
+Steps: <step, rigidity, on-failure> per line
+References: <skill:<name>, why> or none
+Scope: project | user (user only if the workflow crosses repositories)
+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. 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 `draft-skills/<approved-name>/`, outside protected active
+skill and installed package roots, 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. The proposed installation scope defaults to project; suggest user
+scope only when the user said the workflow crosses repositories. Creation here
+produces a draft. The operator later reviews a portable package envelope and
+installs through the Library; never write into an active skill store directly. 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. `clio-coder
+library validate draft-skills/<approved-name>/SKILL.md` 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 library 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
+
+Session: the user fetched a CSV export, normalized column names with a small
+script, and verified row counts against the source, three sessions in a row.
+
+1. Reconstruct: `bash curl ...` (ran), `write normalize.py` + `bash python3
+   normalize.py` (ran), `bash wc -l` comparison (ran). User also mentions "and
+   I always spot-check five rows" - not visible this session, tagged
+   assumption.
+2. Interview: confirms reconstruction; spot-check confirmed as a real step;
+   recurrence "weekly"; normalization must-match, fetch any-approach; failure
+   on row-count mismatch must fail loudly; name `csv-ingest`.
+3. Overlap: the `context(scope="skills")` listing shows no fetch or CSV skill
+   installed; no references.
+4. Gate: summary presented; user approves after tightening the description.
+5. Create: write `draft-skills/csv-ingest/SKILL.md`, placeholders for the
+   export URL and column map; frontmatter contract confirmed by reading the
+   file back (no `bash`, so no `clio-coder library 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 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 library 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/library/skills/workflow/workflow-distiller/evals.md

@@ -0,0 +1,233 @@
+# Evals - workflow-distiller
+
+Baseline scenarios (run a subagent WITHOUT the skill to capture the gap, then
+WITH the skill to confirm it closes). Rubric is pass/fail per bullet.
+
+## S1 - "make what we just did a skill"
+
+Setup: Make what we just did a skill. For the record, this session we ran
+the release-notes workflow end to end: pulled the merged PR titles since
+the last tag with gh, grouped them by conventional-commit type, rewrote
+each group into user-facing bullets, and verified every PR number in the
+draft against the gh list before saving docs/release-notes.md. I also
+mentioned we sometimes ping the release channel afterwards, but we did not
+do that here.
+
+Expected:
+
+- Reconstructs the executed steps from the session record, in order, before
+  asking any question; unobserved steps the user mentions are tagged as
+  assumptions.
+- Interviews via `ask_user` with `mode: "single_question"`, one question per
+  round, bounded rounds.
+- Lists installed skills via `context(scope="skills")` with no name before
+  designing.
+- Presents a compact design summary and waits for explicit approval.
+- Writes `draft-skills/<name>/SKILL.md` only after approval, with
+  session-specific values replaced by placeholders.
+- Keeps the draft outside protected active roots and identifies the operator
+  Library installation step; creation alone does not install or activate it.
+- Records a RED-GREEN validation scenario.
+
+## S2 - overlap with an installed skill
+
+Setup: the workflow's retrieval step is already covered by an installed skill
+(for example arxiv-literature for paper retrieval).
+
+Expected:
+
+- The overlap check finds the installed skill.
+- The generated skill references it by name instead of reimplementing the
+  step, with a one-line rationale in the body.
+- The generated frontmatter carries `requires: [skill:<name>]` so the loader's
+  unmet-dependency warning arms when the referenced skill is absent.
+
+## S3 - no recurrence
+
+Setup: mid-interview the user admits the workflow has only ever run once and
+may not recur.
+
+Expected:
+
+- Questions whether distillation is worth it and offers to stop.
+- Does not press on to create a skill for a one-off by default.
+
+## S4 - anti-trigger: brand-new skill
+
+Setup: user asks for a new skill for something never done in any session.
+
+Expected:
+
+- Skips the distiller ceremony and points at writing the SKILL.md directly,
+  following skill-craft.
+
+## Baseline failure modes to watch for (RED)
+
+- Writes a vague skill immediately from the user's description, no grounding
+  in what actually ran.
+- No overlap check; reimplements an installed skill's behavior.
+- No approval gate; the skill file appears before the user saw a design.
+- Session-specific paths, URLs, and values baked into the skill body.
+- Multi-question interviewing or an unbounded question stream.
+
+## Instruction correction (2026-09-10)
+
+Version 0.4.2 moves draft creation outside protected active roots and corrects
+the validator command. Historical observations below describe earlier versions.
+The revised scenarios are recorded; no fresh model smoke run is claimed.
+
+## Observed results
+
+Runs 2026-07-02, headless `clio-coder run --skill`. `ask_user` is not registered in
+headless runs, so interviews were exercised with pre-supplied decisions in the
+prompt; the phases still had to run in order.
+
+- Six-phase walk (CSV header normalization fixture): the workflow visibly ran
+  (write plus execute normalize.py, row-count check), Phase 1 cited exactly
+  those steps, Phase 2 applied the pre-supplied decisions question by
+  question, Phase 3 listed installed skills with no name, Phase 4 presented
+  the summary and stopped for approval even though pre-approval was offered
+  (the strict reading of the gate), and after an explicit approval turn Phase
+  5's skill-creation call landed a loadable project skill that `clio-coder skills
+  inspect` resolves, with placeholders instead of session paths. Phase 6
+  recorded the validation scenario in the body.
+- S2 RED (no distiller, arxiv-literature installed): the baseline created the
+  skill immediately with no overlap check against the installed-skill
+  listing, no gate, and a body that reimplements the fetch step. Gap
+  confirmed.
+- S2 GREEN: with the shipped per-step overlap wording, the design references
+  `arxiv-literature` with a rationale instead of reimplementing retrieval.
+  Two earlier drafts missed this: workflow-level overlap judgment and a
+  fixture prompt that prescribed the fetch mechanism both masked the
+  behavior; the wording now says a different end goal does not excuse
+  reimplementing a covered step. At the time of that run the skill-creation
+  tool could not emit `requires` frontmatter, so the skill handed the user
+  the line to add; `requires: [skill:arxiv-literature]` on the generated
+  skill was verified to produce the loader's "requires skill ... which is not
+  available" warning when the dependency is absent. 2026-07-02: skill
+  creation moved to writing SKILL.md directly (the artifact tool's skill kind
+  was removed); Phase 5 now writes the `requires` entries into the
+  frontmatter itself.
+
+## Smoke record (2026-08-13)
+
+One representative scenario via `clio-coder eval skill` 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 library 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 library 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 library 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/library/skills/workflow/workflow-distiller/plugin.json

@@ -0,0 +1,23 @@
+{
+	"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
+	"name": "workflow-distiller",
+	"version": "0.4.2",
+	"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.",
+	"license": "Apache-2.0",
+	"extensions": {
+		"ai.iowarp.clio": {
+			"manifestVersion": 1,
+			"kind": "skill",
+			"resources": {
+				"skills": "."
+			},
+			"components": [
+				{
+					"kind": "skill",
+					"id": "workflow-distiller",
+					"path": "SKILL.md"
+				}
+			]
+		}
+	}
+}

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@iowarp/clio-coder",
-	"version": "0.4.6",
+	"version": "0.4.8",
 	"description": "The terminal coding agent for people who maintain the code that science runs on, with user-chosen models and inspectable evidence.",
 	"keywords": [
 		"ai",
@@ -43,17 +43,20 @@
 		"clio-coder": "dist/cli/index.js"
 	},
 	"exports": {
-		"./package.json": "./package.json"
+		"./package.json": "./package.json",
+		"./extensions": {
+			"types": "./src/domains/extensions/public-api.ts"
+		}
 	},
 	"files": [
 		"dist",
 		"!dist/**/*.map",
 		"assets/clio-coder-logo-128.webp",
 		"src/**",
-		"skills/**",
+		"library/**",
+		".claude-plugin/marketplace.json",
 		"evals/**",
 		"docs/**/*.md",
-		"!docs/html/**",
 		"README.md",
 		"CHANGELOG.md",
 		"CONTRIBUTING.md",
@@ -61,14 +64,15 @@
 		"CODE_OF_CONDUCT.md",
 		"NOTICE",
 		"LICENSE",
-		"damage-control-rules.yaml"
+		"damage-control-rules.yaml",
+		"examples/extensions/**"
 	],
 	"publishConfig": {
 		"access": "public"
 	},
 	"scripts": {
-		"build": "tsup && node --import tsx scripts/build-codewiki-asset.ts",
-		"dev": "tsup --watch",
+		"build": "node --import tsx scripts/build.ts && node --import tsx scripts/build-codewiki-asset.ts",
+		"dev": "node --import tsx scripts/build.ts --watch",
 		"clean": "rm -rf dist",
 		"typecheck": "tsc -p tsconfig.tests.json",
 		"format": "biome format --write .",
@@ -77,16 +81,21 @@
 		"pi:surface-snapshot": "node --import tsx scripts/pi-surface-diff.ts --write",
 		"test:file": "node --import tsx --import ./tests/harness/tmp-root.ts --test",
 		"pretest": "test -f dist/cli/index.js || pnpm run build",
-		"test": "node --import tsx --import ./tests/harness/tmp-root.ts --test tests/contracts/*.test.ts tests/smoke/*.test.ts",
-		"test:trace-viewer": "pnpm --filter @iowarp/clio-trace-viewer test",
-		"trace:ui": "node apps/trace-viewer/server.mjs",
-		"ci": "pnpm run typecheck && pnpm run lint && pnpm run build && pnpm run test && pnpm run test:trace-viewer",
-		"ci:release": "pnpm run ci && node scripts/check-release.mjs",
+		"test": "node --import tsx --import ./tests/harness/tmp-root.ts --test --test-concurrency=2 tests/contracts/*.test.ts tests/smoke/acp-boundary.test.ts tests/smoke/real-binary-boot.test.ts tests/smoke/process-lifecycle.test.ts",
+		"test:web": "pnpm --filter @iowarp/clio-coder-web test",
+		"ci": "pnpm run typecheck && pnpm run lint && pnpm run build && pnpm run test && pnpm run test:web",
+		"ci:release": "node scripts/release-candidate.mjs qualify",
 		"install:local": "bash scripts/install-local.sh",
 		"smoke:real-home": "bash scripts/smoke-real-home.sh",
-		"prepublishOnly": "CLIO_CODER_RELEASE_CONTEXT=publish pnpm run ci:release",
+		"prepublishOnly": "node scripts/release-candidate.mjs preflight",
 		"skills:pin": "node --import tsx scripts/pin-skills.ts",
-		"skills:check": "node --import tsx scripts/pin-skills.ts --check"
+		"skills:check": "node --import tsx scripts/pin-skills.ts --check",
+		"library:pin": "node --import tsx scripts/pin-library.ts",
+		"library:check": "node --import tsx scripts/pin-library.ts --check",
+		"test:full": "node --import tsx --import ./tests/harness/tmp-root.ts --test tests/contracts/*.test.ts tests/extended/*.test.ts tests/smoke/*.test.ts tests/extended-smoke/*.test.ts",
+		"test:package": "node --import tsx --import ./tests/harness/tmp-root.ts --test --test-concurrency=2 tests/smoke/installed-package.test.ts tests/smoke/native-call-timing.test.ts",
+		"release:preflight": "node scripts/release-candidate.mjs preflight",
+		"test:web:full": "pnpm --filter @iowarp/clio-coder-web test:full"
 	},
 	"optionalDependencies": {
 		"@anthropic-ai/claude-agent-sdk": "0.3.186"

package/src/cli/agents.ts

@@ -9,7 +9,7 @@ import { printError } from "./shared.js";
 
 const HELP = `clio-coder agents [--json] [--all]
 
-List user-facing agent specs from built-in, extension, user, and project recipes.
+List user-facing agent specs from built-in, plugin, user, and project recipes.
 
 Flags:
   --json   emit specs as JSON instead of the formatted table

package/src/cli/config-inspect.ts

@@ -52,7 +52,7 @@ export type CustomizationCategory =
 	| "safety"
 	| "memory";
 
-/** `reload` means an explicit `/resources extensions reload` (or a restart) publishes the change. */
+/** `reload` means an explicit `/extensions reload` (or a restart) publishes the change. */
 export type ReloadClass = "hot" | "next-turn" | "reload" | "restart" | "n/a";
 
 export interface CustomizationEntry {

package/src/cli/configure.ts

@@ -1372,7 +1372,7 @@ const SECTIONS: ReadonlyArray<SectionSpec> = [
 				["Chat thinking", settings.chat.thinkingLevel],
 				["Fleet thinking", settings.fleet.default.thinkingLevel],
 				["Favorites", listOr(settings.chat.modelPicker.favorites)],
-				["Cycle set (Alt+J/K)", listOr(settings.chat.modelPicker.cycleSet)],
+				["Model cycle set", listOr(settings.chat.modelPicker.cycleSet)],
 			];
 		},
 		actions: [
@@ -1437,7 +1437,7 @@ const SECTIONS: ReadonlyArray<SectionSpec> = [
 			},
 			{
 				label: "Cycle set",
-				hint: "comma-separated, Alt+J/K walks it",
+				hint: "comma-separated models for the scoped cycle actions",
 				run: async (io) => {
 					await askList(io, "Cycle set", readSettings().chat.modelPicker.cycleSet, (values) => {
 						updateSettings((draft) => {