Planner

A Goal is bigger than one PR. Automation can carry a Goal’s children all the way through, but someone has to split them out first. That’s the Planner’s job: it breaks the goal into child issues that can each ship on their own, writes the plan into the Goal, and stops. Nothing runs until you approve.

Who the Planner is

The Planner isn’t a role note. It’s a position: a chat opened beside a Goal issue is that Goal’s Planner. Whenever the issue’s type is Goal, a chat opened on the right of its page carries the Planner’s rules, on the same runtime and model you normally chat with.

Its rules are fixed:

• Read first: the Goal, the project’s main note (Context first), the project’s Decision-Log, the project’s open issues and the states of each type, recent changes nobody has acknowledged, and the notes the Goal links to.
• Look at the code, read-only: search, read files and run read-only commands in the working directory. No edits, commits or branches.
• Ask first if the goal is unclear, then split.
• Split into child issues: each child is one deliverable change, one branch, one PR. Cut by file ownership so children that can run in parallel don’t touch the same files; when two must, or one needs the other’s result, chain them with blocked_by. At most max_children, 8 by default, set in the Settings table of Issues/Issues.md.
• Write each child after its type’s template: links to the notes a worker must read, Goal, Why, and testable acceptance criteria. Each child points to the Goal (goal:), has the Goal’s owner, and waits in its type’s first Todo state.
• Fill the Goal’s ### Plan table and add an entry under ## Log.
• Then stop and tell you what it created. It doesn’t change the state of the Goal or any child, and it dispatches nothing.

On the Goal page

While a Goal is in its type’s first state (Draft for the built-in Goal), its page shows a Planner card.

1. Click Start planning. A fresh chat opens on the right with the first line filled in: “Split this goal into child issues.” Edit it, add what you have in mind, and send.
2. The Planner reads, asks, and splits. The Goal’s Plan table fills in, the children appear in Todo on the board, and the card says how many child issues point to this goal.
3. Not happy? Keep talking in the same chat: “Number 3 is too big, split it”, “leave the database part for later”. The Planner updates the children it already created instead of making duplicates; for ones that should go, it names them and you cancel them.
4. When you’re happy, click Approve → Approved. The Goal moves to the next Todo state and automation takes over: the Goal goes In Progress and unblocked children start, up to max_parallel at a time.

Dragging the Goal from Draft to Approved on the board is the same approval.

Why approval is your click

The Planner could call the tool that changes states, but a state change made from a chat doesn’t trigger automation, and its rules forbid it anyway. Ask it to “approve” and it will point you at the button.

That split is deliberate. Drafting a plan is something an AI can redo as often as you like; starting to spend your runtime’s time and opening PRs against your repository is your call. After approval, each child still follows its own type’s flow and stops at Your turn states such as Review PR and Verify Staging.

When the Goal is already split

If the Goal already has children, the Planner won’t split it again unless you ask. Ask “how is it going?” or “what’s stuck?” in the chat beside the Goal and it answers from the Goal’s list of children.