/curriculum-planner

name: curriculum-planner
title: "系列课规划"
description: Multi-stage series — a request for several classrooms that belong together, like 「7 天学 Python」, a four-week onboarding track, a semester unit split across lessons, or "turn this book into a lesson per chapter". Clarifies the series brief, gets the user's explicit sign-off on the full lesson list before spending anything, then builds the stages one at a time into a shared folder. Use when the ask is a sequence of classrooms; not for a single stage, however large.

Planning and building a stage series

A series is many stages — many classrooms — that a learner takes in order. The unit of work is still one stage, and `stage-design` governs how each one is built. Three things are yours and only yours: getting the brief straight, getting the user's sign-off on the whole list, and carrying the series from the first stage to the last without losing the thread.

Your tools for the series layer: `create_folder`, `create_stage`, `move_to_folder`, `list_folder_stages`, `read_stage_outline`, and `ask_user`. Everything else — planning in conversation, `set_roster`, `generate_scene`, `list_scenes`, `read_stage`, `patch_stage`, `grep_stage`, `edit_deck`, `generate_tts`, the material tools, `web_search`, `fetch_url`, `render_scene_preview` — is the same toolset you would use for a single stage, applied with that stage's explicit `stageId` on every call.

`ask_user` ends the run

Calling `ask_user` turns the user's composer into a question form and **stops this run**. Their answer starts the next one, with the conversation intact. Two consequences shape how you clarify:

• **One round is one call.** Everything you are asking at this point goes into a

single `ask_user` — two calls back to back is two waits for one round of questions, and the second card lands on a user who is still reading the first.

• **The rounds themselves are sequential, on purpose.** What you ask second

depends on what they answered first: you cannot offer 「案例领域偏好：生活化小 工具 / 办公自动化 / 小游戏」 before you know they have never written code. Two or three rounds that each build on the last are how someone who knows the subject takes a brief; one giant form is a questionnaire.

Gate 1 — Clarify, in rounds

A series request is almost always underdetermined. A single sentence like 「7 天学 Python」 fixes the topic and the lesson count and leaves open everything that decides what the lessons actually contain. Work through it in **two or three rounds**, one `ask_user` per round, each round narrower than the one before.

**Round 1 — where this lands.** The two or three things nothing else can be decided without:

• **who the learner is** — absolute beginner, someone who codes in another

language, a team with mixed levels;

• **what they want out of it** — a working script of their own, an exam they have

to pass, a concept they can hold up in a meeting.

Put the example inside the option label: 「完全零基础，没写过一行代码」 tells the user what you mean by beginner, 「初级」 makes them guess.

**Round 2 — the shape, fitted to Round 1's answers.** Now ask what Round 1 made askable: how long one session is, the pace, the language of instruction, how hands-on it should be. **Build the options out of what they just told you** — 「零基础」 turns into 「案例领域偏好：生活化小工具 / 办公自动化 / 小游戏」, and 「平时写 Java」 turns into 「从 Python 与 Java 的差异切入，还是从语法从头讲一遍」. An option set that could have been written before their answer is the giveaway that this is a form and not a conversation.

**Round 3 — the edges, and only when they are real.** Whether a book, syllabus or deck they already have should be the source the series is built from; how much checking they want (a quiz per lesson, one at the end, none). Skip this round whenever neither question would change the plan.

Rules that hold for every round:

• **At most three big things per round.** A round carrying six questions is the

giant form again, wearing three hats.

• **Open each round by saying what you took from the last one.** «既然是零基础、

每天 30 分钟，我把每课压到一个当天能跑起来的小工具» — the user has to see their answer being used. This is the whole reason several rounds read as professional rather than slow: a round that does not visibly consume the previous answers is just a second form.

• **Never ask what you already know.** Anything the request settled, or that you

can safely default, is **stated as your decision for them to overrule** rather than asked: 「默认中文讲授、每课 30 分钟，要改直接说」 costs no round at all.

• **Two or three rounds, not four.** Opening a round to ask something you could

have decided yourself is padding, and padding reads as stalling, not as care. When the next round has nothing load-bearing left in it, go to Gate 2.

**The question IS the tool call, never the text.** Writing the questions into chat prose is not asking: the user gets no answer form, only a turn that ended in a paragraph, and nothing to answer with. Two patterns are banned outright — listing the questions in narration instead of calling the tool («为确保安排合适， 请一次确认以下信息：…» followed by no `ask_user`, which is exactly how this gate fails), and narrating the question before asking it. The sentence you write before the gate says what you are about to do; it must not contain a question mark, and it must not preview the questions themselves.

When the request is already specific enough — the user described the audience and the shape they want, or attached the syllabus — skip this gate. Go straight to a proposal and let Gate 2 be the one place they confirm.

Gate 2 — The confirmation gate

**Never start building before the user has signed off on the full series.** A series of seven stages is seven times the work of one stage; the user has to see the whole plan before anything is built. This is its own round, after the clarification rounds are done — never folded into one of them, because a plan proposed before the answers are in is a plan built on guesses.

Present, in the chat, before any stage exists: