# Skill Intake

Move incoming issues and pull requests through triage states until each is actionable...

- Repository: https://github.com/nyldn/claude-octopus (4351 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add nyldn/claude-octopus --skill skill-intake -g -a claude-code -y`
Codex: `npx skills add nyldn/claude-octopus --skill skill-intake -g -a codex -y`
Cursor: `npx skills add nyldn/claude-octopus --skill skill-intake -g -a cursor -y`
Gemini CLI: `npx skills add nyldn/claude-octopus --skill skill-intake -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add nyldn/claude-octopus`

## Description

Move incoming issues and pull requests through triage states until each is actionable or closed, use when the queue has piled up or a report arrives unsorted

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Intake

Work the incoming queue. Each item moves through a small set of states until it
is either actionable by someone who did not write it, or closed with a reason.

**A pull request is an issue with attached code.** Same states, same moves, with
the deltas noted below. Resolving a bare `#42` means checking both.

Adapted from `triage` in
[mattpocock/skills](https://github.com/mattpocock/skills) (MIT), cut down to the
states this repo can actually represent and retargeted at `gh` and `bd`.

## When To Use

- Open issues or PRs have accumulated and nobody knows which are real.
- A new report arrives and needs sorting before anyone works it.
- An issue has been sitting because it is not clear what it is asking for.
- Before planning, to establish what is actually in the queue.

## When Not To Use

- To do the work an item describes. Triage decides what happens to it, not how.
- For local, private notes. That is `skill-issues` and `.octo/ISSUES.md`.
- To review a PR's code quality. That is `skill-code-review` or
  `skill-staged-review`; intake decides whether the PR should be reviewed at all.

## Inputs

An issue or PR reference, or nothing, with nothing, take the queue in order.
`gh issue list` and `gh pr list` for the public surface; `bd ready` and
`bd blocked` for tracked work.

## Workflow

### 1. Categorise

What kind of thing is it: a bug, an enhancement, a question, or noise. For a PR,
also: does it correspond to an existing issue, or arrive unannounced?

Do not skip this because the title looks obvious. Titles are written by people
who already know what they meant.

### 2. Verify

The step that earns the whole skill. For a bug: **reproduce it, or establish that
you cannot.** For a PR: check the claim it makes is the change it contains.

An unverified bug report is a hypothesis. Filing it as fact wastes whoever picks
it up. If reproduction needs something you do not have, credentials, a dataset,
a platform, that is `needs-info`, not `verified`.

The rest: https://github.com/nyldn/claude-octopus/blob/HEAD/.claude/skills/skill-intake/SKILL.md