board-superpowers

Use whenever a board-superpowers molecular SKILL is about to invoke a sibling plugin SKILL from `gstack:*` or `superpowers:*` namespaces. Callers: all four Producer routines (`briefing-daily`, `intaking-requirement`, `reviewing-pr-queue`, `triaging-board`), `consuming-card`, and `decomposing-into-milestones`. Apply at every cross-plugin handoff point — this skill is the single source of truth for namespace prefix rules and Mode-2 max_depth=1 compatibility decisions. Do NOT use for: (a) board-superpowers internal SKILL calls (governed by `SKILLS.md` topology); (b) user-facing direct invocations of sibling skills (route directly per `using-board-superpowers/references/routing.md`).

Use whenever any board operation in board-superpowers needs the canonical contract — the 6-state machine, the Card body schema, the branch-naming convention (claim/<kanban-id>-<key-slug>-<title-slug>), or the WIP counting formula. This is the read-only source of truth that every other board-superpowers skill consults before transitioning a card, validating a claim, or checking WIP. Use it even when the user doesn't say "schema" or "state machine" — any time card, branch, Status, or WIP comes up, this is what defines the rules.

Use when board-superpowers needs to run setup stages — first session, plugin upgrade with new stages, interrupted session resume, or explicit architect request. Triggers automatically when SessionStart hook emits `INVOKE: bootstrapping-repo`. Also triggers on: "set up board-superpowers", "bootstrap this repo", "first time on this repo", "configure the plugin", "run setup stages". Apply whenever plugin setup or reconfiguration is wanted, even without the word "bootstrap". Do NOT use once all stages are applied with no upgrade pending.

Use when a board-superpowers SKILL is about to perform a mutating action — changing card status, editing card body, pushing a claim branch, opening or merging a PR, writing project config, writing host-local credentials, deleting a worktree, deleting a branch — and needs to know whether the action proceeds automatically or waits for architect approval. Apply at every mutating-action decision point inside any board-superpowers skill (briefing-daily / intaking-requirement / reviewing-pr-queue / triaging-board / consuming-card / bootstrapping-repo). Apply even when the action looks obviously safe; the decision table is the source of truth, not intuition. Do NOT use for read-only actions or for queries that surface information without changing state. Do NOT invoke for the audit-row write step that follows the decision — that is `board-superpowers:auditing-actions`.

Use when the user has a design artifact (brainstorming output, eng-review notes, requirements doc, intake batch) and asks for cards / milestones / a slice plan, OR when the intake routine triggers a handoff. Typical phrasings include "decompose this feature", "split into cards", "break this into milestones", "拆解这个 feature", "拆成卡", "拆里程碑", "intake 后落卡", "decompose the eng-review output". Apply this skill even when the user does NOT say "decompose" — any message that brings a multi-card-shaped requirement routes here. Do NOT use this skill for single-card edits, refactors with no new capability, or already-decomposed batches that just need creation — use `intaking-requirement` for those.

Use whenever a PR is being authored from a board-superpowers card claim, OR a PR is being reviewed against the board's contract. Enforces the three-part PR contract — Contract A (PR body sections: Automated Verification + Human Verification TODO + Retro Notes), Contract B (linked card body acceptance criteria all in terminal state), Contract C (PR body contains `Closes|Fixes|Resolves #<N>` auto-close keyword at PR-OPEN time) — and rejects filler. Apply on the Consumer side at PR submission AND on the Producer side during review-queue triage. Apply even when the user doesn't explicitly mention "PR contract" — any time a PR body is being drafted, edited, or reviewed in this plugin's loop, this skill governs.

Use when an agent needs to perform any of the eight Kanban Protocol actions on the active backend — read_board, read_card, create_card, transition_card, claim_card, release_claim, link_pr_to_card, comment_on_card (OPTIONAL). Routes through the active projection's reference file (Form A bash CLI / Form B plugin-shipped MCP server / Form C REST/GraphQL) per the kanban entry recorded in this repo's settings. Also owns the bootstrap-side setup-capability registry that bootstrap stage predicates consume. Use even when the molecular skill body just says "read the board" or "transition card N to In Review" — that is a protocol action and dispatch goes through this skill. Do NOT use this skill for backend-agnostic schema questions ("what states does a card have", "what is the canonical Card body shape", "how is WIP counted") — that is the board-canon skill.

Use as the FIRST skill in any board-superpowers session AND as the plugin's manual page. Read this skill (body + references/) for a complete, self-contained orientation — what the plugin is, the 14-skill catalog, the 6-state Card lifecycle, on-disk state, and dispatch routing. Routes ambiguous sessions into the correct Producer routine (briefing-daily / intaking-requirement / reviewing-pr-queue / triaging-board) or Consumer mode (consuming-card, for claiming card N). Skip when the message clearly matches a downstream skill directly (e.g., "[board-card:#12]" → consuming-card).

