agentic-board

Run coding agents off your real GitHub Projects board — a quota-aware, review-gated coordinator, not another local Kanban.

Install it, then just talk to your board:

agentic-board is a Claude Code plugin for developers who track work on GitHub Projects and want an agent to actually do the board work: pick the next issue, start it on its own branch and worktree, take it through a PR and a review gate, and merge it — across multiple GitHub accounts, always with a confirmation before anything destructive.

Ask in plain language — "what's pending?", "start issue #42", "move these to Done", "add everything labeled bug", "close the stale ones" — or just run /board work and let it drive the whole issue → branch → PR → gate → merge loop.

What makes it different

• Your real board, not a local clone. It drives the GitHub Projects (v2) and Issues APIs through the gh CLI — the same board your team already uses, not a throwaway Kanban in a tab.
• A quota-aware multi-CLI fleet. /board work can start several independent issues at once, each in its own git worktree, and optionally launch one agent session per issue — probing each CLI (Claude, Antigravity, Codex, Jules, Copilot) for quota and availability before handing it work.
• Review-gated by default. Every issue finishes through a PR and a review gate (a review on the current head commit — the gate requests a GitHub Copilot review when the account has it — plus CI checks and unresolved-thread checks) before it can merge. Good GitHub hygiene is driven by the flow, not left to willpower.

See it run on itself → SHOWCASE.md — the tool governs its own roadmap board; every fix was found while using it and tracked in the open (the dogfooding loop).

Read the case study on running a real BI project's board with this tool → agentic-board: agentes de Claude Code en tu board de GitHub (in Spanish)

BI work rides on the same foundation: TMDL diff review and BI toolkit provisioning have shipped; the rest is on the roadmap.

What it runs, sends and fetches — hooks, launched CLIs, permission defaults, network calls and installs are listed, checked against the code, in the plugin README.

---

Why

Teams track their work on GitHub Projects, but the board work stays manual: creating fields, moving cards, bulk-triaging issues, wiring CI automation, then babysitting each change through its branch, PR, and merge. This plugin turns those chores into natural-language requests an agent executes consistently — including the GitHub gotchas (single-select field IDs, native sub-issues, gh project delete having no --yes flag) that are easy to get wrong by hand.

---

Install

/plugin marketplace add CSalcedoDataBI/agentic-board
/plugin install agentic-board

Then enable agentic-board in your Claude Code plugins.

Coming from agentic-bi-ops? The plugin was renamed to agentic-board and the old marketplace alias has been removed, so an agentic-bi-ops install no longer updates. Uninstall it and install the new id:

/plugin marketplace update agentic-board
/plugin uninstall agentic-bi-ops@agentic-board
/plugin install agentic-board@agentic-board

---

Quick start

After installing, use the /board command or just ask:

/board work                      # the daily driver: see pending work, pick an issue, start it
/board init                      # create a Projects board and link it to this repo
/board add #42                   # add issue #42 to the board
/board move #42 to Done          # set an item's Status
/board fill                      # detect + fill board gaps (assignees, Status, Priority, ...)
/board bulk close label:stale    # batch-close (shows a dry-run + asks first)
/board automate                  # install the CI workflow that auto-adds issues/PRs
/board templates                 # install issue forms + PR template into the repo
/board labels                    # apply the label taxonomy (bug/docs/refactor/chore/blocked/...)
/board update                    # post a high-level status update on the board
/board handoff                   # save/resume context to continue in another session (days later)

---

The command model

agentic-board follows the noun-verb convention used by git, gh, docker, and kubectl (clig.dev): a few command "nouns", with verbs as arguments. You learn one door, not a wall of commands.

Command	What it does
/board	Run a GitHub Projects board — verbs work/plan/fill/init/add/move/field/bulk/automate/templates/labels/update/changelog/handoff/doctor/close-cycle/telemetry/triage/complete/bi-checklist/actions-cost/setup. No arguments shows the menu.
/cleanup	Machine housekeeping for Claude Code, apart from board work — verbs sessions/transcripts/disk/plugins. Plans first, acts on one confirmation.
/docs	Publish all wiki pages (product docs + knowledge registry) in a single push; or check DeepWiki indexing status for this repo.
/expert	Run a tracked plan autonomously as an expert persona, stopping at the irreversible line — verbs config/auto/roles.
/knowledge	Manage the project knowledge references registry by domain (add/harvest/list/gen/wiki). Versioned in knowledge/registry.json + generated KNOWLEDGE.md.
/scan	Turn the current repo's untracked work (code TODOs, doc checklists, plans) into a ready board — issues, priorities, a plan epic — on one confirmation.
/skills	Agent Skills lifecycle — verbs create/improve/organize/audit/bootstrap [quality|bi]/freshness.
/tools	The project's referenced external tools in one catalog — verbs browse/research/install/install --all (a skill-clone keeps its LICENSE).

Two rules keep it discoverable, so nothing has to be memorized:

• No args → a menu. Run a command with nothing after it (just /board) and it lists its own verbs.
• One front door. /board also points to the sibling commands, so the whole tool is reachable from a single entry point.

