Menu
Open an iteration — set the goal, pull prioritized work in against capacity, and leave the board reflecting the plan.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 | planning |
| description | Open an iteration — set the goal, pull prioritized work in against capacity, and leave the board reflecting the plan. |
| disable-model-invocation | true |
Open the next iteration on the company board. Preset and board values come from docs/agents/board.md; under Kanban (no iterations) this ritual reduces to ordering the Ready column and stops there.
Look at the ending iteration before opening the new one: items not Done either carry over (re-justified, not by default) or return to Backlog. Note the planned-vs-delivered ratio — it calibrates today's capacity. Carry-over that keeps recurring is a /retro topic, not a planning fix.
One sentence, outcome-shaped: "By the end, users can X." Draft it from the top of the backlog and the active epics, then confirm with the user. Scrumban: a theme instead of a goal. A goal that just lists the tickets is a smell — say so and propose the outcome behind them.
Walk the prioritized backlog top-down with the user, pulling items into the iteration until capacity is reached. Capacity = what was actually delivered the last 2–3 iterations, minus known absences — not optimism. Every pulled item must be Ready: labelled, sized, unblocked, and inside an epic if it belongs to one. An item that fails the bar goes to /refinement, not into the iteration.
Via the board skill: set each pulled item's Iteration field and Status = Ready. The plan lives on the board, not in the chat.
Done when: the iteration has a recorded goal (in the iteration name or a pinned issue), every pulled item carries the iteration + Ready status, and the user has confirmed the set. Close by restating goal, item count, and capacity basis in three lines.
