← back to Cli Printing Press

fix(skills): drop context: fork from polish so AskUserQuestion works natively (#410)

0683ef1f2790672f969f946c6fe34fcf2a85b3bd · 2026-04-29 21:28:17 -0700 · Trevin Chow

Polish ran in a forked context so its diagnostic and fix-loop noise
wouldn't pollute the caller. The cost was deferred-tool unreliability:
AskUserQuestion is a deferred tool whose schema is invisible to the
fork's starting tool list, and the agent at every prompt site
inconsistently scanned-the-list-then-fallback-to-plain-text instead
of running ToolSearch first. The plain-text fallback strands the
user — their reply lands in the parent session, never reaches the
fork, and the workflow stalls.

Two prose-only fixes (#399, then a louder #408 which superseded it)
both shipped, and the second still failed on the next CLI tested.
The architectural call is to take the noise pollution and gain
reliable user prompting. Polish runs in the parent context now;
AskUserQuestion is available natively at every prompt site.

While here: drop the redundant allowed-tools list (the parent
context inherits its tool set), remove the now-stale "runs in a
forked context" prose paragraph, and update docs/SKILLS.md so the
context: fork example no longer cites polish (the doc now flags
"skills with interactive question sites should usually NOT fork"
as the lesson).

Supersedes #408.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Files touched

• M docs/SKILLS.md
• M skills/printing-press-polish/SKILL.md

Diff

commit 0683ef1f2790672f969f946c6fe34fcf2a85b3bd
Author: Trevin Chow <trevin@trevinchow.com>
Date:   Wed Apr 29 21:28:17 2026 -0700

    fix(skills): drop context: fork from polish so AskUserQuestion works natively (#410)
    
    Polish ran in a forked context so its diagnostic and fix-loop noise
    wouldn't pollute the caller. The cost was deferred-tool unreliability:
    AskUserQuestion is a deferred tool whose schema is invisible to the
    fork's starting tool list, and the agent at every prompt site
    inconsistently scanned-the-list-then-fallback-to-plain-text instead
    of running ToolSearch first. The plain-text fallback strands the
    user — their reply lands in the parent session, never reaches the
    fork, and the workflow stalls.
    
    Two prose-only fixes (#399, then a louder #408 which superseded it)
    both shipped, and the second still failed on the next CLI tested.
    The architectural call is to take the noise pollution and gain
    reliable user prompting. Polish runs in the parent context now;
    AskUserQuestion is available natively at every prompt site.
    
    While here: drop the redundant allowed-tools list (the parent
    context inherits its tool set), remove the now-stale "runs in a
    forked context" prose paragraph, and update docs/SKILLS.md so the
    context: fork example no longer cites polish (the doc now flags
    "skills with interactive question sites should usually NOT fork"
    as the lesson).
    
    Supersedes #408.
    
    Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---
 docs/SKILLS.md                        |  2 +-
 skills/printing-press-polish/SKILL.md | 13 +------------
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/docs/SKILLS.md b/docs/SKILLS.md
index 0f8cecc1..7ffdba6c 100644
--- a/docs/SKILLS.md
+++ b/docs/SKILLS.md
@@ -39,7 +39,7 @@ Default: skills run in the caller's context. The skill sees the full parent conv
 - **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.
+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-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. Skills with interactive question sites (AskUserQuestion calls in the middle of the workflow) should usually NOT fork: deferred-tool reliability is weaker in forked contexts and a missed prompt loop stalls the whole run. Polish hit this and ran in the parent instead.
 
 ### `user-invocable`
 
diff --git a/skills/printing-press-polish/SKILL.md b/skills/printing-press-polish/SKILL.md
index 54b2b351..832246c6 100644
--- a/skills/printing-press-polish/SKILL.md
+++ b/skills/printing-press-polish/SKILL.md
@@ -8,22 +8,13 @@ description: >
   /printing-press run, or on any CLI in ~/printing-press/library/. Trigger
   phrases: "polish", "improve the CLI", "fix verify", "make it publish-ready",
   "clean up the CLI", "get this ready to ship".
-context: fork
-allowed-tools:
-  - Bash
-  - Read
-  - Glob
-  - Grep
-  - Write
-  - Edit
-  - AskUserQuestion
 ---
 
 # /printing-press-polish
 
 Polish a generated CLI so it passes verification and is ready to publish.
 
-The retro improves the Printing Press. Polish improves the generated CLI. This skill runs in a forked context (`context: fork`) so its diagnostic and fix loop doesn't pollute the caller — the diagnostic spam, fix iterations, and re-diagnose noise stay scoped to the polish session, and the caller receives a clean summary.
+The retro improves the Printing Press. Polish improves the generated CLI.
 
 ```bash
 /printing-press-polish redfin
@@ -48,8 +39,6 @@ PRESS_HOME="$HOME/printing-press"
 PRESS_LIBRARY="$PRESS_HOME/library"
 ```
 
-**`AskUserQuestion` is a deferred tool.** Before the first use in this session, load its schema with `ToolSearch select:AskUserQuestion`. Without that load step the tool's schema isn't visible in the tool list and it appears unavailable — do not fall back to plain-text "reply 1 or 2" prompts when running in a forked context. Plain-text replies land in the parent session, never reach this fork, and the workflow stalls. Load AskUserQuestion eagerly during Setup so every later prompt site (resolve CLI, divergence check, publish offer) just works.
-
 ### Public-library hint
 
 If the user's request includes phrasing like "polish notion **in the

← fe1e6d77 fix(cli): dogfood agent-context discovery reads stdout only  ·  back to Cli Printing Press  ·  fix(cli): OpenAPI parser prefers description over summary on cb91024d →