soia-edu-design-course-outline

Turn the course topic, audience characteristics, and session-hour constraints into a course outline with measurable objectives, coherent structure, and aligned assessment. Deliverables cover teaching objectives, modules and session hours, prerequisite knowledge, and assessment design, and do not replace software requirements design or communication content planning.

Customer-readable description

What this skill can do

The customer wants	The skill will do	The customer can see
Plan a complete course from a single topic	Clarify the audience, total session hours, individual session length, and teaching context	Course positioning, constraint summary, and assumptions to be confirmed
Turn learning expectations into acceptance-testable objectives	Rewrite objectives using observable actions, completion conditions, and mastery criteria	Measurable teaching objectives and an objective-assessment alignment table
Arrange modules and content for each session	Sequence by prerequisite relationships and cognitive difficulty, and control session-hour load	Module breakdown, key points for each session, prerequisite knowledge, and assessment methods

How the customer uses it

Describe the course topic, target audience, total session hours, individual session length, and teaching scenario.
Optionally provide existing materials, content that must be covered or excluded, assessment constraints, and accessibility requirements.
If key information is missing, first answer the minimum set of clarifying questions; when waiting is not possible, explicitly list assumptions before generating the draft.
Review the objectives, session-hour load, and assessment methods; point out priorities or constraints to adjust and iterate.

Dependencies and installation

This skill is a pure methodology skill with no hard dependencies, scripts, or external services; it can be used without configuration.

claude plugin marketplace add soia-team/soia-open-skills

claude plugin install soia-edu-course@soia

When only this one skill is needed, the npx route can be used. Note that the skill will land in the shared source of truth ~/.agents/skills; if plugins are also installed, the same skill will appear in two indexes and each will drift, so it is recommended to choose one of the two:

npx skills add soia-team/soia-open-edu-course-skills -g -a '*' -s soia-edu-design-course-outline -y

If personalized teaching preferences need to be saved, they can only be placed in the user's own schema v2 configuration:

~/.config/soia-skills/soia-edu-design-course-outline/config.yml

schema_version: 2
defaults:
  lesson_minutes: 45
  delivery_mode: classroom
  accessibility_needs: []

Configuration is entirely optional. The example values are generic placeholders; real institution, learner, or family information must not be written into skill files, prompt examples, or public repositories.

WorkBuddy 's loading unit is a role-based expert rather than a plugin,npx skills add -a '*' cannot cover it, so it needs to be installed separately; see docs/install/workbuddy.md。

Private information and intermediate data

Use only the minimum audience characteristics needed to complete the task; prefer aggregate descriptions such as age range, baseline level, and class size.
Real names, schools, contact information, detailed grades, health conditions, and family circumstances must not enter the skill, logs, or public examples.
When the user truly needs personalization, write the data into the above user-private configuration and use anonymous codes or interval values; remove identifiable information before delivery.
By default, generate drafts only in the conversation and do not write to disk. When the customer requests saving, write to the customer-specified location; delete temporary copies after completion or retain them according to the customer's agreement.

Logs and completion receipts

On completion, report: the inputs used and explicit assumptions, the number of modules and session hours, the alignment check between objectives and assessment, and gaps still requiring customer confirmation. Do not print private configuration content or learner details.

Applicable boundaries

Course design centered on learners achieving teaching objectives belongs to this skill.
Software features, interfaces, acceptance criteria, or technical implementation plans belong to the dev domain; when such requests arise, stop expanding the course outline and suggest handing them over to the corresponding dev skill.
Promotional themes, channels, content calendars, or communication conversion belong to the media domain; this skill handles them only when the content serves teaching objectives and learning assessment.
If a request spans domains at the same time, first split the teaching part from the non-teaching part, deliver only what is within this skill's scope, and mark the handoff items.

Input Contract

Obtain at least the following information; missing items must be asked about or marked as assumptions:

topic: <课程主题>
audience:
  level: <起点水平>
  age_band: <可选，使用区间>
constraints:
  total_lessons: <正整数>
  minutes_per_lesson: <正整数>
  delivery_mode: <线下|线上|混合>
required_content: []
excluded_content: []
assessment_constraints: []

Do not guess the identity, ability diagnosis, or privacy attributes of specific learners. When the topic is too broad but class hours are insufficient, first narrow the scope rather than stacking key points to conceal overload.

Workflow

Define the task. Determine whether it is oriented toward teaching objectives; list dev, media, or other domain content as out of scope.
Normalize constraints. Summarize total teaching minutes, number of class hours, delivery mode, required coverage content, and immutable constraints; check whether the numbers are mutually consistent.
Describe the learning starting point. Use only aggregated information provided by the user, list necessary prerequisite knowledge; distinguish "known," "inferred," and "to be confirmed."
Write teaching objectives. Each objective includes an observable action, learning content, completion conditions, and attainment criteria; avoid standalone expressions such as "understand, be familiar with, master" that cannot be directly measured.
Divide modules. Sequence by prerequisite relationships, from concrete to abstract, or from demonstration to transfer; each module is bound to at least one teaching objective.
Allocate class hours. For each class hour, specify the title, corresponding objectives, core points, learning activities, and formative checks; include review, practice, and feedback in the time budget.
Design assessment. For each objective, choose formative or summative assessments that can produce evidence, and give judgment criteria; do not substitute participation counts for learning outcomes.
Attack the draft. Check whether objectives are measurable, whether content is overloaded, whether prerequisites are missing, and whether assessments truly cover the objectives, and fix the breaks.
Delivery and receipt. Output the outline and alignment table, indicating assumptions, trade-offs, uncovered content, and next steps.

Output Contract

Deliver Markdown in the following order; when the customer specifies another format, keep the field semantics unchanged.

Course Overview: course name, topic, audience, total class hours, length of a single class hour, delivery mode.
Scope and Assumptions: inclusions, exclusions, known constraints, assumptions to be confirmed, cross-domain handoff items.
Prerequisite Knowledge: required items, recommended items, and optional remediation methods.
Measurable Teaching Objectives: number, action, conditions, attainment criteria.
Module Structure: module name, module outcomes, covered objectives, class hour range.
Class-by-Class Schedule: class hour, corresponding objectives, key points, activities, formative checks, after-class connection.
Assessment Plan: assessment name, evidence form, corresponding objectives, scoring or passing criteria, feedback timing.
Objective–Teaching–Assessment Alignment Table: each objective corresponds to at least one teaching activity and one assessment evidence item.
Quality check and next steps: time accounting, coverage gaps, risks, and items requiring client confirmation.

Quality thresholds

All teaching objectives can be observed and judged as achieved.
The total number of modules and lesson hours strictly equals the input constraints, and the time budget is not exceeded.
The number of key points per lesson hour is commensurate with its duration, and time is reserved for practice or feedback.
Each assessment can be traced to a teaching objective; each objective has teaching activities and assessment evidence.
Prerequisite knowledge appears before content that depends on it, and out-of-scope items are not mixed into the deliverables.
Contains no real institution, student, or family information.

Fictional example

Input: “Design a 6-lesson introductory course titled ‘Campus Weather Observation’ for Example School, with each lesson lasting 45 minutes, for learners with zero prior knowledge.”

Treat only “Example School” as a fictional placeholder; the output should still use an aggregated audience description, and should not add a school name, class, student name, or personal profile.