mcpField
I
inbound-triage

inbound-triage

github.com/bbengaminMarketing & growth344 installsUpdated 11w ago
Repository

About inbound-triage

A Paperclip skill for assessing whether planned inbound work is ready for AFK execution at its stated readiness level. It classifies issues, identifies missing readiness details, and applies changes only after approval.

Key features

  1. 01Inspects issue context and readiness details
  2. 02Classifies each issue with one outcome
  3. 03Identifies specific readiness gaps
  4. 04Verifies approved updates

Use cases

  1. 01Checking whether content research can run AFK
  2. 02Finding missing context before drafting a post
  3. 03Reviewing publishing-prep work for blockers

MCP support

The skill uses the CLI-first integration matrix and checks wiki sources with paperclip-wiki-fetch when readiness depends on them.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/bbengamin/skills --skill inbound-triage

After installing, type/inbound-triagein Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
CONTEXT.md
references/docs/growth-operator/
afk-readiness.md
control-plane.md
references/docs/paperclip-operator/
cli-contract.md
control-plane.md
integration-matrix.md

Details

From the project README

Inbound Triage

Decide whether planned inbound work is ready for AFK execution at the declared readiness level.

References

Read these first:

  • references/CONTEXT.md
  • references/docs/growth-operator/afk-readiness.md
  • references/docs/growth-operator/control-plane.md
  • references/docs/paperclip-operator/integration-matrix.md

Open only when needed:

  • references/docs/paperclip-operator/control-plane.md
  • references/docs/paperclip-operator/cli-contract.md

Process

  1. Read the target issue or issue list.

  2. 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
  3. 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.

  4. Recommend exact changes. Done when each non-AFK-ready issue names the specific missing readiness element.

  5. Ask for approval.

  6. 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

  • todo means ready and actionable at the declared inbound readiness level.
  • backlog means parked or not startable.
  • blocked requires first-class blocker links for concrete issue dependencies when supported.
  • Use inbound-plan-work for 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.

Comments

Markdown supported