• MODE=direct

  — the prompt contains a concrete CLI name AND at least one direct-input signal:
  • Action verbs targeting the CLI:

    rename

    ,

    add

    ,

    remove

    ,

    fix

    ,

    sniff

    ,

    discover

  • Explicit URLs the user wants added (e.g.,

    https://example.com/feed/x

    )
  • An enumerated list of feeds, commands, endpoints, or features
  • Phrasing like "these ideas", "these features", "with the following"

• MODE=dogfood

  — the prompt is empty, OR names a CLI without any asks ("amend the superhuman CLI"), OR explicitly references the session ("what I just dogfooded", "this session's friction", "from my session today")

• MODE=both

  — the prompt clearly references both: a session AND specific asks ("I dogfooded this session and also want to add feature X", "in addition to the friction I hit, please add command Y")
• Ambiguous — only one signal is present (CLI named with no verbs, or verbs with no target CLI, or asks worded so they could be friction reports OR new asks). Ask the user via

  AskUserQuestion

  :

  "Two ways to source findings for this amend. Which fits?

  1. Mine the current session transcript (dogfood mode)
  2. Use the asks I just typed (direct-input mode)
  3. Both — combine transcript friction with my asks"

MODE=dogfood

/printing-press-amend

references/transcript-parsing.md

1. Resolve the active session transcript file — derive

   <project-dir-slug>

   from the current working directory, list

   ~/.claude/projects/<slug>/*.jsonl

   by mtime, pick the most-recently-modified. ALWAYS confirm the resolved path with the user via

   AskUserQuestion

   before reading — wrong-file selection ingests friction from the wrong session.
2. Walk the transcript and extract friction signals — non-zero exit codes, error messages, hand-rolled API payloads (e.g. direct

   curl

   POSTs that should be a CLI command), retry-after-failure patterns, agent commentary like "X doesn't exist" / "X returns 400", missing-flag references, silent-null returns, auth confusion. Each signal carries timestamp + category + verbatim evidence + the

   <slug>-pp-cli

   it references.
3. Classify each signal as bug or feature with a one-line rationale. Bug = CLI behavior is wrong; feature = CLI behavior is missing. The classification is the agent's best read; the user confirms or overrides at the U4 scope checkpoint.
4. Auto-detect target CLI — count occurrences of each

   <slug>-pp-cli

   in the signals, propose the most-touched CLI as the default. Confirm with

   AskUserQuestion

   (single CLI: simple yes/no; multiple close: pick from list). When the user passed an explicit

   <cli-name-or-path>

   argument, skip auto-detect.
5. Resolve target paths — accept short name, full name, or absolute path (per R4). Look up the public-library category by walking

   ~/printing-press-library/library/*/

   for a matching directory. The category is needed by U7's PR open phase and is captured here so it doesn't have to be re-derived.

provenance: transcript

references/transcript-parsing.md

references/direct-input-parsing.md

1. Read the slash-command prompt body plus the immediate agent-message turn that fired the skill — these carry the user's verbatim asks (e.g., "rename Digg 1000 to Digg, add these four feeds: ..., sniff for new endpoints"). There is no transcript to confirm; skip the U1 transcript-path modal that 1a runs.
2. Resolve the target CLI — same name-resolution rules as 1a step 4-5 (per R4), but the CLI is normally already named in the prompt itself. Extract via regex (

   <slug>-pp-cli

   or "the <slug> CLI"); if absent, ask the user.
3. Parse the asks into structured findings using the rubric in

   references/direct-input-parsing.md

   . Each ask maps to one finding with a typed

   kind

   field:

   • rename

     — "rename X to Y" / "call it X instead of Y" →

     classification: feature

   • add-command

     — "add command X" / "add subcommand X" →

     classification: feature

   • add-feed

     — "add feed <url>" / enumerated URLs the user wants added (one finding per URL) →

     classification: feature

   • add-endpoint

     — "add endpoint <url>" / explicit API path →

     classification: feature

   • fix-bug

     — "fix X" / "X is broken" / "X returns null" →

     classification: bug

   • sniff

     — "sniff for new APIs" / "find new endpoints" / "discover more" → routes to the sniff subroutine in

     ### 1b.i

