[object Object]

← back to Cli Printing Press

refactor(skills): extract Phase 4.85 into printing-press-output-review sub-skill (#379)

a9ca3f80e2f9291df7d4006c9009667314eb24fa · 2026-04-29 00:37:16 -0700 · Trevin Chow

Resolves the cross-skill path-resolution problem where the polish skill
said "run Phase 4.85 as defined in main printing-press SKILL.md" — a
text-level reference that doesn't work reliably when the polish skill
runs in a forked context away from the main skill's bundle.

The new skill at skills/printing-press-output-review/ owns the Phase
4.85 dispatch prompt, gate logic, and known blind spots. Both main
printing-press SKILL.md (Phase 4.85) and printing-press-polish SKILL.md
(diagnostic loop) invoke it via the Skill tool. Single source of truth,
no cross-tree reference, framework dispatch instead of filesystem
lookup.

Frontmatter:

- `context: fork` — reviewer agent's diagnostic chatter stays isolated
  from the calling skill's context.
- `user-invocable: false` — no standalone user value (mid-pipeline
  sub-step). The actionable wrappers are /printing-press and
  /printing-press-polish; running this directly produces floating
  findings text with no ship verdict.

Adds a "Skill Frontmatter: context: fork and user-invocable" section
to AGENTS.md teaching when to set each field, with the printing-press
skill family as a worked example. The internal-only sub-skill pattern
joins the deterministic-inventory + agent-marked-ledger pattern from
PR #378 as documented orchestration shapes future work can reach for.

Files touched

Diff

commit a9ca3f80e2f9291df7d4006c9009667314eb24fa
Author: Trevin Chow <trevin@trevinchow.com>
Date:   Wed Apr 29 00:37:16 2026 -0700

    refactor(skills): extract Phase 4.85 into printing-press-output-review sub-skill (#379)
    
    Resolves the cross-skill path-resolution problem where the polish skill
    said "run Phase 4.85 as defined in main printing-press SKILL.md" — a
    text-level reference that doesn't work reliably when the polish skill
    runs in a forked context away from the main skill's bundle.
    
    The new skill at skills/printing-press-output-review/ owns the Phase
    4.85 dispatch prompt, gate logic, and known blind spots. Both main
    printing-press SKILL.md (Phase 4.85) and printing-press-polish SKILL.md
    (diagnostic loop) invoke it via the Skill tool. Single source of truth,
    no cross-tree reference, framework dispatch instead of filesystem
    lookup.
    
    Frontmatter:
    
    - `context: fork` — reviewer agent's diagnostic chatter stays isolated
      from the calling skill's context.
    - `user-invocable: false` — no standalone user value (mid-pipeline
      sub-step). The actionable wrappers are /printing-press and
      /printing-press-polish; running this directly produces floating
      findings text with no ship verdict.
    
    Adds a "Skill Frontmatter: context: fork and user-invocable" section
    to AGENTS.md teaching when to set each field, with the printing-press
    skill family as a worked example. The internal-only sub-skill pattern
    joins the deterministic-inventory + agent-marked-ledger pattern from
    PR #378 as documented orchestration shapes future work can reach for.
---
 AGENTS.md                                    |  29 ++++++
 skills/printing-press-output-review/SKILL.md | 128 +++++++++++++++++++++++++++
 skills/printing-press-polish/SKILL.md        |  15 +++-
 skills/printing-press/SKILL.md               |  69 +++------------
 4 files changed, 179 insertions(+), 62 deletions(-)

diff --git a/AGENTS.md b/AGENTS.md
index 10701850..473fbf48 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -324,3 +324,32 @@ Reach for this pattern when the work has the **detect mechanically + decide per-
 5. **Verification asks for zero pending, not zero findings.** "Done" means every finding is either fixed (auto-removed) or explicitly accepted with a note — not that the count is zero. Reviewers can see accepts in the ledger and judge whether each rationale holds.
 
 Compared to the alternatives: pure `TodoWrite` state is invisible to the binary and dies with the session; pure binary recompute can't track accept decisions and re-flags them every run; multi-file artifacts (cards/, ledger.md, rejections.md per the `simplify-and-refactor` skill) are heavier than warranted when each item is small and self-contained.
+
+## Skill Frontmatter: `context: fork` and `user-invocable`
+
+Two skill frontmatter fields shape how a skill participates in larger workflows. Both default to permissive behavior (shared context, user-invocable). Set them explicitly when the skill plays a non-default role.
+
+### `context: fork`
+
+Default: skills run in the caller's context. The skill sees the full parent conversation; the parent sees the skill's tool calls and output interleaved with its own work.
+
+`context: fork` gives the skill its own context window. Two consequences pull in opposite directions:
+
+- **Benefit:** the skill starts with a fresh, dedicated context — its full window is available for its own work (multi-step loops, sub-agent transcripts, large reads) rather than competing with whatever the parent has already accumulated.
+- **Cost:** the skill can't see anything from the parent's conversation. Everything it needs must come through `args`, be readable from disk, or be hardcoded.
+
+The decision rule is whether the skill is **self-contained** given its declared inputs. If args plus the filesystem cover everything the skill needs (e.g., `printing-press-polish` takes a CLI dir and reads the rest from the repo and manuscripts; `printing-press-output-review` takes a CLI dir and runs `scorecard --live-check` to gather data), `context: fork` is a clear win. If the skill needs prior tool output, conversation history, or anything else the parent has accumulated, don't fork — the skill won't have access to it and you'll end up plumbing context through args anyway.
+
+### `user-invocable`
+
+Default: `true` — the skill is discoverable as a slash command (`/skill-name`) and routes from trigger phrases in the description. Setting `user-invocable: false` makes it internal-only: only Claude can invoke it (typically via the Skill tool from another skill).
+
+Set `user-invocable: false` when the skill has no standalone meaning for a user. A user typing `/internal-skill` would get half a workflow with no input gate, no follow-up offer, no completion verdict. The actionable wrappers are the parent skills.
+
+In this family, every printing-press skill is user-invocable except `printing-press-output-review`, which runs only as a sub-step inside Phase 4.85 (main skill) and the polish diagnostic loop.
+
+### Internal-only sub-skill pattern
+
+When a workflow step has multiple parents and no standalone user meaning, extract it into a `user-invocable: false` skill that both parents invoke via the Skill tool. Single source of truth for the prompt, gate logic, and any reference docs. The framework dispatches it; nobody has to find and read sibling SKILL.md prose at runtime.
+
+The two fields compose. `context: fork` + `user-invocable: false` is the combo for self-contained internal sub-skills. `context: fork` alone (default user-invocable) is for user-facing skills with their own multi-step workflow that don't need parent context. Default frontmatter is for terse helper skills, or any skill that genuinely needs to see the parent's conversation.
diff --git a/skills/printing-press-output-review/SKILL.md b/skills/printing-press-output-review/SKILL.md
new file mode 100644
index 00000000..73007c09
--- /dev/null
+++ b/skills/printing-press-output-review/SKILL.md
@@ -0,0 +1,128 @@
+---
+name: printing-press-output-review
+description: >
+  Internal sub-skill: agentic review of a printed CLI's sampled command output for
+  plausibility issues that rule-based checks can't encode (substring-match
+  relevance, format bugs, silent source drops, ranking failures). Invoked via the
+  Skill tool by main printing-press SKILL.md (Phase 4.85) and printing-press-polish
+  SKILL.md during the diagnostic loop. Not for direct user invocation — its
+  actionable wrappers are /printing-press and /printing-press-polish.
+context: fork
+user-invocable: false
+allowed-tools:
+  - Bash
+  - Agent
+---
+
+# printing-press-output-review (internal)
+
+Review the sampled outputs from a printed CLI for plausibility bugs that dogfood, verify, and the rule-based `scorecard --live-check` rules can't catch. Wave B policy: all findings surface as warnings, never errors.
+
+This skill is **internal-only** (`user-invocable: false`). It's invoked by parents — main printing-press skill at shipcheck Phase 4.85, polish skill during its diagnostic loop. Running it standalone would produce floating findings text with no ship verdict, no fixes applied, no publish offer; the actionable wrappers are `/printing-press` and `/printing-press-polish`. The skill carries `context: fork` so the reviewer agent's diagnostic chatter stays isolated from the calling skill's context.
+
+## Input
+
+The caller passes `$CLI_DIR` as the argument: an absolute path to the printed CLI's working directory.
+
+## What this catches
+
+Bugs that rule-based checks miss, typically surfaced by 5 minutes of hands-on testing but slipping past dogfood, verify, and `scorecard --live-check` rules:
+
+- Substring-match results that coincidentally contain the query but don't match semantically (e.g., a query matches a substring of a larger unrelated term)
+- Aggregation commands silently dropping sources when only some of the requested N come back
+- Ranking or sort commands returning top-N results that aren't plausibly the best for the query (broken weights, extractor fallbacks)
+- URLs in output pointing at category index pages, feed endpoints, or random-selector routes rather than canonical content permalinks
+- Format bugs the rule-based layer doesn't catch (mojibake, inconsistent pluralization, truncated/wrapped cell content)
+
+## Procedure
+
+### Step 1: Gather sample data
+
+```bash
+printing-press scorecard --dir "$CLI_DIR" --live-check --json > /tmp/output-review-livecheck.json 2>&1 || true
+```
+
+If the scorecard call fails or `/tmp/output-review-livecheck.json` is empty, return the SKIP result (Step 3) without dispatching the reviewer.
+
+### Step 2: Dispatch the reviewer agent
+
+Use the Agent tool (general-purpose) with this prompt contract:
+
+> Review the sampled outputs from the shipped CLI at `$CLI_DIR`. You have these ground-truth sources:
+>
+> - Sampled command output: read `/tmp/output-review-livecheck.json` and inspect the `live_check.features[]` array. Each entry has the command, example invocation, actual stdout (in `output_sample`, bounded to ~4 KiB), the pass/fail reason, and a `warnings` array (populated by rule-based checks like the raw-HTML-entity detector).
+> - **Review only `status: pass` entries.** Entries with `status: fail` either crashed, timed out, or had placeholder args (`<id>`, `<url>`) that never produced real output — their sample is empty and there's nothing for you to judge. Phase 5 dogfood handles test-coverage and exit-code concerns.
+> - `$CLI_DIR/research.json` `novel_features` (planned behavior per feature) and `novel_features_built` (verified built commands).
+> - The CLI binary at `$CLI_DIR/<cli-name>-pp-cli` — you may invoke additional commands to gather more output when a finding needs verification.
+>
+> For each of these checks, report findings under 50 words each. Only report issues a human user would notice in 5 minutes of hands-on testing — not every edge case a thorough QA pass might find:
+>
+> 1. **Output *semantically* matches query intent.** For sampled novel features with a query argument, judge relevance beyond what the mechanical query-token check in live-check already enforced. A feature that passed live-check's `outputMentionsQuery` test still contains *some* query token somewhere — but "buttermilk" appearing as a substring of "butter" results, or "brownies" returning a chili recipe because the extractor fell back to adjacent content, both slip past the mechanical check. Only flag when a human user would look at the top results and say "this isn't what I asked for." Skip this check when the example has no query argument.
+> 2. **No obvious format bugs.** Does the output contain raw HTML entities, mojibake (question marks or replacement chars in titles), or malformed URLs (pointing at category index pages, feed endpoints, or random-selector routes rather than canonical content permalinks)? Rule-based live-check catches numeric entities; this layer catches the broader class.
+> 3. **Aggregation commands show all requested sources.** For commands with a `--source`/`--site`/`--region` CSV flag: if the user requested N sources, does output show N, or does stderr explain the missing ones? Silent drops of failed sources are a top failure mode for fan-out commands.
+> 4. **Result ordering/ranking makes sense.** For commands that claim to rank or sort, does the top result look plausibly best given the query? Watch for broken score weights, off-by-one sort bugs, and silent fallback to recency when relevance computation fails.
+>
+> Return a list of findings. For each: check name, severity (`warning` in Wave B; `error` reserved for Wave C), one-line description, one-sentence fix suggestion. If the CLI passes all four checks, return "PASS — no findings."
+
+### Step 3: Emit the structured result block
+
+End the skill response with a `---OUTPUT-REVIEW-RESULT---` block the parent parses:
+
+**On clean pass:**
+
+```
+---OUTPUT-REVIEW-RESULT---
+status: PASS
+findings: []
+---END-OUTPUT-REVIEW-RESULT---
+```
+
+**On warnings:**
+
+```
+---OUTPUT-REVIEW-RESULT---
+status: WARN
+findings:
+- check: <check-name>
+  severity: warning
+  description: <one-line>
+  suggestion: <one-sentence>
+- ...
+---END-OUTPUT-REVIEW-RESULT---
+```
+
+**On reviewer failure (timeout, agent-budget exhaustion, missing live-check data):**
+
+```
+---OUTPUT-REVIEW-RESULT---
+status: SKIP
+reason: <one-line description>
+findings: []
+---END-OUTPUT-REVIEW-RESULT---
+```
+
+## Wave B policy (current)
+
+- All findings surface as `warning` — never `error`. Shipcheck proceeds regardless.
+- The caller logs findings to the run's artifact directory (e.g., `manuscripts/<api>/<run>/proofs/phase-4.85-findings.md`) and surfaces them to the user. Findings are not persisted to `scorecard.json` — that path is reserved for Wave C.
+- The user decides case by case whether to fix before shipping.
+
+**Non-interactive contract (CI, cron, batch regeneration):**
+
+- If stdout is not a TTY, callers follow fail-open-with-log: findings recorded, shipcheck proceeds without prompting.
+- `status: SKIP` (reviewer crash, timeout, missing data) is informational — shipcheck does not block on it.
+- No `--auto-approve-warnings` flag yet. The policy is already "warnings don't block" in Wave B, so the flag has no effect to gate.
+
+Wave C (separate future PR) will flip `error`-severity findings to blocking after calibration data across the library shows false-positive rate below 10%.
+
+## Why agentic vs template-only
+
+Output-plausibility questions are not pattern-matchable against source. Rule-based live-check rules cover what regexes can (numeric HTML entities, query-token absence). Everything else — "are these substitution results plausibly correct for the query?", "does the top search result look related?" — is an LLM-shaped question. The token cost is bounded (once per run, not per command) and the catch rate against the bug classes that motivated this phase justifies the dispatch.
+
+## Known blind spots
+
+- Can't verify numeric accuracy (prices, ratings, rankings vs ground-truth). If the CLI says a recipe has 4.8 stars and it actually has 4.2, this skill won't catch it.
+- Can't detect data-freshness issues (recipe published 2019 vs 2024). These need live comparison against authoritative sources.
+- Can't judge subjective preferences ("is this the *best* recipe for chocolate chip cookies?").
+- Sampled outputs only — covers the commands in `live_check.features[]`. Full command-tree coverage belongs in Phase 5 dogfood.
+- Non-English output: the reviewer's query-intent check assumes English-language query/output. For non-English CLIs, calibrate the prompt separately.
diff --git a/skills/printing-press-polish/SKILL.md b/skills/printing-press-polish/SKILL.md
index b4c2abee..f9627980 100644
--- a/skills/printing-press-polish/SKILL.md
+++ b/skills/printing-press-polish/SKILL.md
@@ -157,11 +157,20 @@ Parse findings into categories:
 
 ### Phase 4.85 — Agentic output review (Wave B)
 
-After the mechanical diagnostics above complete, run Phase 4.85 exactly as defined in the main printing-press SKILL.md (under `## Phase 4.85: Agentic Output Review`). The polish pathway uses the same Dispatch / Gate / Known blind spots contract — it's the canonical backfill path for CLIs shipped before Phase 4.85 existed. Record findings alongside the mechanical gates above so Phase 2 fixes address both.
+After the mechanical diagnostics above complete, invoke the `printing-press-output-review` sub-skill via the Skill tool. The sub-skill carries `context: fork` and owns the dispatch prompt, gate logic, and known blind spots — single source of truth shared with the main printing-press skill.
 
-Wave B gating applies: all Phase 4.85 findings are surfaced as warnings, not blockers. Fix if obvious and cheap; document with a short comment in the scorecard JSON if deferred. Non-interactive polish runs (CI, cron) follow the fail-open-with-log contract from Phase 4.85's Gate section.
+```
+Skill(
+  skill: "cli-printing-press:printing-press-output-review",
+  args: "$CLI_DIR"
+)
+```
+
+Parse the returned `---OUTPUT-REVIEW-RESULT---` block. `status: WARN` findings flow into the diagnostic categories above so Phase 2 fixes address both rule-based and plausibility issues. `status: SKIP` is informational — record but don't block.
+
+Wave B gating applies: all findings are warnings, never blockers. Fix if obvious and cheap; document with a short comment if deferred.
 
-Record baseline scores: scorecard total, verify pass rate, dogfood verdict, go vet issue count, Phase 4.85 finding count.
+Record baseline scores: scorecard total, verify pass rate, dogfood verdict, go vet issue count, output-review finding count.
 
 ## Phase 2: Fix
 
diff --git a/skills/printing-press/SKILL.md b/skills/printing-press/SKILL.md
index e2c1f229..18839540 100644
--- a/skills/printing-press/SKILL.md
+++ b/skills/printing-press/SKILL.md
@@ -1960,69 +1960,20 @@ Use the Agent tool or review directly with this prompt contract:
 
 ## Phase 4.85: Agentic Output Review
 
-**Runs after Phase 4.8, before Phase 5.** Phase 4.8 reviews SKILL.md prose against the shipped CLI. Phase 4.85 reviews the CLI's **actual command output** for plausibility — the class of bug rule-based checks can't encode:
+**Runs after Phase 4.8, before Phase 5.** Phase 4.8 reviews SKILL.md prose against the shipped CLI. Phase 4.85 reviews the CLI's **actual command output** for plausibility bugs that rule-based checks can't encode (substring-match relevance failures, format bugs, silent source drops, ranking failures). The dispatch prompt, gate logic, and known blind spots live in the `printing-press-output-review` sub-skill — single source of truth shared with the polish skill (which runs the same review during its diagnostic loop).
 
-- Substring-match results that coincidentally contain the query but don't match semantically (e.g., a query matches a substring of a larger unrelated term)
-- Aggregation commands silently dropping sources when only some of the requested N come back
-- Ranking or sort commands returning top-N results that aren't plausibly the best for the query (broken weights, extractor fallbacks)
-- URLs in output pointing at category index pages, feed endpoints, or random-selector routes rather than canonical content permalinks
-- Format bugs that live-check's rule-based layer doesn't catch (mojibake, inconsistent pluralization, truncated/wrapped cell content)
+Invoke the sub-skill via the Skill tool:
 
-These bugs are typically surfaced by 5 minutes of hands-on testing but slip past existing dogfood, verify, and the rule-based `scorecard --live-check` rules — only a human-in-the-loop pattern-matcher finds them. Phase 4.85 is that loop. A concrete case history that motivated this phase: `docs/retros/2026-04-13-recipe-goat-retro.md`.
-
-**Wave B rollout policy (first 2 weeks):** all findings from this phase are surfaced as **warnings**, not blockers. Shipcheck does not fail on Phase 4.85 findings. The goal of Wave B is to calibrate false-positive rates across domains (transactional APIs like Stripe, document stores like Notion, scraping CLIs like recipe-goat) before Wave C flips errors to blocking.
-
-### Dispatch
-
-Use the Agent tool (general-purpose) with this prompt contract:
-
-> Review the sampled outputs from the shipped CLI at `$CLI_WORK_DIR`. You have these ground-truth sources:
->
-> - Sampled command output: run `printing-press scorecard --dir $CLI_WORK_DIR --live-check --json` and read the `live_check.features[]` array. Each entry has the command, example invocation, actual stdout (in `output_sample`, bounded to ~4 KiB), the pass/fail reason, and a `warnings` array (populated by rule-based checks like the raw-HTML-entity detector).
-> - **Review only `status: pass` entries.** Entries with `status: fail` either crashed, timed out, or had placeholder args (`<id>`, `<url>`) that never produced real output — their sample is empty and there's nothing for you to judge. Phase 5 dogfood handles test-coverage and exit-code concerns.
-> - `$CLI_WORK_DIR/research.json` `novel_features` (planned behavior per feature) and `novel_features_built` (verified built commands).
-> - The CLI binary at `$CLI_WORK_DIR/<cli-name>-pp-cli` — you may invoke additional commands to gather more output when a finding needs verification.
->
-> For each of these checks, report findings under 50 words each. Only report issues a human user would notice in 5 minutes of hands-on testing — not every edge case a thorough QA pass might find:
->
-> 1. **Output *semantically* matches query intent.** For sampled novel features with a query argument, judge relevance beyond what the mechanical query-token check in live-check already enforced. A feature that passed live-check's `outputMentionsQuery` test still contains *some* query token somewhere — but "buttermilk" appearing as a substring of "butter" results, or "brownies" returning a chili recipe because the extractor fell back to adjacent content, both slip past the mechanical check. Only flag when a human user would look at the top results and say "this isn't what I asked for." Skip this check when the example has no query argument.
-> 2. **No obvious format bugs.** Does the output contain raw HTML entities, mojibake (question marks or replacement chars in titles), or malformed URLs (pointing at category index pages, feed endpoints, or random-selector routes rather than canonical content permalinks)? Rule-based live-check catches numeric entities; this layer catches the broader class.
-> 3. **Aggregation commands show all requested sources.** For commands with a `--source`/`--site`/`--region` CSV flag: if the user requested N sources, does output show N, or does stderr explain the missing ones? Silent drops of failed sources are a top failure mode for fan-out commands.
-> 4. **Result ordering/ranking makes sense.** For commands that claim to rank or sort, does the top result look plausibly best given the query? Watch for broken score weights, off-by-one sort bugs, and silent fallback to recency when relevance computation fails.
->
-> Return a list of findings. For each: check name, severity (`warning` in Wave B; `error` reserved for Wave C), one-line description, one-sentence fix suggestion. If the CLI passes all four checks, return "PASS — no findings."
-
-### Gate
-
-Wave B policy (current):
-
-- All findings surface as `warning` — never `error`. Shipcheck proceeds regardless.
-- Findings are returned in the reviewer agent's response to its caller (main skill at shipcheck, the polish skill during polish runs). The caller logs them to the run's artifact directory (e.g., `manuscripts/<api>/<run>/proofs/phase-4.85-findings.md`) and surfaces them to the user for review. Wave B does not persist findings into `scorecard.json` — that path is reserved for Wave C if findings become blocking.
-- The user decides case by case whether to fix before shipping.
-
-**Non-interactive contract (CI, cron, batch regeneration):**
-
-- If stdout is not a TTY, findings default to fail-open-with-log: recorded in the scorecard, shipcheck proceeds without prompting.
-- Reviewer crashes (timeout, agent-budget exhaustion) map to `SKIP` status with detail in the scorecard — shipcheck treats as informational, not blocking.
-- No `--auto-approve-warnings` flag yet. The policy is already "warnings don't block" in Wave B, so the flag has no effect to gate.
-
-Wave C (separate future PR) will flip `error`-severity findings to blocking after calibration data across the library shows false-positive rate below 10%.
-
-### Polish skill invocation
-
-Phase 4.85 also runs during `/printing-press-polish` as the backfill path for CLIs shipped before this phase existed. The polish skill runs verify + dogfood + scorecard inline; Phase 4.85 runs as part of the same diagnostic loop so every polish run re-reviews outputs of older CLIs without a separate campaign.
-
-### Why agentic vs template-only
-
-Output-plausibility questions are not pattern-matchable against source. Rule-based live-check rules cover what regexes can (numeric HTML entities, query-token absence). Everything else — "are these substitution results plausibly correct for the query?", "does the top search result look related?" — is an LLM-shaped question. The token cost is bounded (once per run, not per command) and the catch rate against the bug classes that motivated this phase (see `docs/retros/2026-04-13-recipe-goat-retro.md` for a concrete case) justifies the dispatch.
+```
+Skill(
+  skill: "cli-printing-press:printing-press-output-review",
+  args: "$CLI_WORK_DIR"
+)
+```
 
-### Known blind spots
+The sub-skill carries `context: fork` so the reviewer agent's diagnostic chatter stays isolated from this generation flow. It returns a `---OUTPUT-REVIEW-RESULT---` block with `status: PASS|WARN|SKIP` and a list of findings.
 
-- Can't verify numeric accuracy (prices, ratings, rankings vs ground-truth). If the CLI says a recipe has 4.8 stars and it actually has 4.2, Phase 4.85 won't catch it.
-- Can't detect data-freshness issues (recipe published 2019 vs 2024). These need live comparison against authoritative sources.
-- Can't judge subjective preferences ("is this the *best* recipe for chocolate chip cookies?").
-- Sampled outputs only — covers the commands in `live_check.features[]`. Full command-tree coverage belongs in Phase 5 dogfood.
-- Non-English output: the reviewer's query-intent check assumes English-language query/output. For non-English CLIs, calibrate the prompt separately.
+**Wave B rollout policy:** all findings surface as **warnings**, not blockers. Shipcheck does not fail on Phase 4.85 findings. Log the findings to `manuscripts/<api>/<run>/proofs/phase-4.85-findings.md` and surface them to the user. The user decides case by case whether to fix before shipping. Wave B calibrates false-positive rates before Wave C flips errors to blocking.
 
 ## Phase 5: Dogfood Testing

← e4a0089c feat(cli): add tools-audit subcommand and merge polish into  ·  back to Cli Printing Press  ·  feat(skills): add divergence check to polish skill setup (#3 6727d0d8 →