Inbound Triage
Decide whether planned inbound work is ready for AFK execution at the declared readiness level.
References
Read these first:
references/CONTEXT.mdreferences/docs/growth-operator/afk-readiness.mdreferences/docs/growth-operator/control-plane.mdreferences/docs/paperclip-operator/integration-matrix.md
Open only when needed:
references/docs/paperclip-operator/control-plane.mdreferences/docs/paperclip-operator/cli-contract.md
Process
Read the target issue or issue list.
Inspect:
- status
- project
- parent chain
- linked goals
- plan document
- description
- acceptance criteria
- inbound readiness level
- author/persona
- channel and campaign context
- audience or ICP
- wedge, positioning, story, and claims
- source material and proof
- expected output
- publishing, scheduling, and account-action boundaries
- blockers and
blockedByIssueIds - comments
- assignee
Classify each in-scope issue into exactly one of:
- AFK-ready
- needs-info
- blocked
- needs-human
- too-broad
- revise
- cancel
- done
Done when every issue in scope carries exactly one classification.
Recommend exact changes. Done when each non-AFK-ready issue names the specific missing readiness element.
Ask for approval.
Apply approved changes and verify by reading records back.
Wiki Source Material
When readiness depends on a Paperclip wiki URL, wiki page path, or captured wiki source, use paperclip-wiki-fetch to verify the source is accessible and sufficient before classifying the issue as AFK-ready. Include the fetched title, path, update time, and hash in Source/proof status when available.
If the wiki reference cannot be fetched because credentials, company scope, wiki id, space slug, or page path are missing, classify the issue as needs-info and name the missing wiki access in Missing readiness elements.
If triage discovers stale, missing, or incorrect wiki content, recommend paperclip-wiki-manage as the follow-up skill. Do not mutate wiki content from ordinary triage unless the operator explicitly switches to wiki management and approves the exact mutation.
Readiness Levels
I0 strategy- strategy or branch parent readiness.I1 source-research- research or proof collection.I2 asset-draft- post, newsletter, script, angle, or content asset drafting.I3 publishing-prep- preparing a reviewed asset for publication without posting.I4 signal-capture- summarizing inbound responses, comments, conversations, or content signals.
Readiness Rule
Inbound work is AFK-ready only when the issue gives an agent enough context to act without continuous operator supervision:
- related acquisition company goal or team goal
- durable inbound channel project
- parent strategy or campaign context
- readiness level
- author/persona
- channel
- audience or ICP
- wedge, story, positioning, or hypothesis
- approved source material and proof
- expected output
- acceptance criteria
- validation expectations
- stop conditions
- no unresolved first-class blockers
Inbound work is not ready when publishing, scheduling, external account actions, or ungrounded claims are implied but not explicitly approved.
Recommendation Format
## Inbound Triage Recommendation
### <issue identifier/title>
- Classification:
- Readiness level:
- Current status:
- Recommended status:
- Missing readiness elements:
- Author/channel context:
- Source/proof status:
- Publishing/account-action boundary:
- Proposed comment:
- Proposed blocker links:
- Follow-up skill:
Status Rules
todomeans ready and actionable at the declared inbound readiness level.backlogmeans parked or not startable.blockedrequires first-class blocker links for concrete issue dependencies when supported.- Use
inbound-plan-workfor too-broad inbound strategy or campaign issues. - Use comments to explain triage reasoning.
Mutation Rule
Report recommendations first. Only update status, comments, blockers, labels, or assignees after operator approval.