4. Each finding records the user's verbatim phrasing in

   evidence

   so the U4 scope confirmation modal shows the user what they actually wrote.
5. Edge cases — multi-CLI asks split into two separate runs (out of scope for v0.2; ask the user to pick one). Ambiguous verbs (

   update X

   without specifics) trigger an

   AskUserQuestion

   clarification rather than a guess.

provenance: user-ask

provenance: sniff

kind: sniff

~/printing-press-library/library/<category>/<slug>/.printing-press.json

source_url

spec_url

"Sniff needs a target URL — paste the source site you want sniffed, or skip the sniff finding for this run?"

<PRINTING_PRESS_BIN>

<PRINTING_PRESS_BIN> crowd-sniff --site "$SOURCE_URL" --json > /tmp/amend-sniff-crowd.json
crowd_exit=$?

crowd-sniff

<PRINTING_PRESS_BIN> browser-sniff --har "$HAR_PATH" --json > /tmp/amend-sniff-browser.json
browser_exit=$?

• id: F<n>

  (next available number after the parsed asks)

• kind: add-endpoint

• classification: feature

• evidence: "discovered via crowd-sniff: <endpoint-path>"

  (or

  browser-sniff

  when applicable)

• target_cli: <slug>-pp-cli

• rationale: <one-line summary from sniff output if available, otherwise "sniff candidate, user to confirm">

• provenance: sniff

.printing-press.json

source_url

crowd-sniff

crowd-sniff

(sniff)

Tier 3 — Polish / architecture (5)
  F8  add-endpoint /v1/feeds/stars (sniff)
  F9  add-endpoint /v1/feeds/new (sniff)
  F10 add-endpoint /v1/feeds/activity (sniff)
  ...

• Tier 1 — Bugs — every finding with

  classification: bug

  . CLI behavior is wrong; fixes restore correctness.
• Tier 2 — Missing features that solve immediate session pain —

  classification: feature

  findings tied to a hand-rolled workaround the user actually built during the session (i.e. the user clearly needed it now, not theoretically).
• Tier 3 — Polish / architecture — remaining

  classification: feature

  findings that are nice-to-have or architectural improvements without an immediate workaround in the session.

Friction found for <slug>-pp-cli (12 signals, 2 suppressed as duplicates):

Tier 1 — Bugs (4)
  F1  drafts list returns 400 silently
  F4  messages query returns data: null
  F7  refresh-token expiry not surfaced in errors
  F11 ai --query returns code 500

Tier 2 — Missing features that solve session pain (4)
  F2  no `drafts new` command (user hand-rolled writeMessage payload)
  F5  no `--type sent` for threads list (user worked around with messages query)
  F8  no `--remind-in <duration>` flag for send (user manually re-flagged drafts)
  F10 no `bootstrap` to local SQLite (user did 50+ thread API calls)

Tier 3 — Polish / architecture (2)
  F12 `auth status` doesn't link to `auth login` when refresh expired
  F13 doctor doesn't surface stale-binary warning vs. published version

"All findings from this session were addressed by existing PRs. No novel patches found."

$PRESS_MANUSCRIPTS/<slug>/<run-id>/proofs/<timestamp>-amend-<cli-name>.md

/tmp/printing-press/amend/

• Frontmatter:

  date

  ,

  target_cli

  ,

  amend_run_id

  ,

  scope_tier

  ,

  findings_count

• One section per active finding: id, category, classification, rationale, target files (

  $CLI_DIR/...

  paths), expected behavior change, test scenarios for this finding
• Risks and dependencies between findings (if any)

1. Edit the target files under

   $CLI_DIR/

   . Honor AGENTS.md anti-reimplementation rules (no hand-rolled response builders; novel commands must call the real endpoint or read from the local store via

   // pp:client-call

   /

   // pp:novel-static-reference

   opt-outs only when truly justified).
2. Add a

   // PATCH(<short reason>)

   source comment at every changed site. Format examples:
   go

   // PATCH(amend-2026-05-15: surface refresh-token expiry to user) — was silently retrying
   func (c *Client) Refresh(ctx context.Context) error {
       ...
   }

