operating-kanban

Estrellas2

Forks0

Actualizado3 de mayo de 2026 a las 11:53

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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Fuente

PanQiWei

PanQiWei/board-superpowers

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Especialistas en gestión de proyectosOperaciones empresariales y financieras·SOC 13-1082

Explorador de archivos

10 archivos

SKILL.md

readonly

Más de este repositorio

mismo repositorio

composing-siblings

PanQiWei/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`).

2026-05-032

board-canon

PanQiWei/board-superpowers

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.

2026-05-032

bootstrapping-repo

PanQiWei/board-superpowers

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.

2026-05-032

classifying-actions

PanQiWei/board-superpowers

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

2026-05-032

decomposing-into-milestones

PanQiWei/board-superpowers

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.

2026-05-032

enforcing-pr-contract

PanQiWei/board-superpowers

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.

2026-05-032

name	operating-kanban
description	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.
when_to_use	Use whenever a board-touching skill body invokes a Kanban Protocol action against the live backend, OR a bootstrap stage predicate evaluator needs to know whether the active projection declares a given setup capability.
user-invocable	false

operating-kanban

Use this skill when you need to do one of the eight Kanban Protocol actions — read_board / read_card / create_card / transition_card / claim_card / release_claim / link_pr_to_card / comment_on_card — on the active backend. Caller passes the action name + payload + (optional) kanban_id. Caller receives back the action's typed result or a typed failure.

This skill is also the bootstrap-side dispatcher that answers "does the active projection declare capability X?" so a bootstrap stage predicate can decide to run or skip.

Reflexive constraint

This skill is atomic: it MUST NOT call any other same-plugin skill. Externally it invokes the active projection (a bash command, an MCP tool, or an HTTP endpoint), but it never reaches back into briefing-daily / intaking-requirement / reviewing-pr-queue / triaging-board / consuming-card / decomposing-into-milestones / bootstrapping-repo / board-canon / classifying-actions / auditing-actions. The molecular caller orchestrates; this skill dispatches.

How to apply this skill

You arrive here with an action name plus a payload. Run these four steps in order.

Resolve the active projection. Read <repo>/.board-superpowers/settings.yml § modules.m10_kanban to find the active kanban entry's projection field. Full procedure (including multi-kanban disambiguation, legacy fallback, and every refusal message) is in references/backend-selection.md. Output: a path to references/<projection-id>.md.
Pick the action's procedure. Look up the action name in the per-action quick reference below. The row tells you what to pass, what you get back, the action's compliance level, idempotency, and failure tier. For the full per-action breakdown — what Form A / Form B / Form C invocation look like and the audit hand-off sequencing — read references/action-dispatch.md.
Invoke per the loaded reference. Open the projection reference (e.g., references/github-project-v2.md for the GitHub Project v2 backend) and run that file's per-action procedure. Form A invocation conventions (exit-code mapping, helper preference, worktree-relative paths) are in references/form-a-bash.md; Form B and Form C have analogous files.
On failure, route per references/failure-mode-dispatch.md. Match the underlying signal (Form A exit code, Form B MCP error, Form C HTTP status) to the typed failure mode, take the tier action (silent retry / log-only / audit-row / surface-immediately), and surface to the caller. Do NOT retry unconditionally — the failure-mode table tells you which modes are retryable and at what budget.

Per-action quick reference

You arrive at the right entry below by matching your action name. Each row tells you what to pass, what you get back, idempotency, the compliance level a projection must advertise to support it, and the failure tier of a typical refusal.

Action	What you pass	What you get back	Idempotent?	Compliance
`read_board`	`(kanban_id?)`	List of card records `(key, title, status, labels, url)`	Yes (read)	L0
`read_card`	`(kanban_id, card_key)`	Full card record `(key, title, body, status, labels, url, timestamps, display_*)`	Yes (read)	L0
`create_card`	`(kanban_id, title, body, labels)` — backend assigns `Card.key`, status starts at `Backlog`	New `Card.key` (opaque string)	No — re-running creates duplicates	L1
`transition_card`	`(kanban_id, card_key, target_status)`	`(success	refused	conflict)`
`claim_card`	`(kanban_id, card_key, title)`	`(claim acquired	race lost	wip exceeded
`release_claim`	`(kanban_id, card_key)`	`(released	not held	branch already gone)`
`link_pr_to_card`	`(kanban_id, card_key, pr_url, pr_body)`	`(linked	already linked	fallback inserted)`
`comment_on_card` (OPTIONAL)	`(kanban_id, card_key, comment_body)`	`(posted	not supported	length exceeded)`

The compliance column is what the projection must advertise to accept the action. If the projection's level is below the row, dispatch refuses synchronously with a typed compliance-gap failure (tier D — surface immediately).

Three invocation forms

The protocol is transport-agnostic: each projection picks one of three forms for its invocation surface. The choice is the projection's; this skill dispatches uniformly.

Form	What the reference file documents	Where backends pick it
Form A — bash CLI	`gh project ...` / `linear ...` / equivalent shell calls plus `bsp_*` helpers from `scripts/lib/common.sh`.	Backends with a stable scriptable CLI. The shipped GitHub Project v2 projection is Form A.
Form B — plugin-shipped MCP server	The plugin's `.mcp.json` registers the backend's MCP server; the reference names the tools and their input shapes.	Backends with an official MCP server (Linear, Atlassian Remote MCP for Jira).
Form C — REST / GraphQL	The reference documents endpoint shape, auth header derivation, response parsing.	Backends with no MCP server and where a CLI is insufficient.

Per-form invocation conventions live in references/form-a-bash.md, references/form-b-mcp.md, references/form-c-rest.md. The active projection's reference file tells you which form applies.

Setup capabilities — bootstrap-side dispatch

Some board-preparation operations (creating the canonical label set, validating the backend's status taxonomy) run only at bootstrap time, not in the runtime action loop. Each projection declares which of these capabilities it supports; bootstrap stage predicates consult that declaration to decide whether to run or skip a stage.

When the bootstrap stage predicate evaluator asks for capability X, do this:

Resolve the active projection per Step 1 above (references/backend-selection.md).
Read the projection reference (references/<projection-id>.md) § "Setup capabilities".
Return true if the named capability is declared; return not-applicable if it is not. not-applicable is normal flow (the bootstrap stage executor skips the stage); it is NOT a failure.

The capability vocabulary is registry-internal — capability names are valid only within this skill's reference files. The shipped GitHub Project v2 projection declares two capabilities (ensure-labels, validate-status-field); their procedures live in references/github-project-v2.md § "Setup capabilities".

References

File	When to read	Purpose
`references/action-dispatch.md`	When you have an action name and need its procedure (the per-Form invocation rows, audit hand-off sequencing).	Per-action dispatch entries — input/output shape, idempotency, failure tier, per-Form invocation pointers.
`references/backend-selection.md`	When you need to resolve the active projection from this repo's settings (Step 1 above), or when you hit a missing-registry / unknown-projection refusal.	The settings → projection resolver; multi-kanban disambiguation; legacy fallback; refusal-message taxonomy.
`references/failure-mode-dispatch.md`	When the dispatch returned a non-success outcome and you need to classify, pick a tier, and decide retry / log / audit / surface.	Cross-Form failure taxonomy + four-tier visibility model + architect-surfacing template.
`references/form-a-bash.md`	When the active projection is Form A and you need exit-code mapping, helper preference, or worktree-path conventions.	Form A operational contract — invocation conventions, exit-code table, helper preference (`bsp_*` over raw CLI).
`references/form-b-mcp.md`	When you are authoring a future Form B projection (Linear, Jira via Atlassian Remote MCP).	Form B conventions — `userConfig.sensitive` credential storage, MCP tool-call shape, response parsing.
`references/form-c-rest.md`	When you are authoring a future Form C projection (REST / GraphQL backends with no MCP server).	Form C conventions — auth header derivation, request shape, response parsing.
`references/github-project-v2.md`	When the active projection is `github-project-v2` and you need the per-action procedure or setup-capability procedure for this backend.	The shipped GitHub Project v2 projection — paste-and-run shell snippets per action plus the two setup-capability procedures.

When a new projection ships (Linear, Jira, etc.), its per-projection reference file lands in this directory under the projection's identifier. The reference file declares the projection's chosen Form, the per-action procedure, the custom-state folding map, and the supported setup capabilities.

What this skill does NOT cover

Want to know what states a card has, what the Card body schema looks like, how WIP is counted, or how a claim branch is named? See board-canon.
Want to know whether your action proceeds automatically or waits for architect approval? See classifying-actions.
Want to write the audit row that records what was decided and what happened? See auditing-actions.
Want to run a bootstrap stage end-to-end (lifecycle diff, executor selection, stale-state detection)? That is the bootstrapping flow's responsibility; this skill answers the predicate question and dispatches the capability invocation, but does not orchestrate the stage.
Want to discover which projections this skill recognizes? Read the file names under references/<projection-id>.md. There is no introspection API — new projections land by adding a reference file in a normal PR.