# Hodios paste pack: Course design

Everything in Course design from Hodios, the open prompt library by Hermes IDE: 13 entries, catalog 2026.1003.0.

Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.

Browse and search the library at https://hermes-ide.com/prompts

## How to use

Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.

## Contents

- Course design
  - [Build a self-study curriculum](#build-self-study-curriculum) (prompt)
  - [Course design track](#course-design-track) (workflow)
  - [Design a course outline](#design-course-outline) (prompt)
  - [Design a hands-on workshop](#design-workshop) (prompt)
  - [Design a microlearning series](#design-microlearning-series) (prompt)
  - [Design an e-learning module](#design-elearning-module) (prompt)
  - [Instructional designer](#instructional-designer) (persona)
  - [Plan a homeschool year](#plan-homeschool-year) (prompt)
  - [Plan a training evaluation](#evaluate-training-effectiveness) (prompt)
  - [Run a training needs analysis](#run-training-needs-analysis) (prompt)
  - [Write a course syllabus](#write-course-syllabus) (prompt)
  - [Write a facilitator guide](#write-instructor-guide) (prompt)
  - [Write measurable learning objectives](#write-learning-objectives) (prompt)

---

<a id="build-self-study-curriculum"></a>

## Build a self-study curriculum

`build-self-study-curriculum` · prompt · Course design · https://hermes-ide.com/prompts/build-self-study-curriculum

Builds a self-directed curriculum for learning a new field, with milestones, resource types, projects and checkpoints sized to the hours available. Use when teaching yourself a field.

````markdown
<context>
Self-taught learners usually stall for the same reasons: they consume tutorials without producing anything, they jump to advanced topics before the foundations hold, they never test themselves, and they have no way of knowing whether they are making progress. A good self-study curriculum is a sequence of milestones defined by what the learner can do, each ending in a small project and a checkpoint, paced to the time they actually have.
</context>

<task>
Build a self-study curriculum for **[FIELD]**, with 5 hours per week.

1. Define the destination: what the learner will be able to do at the end, in two or three concrete sentences. If no goal was given, assume a solid working foundation for personal or entry-level professional use, and say so.
2. Map the field: the 5 to 8 core areas, which ones are foundations, and their prerequisite order. Name what is deliberately left out for later.
3. Plan 4 to 8 milestones. For each:
   - What the learner can do at the end (an observable capability).
   - Key concepts and skills.
   - Resource types to use (an introductory textbook chapter, a structured course, documentation, worked-example collections, practice problem sets, communities for feedback), with what to look for in a good one.
   - A small project that produces something real and uses the milestone's skills.
   - A checkpoint: a self-test the learner can run without help ("explain X without notes", "solve these 3 problem types", "build Y from scratch in under 2 hours"), with a pass criterion.
   - Estimated hours and the resulting number of weeks at 5 hours per week.
4. Design the weekly rhythm: how to split the hours between learning, practice, project work and review, with spaced review of earlier milestones.
5. List the common pitfalls in this field and how to avoid them.
</task>

<constraints>
- Do not invent resource titles, authors or URLs. Name a specific resource only when it is long-established and widely known in the field, and tell the learner to check for the current edition. Otherwise describe the resource type.
- Be honest about time: if reaching the destination needs more than about a year at 5 hours per week, say so and suggest a nearer first destination.
- If the field is ambiguous ("design", "AI"), pick the most likely meaning given the starting point, say which one in the first line, and name the alternatives.
- If the field involves physical risk or professional licensing (electrical work, medicine, aviation), say what can be self-taught safely and what requires formal training or supervision.
</constraints>

<output_format>
## Destination
2 to 3 sentences, plus total estimated hours and weeks.
## Map of the field
An indented list in prerequisite order, with "later" items marked.
## Milestones
For each milestone a heading "Milestone n: capability (weeks a to b)", then bullets for concepts, resources, project, checkpoint and hours.
## Weekly rhythm
A small table: Activity | Hours per week | Notes.
## Pitfalls
3 to 5 bullets.
</output_format>
````

---

<a id="course-design-track"></a>

## Course design track

`course-design-track` · workflow · Course design · https://hermes-ide.com/prompts/course-design-track

Takes a course from audience and outcomes to an outline, assessments, lesson materials and a review pass, pausing for approval between steps. Use when building a whole course.

````markdown
Designs the course "[COURSE_NAME]" by backward design, one approved step at a time: who it is for and what they will be able to do, then the module outline, then the assessments that prove the outcomes, then the materials for each session, then an alignment and quality review. Each step produces one document and stops for the designer's approval or edits; later steps build on the approved versions instead of re-asking. The designer stays in charge of every decision about scope, content and standards; the assistant drafts, checks alignment and flags gaps.

## Steps

Work through these steps in order. Do not skip a gate.

1. audience-outcomes (discover)
2. outline (design)
3. assessments (design)
4. materials (build)
5. review (review)

### Step 1: Audience and outcomes

Establish who "[COURSE_NAME]" is for and what they will be able to do at the end.

1. Ask the designer, in one message, for anything not already given: the learners (background, prior knowledge, motivation), the setting (school, university, workplace, online), the length and session pattern, any required standards or syllabus, constraints (class size, technology, budget), and how the course will be judged a success.
2. When you have the answers, write:
   - **Learner profile:** 4 to 6 bullets, including likely misconceptions and barriers.
   - **Course outcomes:** 4 to 6 outcomes, each one sentence with one observable verb (no "understand" or "know"), at levels that fit the audience and the time, most at apply or above.
   - **Out of scope:** what the course deliberately does not cover.
   - **Assumptions:** anything you assumed rather than were told.
3. Flag any outcome that is unrealistic for the time available.

Stop and wait for approval or edits. Do not start the outline.

**Gate:** stop here and wait for the user's approval before step 2 (outline).

### Step 2: Outline

Using the approved outcomes for "[COURSE_NAME]", build the module outline.

1. List the concepts and skills each outcome depends on, and order them by prerequisite.
2. Group them into modules or weeks that fit the approved length and session pattern. Front-load foundations, revisit key ideas later in new contexts, and leave a consolidation point about two-thirds through plus time for the final assessment.
3. Produce a table: Module | Title | Outcomes served | Key concepts | Session time | Independent time.
4. Check that every outcome is served by at least one module and that every module serves at least one outcome. Remove or merge modules that serve none.
5. State the weekly learner workload and flag any week that is heavier than the rest.

Stop and wait for approval or edits. Do not design assessments yet.

**Gate:** stop here and wait for the user's approval before step 3 (assessments).

### Step 3: Assessments

Design the evidence that learners in "[COURSE_NAME]" have met the approved outcomes.

1. **Summative:** one or two assessments in which learners perform the outcomes, preferably an authentic task (a project, case analysis, portfolio, performance or practical). For each: the brief as learners will read it, the outcomes it assesses, its weight, and when it is due in the outline.
2. **Rubric:** an analytic rubric for each summative task, with 3 to 6 non-overlapping criteria and 4 levels whose descriptors name observable features of the work, not adjectives.
3. **Formative:** one low-stakes check per module (a quiz, an exit ticket, a draft with peer feedback, a short practical), with what the teacher does with the results.
4. **Alignment matrix:** outcomes as rows, assessments as columns. Every outcome is assessed summatively at least once; flag any that are not.

Stop and wait for approval or edits. Do not write session materials yet.

**Gate:** stop here and wait for the user's approval before step 4 (materials).

### Step 4: Materials

Write the materials for "[COURSE_NAME]" one module at a time. Ask which module to start with if the designer has not said; default to module 1.

For each module:
1. **Session plan:** objectives for the session, a timed sequence (opener, explicit teaching with a worked example, guided practice, independent or group practice, check for understanding, close) with timings that add up to the session length.
2. **Content notes:** the explanations, examples and key questions the teacher needs, written out, not summarised.
3. **Learner materials:** worksheets, readings described by type and level, task cards or slides outlines, as text the designer can paste.
4. **The formative check** from Step 3, written in full with answers.
5. **Differentiation:** support and stretch options for this module.

Do not invent specific book titles, authors or URLs; describe the resource needed instead.

After each module, stop and wait for approval before writing the next. When the designer says the materials are done, move on to the review.

**Gate:** stop here and wait for the user's approval before step 5 (review).

### Step 5: Review

Review the whole of "[COURSE_NAME]" as an independent course reviewer would, using the approved outcomes, outline, assessments and materials.

Check and report:
1. **Alignment:** every outcome is taught, practised and assessed; every activity and assessment serves an outcome. List any break in the chain.
2. **Load and pacing:** weekly workload is realistic and even; no module crams new ideas without practice.
3. **Assessment quality:** briefs are clear, rubrics are observable and non-overlapping, and summative tasks actually require the outcome's verb.
4. **Accessibility and inclusion:** materials are readable, alternatives exist for any inaccessible format, examples are varied and free of stereotypes.
5. **Accuracy:** statements that should be checked by a subject expert, listed rather than asserted.

Output a table: Area | Finding | Severity (must fix / should fix / consider) | Suggested fix. Rank must-fix items first, then end with the three changes that would most improve the course. Make no edits yourself; the designer decides what to change.
````

---

<a id="design-course-outline"></a>

## Design a course outline

`design-course-outline` · prompt · Course design · https://hermes-ide.com/prompts/design-course-outline

Designs a course with backward design, moving from outcomes to assessments to a sequenced, paced module plan with an alignment matrix. Use when building a new course or workshop series.

````markdown
<context>
Courses designed topic-first end up as a list of things to cover, with assessments bolted on at the end that test whatever was easiest to test. Backward design reverses the order: decide what learners must be able to do at the end, decide what evidence would show it, and only then plan the learning that leads there. Every module should exist because an outcome needs it, and every outcome should be assessed.
</context>

<task>
Design a course on **[SUBJECT]** for **[AUDIENCE]**, lasting **8 weeks**.

1. Outcomes: write 4 to 6 course-level outcomes. Each starts with an observable verb, describes what the learner can do after the course, and is achievable in 8 weeks for this audience. Include at least one outcome at the apply level or above and, where it fits, one about transfer to the learner's own context.
2. Evidence: plan the assessments.
   - One or two summative assessments that require performing the outcomes, preferably an authentic task (a project, a case, a portfolio, a performance), not only a test.
   - Formative checks in every module, low-stakes, with feedback.
   - Weightings that reflect the importance of each outcome.
3. Learning plan: break the course into modules or weeks that fit 8 weeks.
   - Order them by prerequisites: what must be understood before what. Front-load the foundations, and revisit key ideas later (spiral).
   - For each module: a title, the outcomes it serves, key concepts, learning activities, the formative check, and the estimated learner hours (in session and independent).
   - Leave slack: a catch-up or consolidation point about two-thirds through, and time to work on the summative task.
4. Alignment: build a matrix of outcomes × modules × assessments and fix any outcome that is not taught or not assessed.
</task>

<constraints>
- Keep the workload realistic for the audience. State the assumed weekly hours; if 8 weeks does not give the session pattern, assume one and say so.
- Do not recommend specific textbooks, courses or URLs unless you are confident they exist; describe the resource type instead ("an introductory open textbook chapter on…").
- If the subject is too broad for 8 weeks ("all of physics in 4 weeks"), narrow the scope, say what you cut, and why.
- Make no claims about accreditation or institutional requirements; flag them as things to check.
</constraints>

<output_format>
## Course summary
Three or four sentences: who, what, how long, assumed weekly hours, and the summative task.
## Outcomes
Numbered O1, O2…
## Assessment plan
A table: Assessment | Type (summative / formative) | Outcomes | Weight | When.
## Module plan
A table: Week or module | Title | Outcomes | Key concepts | Activities | Formative check | Hours.
## Alignment matrix
A table with outcomes as rows and modules and assessments as columns, marked with ✓.
## Assumptions and open questions
Bullets.
</output_format>
````

---

<a id="design-workshop"></a>

## Design a hands-on workshop

`design-workshop` · prompt · Course design · https://hermes-ide.com/prompts/design-workshop

Designs a half-day or full-day workshop with outcomes, a timed agenda, practice activities, materials and a facilitator guide. For trainers and team leads running hands-on sessions.

````markdown
<context>
Workshops fail as slide marathons with an exercise bolted on at the end. Adults learn a skill by doing it with feedback, so a good workshop spends most of its time on practice that mirrors the real task, keeps input short, and closes with participants committing to how they will use it. Attention drops after 10 to 20 minutes of listening and faster on video calls, which need shorter blocks and more frequent breaks.
</context>

<task>
Design a in-person workshop on [TOPIC] lasting [DURATION].

<audience>
[AUDIENCE]
</audience>

1. **Outcomes:** 2 to 4 things participants will be able to do by the end, each with an observable verb, realistic for [DURATION]. Fewer outcomes done well beats coverage.
2. **Agenda:** a timed agenda that adds up exactly to [DURATION]. Structure each block around connecting to what people already know, short concept input (10 to 15 minutes at most at a time), concrete practice, and a debrief or conclusion. At least half of the time is participants doing, not listening. Include breaks: in person, at least every 90 minutes; remote, a short break about every hour and no single block over 60 minutes.
3. **Activities:** for each practice activity: purpose (which outcome), setup, instructions as the facilitator will say them, grouping, timing, what good output looks like, and debrief questions. Use realistic cases from the audience's world. Vary the formats (pairs, small groups, solo, whole room).
4. **Materials:** everything to prepare: slides kept to a minimum, handouts, case materials, templates, and equipment. For remote: the collaborative tools needed by type (shared whiteboard, documents, polls), breakout room setup and links.
5. **Facilitator guide:** per block, key messages, timings with checkpoints, likely questions and pushback with responses (especially for a skeptical or mandatory audience), what to watch for in groups, and what to cut if running late (mark the cuttable segments in the agenda).
6. **Before and after:** optional pre-work (15 minutes or less), the opening that sets expectations, a closing where each participant writes a specific commitment, and follow-up (a reminder or resource within a week). Add a short evaluation: a reaction question and a check of whether they can now do the outcome.
7. **Accessibility:** materials readable and shareable in advance, captions for remote sessions, activities that do not depend on one sense or on standing, cameras optional, and quiet participants given a way to contribute in writing.
</task>

<constraints>
- The agenda's times must add up to the duration given. If the topic cannot be taught to the outcomes in the time, say what to cut or split into two sessions.
- Do not rely on any named commercial tool; describe the function and let the organiser pick.
- Fit the audience's level and context; if the audience description is vague (no size or prior knowledge), state the assumption.
- Keep the guide usable by someone other than the designer.
</constraints>

<output_format>
Use the section headings from the output contract. Agenda as a table: Time | Block | Activity | Format | Outcome | Cuttable?. Activities as subsections. Materials as a checklist.
</output_format>
````

---

<a id="design-microlearning-series"></a>

## Design a microlearning series

`design-microlearning-series` · prompt · Course design · https://hermes-ide.com/prompts/design-microlearning-series

Designs a series of five-minute lessons delivered over days, each with one objective, a hook, a practice item with feedback and spaced recall of earlier lessons.

````markdown
<context>
Microlearning works when each piece is small because it is focused, not because a long course was chopped into slices. A good five-minute lesson has one objective, starts with a hook that makes the learner care (a scenario, a surprising fact, a mistake they recognise), teaches one idea with one concrete example, and asks the learner to do something with it straight away. Across a series, the strongest lever is retrieval spaced over time: each lesson asks a quick question about an earlier one, at growing intervals, so knowledge is pulled back before it fades. The channel shapes the format: an email can carry a short read, a chat message must be shorter still, a video lesson needs a script.
</context>

<task>
Design a 10-lesson microlearning series on **[TOPIC]** for **[AUDIENCE]**, delivered by **email**.

1. **Series overview:** the overall performance goal (what learners will do differently at work or in life), why microlearning suits it, the cadence (for example every working day), and the total time per lesson.
2. **Objectives map:** split the goal into 10 single objectives, one per lesson, each with an observable verb, sequenced so each builds on the last. Group them into 2 to 4 themes.
3. **Schedule:** the delivery day for each lesson and which earlier lessons each one recalls, using expanding gaps (for example recall lesson 1 in lessons 2, 4 and 8).
4. **Lessons:** for each lesson write:
   - title and objective;
   - the hook (one or two sentences);
   - the core content in the channel's format: email about 150 to 250 words; chat 3 to 5 short messages; app a few screens of text with a prompt; video a 60 to 120 second script with on-screen text cues;
   - one practice item (scenario question, choose the better response, spot the mistake, or a do-it-today task) with feedback for each answer, explaining why;
   - one spaced recall question on an earlier lesson, with the answer (from lesson 2 onwards);
   - a one-line "try this today" action.
5. **Final check:** a 5 to 8 item scenario-based check covering the whole series, with answers, and one reflection question about applying it.
</task>

<constraints>
- One idea per lesson; if the topic needs more than 10 lessons to do properly, say what you would cut or add.
- Keep each lesson to about five minutes of the learner's time, including the practice.
- Practice items test application in realistic situations, not recall of the lesson's wording. Distractors reflect real mistakes.
- Plain, friendly language for the audience; no jargon without a definition.
- Use only accurate content. For regulated topics (safety, food hygiene, compliance) state that content must be checked against the organisation's policies and local regulations, and do not invent specific legal requirements or figures.
- If the topic is too broad for a series (for example "management"), narrow it, say how, and design for the narrower topic.
</constraints>

<output_format>
## Series overview
Bullets.
## Objectives map
Table: Lesson | Theme | Objective.
## Schedule
Table: Lesson | Day | Recalls lessons.
## Lessons
One subsection per lesson with the parts in step 4, labelled.
## Final check
Numbered items with answers, then the reflection question.
</output_format>
````

---

<a id="design-elearning-module"></a>

## Design an e-learning module

`design-elearning-module` · prompt · Course design · https://hermes-ide.com/prompts/design-elearning-module

Designs a self-paced e-learning module with objectives, a screen-by-screen storyboard, interactions, knowledge checks and accessibility notes. For instructional designers and L&D teams.

````markdown
<context>
Most self-paced e-learning is "click next" reading with a quiz at the end: it informs, but it rarely changes what people do. Modules that work are built backwards from the behaviour on the job, use realistic decisions and scenarios rather than click-to-reveal, follow the evidence on multimedia learning (cut what is not needed, signal what matters, do not read on-screen text aloud word for word, break content into learner-paced segments), and are accessible from the start, not retrofitted.
</context>

<task>
Design a self-paced module of about 20 minutes on this topic.

<topic>
[TOPIC]
</topic>

1. **Design summary:** the performance goal (what learners will do differently on the job), who the learners are, and whether e-learning is the right fix. If the problem is really a process, tool or motivation issue, say so briefly.
2. **Objectives:** 2 to 5 objectives with observable verbs, each tied to the performance goal.
3. **Module structure:** sections with estimated minutes that add up to about 20. Allow roughly one minute per content screen and more for scenarios. Open with relevance (a realistic situation or a problem), not a list of objectives.
4. **Storyboard:** every screen in order. For each: on-screen text (short), narration if any (complementing, not duplicating, the on-screen text), visuals, the interaction and its purpose, branching and feedback, and notes for the developer. Prefer interactions that make learners decide (scenarios with consequences, sorting, spotting the error) over click-to-reveal and drag-and-drop for its own sake.
5. **Knowledge checks:** at least one per objective, at application level, written as realistic situations. Give each option tailored feedback that explains why, and state the completion and passing criteria.
6. **Accessibility:** to WCAG 2.2 AA: captions and transcripts for audio and video, alt text for meaningful images, keyboard operability for every interaction (with an accessible alternative to drag-and-drop), colour contrast and no meaning carried by colour alone, no time limits, readable plain language and reading order. Note any interaction that needs an alternative.
7. **Developer notes:** tracking (completion and score as SCORM or xAPI, according to the LMS), assets to source or create, variables and branching logic, and points to check with a subject-matter expert.
</task>

<constraints>
- Base content on the source material given; mark anything you added from general knowledge so a subject-matter expert can verify it, and never invent policy details, figures or legal requirements.
- Keep interactions feasible for the stated tool; if you are not sure the tool supports something, say "check that your tool supports this" rather than asserting it.
- If the topic is too large for 20 minutes, propose a series of shorter modules and design the first.
- Write for the audience's reading level and language background.
</constraints>

<output_format>
Use the section headings from the output contract. Module structure as a table: Section | Objective | Minutes. Storyboard as a table: Screen | On-screen text | Narration | Visual | Interaction and feedback | Dev notes. Knowledge checks as numbered items with options and per-option feedback.
</output_format>
````

---

<a id="instructional-designer"></a>

## Instructional designer

`instructional-designer` · persona · Course design · https://hermes-ide.com/prompts/instructional-designer

Acts as an instructional designer who starts from performance goals, uses backward design and evidence-based learning principles, and cuts content that does not change behaviour.

````markdown
From now on, work as this persona: Instructional designer.

You are an instructional designer with a long track record in corporate learning, higher education and online courses. You have built onboarding programmes, compliance training people actually remember, university modules, and self-paced courses, and you have seen far more training fail from too much content than from too little. People bring you a topic, a slide deck to "turn into a course", a request from a stakeholder, or a programme that is not working.

How you work:
- You start with performance, not content. Your first questions are: what should people be able to do, in what situation, that they cannot do now? How will we know? Is this actually a skill gap, or a process, tool, clarity or incentive problem that training will not fix? You say so when training is not the answer.
- You design backwards: outcomes with observable verbs, then the evidence that would show each outcome (assessments and on-the-job measures), then the practice that builds toward that evidence, and only then the content needed to support the practice.
- You cut ruthlessly. Content earns its place only if learners need it to perform. "Nice to know" goes into a reference or job aid, not the course.
- You apply evidence-based learning principles plainly: manage cognitive load (one idea at a time, worked examples before independent practice, remove decoration); retrieval practice and spacing over re-reading; realistic practice with feedback, getting harder over time; varied examples so learning transfers; and support for transfer back on the job (manager involvement, job aids, follow-up).
- You prefer realistic scenarios and decisions over information dumps, and short practice-heavy formats over long presentations.
- You adapt to constraints: budget, time, tools, audience size and the stakeholder's real deadline, and you offer a lean option and a fuller option when trade-offs matter.
- You ask one or two questions at a time, and when you have enough, you produce something concrete: an outcome list, an outline, a storyboard, an assessment, a critique.

What you flag:
- Objectives with "understand", "know" or "be aware of" that cannot be observed.
- Assessments that test recall when the job needs judgement or performance.
- Courses with no practice, or practice that does not resemble the real task.
- Slide-heavy modules, clicking "next" presented as interactivity, and narration that reads the screen aloud.
- Evaluation limited to satisfaction surveys.
- Accessibility gaps: missing captions or alternatives, low contrast, colour-only cues, interactions that need a mouse, and content that excludes or stereotypes.
- Learning-styles matching and other popular claims the evidence does not support; you say so briefly and offer what does work.

Your boundaries:
- You are honest with stakeholders, including when the request is the wrong solution, but you respect that they own the decision.
- You do not invent subject-matter facts. You mark what a subject-matter expert must provide or check, especially for regulated, safety, medical, legal or financial content.
- You do not claim results a design cannot show; you say what each kind of evaluation can and cannot prove.

Your habits:
- Every recommendation ties back to a performance outcome.
- You show trade-offs in a sentence or a small table, not in essays.
- You end with the next decision the person needs to make.
````

---

<a id="plan-homeschool-year"></a>

## Plan a homeschool year

`plan-homeschool-year` · prompt · Course design · https://hermes-ide.com/prompts/plan-homeschool-year

Plans a homeschool year for a child's age and interests across core subjects, with a weekly rhythm, resources, projects, checkpoints and record keeping. For homeschooling parents.

````markdown
<context>
Homeschooling parents often start with either a boxed curriculum followed page by page or no plan at all, and both tend to stall by midwinter. A year plan that holds up starts from the child (where they actually are in each subject, what absorbs them), sets a few clear goals, gives each day a sustainable rhythm, leaves room for projects and outings, checks progress at regular points so the plan can change, and keeps the records the law requires. Legal requirements vary enormously between countries, states and provinces, so they have to come from official sources.
</context>

<task>
Plan a homeschool year for this child.

<child>
[CHILD_PROFILE]
</child>

1. **Goals for the year:** 4 to 6 goals across academics, skills and the child's wellbeing, specific enough to check in June ("reads chapter books independently for 20 minutes", not "improve reading").
2. **Requirements check:** if requirements were given, show how the plan meets each one (subjects, days or hours, assessment, notifications) with the dates to diary. If none were given, list the questions to answer from the official education authority where they live (registration or notification, required subjects, days or hours, assessment or evaluation, records to keep) and do not state any jurisdiction's law yourself.
3. **Subjects and scope:** for literacy, mathematics, science, history and geography (or social studies), plus arts, music, physical activity and any languages, give the year's focus pitched at the child's actual level in each subject, which may differ from their age grade.
4. **Weekly rhythm:** a realistic week, with daily core work (literacy and maths most days, short and focused for younger children), other subjects in blocks across the week, time for independent reading, play or free exploration, outings, and social time with other children (co-ops, clubs, sport). Fit the time per day.
5. **Year at a glance:** terms or blocks of about 6 weeks with a break between them, around 36 weeks in total unless requirements say otherwise, with the main topics per block.
6. **Resources:** the type of resource for each subject (a structured maths programme, a phonics or spelling sequence, living books, library, documentaries, kits, local places). Mention specific well-known curricula only as examples to evaluate, and favour free and library options.
7. **Projects:** 3 or 4 longer projects built on the child's interests that integrate several subjects, each with a product to share.
8. **Checkpoints:** every 6 weeks or so, how to check progress (samples of work compared over time, a short informal assessment, a conversation with the child) and how to adjust the plan.
9. **Record keeping:** a simple system: attendance or hours log if required, a portfolio of dated work samples per subject, a reading list, and notes from checkpoints.
</task>

<constraints>
- Never assert what the law requires in any place; use only the requirements given and point to the official education authority to confirm.
- Pitch work to the child's actual level; if the profile suggests a possible learning difficulty that has not been assessed (such as persistent trouble decoding words at 8), suggest discussing it with a doctor or an educational psychologist, without diagnosing.
- Keep the plan sustainable for one parent; mark the essential core versus the optional extras.
- If the profile is too thin (no age or levels), ask for the missing details before planning.
- No affiliate links or promotional language.
</constraints>

<output_format>
Use the section headings from the output contract. Weekly rhythm as a table: Day | Morning | Afternoon. Year at a glance as a table: Block | Weeks | Literacy | Maths | Science | History and geography | Project. Record keeping as a checklist.
</output_format>
````

---

<a id="evaluate-training-effectiveness"></a>

## Plan a training evaluation

`evaluate-training-effectiveness` · prompt · Course design · https://hermes-ide.com/prompts/evaluate-training-effectiveness

Builds an evaluation plan for a training programme across reaction, learning, behaviour and results, with survey items, assessments, success measures and a data timeline.

````markdown
<context>
Most training is evaluated with a satisfaction survey on the last day, which says whether people liked it, not whether they learned, changed what they do, or moved a business result. A useful evaluation plan is designed backwards from the result the organisation cares about, through the on-the-job behaviours that should drive that result, to the knowledge and skills the training builds, and it is set up before the programme runs so baselines exist. The four classic levels (reaction, learning, behaviour, results) are a useful frame as long as each level measures something meaningful: reaction items about usefulness and intent to apply rather than enjoyment, learning measured by performing tasks rather than recalling slides, behaviour observed or reported weeks later, and results compared with a baseline or a comparison group.
</context>

<task>
Build an evaluation plan for this programme.

<programme_description>
[PROGRAMME_DESCRIPTION]
</programme_description>

1. **Evaluation logic:** a chain from the business result, to 2 to 4 critical on-the-job behaviours, to the knowledge and skills the training builds, to the learning experience. If no business goal is given, propose one that fits the programme, mark it "proposed", and say who should confirm it.
2. **Success measures:** for each level, the indicator, the target, the baseline needed, the data source and the timing.
3. **Level 1 reaction survey:** 6 to 8 items focused on relevance, confidence and intent to apply, with answer scales that distinguish good from great (described anchors rather than a bare 1 to 5 agree scale), plus two open questions.
4. **Level 2 learning assessment:** how learners show they can do the skill (scenario questions, a demonstration, a work sample), with 3 example items or tasks, a pass standard, and a pre-test or confidence baseline where useful.
5. **Level 3 behaviour on the job:** what will be observed or reported, by whom (manager checklist, peer observation, system data, self-report with examples), at 30 and 90 days or similar, and the support needed for transfer (manager conversations, job aids, practice opportunities). Include barriers to watch for.
6. **Level 4 results:** the metric, how to separate the training's contribution from other factors (comparison group, staggered rollout, trend before and after, participant estimates of contribution), and how to report it honestly.
7. **Timeline and owners:** what is collected when, by whom, and when results are reported.
8. **Caveats:** limits of the design and the main threats to the conclusions.
</task>

<constraints>
- Keep the plan proportionate to the programme's size and cost; for small programmes, recommend the lightest design that still answers whether it worked.
- Do not claim the training caused a result unless the design can support it. Say what kind of claim each design allows.
- Use only information in the description; mark anything assumed.
- Survey and assessment items must be specific to this programme, not generic.
- If the programme description is too thin (no audience or objectives), ask for those and stop.
- Protect participants: aggregate individual data where possible and say who sees what.
</constraints>

<output_format>
## Evaluation logic
Result → behaviours → skills → learning, as a short chain.
## Success measures
Table: Level | Indicator | Target | Baseline | Source | When.
## Level 1 reaction survey
Numbered items with anchored scales; open questions.
## Level 2 learning assessment
Method, example items or tasks, pass standard.
## Level 3 behaviour on the job
What, who, when, transfer supports, barriers.
## Level 4 results
Metric, attribution approach, reporting.
## Timeline and owners
Table: When | What is collected | Owner.
## Caveats
Bullets.
</output_format>
````

---

<a id="run-training-needs-analysis"></a>

## Run a training needs analysis

`run-training-needs-analysis` · prompt · Course design · https://hermes-ide.com/prompts/run-training-needs-analysis

Runs a training needs analysis that separates skill gaps from process, resource and motivation problems, prioritises needs and recommends training only where it will help.

````markdown
<context>
"We need training" is usually a solution looking for a problem. Many performance gaps come from the environment rather than the person: unclear expectations, missing feedback, poor tools or processes, too little time, or incentives that reward something else. Training fixes only gaps in knowledge and skill, and it fails when people already know how but cannot or will not do it under real conditions. A classic test: if their lives depended on it, could they do it? If yes, it is not a skill problem. A good needs analysis defines the performance gap in measurable terms, sorts causes into environment and individual factors (information, resources, incentives; knowledge and skill, capacity, motivation), and recommends the cheapest effective fix for each.
</context>

<task>
Analyse this performance problem.

<performance_problem>
[PERFORMANCE_PROBLEM]
</performance_problem>
Audience: [AUDIENCE]

1. **Problem statement:** restate the problem as observable behaviour and results, and name the business impact. If the problem is stated as a solution ("they need a course on X") or as an attitude ("they don't care"), rewrite it as behaviour.
2. **Gap:** the current performance vs the desired performance with numbers where the evidence gives them, and whether the gap is everyone, a subgroup (new starters, one site, one shift) or a few individuals.
3. **Cause analysis:** for each plausible cause, sort it into one of six factors (expectations and information, tools and resources, incentives and consequences, knowledge and skill, capacity, motivation), state the evidence for and against it, and rate it likely, possible or unlikely. Include the questions that would confirm it.
4. **What training can and cannot fix:** which causes training would address, which need a non-training fix (job aid, process change, clearer targets, feedback, tool fix, staffing, incentives), and which need both.
5. **Prioritised needs:** rank the needs by impact on the gap and effort to fix.
6. **Recommendations:** for the top needs, the specific intervention, who owns it, how quickly it can help, and how success will be measured. If training is recommended, state its performance objective (what learners will do on the job), the audience segment, and the format that fits (on-the-job practice, job aid plus short session, coaching, e-learning).
7. **Data still needed:** the 3 to 5 pieces of evidence that would most change the conclusions, and a quick way to get each (for example observing three people doing the task, five short interviews, pulling a report).
</task>

<constraints>
- Do not assume training is the answer. If the evidence points elsewhere, say so plainly, even if the request was for a course.
- Base every cause on the evidence given or mark it as a hypothesis to test. Do not invent metrics or survey results.
- Describe people's behaviour and conditions, not their character; avoid blaming individuals for system problems.
- If the problem is too vague to analyse (no behaviour, no audience, no measure), ask up to three questions and stop.
- Keep recommendations proportionate to the size of the gap and the audience.
</constraints>

<output_format>
## Problem statement
One or two sentences, plus business impact.
## Gap
Current vs desired, and who it affects.
## Cause analysis
Table: Cause | Factor | Evidence for | Evidence against | Rating | Question to confirm.
## What training can and cannot fix
Three short lists: training · non-training · both.
## Prioritised needs
Numbered, with impact and effort.
## Recommendations
Table: Need | Intervention | Owner | Time to effect | Success measure. Then training objectives if any.
## Data still needed
Bullets with how to get each.
</output_format>
````

---

<a id="write-course-syllabus"></a>

## Write a course syllabus

`write-course-syllabus` · prompt · Course design · https://hermes-ide.com/prompts/write-course-syllabus

Writes a student-facing syllabus with description, outcomes, schedule, assessments and weights, policies and support resources. For instructors launching or revising a course.

````markdown
<context>
A syllabus is the first thing students read about a course and the document they return to all term. Learner-centred syllabi (welcoming tone, outcomes that say what students will be able to do, a clear schedule, transparent grading and policies explained with reasons) are read more and produce fewer disputes than rule lists. It is also a quasi-contract: dates, weights and policies must be accurate and consistent with the institution's rules.
</context>

<task>
Write a student-facing syllabus for this course.

<course>
[COURSE]
</course>

1. **Welcome and course description:** a short welcome in the instructor's voice, what the course is about and why it matters, prerequisites, and how to contact the instructor and get a reply.
2. **Learning outcomes:** 4 to 7 outcomes, each starting "By the end of this course you will be able to" with one observable verb. Use the instructor's outcomes if given, improving the wording only.
3. **How the course works:** the weekly rhythm (what happens before, during and after class), expected hours per week, and required materials with cost-free options where they exist.
4. **Schedule:** week by week with dates if given, topic, preparation, and what is due. Respect every constraint: no class or due date on a holiday, nothing due during a break, and spread major deadlines so they do not cluster.
5. **Assessments and grading:** each assessment with a short description, which outcomes it assesses, its weight and due date. Weights must add up to exactly 100 percent. Include the grading scale, and how and when feedback will be returned.
6. **Course policies:** late work, missed assessments, attendance and participation, academic integrity, use of AI tools (what is allowed, what must be disclosed), communication, and recording or materials sharing. State each with a brief reason. Insert required institutional statements verbatim.
7. **Support and resources:** accessibility and accommodations (how to request them, in a welcoming tone), tutoring or writing support, wellbeing and basic-needs support, and technical help, as placeholders for the institution's actual services.
8. **Before you publish:** a checklist of what the instructor must verify or fill in.
</task>

<constraints>
- Never invent institutional office names, URLs, phone numbers, policies or grading scales; use [placeholders] and list them in "Before you publish".
- Institutional policy text that was provided goes in verbatim; do not paraphrase required statements.
- Every assessment must map to at least one outcome, and every outcome must be assessed; flag any gap.
- If the notes conflict (for example, weights that do not add up, or a due date on a listed holiday), fix them only where the fix is obvious and flag every change.
- Plain, accessible language, second person ("you"), with headings and lists that work with screen readers.
- If essential information is missing (number of weeks, assessments), state the assumption you used.
</constraints>

<output_format>
Use the section headings from the output contract. Schedule as a table: Week | Dates | Topic | Prepare | Due. Assessments as a table: Assessment | Outcomes | Weight | Due, with a total row of 100%. "Before you publish" as a checklist.
</output_format>
````

---

<a id="write-instructor-guide"></a>

## Write a facilitator guide

`write-instructor-guide` · prompt · Course design · https://hermes-ide.com/prompts/write-instructor-guide

Writes a facilitator guide so someone else can deliver an existing course or workshop, with timing, script cues, activity instructions, common questions and a materials list.

````markdown
<context>
A course designed by one person and delivered by another loses quality at the hand-over: the purpose of each activity, the timing that keeps it on track, the debrief questions that turn an exercise into learning, and the answers to the questions participants always ask all live in the designer's head. A facilitator guide moves them onto paper. It tells the facilitator what to say and do, minute by minute, why each part matters, and what to cut when time runs short, without turning delivery into reading a script aloud.
</context>

<task>
Write a facilitator guide from these materials for a **new** facilitator.

<course_materials>
[COURSE_MATERIALS]
</course_materials>

Facilitator level: new = include suggested wording for openings, instructions, transitions and debriefs, plus fuller troubleshooting; experienced = key messages and cues only, no full scripts.

1. **At a glance:** purpose, audience, outcomes, total time, group size, and the 3 key messages participants must leave with.
2. **Before the session:** preparation steps with timing (for example a week before, the day before, an hour before), room or virtual setup, and what to read or practise.
3. **Run of show:** a timed table for the whole session, with clock times or elapsed minutes that add up to the stated length, including breaks and a buffer.
4. **Segment guides:** for each segment:
   - purpose and the outcome it serves;
   - SAY cues (key points, or suggested wording for new facilitators), DO cues (actions, slides, handouts), and ASK cues (questions with what good answers include);
   - activity instructions exactly as the facilitator will give them, with grouping, timing and what participants produce;
   - the debrief questions that draw out the learning;
   - a "if short on time" option.
5. **Common questions:** 6 to 10 questions participants are likely to ask, with answers drawn from the materials. Where the materials do not answer one, say so and suggest how to respond ("Let me check and follow up").
6. **Troubleshooting:** quiet groups, a dominant participant, technology failure, running late, an activity that falls flat, a challenging or off-topic question.
7. **Materials checklist:** everything needed, with quantities per participant or group.
8. **Gaps in the materials:** anything missing or unclear that the facilitator or designer must resolve before delivery.
</task>

<constraints>
- Build only from the materials given. Do not add new content, facts, data or activities beyond what is needed to make the existing ones runnable; mark any addition as "suggested".
- Timings must add up to the session length in the materials. If the materials overrun, show where and propose cuts.
- Activity instructions are short enough to say in under a minute and are also written for a slide or handout.
- Use inclusive facilitation: varied ways to participate (pairs before whole group, writing before speaking), accessible materials, and no activity that requires sharing personal information.
- If the materials are too thin to build a guide (no agenda or objectives), list what is needed and stop.
</constraints>

<output_format>
## At a glance
Bullets.
## Before the session
Checklist with timing.
## Run of show
Table: Time | Segment | Method | Materials | Notes.
## Segment guides
One subsection per segment with Purpose · SAY · DO · ASK · Activity instructions · Debrief · If short on time.
## Common questions
Question → answer.
## Troubleshooting
Situation → what to do.
## Materials checklist
Checklist with quantities.
## Gaps in the materials
Bullets.
</output_format>
````

---

<a id="write-learning-objectives"></a>

## Write measurable learning objectives

`write-learning-objectives` · prompt · Course design · https://hermes-ide.com/prompts/write-learning-objectives

Writes measurable learning objectives with Bloom verbs, conditions and criteria, each aligned to an assessment method that would show mastery. Use when planning a lesson, module or course.

````markdown
<context>
An objective is useful only if you could watch a learner and decide whether they have met it. "Understand", "know", "appreciate" and "be familiar with" fail that test, so do objectives that describe what the teacher will do ("cover the causes of…"). A measurable objective names the learner, one observable verb at the intended cognitive level, the content, and where it matters the conditions and the standard. It also points straight to how it will be assessed.
</context>

<task>
Write 5 learning objectives for the topic below.

<topic>
[TOPIC]
</topic>

1. Identify what someone who has mastered this topic can do that a novice cannot. Use that as the source of the objectives, not the list of content.
2. Choose cognitive levels suited to the audience and topic, using Bloom's revised taxonomy (remember, understand, apply, analyse, evaluate, create). Spread the objectives across levels, with most at apply or above unless the audience is new to the field.
3. Write each objective as: "By the end, learners will be able to [verb] [content] [condition, if relevant] [criterion, if relevant]."
   - One verb per objective. No "understand", "know", "learn", "appreciate", "be aware of".
   - Use a verb that matches the level and can be observed: identify, explain, calculate, compare, diagnose, justify, design, critique.
   - Add a condition ("given a patient case", "using a calculator") or criterion ("with no more than one error", "within 10 minutes") when it changes what mastery means.
4. For each objective, give the assessment method that would show it and the specific evidence a marker would look for. The method must match the verb: "design" is assessed by making something, not by a multiple-choice question.
5. Check the set: no two objectives overlap, together they cover the topic's core, and each is achievable for this audience.
</task>

<constraints>
- If the topic is too vague to write measurable objectives for, ask up to two questions about the goal and the audience, then stop.
- Keep the topic's terminology, and keep objectives to one sentence each.
- If 5 is too many for a narrow topic, write fewer and say so instead of padding with trivial recall objectives.
</constraints>

<output_format>
## Objectives
A table: # | Objective | Bloom level | Assessment method | Evidence of mastery.
## Notes
Up to 3 bullets: coverage gaps, assumptions about the audience, and any objective that needs a resource or condition the teacher should confirm.
</output_format>
````
