A team-leading starter at the top, the picker in ladder order, and ⇧⏎ line breaks

[scgopi]

"Lead a team toward a goal"

The eleventh starter and the first in the list, because this is what most work turns into: one loop that understands the goal, splits it into goal loops for the independent pieces and timed loops for anything that needs checking rather than finishing, and stays to put the pieces back together.

A Main loop on purpose — MAIN_LOOP.md names this as the orchestration path — and it cuts no worktree: a coordinator reads and steers while its children write. Tokens: {goal} and {topic}; the topic is the human's handle on the effort, so graphcode artifactory list <project-path> --search <topic> from a shell shows the whole thread.

The brief is about the task. The Artifactory appears in it as the team's inbox — where the plan is posted for loops that don't exist yet, where children post what they finished, and the record of every message between them:

Lead the work toward this goal: {goal}.

Start by understanding the project well enough to say what done looks like and where the work splits. Then split it: give each independent piece its own goal loop — graphcode node create <project-path> --title <name> --type goal --goal <what done looks like> — and give anything that needs checking rather than finishing, like a build, a flaky test or a service, a timed loop: --type time --prompt "/loop 30m <what to check>". Keep the integration for yourself: the goal is met when the pieces fit together, not when each child says it's done.

The team talks through the Artifactory — treat it as the inbox for this effort, under the topic {topic}. Post your plan there first — graphcode artifactory post <project-path> --topic {topic} <plan> — so every loop you create reads it before starting. Tell each child to post its result there the same way when it's done. Run graphcode artifactory watch <project-path> --topic {topic} so their posts reach you, and graphcode artifactory sync <project-path> whenever you come back, to catch up on what arrived while you were away. A stuck child gets a direct message: graphcode node send <project-path> <id> --follow-up <steer>.

Finish by checking the assembled result against the goal, posting a closing note to the same topic — done, not done, next — and stopping.

Every command in it is verbatim from the CLI help; a test asserts each one is present.

The picker, in ladder order

Starters no longer sort alphabetically — that put Get the build green above everything. They keep their shipped order: lead a team → Goal ×3 → Timed ×2 → the rest. A starter the app no longer ships goes last rather than nowhere.

Your own templates get their own section, Your templates, below the starters and sorted by name. The two stay apart for good: scaffolding and somebody's library are different things, and the earlier fold-away rule would have buried the shipped ones once a library grew.

Rendered headless with the library handed over reversed — the order held.

Seeding is per-starter now

The marker records the ids it has seeded, so an install that already has beta2's ten still receives this one, and nothing it deleted comes back. beta2/beta3 wrote an empty marker; that is read as "the first ten", which is exactly what those installs seeded.

⇧⏎ line breaks

In every prose brief — Main's note, Goal's what does done look like, Timed's task, Turn's first instruction. ⏎ stays the dialog's primary action, as its button says. The insert goes through the field editor so it lands at the caret and the binding updates the ordinary way. Keyboard behaviour can't be exercised headless — this one wants a real keypress before it's trusted.

Verification

• Build succeeds; 1486 tests in 153 suites pass (4 new)
• swiftlint lint — 0 errors; swift format lint --strict — clean
• Picker order confirmed from a headless render

🤖 Generated with Claude Code

https://claude.ai/code/session_01MJR8Wuwc4qnaSBUMcYf7Af