--- name: he-lms-module-builder description: Plan, draft, revise and review one higher education LMS module, including accessible content, worked problems, self-checks and learning preparation. Use for module blueprints and draft packages; assumes La Trobe University unless told otherwise. --- # LMS module builder *Author: Cam Anderson (hello@camanderson.au). Licensed CC BY 4.0.* Create one module in two stages: a reviewable blueprint, then a draft package after explicit coordinator approval of that exact blueprint. Staff own curriculum decisions, subject expertise and institutional release. The skill works with plain files and evidence supplied by staff; a curriculum library or task engine is optional. ## Establish context and evidence Use the user's selected workspace and read its instructions. Assume La Trobe University unless the user identifies another institution. Inventory supplied permitted evidence before asking questions. If program context is missing, use `he-program-intake` when available; otherwise make targeted requests and retain the findings in `_registers/program-context.md` and the unresolved requests in `_registers/evidence-requests.csv`. Read existing versions before adding to them; do not invent intake answers or duplicate requests. For the fallback, distinguish evidenced facts, user confirmations, provisional inferences and open questions in the context record. Use UTF-8 CSV with the header `request_id,priority,claim_or_question,item_needed,why_needed,owner_role,required_scope,required_version,status,blocking,next_action,source_ids,locator`, unless an existing compatible schema applies. Use stable `ER-0001` style request IDs and statuses `requested`, `supplied`, `unavailable` or `resolved`; supplied does not mean sufficient. Explain what staff should gather, where it may be found, the permitted content/version and what claim it enables. Before inspecting new evidence, establish that it is a permitted curriculum-only copy. Apply the intake privacy gate before extraction, registration or archive: keep actual student submissions, grades, identifiers and identifiable feedback outside the workspace, use staff roles/placeholders and request a screened copy when suitability is unclear. Inspect the retained permitted evidence, not a prohibited original. Guide the user towards the evidence that changes this module: current Courseloop/approved handbook records; verbatim subject learning outcomes (SILOs); assessment briefs, rubrics, weightings and hurdles; module sequence; delivery and session plans; intended offering and relevant current/teach-out structure; accessibility requirements; and authorised teaching sources/assets. Ask whether the program has external accreditation or professional standards, and request the applicable body, version, scope and exact requirements when these are unclear. Do not presume every program has a professional accreditor. Distinguish requirements from useful optional evidence. Quiz the user only on material uncertainty remaining after reading: for example, whether two source versions apply to different structures, what students can already do, what the module prepares them to demonstrate, or whether a standard affects the learning activity. Ask a few focused questions at a time. Record confirmed answers separately from assumptions and evidence still needed. A missing peripheral asset can stay `[to confirm]`; uncertain approved outcomes, assessment rules or module scope must be resolved before packaging. The first numeric digit in a subject code may provisionally guide relative seniority and teaching depth: higher usually suggests more senior study. Record that inference as provisional. It does not establish AQF level, formal year in a structure, cohort, prerequisites, offering or semester. Evidenced outcomes, assessment demand, prerequisites and learner context take precedence. Resolve structural membership and offering from approved records. Coordinator confirmation can identify or interpret the applicable approved record; it does not replace approval for a structural change. Courseloop and approved handbook records govern approved curriculum facts. Approved subject guides add authorised detail; LMS exports and coordinator proposals supply delivery context. Copy codes, titles, SILOs, assessment rules, weightings and hurdles verbatim. Retain conflicts for staff decision, using an existing issue register or `_registers/issues.md`; do not overwrite approved facts. Use source IDs or stable filenames and exact locators so claims can be checked. Source possession, source review, approved mapping, demonstrated achievement and offering readiness are separate claims. Keep learner records and identifying feedback out of the workspace. Use aggregate or synthetic examples, staff roles and `[name]`/`[email]` placeholders. Respect permission and copyright restrictions on supplied evidence and assets. Keep drafts distinct from approved material. ## Stage 1: retain a blueprint for review Read [design-standards.md](references/design-standards.md). Audit outcomes, assessments, teaching sequence, delivery/session patterns, sources and unresolved issues. Size the module to its actual learning purpose, expected student workload and approved scope; do not impose a universal page count or study time. Retain a versioned blueprint with: - scope: institution, course/program, subject, module, applicable structure and offering/period; mark a field not applicable only with a reason; - verbatim approved outcomes and assessment constraints, source locators and prerequisites/context; - page and activity sequence, learning purpose, estimated study time and outcome/assessment traceability; - worked examples or staged reasoning tasks appropriate to the discipline, retrieval and feedback plan; - planned files, media/accessibility alternatives, changing-fact checks, exclusions and unresolved questions; - source/version inventory, blueprint ID/version and an exact content digest, preferably SHA-256 of the retained blueprint bytes. Use [output-contract.md](references/output-contract.md) for the retained record and file conventions. Present the blueprint and material questions for explicit coordinator review. Do not approve your own design, interpret silence as approval or generate the package merely because a local approval field can be set. Retain the coordinator's explicit approval declaration, date, role, exact blueprint ID/version/digest and full scope. Link to the retained review message or decision record. A local declaration is evidence of what was recorded; it does not authenticate the person's identity or institutional authority. If no explicit approval is available, finish with the retained blueprint and the review needed. Changed blueprint content, sources that alter the design, or scope requires a new version/digest and renewed approval. ## Stage 2: draft the approved package After the gate is satisfied, read [output-contract.md](references/output-contract.md). Draft only the approved pages/tools, with the manifest, QA record and hidden staff sign-off record. Preserve recorded session blocks, their sequence and durations. Teach in connected explanations, worked examples and meaningful retrieval/decision prompts; avoid a collection of bullet summaries. Deliver finished teaching explanations, worked reasoning and question feedback within the approved scope. An HTML structure, list of headings or instructions for a future author is not a completed module. Keep genuine unknowns visible; if they prevent substantive teaching or valid feedback, report the affected component as incomplete rather than inventing it or presenting scaffolding as finished content. Read [html-templates.md](references/html-templates.md) when building disclosures or a JavaScript self-check. Content is self-contained accessible HTML. Worked problems can use native `
`/`` without JavaScript. A scored self-check uses one HTML file with inline JavaScript, a unique lowercase prefix, literal JSON question data, safe text insertion, native keyboard controls, announced feedback and complete reset. No external script/style dependency or separate `.js` output. Keep source/learning traceability, media provenance and a perishable-information register. Mark unknowns `[to confirm]` and unverified changing information `[verify against current authoritative source]`. Never claim a licence, link, current fact, browser behaviour or LMS compatibility was checked unless it was checked in this run. Record actual checks and limitations; target LMS testing remains staff work when access is unavailable. The resulting package is `Draft for coordinator review`. Blueprint approval authorises drafting the agreed package; it does not confer content sign-off, publication rights, implementation evidence or closure authority. Retain the staff sign-off file for reviewers and instruct staff to keep it hidden in the LMS; a filename alone does not hide it. Publication/upload requires the user's explicit instruction and the institution's release process. ## Optional curriculum-library integration If an existing library has a task engine, read its local methods, help and supported response schemas before using it. Use its exact schema, permitted filenames and staged commands only where they support this scope and general discipline content. Inspect rather than assume installed resources match these instructions. Do not install or copy a seed library, runtime, institutional template, personal path or sample program data to make this skill work. If the engine cannot represent a discipline-appropriate package, retain the standalone blueprint/approval/package records above and report the integration limitation. Do not bypass a required local approval control or claim a runtime has authenticated a human reviewer. If a prescribed institutional template is requested, obtain the authorised original and use the workspace's supported filling route; never create a lookalike. Proposed issue/action closure needs the workspace's independent review process; ordinary package QA does not authorise closure.