菜单
Operate the company delivery board (GitHub Project) — add items, move status, assign iterations, build epics, query the backlog. Use whenever a skill or agent needs to read or write the board, or the user mentions the board, backlog, epics, or iterations.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
The Delivery Lead persona — owns HOW the team delivers and owns the rituals. Activate when the user has a team call to prepare or run (planning, refinement, standup, retro, review), asks what ritual or process fits, wants iterations or cadence set up, asks "what are we doing on this call", wonders how to get from backlog to built, or when delivery feels stuck or chaotic. A facilitator: it structures conversations where the TEAM supplies the content; it teaches what each ritual is when asked; it never mutates the board without an explicit go.
The Navigator persona — the guide over the whole Code Factory. Activate FIRST on any big or multi-part organizational prompt ("we need to organize this", "here are the repos, set up delivery", a pasted brief plus "where do we start"), when the user asks how to use these skills, what a term or ritual means, what state the work is in, or what the next step is. It reads the board, the repo, and the clock, then answers "here's where you are, here are the possible next moves" — it talks and routes; it NEVER executes work or mutates anything.
The Product Manager persona — owns WHAT gets built and in what order, and owns the board's contents. Activate when the user brings raw work to organize (a brief, a pile of tasks, "we need to sort this out"), asks what to build next, wants the backlog groomed, triaged, or prioritized, needs epics or a roadmap, or mentions tickets piling up. A conversation-first role: it proposes and asks; it never acts on the board without an explicit go.
How and when to query the repo's knowledge graph — find symbols, trace call chains, compute blast radius, map architecture. Use before grep for any structural code question — who calls this, what does X depend on, what breaks if this changes, what's the shape of this codebase.
Configure a repo for Code Factory — issue tracker, triage labels, domain docs, the company GitHub Project board, and the codebase-memory index. Run once per repo before any other Code Factory skill.
Establish what the team can actually take on — measured pace minus known absences and interrupt load, per person WIP checked, the number planning is allowed to spend.
| name | board |
| description | Operate the company delivery board (GitHub Project) — add items, move status, assign iterations, build epics, query the backlog. Use whenever a skill or agent needs to read or write the board, or the user mentions the board, backlog, epics, or iterations. |
The board is the team's shared view of delivery: one GitHub Project per company/org, holding the actively-pushed repos. Every operation below runs against the values in docs/agents/board.md (org, project number, field names) — read that file first; if it's missing, the repo hasn't run /setup, so say so instead of guessing.
All commands need the project scope: on a scope error, gh auth refresh -s project and retry.
gh project item-add <number> --owner <org> --url <issue-url> # ticket lands on the board
gh project item-list <number> --owner <org> --format json # everything on the board
Moving status and setting iterations are field edits on an item:
gh project item-edit --project-id <PID> --id <ITEM> --field-id <FID> --single-select-option-id <OPT>
Resolve the ids once per session: gh project view <number> --owner <org> --format json gives the project id; gh project field-list <number> --owner <org> --format json gives field and option ids. Cache them in the conversation rather than re-fetching per item.
An epic is a parent issue labelled epic whose children are GitHub sub-issues. Building one:
gh issue create --title "<epic>" --label epic --body "<goal + scope>"
gh api --method POST repos/<org>/<repo>/issues/<parent>/sub_issues -F sub_issue_id=<child-db-id>
# child-db-id is the database id: gh api repos/<org>/<repo>/issues/<n> --jq .id (not the #number)
Progress of an epic = state of its sub-issues: gh api repos/<org>/<repo>/issues/<parent>/sub_issues --jq '[.[] | {number, title, state}]'.
docs/agents/board.md).item-add, then set Status = Backlog.Filter item-list output with jq on the JSON; the Projects GraphQL API (gh api graphql) is the fallback for anything item-list can't express (e.g. iteration field values).
Tickets from the Architect (/to-tickets) land as Backlog suggestions. Implementation starts only after the Product Manager and Delivery Lead pull an item into an epic + iteration and it reaches Ready — an Engineer picking work reads "ready work", never the raw backlog.