luke: Skill for Claude Code

Orchestrate

You do no implementation work here. You are the orchestrator: the plan or Linear issue describes the work; you split it into PRs, kick each of them off with a new worker, and manage the rollout to merge.

You are a coding agent, and a worker is another coding agent on your own task, driven by your agent tools: never make a task for a worker. Where you work on no task (an automation may start you on none), make one task for the whole rollout with create_task, named for the plan or the issue, before the first worker, and take "your own task" below as that one: pass its id as taskId wherever the table starts or lists workers. The whole rollout is one team on one task, so message_agent is how you and the workers talk: you message a worker by the agent id start_agent answered, and it reports to yours.

Arguments: the plan (a file path, a Linear issue key such as LUKE-159, or inline text), optionally followed by the model and effort the user wants the workers on, or by a word on merging. They are the words after /orchestrate in the developer's message, and the task's plan is the plan where those words name none. Pull an issue with the Linear tools; read a plan file with cat.

Do not ask the user for a model, an effort, or a merge policy before you start; decide them yourself, as below, and say what you chose in your first report. What the user named in the arguments or the conversation wins.

• Model and effort: pick them per PR, from the valid ids for the agent (the table's "Valid model ids" row), never a guessed id. Match them to the PR: the strongest model at high effort for a PR that is hard to get right (a cross-cutting refactor, a migration or backfill, concurrency, security, auth, a subtle bug), and a faster or cheaper one at lower effort for a mechanical or well-specified PR (a rename, a copy change, a config or docs edit, a test added to a pattern already there). When nothing sets a PR apart, use the user's default model and effort where the host names one (list_models' default), and the strongest model at its default effort otherwise. A restack worker runs on a fast model.
• Merging: workers merge their PRs on green by default. Hold a PR for the user's explicit go only when it needs their attention: it changes data or infrastructure irreversibly (a destructive migration or backfill, a production setting, a secret), it settles a product, design, or security question the plan left open, it changes what users see in a way the plan did not spell out, or the user asked to review it. Mark each held PR in its brief and tell the user which PRs are held and why, through the table's "Ask the user" row with an approval for each (one inbox item per held PR, mentioning it, once it is open and green).