course-outline-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Course Outline Design

课程大纲设计

Schema authority: all primitive field names (unit / concept / prompt / task / material / quiz / faq / illustration) come from
_shared/domain-primitives.md
. When this skill mentions a field, that file is the source of truth.
Filename convention (English-first): all generated files and directories use English names. The mapping from legacy Chinese names is in
_shared/domain-primitives.md
§0.
This skill produces the structural skeleton of a course: how many days, what each day's theme is, what each unit teaches, what the shared running scenario is, and what the meta (hours, classroom, schedule) looks like. It does not write lecture content — that's
course-content-authoring
's job.
Schema authority:所有基础字段名称(unit / concept / prompt / task / material / quiz / faq / illustration)均来自
_shared/domain-primitives.md
。当此Skill提及某个字段时,该文件为权威来源。
文件名约定(英文优先):所有生成的文件和目录均使用英文名称。旧版中文名称与英文的映射关系见
_shared/domain-primitives.md
第0节。
此Skill用于生成课程的结构骨架:包含课程天数、每日主题、每个单元的教学内容、贯穿全程的通用场景,以及课程元信息(时长、授课地点、时间表)。它不负责撰写授课内容——这是
course-content-authoring
的工作。

When to Invoke

调用时机

  • User says "I want to run a workshop on X" but no structure exists yet.
  • User has scattered notes and wants to organise them into a course.
  • User wants to revise an existing outline (add/remove a unit, change day allocation).
  • 用户表示“我想开展一门关于X的工作坊”但尚未搭建课程结构时。
  • 用户有零散笔记,希望将其整理成课程时。
  • 用户想要修订现有大纲(添加/删除单元、调整天数分配)时。

Deliverables

交付成果

A standard outline produces these files. Adapt paths to the user's project, but keep the role of each file distinct — that separation is what enables downstream sub-skills to work.
course-package/   (or your preferred root)
├── overview.md         ← top-level meta + day list + shared scenario summary
├── shared-scenario.md     ← the persistent scenario / fictitious company / characters used across days
├── supporting-docs.md     ← optional: FAQ, pre-reading, environment setup
└── day{n}/
    └── outline.md     ← per-day outline: theme, units, learning goals, hours
The filenames here are Chinese because that's the project convention this skill emerged from. Use whatever language fits the project, but keep the file roles separate. Merging
overview.md
into each Day's outline is a common mistake — it makes meta updates require N edits.
标准大纲会生成以下文件。可根据用户项目调整路径,但需保持每个文件的角色独立——这种分离是后续子Skill能够正常工作的基础。
course-package/   (或自定义根目录)
├── overview.md         ← 顶层元信息 + 每日主题列表 + 通用场景摘要
├── shared-scenario.md     ← 贯穿多日课程的场景/虚构公司/角色
├── supporting-docs.md     ← 可选:FAQ、预读材料、环境设置指南
└── day{n}/
    └── outline.md     ← 每日大纲:主题、单元、学习目标、时长
此处文件名使用中文是因为此Skill源自的项目约定如此。可根据项目使用任意语言,但务必保持文件角色分离。将
overview.md
合并到每日大纲中是常见错误——这会导致元信息更新时需要修改N个文件。

The Five Decisions You Must Pin Down

必须明确的五个决策

Before drafting any file, get these answered (ask the user, one at a time if needed):
  1. Audience + prerequisite knowledge — determines depth of every concept later.
  2. Total contact hours + day count — e.g. 4 days × 6 hours, or 1 day × 8 hours. This drives the unit count.
  3. Shared scenario — every good workshop has a recurring fictional case (a company, a character, a dataset) that ties units together. Pin this before designing units, because the scenario will leak into every unit's example.
  4. Learning outcome verbs — what should the learner be able to do by end of each day? Use action verbs (
    use
    ,
    build
    ,
    evaluate
    ), not knowledge verbs (
    understand
    ,
    know
    ).
  5. Assessment shape — pre-test / post-test / quiz / portfolio? This affects whether you reserve a unit slot for it.
在起草任何文件之前,需确认以下问题(必要时可逐个询问用户):
  1. 受众与前置知识——决定后续每个概念的深度。
  2. 总授课时长与天数——例如4天×6小时,或1天×8小时。这会影响单元数量。
  3. 通用场景——优质工作坊都会有一个重复出现的虚构案例(一家公司、一个角色、一组数据集),将各个单元串联起来。务必在设计单元之前确定场景,因为场景会渗透到每个单元的示例中。
  4. 学习成果动词——学员在每天课程结束后应该能够做什么?使用动作动词(
    use
    build
    evaluate
    ),而非认知动词(
    understand
    know
    )。
  5. 评估形式——预测试/后测试/小测验/作品集?这会影响是否需要为评估预留单元位置。

File-by-File Template

逐文件模板

overview.md
(overview)

overview.md
(课程总览)

markdown
undefined
markdown
undefined

{Course title}

{课程标题}

基本資訊

基本信息

  • 對象: {audience}
  • 總時數: {total hours} ({days} 天 × {hours/day})
  • 上課時間: {schedule, e.g. 每週三 14:00–17:00}
  • 教室: {location + mapUrl if physical}
  • 講師: {instructor}
  • 对象: {受众}
  • 总时数: {总时长} ({天数} 天 × {每日时长}小时)
  • 上课时间: {时间表,例如:每周三 14:00–17:00}
  • 教室: {线下地点 + 地图链接(如有)}
  • 讲师: {讲师姓名}

課程目標

课程目标

{3–5 outcome statements using action verbs}
{3-5条使用动作动词的成果描述}

每日主題

每日主题

Day主題核心產出
Day 1......
Day 2......
...
天数主题核心产出
Day 1......
Day 2......
...

共用案例

共用案例

{1-paragraph summary of the persistent scenario; full details in shared-scenario.md}
undefined
{通用场景的一段摘要;详细内容见shared-scenario.md}
undefined

day{n}/outline.md
(per-day)

day{n}/outline.md
(每日大纲)

markdown
undefined
markdown
undefined

Day {n}: {day theme}

Day {n}: {每日主题}

學習目標 (action verbs!)

学习目标(使用动作动词!)

  • 能夠 {do X}
  • 能夠 {do Y}
  • 能够 {完成X}
  • 能够 {完成Y}

時程

时程

時段單元重點
14:00–14:50u-1 {unit title}...
15:00–15:50u-2 ......
...
时段单元重点
14:00–14:50u-1 {单元标题}...
15:00–15:50u-2 ......
...

單元細部

单元细节

u-1: {title}

u-1: {标题}

  • 學習目標: ...
  • 任務 (tasks): 條列學員實作項目
  • 素材需求: 條列此單元需要的素材檔(給 content-authoring 階段填)
undefined
  • 学习目标: ...
  • 任务 (tasks): 列出学员实操项目
  • 素材需求: 列出此单元需要的素材文件(供content-authoring阶段填写)
undefined

shared-scenario.md

shared-scenario.md

A 1–2 page document describing the recurring fictional context. Include:
  • Company / character names (use placeholder names that won't be mistaken for real entities)
  • The core problem the course will solve for them
  • Data shape examples (column names, file types) — these will be reused as quiz items and prompt examples
一份1-2页的文档,描述贯穿全程的虚构背景。需包含:
  • 公司/角色名称(使用占位符名称,避免与真实实体混淆)
  • 课程将为其解决的核心问题
  • 数据格式示例(列名、文件类型)——这些将被 reused 作为测验题目和提示词示例

Anti-Patterns to Avoid

需避免的反模式

  • "等內容寫完再回來補大綱" — outline must be stable before content authoring, because content authors anchor every unit to the outline's IDs.
  • Unit titles that are noun-only (e.g. "提示詞") — bad, because the title doesn't tell you what the learner does. Prefer verb-based titles ("撰寫一份結構化提示詞").
  • No shared scenario — without it, every unit's example is one-off, and learners can't see how techniques compound.
  • Hour totals that don't add up — the meta says "6 hours/day" but the time table only fills 4.5 hours. Always sum the time table and reconcile.
  • 「等内容写完再补大纲」——大纲必须在内容创作前稳定下来,因为内容创作者会将每个单元锚定到大纲的ID上。
  • 仅包含名词的单元标题(例如“提示词”)——这不好,因为标题无法体现学员需要做什么。优先使用动词开头的标题(例如“撰写一份结构化提示词”)。
  • 无通用场景——没有场景的话,每个单元的示例都是孤立的,学员无法看到技术如何协同作用。
  • 时长总和不匹配——元信息显示“每天6小时”但时间表仅填充了4.5小时。务必核对时间表的总时长并调整一致。

Completion Gate (Hard Rule — must pass before hand-off)

完成标准(硬性规则——移交前必须满足)

Before declaring "outline locked" and suggesting
course-content-authoring
, every item below must have a written artefact (not just a verbal "yes"). Walk the user through them one at a time; if an answer is vague, ask one clarifying question before moving on.
  1. Audience + prerequisite — recorded in
    overview.md
    對象
    field as a concrete sentence (e.g. "行政部門人員,能用 Excel 但沒寫過程式"). Generic "新手" is not enough.
  2. Total hours + day count
    總時數
    populated AND
    每日主題
    table has exactly that many day rows. Sum the time tables in each
    day{n}/outline.md
    and confirm it equals the daily hours.
  3. Shared scenario (optional, but must be explicitly decided) — either:
    • shared-scenario.md
      exists with named company/character + core problem + 1–2 example data shapes; OR
    • overview.md
      contains an explicit one-line note:
      本課無共用案例,每單元獨立舉例
      .
    Silence does not pass — you must ask and record one of the two outcomes.
  4. Learning outcome verbs — every day's
    學習目標
    uses action verbs (
    use
    ,
    build
    ,
    evaluate
    ,
    design
    ,
    compare
    ). Knowledge verbs (
    understand
    ,
    know
    ,
    learn about
    ) fail the gate — ask the user to rephrase.
  5. Assessment shape — explicitly recorded in
    overview.md
    (e.g. "pre-test 5 題 / post-test 10 題 / 每日 quiz 3 題") OR explicitly waived with a one-line note ("本課無評量,採作品集驗收"). Silence does not pass.
If the user pushes "可以了,先開始寫內容" before all 5 items have written artefacts, refuse politely:
「Stage 1 沒鎖好,後面 content/SPA/visual 任一階段改 outline 就要連動多檔重做。先把第 N 項補上,大概 X 分鐘,之後省下的不只這些。」
在宣布“大纲锁定”并建议调用
course-content-authoring
之前,以下每一项都必须有书面记录(不能只是口头确认)。逐项引导用户完成;如果答案模糊,先提出一个澄清问题再继续。
  1. 受众与前置知识——在
    overview.md
    的「对象」字段中记录为具体语句(例如“行政部门人员,会使用Excel但未编写过程序”)。笼统的“新手”不符合要求。
  2. 总时长与天数——「总时数」已填写,且「每日主题」表格中的天数行数与实际天数一致。核对每个
    day{n}/outline.md
    中的时间表总时长,确认其等于每日时长。
  3. 通用场景(可选,但必须明确决定)——满足以下任一条件:
    • shared-scenario.md
      已存在,包含命名的公司/角色 + 核心问题 + 1-2个数据格式示例;或者
    • overview.md
      中包含明确的一行说明:「本课无共用案例,每单元独立举例」。
    沉默不等于同意——必须询问并记录上述两种结果之一。
  4. 学习成果动词——每天的「学习目标」均使用动作动词
    use
    build
    evaluate
    design
    compare
    )。使用认知动词(
    understand
    know
    learn about
    )视为不通过——请用户重新表述。
  5. 评估形式——在
    overview.md
    中明确记录(例如“pre-test 5题 / post-test 10题 / 每日quiz 3题”),或者明确说明无需评估(例如“本课无评量,采用作品集验收”)。沉默不等于同意。
如果用户在所有5项都有书面记录之前就催促“可以了,先开始写内容”,请礼貌拒绝:
「Stage 1 没锁好,后面content/SPA/visual任一阶段修改大纲都要联动多档重做。先把第N项补上,大概X分钟,之后省下的时间远不止这些。」