Use when the user wants to claim, work on, or implement a specific card from the board-superpowers GitHub Project. Triggers immediately on any message containing the literal token [board-card:#N] OR phrases like "claim card 12", "work on card 47", "implement

Use when the user wants a morning briefing, asks "what should I work on", wants to see the current board state, or needs to orient at the start of a session. Triggers on: "morning briefing", "what should I work on", "today's plan", "board overview", "what's running", "what's in progress", "board state", "show me the board", "daily briefing". Use even when the user phrases it casually ("what's up on the board", "catch me up") — the orientation signal is what matters, not formality. Do NOT use when the user wants to bring in a new requirement (that's intaking-requirement), review open PRs (that's reviewing-pr-queue), or investigate blocked cards (that's triaging-board).

Use when the user brings a new requirement, idea, feature, bug, defect, or request that needs to be evaluated and potentially turned into a card on the board. Triggers on: "new requirement", "intake this idea", "I have a feature", "add a card", "new card", "I want to build", "I have an idea", "I have a bug", "I have a defect", "found an issue", "create a card for", "put this on the board", "let's intake". Use even when the user phrases it casually ("I've been thinking about X", "can we add Y", "we should fix the broken Z") — the signal of bringing new work is what matters. Do NOT use when the user wants to see current board state (that's briefing-daily), review open PRs (reviewing-pr-queue), investigate blocked cards (triaging-board), or decompose an already-decided multi-card requirement into INVEST-shaped cards (that's decomposing-into-milestones directly).

Use when the user wants to review open pull requests, check what's in the review queue, or validate PRs against the board contract. Triggers on: "review the PRs", "what's in In Review", "merge ready", "check the review queue", "PR queue", "validate PRs", "review queue", "what PRs need attention", "what needs reviewing". Use even when the user phrases it casually ("let's look at open PRs", "anything waiting to merge?") — the signal of wanting to review or triage open PRs is what matters. Do NOT use when the user wants to see overall board state (that's briefing-daily), bring in new work (intaking-requirement), or investigate blocked cards (triaging-board).

Use when the user wants to investigate blocked cards, release stale claim branches, or triage the board for stuck or abandoned work. Triggers on: "what's blocked", "triage the board", "release stale claims", "check blockers", "stale claims", "blocked cards", "who's stuck", "abandoned work", "ghost claims". Use even when the user phrases it casually ("anything stuck?", "any ghost branches?") — the signal of wanting to investigate stuck or stale work is what matters. Do NOT use when the user wants to see overall board state (that's briefing-daily), bring in new work (intaking-requirement), or review open PRs for contract compliance (reviewing-pr-queue).

Use right after `board-superpowers:classifying-actions` returns a decision, every time a board-superpowers skill is recording what it is about to do or what it just did. For actions that proceed automatically, apply once after the action lands. For actions that wait for architect approval, apply once when first proposing the action and again after the architect approves or declines. Apply even when the action seems too small to log — every mutating action gets a row, no exceptions. Do NOT use for read-only actions; reads are not audited. Do NOT invoke to determine the A/R/N decision — that is `board-superpowers:classifying-actions`.

Use before creating, reading, or transitioning a board card — defines the canonical schema, state machine, branching, and concurrency rules for board-superpowers. Both Board Manager and Board Consumer skills invoke this to confirm they're obeying the protocol. Triggers include "card schema", "card status", "state transition", "claim branch", "WIP limit", or any ambiguity about what belongs on a card.

Use when this session is dispatched to implement one specific board card OR when the user asks to pull a card from the board without naming one — one session = one card = one PR. Triggers include the first user message containing `[board-card:#N]`, "claim card N", "work on card N", "pick up

Use when the architect (or Board Manager) brings a design doc, spec, or multi-point requirement that needs to be turned into GitHub Project cards. Triggers include "decompose this", "turn this into cards", "break this down into milestones", "what cards do we need for this feature". Produces cards sized so one Consumer session delivers one as one PR; enforces INVEST and vertical slicing.

Use when the architect is planning, dispatching, or reviewing the board — not when they're implementing a card. Triggers include "what should I work on today", "plan today", "review the board", "what PRs need me", "I have a new requirement", "decompose this", "triage card

Use when a session first touches the board-superpowers plugin — for preflight dependency check, role disambiguation (Board Manager vs Board Consumer), or one-time project bootstrap. Triggers include "board", "kanban", "project board", "today's work", "decompose this requirement", "claim card", "review the board", or any first message containing `[board-card:#N]`.