--- name: monoceros-plan description: 'Plan a task before implementing it: an issue reference, a backlog entry or free text. Grills the ambiguity out of it, then writes a plan file the implementer and the reviewer work from. Use only when the user asks for a plan in so many words, never on your own before starting work.' argument-hint: '[issue ref | backlog entry | free text]' allowed-tools: Bash(gh issue view *), Bash(git *), Read, Grep, Glob --- Plan this task: $ARGUMENTS The working directory is: !`pwd` The app is the path segment right after `projects/` in that path. If the path has no `projects/` segment, the working directory is not inside an app. You lead this run. You do the asking, and `monoceros-planner` writes the plan. The split is not cosmetic: a subagent has no way to reach the user, so the questions have to be answered here, before it starts. ## 1. Load the task Fetch it before you plan. A GitHub issue with `gh issue view --json title,body,labels,comments`, a backlog entry by reading the file and quoting the entry, free text as it stands. ## 2. Grill it, one question at a time Nothing of the plan exists yet, and this is the cheapest moment to be wrong. The failure this prevents costs a whole run: a plan written confidently under an assumption the user never made. "Todo app" can mean a private list on one machine or something a team shares, and a 200-line plan for the wrong one is worse than no plan. The rules matter more than the questions: - **One question at a time.** Ask it, wait, then decide whether the next one is still needed. A batch of five gets one vague answer. - **Every question carries your recommended answer**, and you say it is what you will assume if they do not object. That way "yes, yes, no" moves the plan forward, and silence still leaves a decision you can defend. - **Never ask what you can read.** If the repo, the package manifest, the briefing or the environment answers it, go and look: `command -v`, `cat package.json`, a `grep`. Asking the user to describe their own code is the fastest way to lose their patience, and you are the one who can check. - **Ask in the user's words, never in yours.** Every question is about what they want to be able to do; the mechanism is yours to derive. Not "do you need authentication?" but "will you use this alone or with other people?". Not "which database?" but "should this still be there after a restart?". Not "batch or streaming?" but "does the data arrive once a day or all the time?". Whatever you are building, the move is the same: name the capability they would notice, never the machinery behind it. Deriving that machinery is your job and it belongs in the plan, never in the question. - **Follow the answer.** A question that opens another one is the point, not a detour: an answer that admits more than one person, more than one place or more than one time usually hides a second question about how they relate. Working down a list you prepared in advance misses exactly those. - **Stop when nothing is left that changes what gets built.** Five is a ceiling, not a target. One question that settles the scope beats three circling the same point. - **Ask nothing at all when the task is already unambiguous.** If it names what should be true afterwards and how to check it, say so in one line and go straight to step 3. A task that arrives with acceptance criteria has been grilled already. ## 3. Hand it to the planner Delegate to the `monoceros-planner` subagent. It starts with an empty context: it sees your prompt and the files it reads, nothing of this conversation. So the prompt has to carry everything, or it is lost. Write a plan for: App folder: Answers already given by the user: - → - → Reply to the user in: Report back. You cannot ask questions: anything still open goes into the plan's Open questions section. If the working directory has no `projects/` segment, you are not inside a project directory. Then use the app the plan is about, the directory under `projects/` that will be created or changed, and say which one you picked. ## 4. Show it and stop Show the user, in their language: the goal in one sentence, the acceptance command, the assumptions being worked from, and the plan's host steps if it has any, because those are theirs to do. Short enough to read in one go, the plan file has the detail. Then ask, plainly: implement it now, change something first, or stop here. This is a real stop, not a rhetorical question. "Change something" means you hand the correction back to the planner and ask again. Either way, name the command that carries on, with the plan filled in as `/`: /monoceros-ship todo-app/dark-mode-toggle If the plan came back with anything under "Open questions", say so first: that plan is not ready to hand over, and the question is yours to ask before anything runs.