Decision-time Defaults (ask, don't assume)

决策时的默认规则(询问,而非假设)

When the user genuinely doesn't know an answer, do not propose templates or fill in placeholder defaults — ask one short direct question and wait for their answer. Looping on a wrong assumption is more expensive than one extra round-trip.
  • Audience unknown → ask directly: 「這堂課是為誰開的?是哪個部門 / 哪種角色的學員,他們現在會什麼、不會什麼?」 Wait for a concrete answer before moving to item 2.
  • Hours / days unknown → ask directly: 「總時數和每日時段怎麼安排?例如『2 天 × 6 小時』或『每週三 14:00–17:00 共 4 週』。」 Do NOT propose 1d×6h / 2d×6h / 4d×6h templates — the user's calendar drives this, not our guess.
  • Shared scenario undecided → ask directly: 「這套課程要不要設一個貫穿全程的虛構案例(例如一家公司、一個角色,讓所有單元的例子都圍繞它)?要的話我們一起設定;不要的話就在
    overview.md
    寫『本課無共用案例』然後跳過第 3 項。」 Accept either answer without pushing for a scenario.
The principle: this skill stays decisive by routing on clear answers, not by assuming on silence.
当用户确实不知道答案时,不要提供模板或填充占位符默认值——提出一个简短直接的问题并等待用户回复。基于错误假设反复沟通比多一次往返更耗时。
  • 受众未知 → 直接询问:「这堂课是为谁开设的?是哪个部门/哪种角色的学员,他们目前会什么、不会什么?」得到具体答案后再进行第2项。
  • 时长/天数未知 → 直接询问:「总时数和每日时段怎么安排?例如『2天×6小时』或『每周三14:00–17:00共4周』。」不要提议1d×6h / 2d×6h / 4d×6h等模板——用户的日程决定了安排,而非我们的猜测。
  • 通用场景未决定 → 直接询问:「这套课程要不要设置一个贯穿全程的虚构案例(例如一家公司、一个角色,让所有单元的例子都围绕它)?要的话我们一起设定;不要的话就在
    overview.md
    写『本课无共用案例』然后跳过第3项。」接受任一答案,无需强制要求设置场景。
原则:此Skill通过基于明确答案决策保持高效,而非基于沉默假设

Hand-off to Next Stage

移交至下一阶段

Only after the Completion Gate passes, the user should have:
  • A complete set of outline
    .md
    files
  • A clear unit ID convention (e.g.
    d{n}-u{m}
    ) that the content-authoring stage will use
  • A pinned shared scenario
Tell the user: "outline is locked. From this point, changing day count or unit IDs has cascading cost — let me know before you do." Then suggest invoking
course-content-authoring
next.
只有在满足完成标准后,用户才会拥有:
  • 一套完整的大纲.md文件
  • 清晰的单元ID约定(例如
    d{n}-u{m}
    ),供content-authoring阶段使用
  • 确定的通用场景
告知用户:「outline已锁定。从此时起,修改天数或单元ID会产生连锁成本——如有变动请提前告知。」然后建议下一步调用
course-content-authoring

Revision Flow (if user wants to change an existing outline)

修订流程(如果用户想要修改现有大纲)

  1. Diff what's changing — list every affected unit ID.
  2. Check if Stage 3+ already exists (
    course-data.js
    present?). If yes, warn that downstream files need parallel updates and remember to flag this when handing back to
    teaching-site
    .
  3. Update files in this order:
    overview.md
    (meta) → affected
    day{n}/outline.md
    shared-scenario.md
    (if scenario changed).
  4. Never rename a unit ID once content has been written for it. Mark deprecated, add a new one with a fresh ID.
  1. 明确变更内容——列出所有受影响的单元ID。
  2. 检查是否已进入Stage 3+(是否存在
    course-data.js
    ?)。如果是,警告用户下游文件需要同步更新,并在移交回
    teaching-site
    时记得标记此情况。
  3. 按以下顺序更新文件
    overview.md
    (元信息)→ 受影响的
    day{n}/outline.md
    shared-scenario.md
    (如果场景有变更)。
  4. 一旦单元已有内容,切勿重命名单元ID。标记为已废弃,添加一个带有新ID的新单元。