The internal skills (account resolution, board admin, tmdl-review, and the rest) are hidden from the / palette — the commands in the table above are the only entry points you type; the internal skills run when you ask for their work in plain language.

---

Session handoff

Stop mid-task and pick it up in a fresh session days later — even on another machine — without re-typing the context. /board handoff saves a curated, verified snapshot and reads it back:

/board handoff save     # snapshot: the last important thing + the concrete next step + traps
/board handoff resume    # rehydrate that context and continue the linked issue

• Durable, board-linked, cross-machine. The source of truth is a pinned [abios-handoff] comment on the linked issue (no main noise), mirrored to a gitignored HANDOFF.md.
• Verified, not hand-waved. Every claim is tagged [V] (re-checked live this run) or [?] (from memory); resume reports drift (branch gone, PR merged) and carries traps forward.
• Surfaces itself. /board handoff save drops a self-cleaning MEMORY.md pointer; an opt-in SessionStart hook (references/handoff-hook.md) announces the handoff when you resume.
• Heavy case, done safely. For persistent semantic memory, Suggest-HeavyMemory.ps1 proposes installing Basic Memory (upstream, AGPL) under a full security gate — never vendored. The lightweight HANDOFF.md stays the default. See references/heavy-memory.md.

Design + reference: plugins/agentic-board/skills/projects-admin/references/handoff.md.

Knowledge vs memory vs handoff

Three markdown surfaces, one job each:

File	Holds	Lifetime
MEMORY.md	facts the agent recalls across sessions	permanent, the agent's
HANDOFF.md	how to resume one task	ephemeral, one task
KNOWLEDGE.md	catalog of external references by domain (/knowledge)	permanent, yours

---

Parallel work sessions

/board work can start several independent issues at once, each in full isolation — the official multi-session pattern built on git worktrees:

/board work                      # pick MORE THAN ONE pending issue to batch-start
# or drive the script directly (path relative to a repo checkout):
plugins/agentic-board/scripts/Board-Work.ps1 -ProjectNum <n> -Parallel 12,14,15 -Launch

For each issue the batch:

1. Moves it to In Progress, assigns you, and posts a [abios-claim] fingerprint.

2. Creates a git worktree on its own branch issue-<n>-<slug>, branched off a fresh origin/main. All worktrees are grouped under one sibling folder so the parent dir stays clean:

   Repos/
     agentic-board/                     ← your main working copy (untouched)
     agentic-board--worktrees/          ← one folder holds the whole fleet
       issue-129/   [issue-129-…]         ← session A
       issue-130/   [issue-130-…]         ← session B
   

   They share a single .git, so N working directories edit in parallel without colliding.

3. With -Launch, opens one Windows Terminal tab per worktree running an autonomous headless claude -p session, each briefed to take its issue through PR → review gate, stopping at the reviewed PR unless you pass -AllowMerge.

Permissions. A launched session keeps its CLI's own permission mode and your allow-list, so a headless session is denied any tool outside it. Pass -AllowPermissionBypass to launch with the CLI's bypass flag instead (--permission-mode bypassPermissions for Claude); the launcher prints a warning when you do. Each session also starts with inherited *TOKEN*, *KEY*, *SECRET* and *PASSWORD* variables removed, except its model credential and one GitHub identity.

Monitor the fleet with plugins/agentic-board/scripts/Board-Work.ps1 -Sessions (dead-PID entries are pruned automatically). Use -DryRun to preview without mutating or spawning. After a PR merges, clean its worktree with git worktree remove. Only parallelize issues that don't depend on each other. Tabs require Windows Terminal (wt); without it, each session opens in a standalone pwsh window. On macOS and Linux each session runs as a background pwsh, with its output in launch-<n>.console.log.

---

Setup

1. Install PowerShell 7 and the gh CLI, then gh auth login.
2. Make sure the token has the project scope: gh auth refresh --scopes project (or use a classic PAT with project and repo).

That is all a single-account user needs: with no account map, the plugin uses GH_TOKEN, then gh auth token, and the default board owner is the login gh is signed in as.

Several accounts. Run /board setup. It writes ~/.agentic-board/accounts.json, your own map of which environment variable holds each account's token (names only — the file never holds a token), the default owner, short aliases for --account, and optionally the separate machine identity that brake-armed autonomous runs use. The plugin never calls gh auth switch, so your global gh state is left alone.

{
  "defaultOwner": "your-login",
  "owners":  { "your-login": "GITHUB_TOKEN_PERSONAL", "work-org": "GITHUB_TOKEN_WORK" },
  "aliases": { "work": "work-org" },
  "agentTokenVar": "GITHUB_TOKEN_AGENT"
}

---

What's inside

Component	Purpose
gh-account skill	Resolves the active account and injects its token per-operation. The shared foundation for every module.
projects-admin skill	Board + issue governance: fields, item moves, bulk ops, CI auto-add — with dry-run safety on destructive actions.
abios-feedback skill	Capture tool improvements found while working in any project, sanitized so private data never leaks back here.
project-scan skill	Scan the CURRENT project for untracked work (code TODOs, doc checklists/pending, plans/specs) and turn chosen items into issues + a board plan.
Field presets	One-step localized governance fields (Status/Priority/Type/Area/Estimate/Target) in EN or ES.
/board, /scan commands	Natural-language entry points for the above.

