メニュー
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
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/hashgraph-online/awesome-codex-plugins --skill skill-intakeコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Coordinate agents via the AMQ CLI for file-based inter-agent messaging. Use this skill whenever you need to send messages to another agent (codex, claude, or any named handle), check your inbox, drain queued messages, set up co-op mode between agents, join a swarm team, route messages across projects, or diagnose delivery issues. Also use it when you receive a message and need to know how to reply, inspect receipts, or handle priority. Covers any multi-agent coordination task where agents need to talk to each other — review requests, questions, status updates, decision threads, wake notifications, and orchestrator integration (Symphony, Kanban). For collaborative spec/design workflows specifically, prefer the /amq-spec skill which provides structured phase-by-phase guidance. Not intended for distributed systems design (RabbitMQ, Kafka), CI/CD pipelines, or single-agent tasks with no partner.
Parallel-research-then-converge design workflow between two agents. Use this skill when the user wants two agents to independently think through a design problem before aligning on a solution — "spec X with codex", "design X together", "both agents think through X", "brainstorm architecture together", "parallel research then joint proposal", "think through separately then align", "careful thought from both sides before coding", or any variation where the user wants collaborative design rather than just splitting implementation work. Also use this when you receive a message labeled workflow:spec and need to know the correct receiver-side protocol. Not for sending simple messages or reviews (use /amq-cli), implementing completed designs, or creating document templates.
Use when defining new features, product behavior, UI/component design, architecture choices, contract changes, or ambiguous medium/high-complexity work before implementation, or when the user asks to grill or pressure-test a plan or design.
SKILL.md を表示中
SOC 職業分類に基づく
| name | skill-intake |
| 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 |
Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than
/octo:*slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, seeskills/blocks/codex-host-adapter.md.
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 (MIT), cut down to the
states this repo can actually represent and retargeted at gh and bd.
skill-issues and .octo/ISSUES.md.skill-code-review or
skill-staged-review; intake decides whether the PR should be reviewed at all.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.
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.
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.
needs-triage — arrived, not yet sorted. The entry state.needs-info — blocked on the reporter. Say exactly what is missing; "more
detail" is not a request anyone can act on.verified — reproduced or confirmed, ready to be worked.needs-decision — real, but what to do is a judgement call the maintainer
has not made. Do not resolve these by inference. Escalate, or run
skill-pressure-test with the maintainer.closed — not a bug, out of scope, duplicate, or fixed. Always with a
reason, and for out-of-scope, why.For anything reaching verified, write what someone picking it up needs and
would otherwise have to rediscover: where the relevant code is, what you already
ruled out, and how to tell when it is fixed. This is the difference between an
item that gets worked and one that gets re-triaged.
For a PR, add: whether it has tests, whether CI is green, and whether it conflicts with anything in flight.
gh issue comment / gh issue edit --add-label for the public surface. bd update for tracked work. If bd writes are blocked by pending migrations, say
so and do not run the migration — see skill-work-slicing for that constraint.
needs-decision items and surface them rather than guessing.Per item:
Then a queue summary: counts by state, and which items are now takeable.
verified item was actually reproduced, or says explicitly that it was
not and why.needs-info names the specific missing thing.