3. Update

   $CLI_DIR/.printing-press-patches.json

   . Append an entry under

   patches[]

   :
   json

   {
     "date": "2026-05-15",
     "amend_run_id": "amend-2026-05-15T1432",
     "summary": "fix(superhuman): surface refresh-token expiry; add drafts new + --type sent",
     "files": [
       "internal/auth/refresh.go",
       "internal/cli/drafts.go",
       "internal/cli/threads.go"
     ],
     "findings_addressed": ["F1", "F2", "F5", "F7"],
     "patch_count": <total // PATCH comments added in this run>
   }

   Both halves of the contract —

   // PATCH(...)

   source comments AND

   .printing-press-patches.json

   entries — are MANDATORY. The library's

   verify-library-conventions

   workflow rejects PRs where one is present without the other. See

   ~/printing-press-library/AGENTS.md

   "How to record a hand-edit" for the authoritative spec.
4. Machine-vs-printed-CLI judgment (per AGENTS.md): when a finding's fix would generalize to every printed CLI (e.g. "the generator should emit

   --type sent

   for any threads list command"), surface as a borderline case:

   "Finding F5 (

   --type sent

   missing) looks like a machine-level fix — the generator template

   internal/generator/templates/threads.go.tmpl

   should emit it for every CLI with this endpoint shape, not just

   <slug>-pp-cli

   . Defer to a

   /printing-press-retro

   follow-up, or proceed CLI-specific?"

   When deferred, drop into the deferred-list with classification

   machine-level

   . When kept, add a comment in the patch noting the generalize-eventually intent.

references/pii-scrubbing.md

1. Credentials — reuse the regex patterns from

   skills/printing-press-retro/references/secret-scrubbing.md

   (Stripe, GitHub PATs, bearer tokens, AWS keys, etc.) plus amend-specific additions for

   Authorization

   /

   Cookie

   /

   X-API-Key

   headers in hand-rolled API payloads quoted from the session transcript.
2. Entities — companies, people, emails matched against the user-maintained stop-list at

   ~/.printing-press/amend-config.yaml

   . Replace with shape-preserving tokens (

   <company-1>

   ,

   <person-1>

   ,

   <email-1>

   ) that maintain identity across the artifact set so reviewers can still parse intent.
3. First-mention defense — walk each artifact for capitalized phrases that look like proper nouns and were NOT in the stop-list. Surface to the user inline before the Phase 6 PR-draft display: "Found

   Esper Labs

   (3x in plan doc, 1x in PR body) — add to stop-list and scrub, or accept?"

$CLI_DIR

<path>.pre-pii-scrub

*.go

$CLI_DIR

~/.printing-press/amend-config.yaml

$PRESS_MANUSCRIPTS/<slug>/<run-id>/scrub-report.json

• fix(<api-slug>): <one-line summary>

  when the scope is bugs-only

• feat(<api-slug>): <one-line summary>

  when the scope includes features

• feat(<api-slug>): <one-line summary>

  when mixed (feature wins because it's the bigger contract change)

<one-line summary>

surface refresh-token expiry; add drafts new + --type sent

1. Summary — 1-3 sentences naming the user pain and the shape of the fix
2. Findings — table with ID, category, type (bug/feature), rationale
3. Changes — output of

   git diff --stat upstream/main..HEAD

4. Verification — build/test/dogfood/validate status from Phase 4
5. Evidence — full GitHub URLs to the per-run plan doc and

   .printing-press-patches.json

   at the PR's HEAD SHA (captured AFTER push so links don't 404)
6. Closes #N footer when an issue match was found in Step 6 of

   library-pr-plumbing.md

comp:<api-slug>

priority:P1

priority:P2

priority:P3

git diff --stat

"Reminder: PR body references

<phrase>

(you accepted as legitimate during Phase 5). Confirm before opening."

references/library-pr-plumbing.md

1. Step 5 —

   git add "$CLI_DIR"

   + commit with conventional message + the findings list
2. Step 6 — search for an existing issue matching the findings; link or open new; self-assign best-effort
3. Step 7 — push the branch (push-vs-fork access mode determined in Step 1),

   gh pr create

   with

   --body-file

   , capture HEAD_SHA, apply labels

references/library-pr-plumbing.md

"PR open: <url>

Greptile will review within ~2 minutes. Check inline comments:

gh api repos/mvanhorn/printing-press-library/pulls/<N>/comments

P0/P1 findings are worth addressing before requesting human review."