# Intake Triage

> Plane intake inbox — triage incoming requests, bug reports, and ideas before they enter the backlog. Use when the user wants to review the intake queue, accept or reject incoming items, convert intake items into work items, or set up a triage process. Covers daily/weekly triage rituals and routing rules.

- Skill: `agents-store/intake-triage` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add agents-store/intake-triage`
- Raw SKILL.md: https://api.skillmd.com/api/skills/agents-store/intake-triage/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: agents-store (https://skillmd.com/u/agents-store)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/agents-store/intake-triage

---


# Intake Triage

The intake inbox is where unvetted requests, bug reports, and ideas land before being turned into proper work items. A disciplined triage prevents the backlog from becoming a dumping ground.

## Tool Name Resolution

Resolve real tool names via the `connector-bootstrap` skill.

## Available Actions

| Action | Purpose |
|--------|---------|
| `list_intake_work_items` | List all items waiting for triage |
| `retrieve_intake_work_item` | Get a single intake item |
| `create_intake_work_item` | Create an intake item (usually by integration — see caveat below) |
| `update_intake_work_item` | Edit intake item (status, notes) |
| `delete_intake_work_item` | Reject and remove an intake item |

## Creating Intake Items — Schema Caveat

`create_intake_work_item` on most Plane deployments expects a **single `data` object wrapping all work item fields**, not flat top-level parameters:

```
create_intake_work_item({
  project_id,
  data: {
    name: "User reports: ...",
    description_html: "<p>…</p>",
    priority: "medium"
  }
})
```

Passing `name`, `description_html`, `priority` as top-level arguments will be rejected as "unexpected keyword arguments". Note that some MCP bridges also have trouble serializing the nested `data` dict — if the call fails with "Input should be a valid dictionary", check the bridge's list/dict parameter handling.

## Triage Workflow

### Step 1 — Review the Queue

```
1. connector-bootstrap → resolve tools
2. list_projects       → pick project_id
3. list_intake_work_items({ project_id })
4. Sort by age (oldest first) and source
```

### Step 2 — Classify Each Item

For each intake item, make one of four decisions:

| Decision | Action | Rationale |
|----------|--------|-----------|
| **Accept** | Convert to work item, add to backlog | Valid work aligned with product goals |
| **Accept + escalate** | Convert to work item, prioritize `urgent`/`high`, assign lead | Critical bug or time-sensitive request |
| **Defer** | Update intake status to "deferred" with rationale | Valid but not now; revisit in N weeks |
| **Reject** | Delete intake item with comment | Duplicate, out of scope, or invalid |

### Step 3 — Convert to Work Item

When accepting, resolve required IDs and create the item (see `work-items` skill):

```
create_work_item({
  project_id,
  name,
  description_html,     // include source link and original reporter
  priority,
  state_id,             // usually backlog state
  label_ids             // e.g. "bug", "feature-request"
})
```

Then remove or mark the intake item as processed per the tool schema.

### Step 4 — Communicate

Always tell the reporter what happened:
- Accepted → link to the new work item
- Deferred → explain when it will be reconsidered
- Rejected → explain why

## Routing Rules

Define routing rules up front so triage is fast:

| Signal | Route to |
|--------|----------|
| "Crashes", "data loss", "can't log in" | Bug → urgent, assign on-call |
| "Would be nice", "suggestion" | Feature request → label and defer until next grooming |
| Duplicate keywords match existing item | Reject → link to existing item |
| Missing reproduction steps (bug) | Request info via comment, keep in intake |
| Single customer with low impact | Defer with rationale |
| Multiple customers report same issue | Escalate |

## Triage Cadence

- **Daily** — check intake for urgent items (5 min)
- **Weekly** — full triage session (30–60 min, joint with PM)
- **Backlog grooming** — re-review deferred items

## Triage Session Output

A triage session should produce:

```
| # | Item | Decision | Target | Notes |
|---|------|----------|--------|-------|
| 1 | "Login 500" | Accept+escalate | PROJ-148 | Assigned to @alice |
| 2 | "Dark mode"  | Defer          | 2 sprints | Low signal |
| 3 | "Same bug"   | Reject         | —       | Duplicate of PROJ-142 |
```

## Best Practices

1. Triage every intake item within 48 hours, even if the decision is "defer".
2. Never let the intake queue grow past 20 items — increase cadence if it does.
3. Always link the original intake source (Slack, email, form) in the resulting work item description.
4. Reject duplicates fast but always link the existing work item so reporters feel heard.
5. Track triage decisions in a weekly report — it reveals product signal patterns.