---

Contributing safely (private → public)

This tool improves itself: most fixes are discovered while using it inside private projects. The hard rule is that the cause may be private, but the contribution must be public-only.

Two layers protect this repo:

1. Discipline — the abios-feedback skill captures each improvement abstracted to the public tool (no repo names, client names, data, GUIDs, or paths).
2. A guard you can't forget — after cloning, run once:

   pwsh -File scripts/install-guard.ps1
   

   This wires a pre-commit + pre-push hook that blocks any commit/push whose added lines contain a known secret pattern or a term from your local .abios/private-denylist.txt (gitignored — never committed). Seed that file with your own private fingerprints.

It's defense-in-depth, not a guarantee: a denylist only catches terms you list, so keep layer 1 honest. Override (--no-verify) only for a confirmed false positive.

---

GitHub best practices — enforced by design

The /board work flow doesn't just allow good GitHub hygiene — it enforces it. Checked against the official guides (Projects, GitHub flow, Pull requests, Issues):

Official practice	How the tool enforces it
Branch per change, descriptive name	work creates issue-<num>-<slug> on start
PR for every change, issue auto-closed	step 5 mandates a PR with Closes #<num> — never direct to main
Right identity per repo	New-BoardPR.ps1 resolves the account from the repo OWNER, pushes with a one-shot credential (remote never rewritten), opens/updates the PR
Merge only after review	review gate: a review on the current head (Copilot requested when available) + CI checks + unresolved threads; exit 0 gates the merge; honest self-review fallback
Small, focused PRs	gate warns over 600 lines / 20 files and suggests a sub-issue split
Delete branch after merge	merge flow uses --delete-branch
Break down large issues	Board-Breakdown.ps1 creates native sub-issues (progress column fills itself)
Custom-field metadata	field presets + Board-Fill (assignees, Status, Priority, Size, Type)
Issue templates & labels	/board templates (forms + PR template) and /board labels (taxonomy)
Status updates	/board update posts high-level progress on the board
Dependencies respected	[BLOCKED] items are flagged and refused by -Start
Single source of truth	one board ⇄ one repo, resolve-before-create, backup-before-delete

Honestly out of scope (GitHub exposes no API): view layouts, charts/insights, project templates.

---

Toolkit provisioning (skills-ops)

agentic-board doesn't rebuild the BI tooling ecosystem — it references, installs, and monitors the tools that already exist, so a Fabric / Power BI project gets the right toolkit without reinventing anything. Zero weight for non-BI users: it's a curated JSON catalog plus a couple of scripts that only run when you invoke a profile.

Profiles (presets/toolkits/<profile>.json):

Profile	Provisions
quality (default)	Skill-authoring / review toolkit
bi	Microsoft Fabric + Power BI ecosystem — task bundles semantic-model-review, fabric-app, data-agent

Commands:

• /skills bootstrap bi — install the gaps for a profile (never duplicating what's already installed). Detects by kind: a skill-clone folder is clean-cloned with its LICENSE; a plugin surfaces its own install command.
• /skills freshness — report-only: compares each installed skill's recorded commit SHA against upstream and flags fresh / behind / unknown. It never reinstalls — you decide.

Catalogued tools (attribution). Every tool keeps its owner and license; nothing is vendored:

Tool	Owner	License	Profile
skills-for-fabric	Microsoft	MIT	bi
skill-creator	Anthropic	See repo	quality
writing-skills	obra	MIT	quality
skill-improver	Trail of Bits	CC BY-SA 4.0	quality
second-opinion	Trail of Bits	CC BY-SA 4.0	quality

Add your own public repos (or another developer's) as skill-clone entries in presets/toolkits/bi.json — always with owner + license. Schema: presets/toolkits/README.md.

---

Module roadmap

Module	Description	Foundation
M1 (current)	Cross-account GitHub Projects & issues governance	gh-account
M2 (shipped)	TMDL diff review — breaking schema-change detection wired into the review gate (the surviving slice of the old PBIP/Fabric git-ops idea). An internal skill: ask for a TMDL diff review in plain language	tmdl-review
M3 (current)	BI toolkit provisioning — reference / install / monitor the Microsoft Fabric + Power BI tooling ecosystem by profile (/skills bootstrap bi, /skills freshness), rather than rebuild it. See Toolkit provisioning	skills-ops
M4 (shipped)	BI release automation — a release checklist spec for BI artifacts (references/bi-release-checklist.md) and changelog generation from board Done issues (/board changelog)	gh-account
M5	Knowledge-ops — per-project references registry by domain (knowledge/registry.json + generated KNOWLEDGE.md), /knowledge add + harvest; Phase 2 wiki publish + capture-in-handoff	gh-account

---

License

MIT — see LICENSE.

---

_{agentic-board v0.44.0 · docs generated by plugins/agentic-board/scripts/Update-Docs.ps1}