focus-receipt-proof-gate

name	focus-receipt-proof-gate
description	Audit whether a "current product focus receipt" (Decision/Now/Why-now/Evidence/Not-now/Cut-suspend/First-visible-proof/ Acceptance-gate/Kill-revisit-trigger/Owner/Review-date) and the work order it gates state a real, testable decision and a real agent launch — not planning-placeholder prose that sounds like an assignment but can't be proven. Use when deciding whether to launch an agent chain against a milestone or a stated "focus," when a work order lacks explicit input/output/owner/proof-gate, or when an acceptance gate would only prove a cached UI state instead of daemon truth. NOT for distinguishing roadmap items from energy-driven sidequests (legible-roadmap-with-sidequests), reviewing a PRD/prototype for product-completeness gaps like cold start or pricing (product-reality-reviewer), or accepting already-finished work against a personal acceptance bar (port-daddy-user-surrogate-pm-review).
license	Apache-2.0
allowed-tools	Read,Write,Edit,Bash,Grep,Glob
metadata	{"category":"Agent & Orchestration","tags":["focus-receipt","proof-gate","milestone-discipline","agent-launch-board","work-order"],"provenance":{"kind":"first-party","owners":["port-daddy"]},"pairs-with":[{"skill":"next-move","reason":"next-move predicts and decomposes the next action; this skill audits whether that prediction was packaged as a real, testable focus receipt before agents launch against it."},{"skill":"legible-roadmap-with-sidequests","reason":"A passing focus receipt is the unit that should get linked into the canonical roadmap or logged as a sidequest — this skill only audits the receipt itself, not roadmap legibility."},{"skill":"agentic-coding-product-research","reason":"Research findings are exactly the kind of Evidence a real focus receipt cites; this skill checks the receipt states that evidence, not that the underlying research is sound."}],"io-contract":{"kind":"deliverable","consumes":["[Truncated]","[Truncated]"],"produces":["[Truncated]","[Truncated]"]}}

Focus Receipt & Proof Gate

Decide whether a stated "focus" is a real, testable decision with a real agent launch behind it — or a planning placeholder dressed up as one.

Use This For

• Auditing a milestone's "current product focus receipt" before agents are launched against it.
• Checking a work order states real input, output, owner, and proof gate before calling it an agent launch.
• Catching an acceptance gate that would only prove a cached UI state instead of daemon/event truth after a restart.
• Verifying a focus receipt names an exit condition (Kill/Revisit Trigger) as explicitly as it names its entry condition (First Visible Proof).
• Gatekeeping the transition from binder prose to agent work order at any milestone boundary.

Do Not Use This For

• Deciding whether the wider roadmap should treat an item as planned work or an energy-driven sidequest (legible-roadmap-with-sidequests).
• Reviewing a PRD, prototype, or vibe-coded concept for missing product fundamentals like cold start or pricing (product-reality-reviewer).
• Accepting or blocking already-finished work against a personal acceptance bar (port-daddy-user-surrogate-pm-review).

Decision Model

flowchart TD
  A[Draft Decision / Now / Why-now / Evidence] --> B{Names First Visible Proof AND Kill/Revisit Trigger?}
  B -->|No| X[Reject: planning placeholder]
  B -->|Yes| C{Acceptance gate testable against daemon truth?}
  C -->|No, proves only cached UI state| X
  C -->|Yes| D[Draft work order: input / output / owner / proof gate]
  D --> E{All four stated?}
  E -->|No| X
  E -->|Yes| F[Launch the agent against the work order]
  F --> G[Re-check the proof gate from daemon truth after the work lands]

1. Write the Decision/Now/Why-now/Evidence quartet before naming any agent. now is the narrow slice, not the whole milestone; whyNow must beat every other candidate; evidence is an observed fact, not an assertion — see references/focus-receipt-schema.md for the full field-by-field contract from the binder's build-prescription chapter.
2. Name the First Visible Proof. The exact observable artifact — a screen, a saved event, a passing probe — that proves the decision produced something real, not a vibe.
3. Name the Kill/Revisit Trigger. The exact condition under which the decision pauses and gets re-litigated. A receipt with an entry condition and no exit condition is half a decision.
4. Write the acceptance gate as a claim rebuildable from daemon/event truth, per the binder's own rule that a proof "must survive relaunch from daemon truth, not from a cached UI model." Mark only when that is actually possible — see .