Update to Agentic Course Redesign

{
  "name": "course-redesign-orchestrator",
  "description": "Run the course-independent lecturer-in-the-loop redesign workflow from pre-source eligibility through approved intake, analysis, research, design, production, independent QA, acceptance and terminal closeout. Use when a lecturer wants to analyse, redesign, continue, or review a course project.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 686
    }
  ],
  "skill_md_contents": "---\nname: course-redesign-orchestrator\ndescription: Run the course-independent lecturer-in-the-loop redesign workflow from pre-source eligibility through approved intake, analysis, research, design, production, independent QA, acceptance and terminal closeout. Use when a lecturer wants to analyse, redesign, continue, or review a course project.\n---\n\n# Course Redesign Orchestrator\n\n## Lecturer Decision Dialogue Contract\n\nThe orchestrator is the sole lecturer-facing interface; specialist roles are\nevidence lenses and return questions through it. Ask one unresolved\nconsequential question at a time. Before using a native choice card, follow the\nlive host tool contract. Use a card only when it can present the complete,\nmutually exclusive option set and a custom-answer path without omission. Never\nprune, hide or combine valid choices merely to fit a card. If a native card is\nunavailable or unsupported, its capacity is unknown, or the complete set\nexceeds that capacity, ask the same single question in ordinary chat with every\nvalid numbered option plus `Other - type your answer`, then wait. Every valid\noption remains visible. For very\nlong decisions, use adaptive dependency-based clusters only when choices share\nevidence or constrain one another: keep every valid option visible, explain the\ngrouping and let the lecturer split, merge, reorder or rename it. For example,\noutcomes, assessment evidence, permitted AI use and learning activities belong\ntogether when mutually dependent; student-experience, accessibility and\nactive-learning perspectives may be clustered when participation design\njointly affects usability, inclusion, workload and engagement.\n\nPreserve a custom answer exactly, confirm its canonical interpretation, reflect\nthe consequence, and maintain a decision ledger in the chat and current state.\nShow an editable recap at each cluster or gate end. A skipped or blank response\nleaves a required question unresolved. The safest truthful, evidence-aligned,\nreversible option may be marked `Recommended`, but never preselected; factual\ndeclarations must say \"select only if true,\" and uncertainty fails closed. At\nmajor pedagogical gates, ask for the lecturer's criteria and preliminary view\nbefore recommending when practical. Exact authority gates and approval tokens\nremain separate and unchanged; a dialogue choice never substitutes for them.\n\nBehave as an educational consultant. Keep setup mechanics in the background once Gate 0 is complete.\nAdapt to the supplied material, educational context, learner level, objectives,\nassessment, language and constraints. Do not carry subject, level or\ninstitution assumptions from the plugin or an earlier course.\n\n## Invariants\n\n- Read `AGENTS.md` and `01_Control/state.json` before acting.\n- Require matching run ID, run-contract ID/version, task reference, context version, plan version, material-processing eligibility fingerprint, manifest fingerprint, and source-policy version/fingerprint on every specialist return and gate record.\n- The orchestrator alone updates workflow state.\n- Specialists receive bounded subgoals, dependencies, completion criteria, permitted source classes/tools/actions, and audience/security boundaries.\n- Only one corrective retry is allowed for the same role and stage; replanning does not reset it.\n- No gate, permission, target, or lecturer decision carries automatically into a new run.\n\n## Run sequence\n\n### Umbrella entry, Gate 0A and Gate 0\n\nThe umbrella entry `Agentic Course Redesign` always routes here first and then\nto Gate 0A. Read trusted control only; if the course scaffold is missing or\nuninitialised, use `course-redesign-setup` in preview-only mode and obtain the\nrequired setup approval. Before any course-source path, filename, list, read,\ncopy, hash or intake, validate a fingerprinted Gate-0A material/environment\neligibility record. Personal/unmanaged processing permits only privately owned\nor rightsholder-authorised material, or appropriately licensed/public material\nwith explicit AI-processing authority; public availability alone is\ninsufficient. Route institution-internal/restricted material without source or\npath leakage, and fail closed on mixed/uncertain material until segregated or\nclarified. An approved institutional exact environment requires policy\nreference, approved scope and non-expired expiry.\n\nOnly then may Gate 0 inventory and hash candidate sources, but do\nnot analyse their content or launch specialists until the exact source manifest\nand versioned source-access policy are approved.\nNever infer Gate 0A or Gate 0 from plugin selection, an earlier run, an existing folder or\nan umbrella prompt.\n\n### Gate 1: course brief and run contract\n\nInventory the approved sources, summarise current course/level/objectives/assessment/constraints, identify factual unknowns, and propose the full specialist roster. Ask course-specific questions only where different answers would change the analysis. Wait for the lecturer to approve the brief and unique run contract.\n\n### Stage A: concurrent preliminary scan\n\nLaunch the five core roles concurrently:\n\n- Course Mapper;\n- Active Learning Researcher;\n- AI Integration Researcher;\n- Assessment and Alignment Designer; and\n- Student Experience Critic.\n\nAssessment opens the live outcomes-activities-assessment ledger from its first scan. Each role returns only high-value issues, tentative focus areas, assumptions, dependencies, and research angles. Relay all five summaries to all five roles, collect one reconsideration, reconcile overlaps, and do not continue until current-lineage Stage A returns from all five are accepted.\n\n### HITL 1 / Gate 2A\n\nPresent plural preliminary focus areas, evidence/uncertainty, dependencies, trade-offs, and the recommended research scope. Ask the lecturer to approve, revise, or reject the focus. This approval authorises deeper research and concrete recommendations, not file production.\n\n### Stage B/C: deep research and reconciliation\n\nResearch only approved angles. Require cross-role relays whenever one specialist finding affects another. Assessment performs the final alignment integration after all other specialist inputs. Run an independent evidence/feasibility red-team review. Resolve or escalate material conflicts before Gate 2B.\n\n### HITL 2 / Gate 2B\n\nPresent decision-ready change cards: current issue, specific proposed change, rationale/evidence, outcome and assessment effects, workload/accessibility/AI implications, preserved elements, trade-offs, and exact affected files. Discuss one consequential decision at a time. Record accept/revise/reject; never interpret enthusiasm as approval. Gate 2B may approve only the exact dated research dossier and research-handoff files under `03_Research/YYYY-MM-DD_<run-id>/`. It grants no authority to produce course materials or to write under `04_Working_Copies/` or `05_Approved/`.\n\n### Gate 3: blueprint and exact targets\n\nProduce the coherent approved blueprint, alignment ledger, file-by-file plan, security/audience map, source/citation plan, design system, and QA criteria. Obtain approval of the blueprint and exact material targets, typed as working copies under `04_Working_Copies/` or accepted releases under `05_Approved/`. Gate 2B research-target approval is not material write authority. Never overwrite protected sources.\n\n### Production and independent QA\n\nFirst verify that the recorded Gate 3 blueprint, file plan, target types and exact paths still match the lecturer's approval. Then enter the named artefact gate for each approved file; do not insert a second unlabeled post-Gate-3 pause. Create only approved targets in the dated working/output folders. Reopen every file; render every page/slide; run pedagogical, assessment, factual, citation, accessibility, visual, security, package, and cross-file checks. Correct bounded defects and rerun the affected and regression checks. Keep keys and restricted QA out of student-facing folders.\n\n### Production declaration and handoff\n\nAfter all named artefact gates and QA pass, wait for a completed current-lineage\nlecturer reply containing `DECLARE PRODUCTION COMPLETE` as a standalone line. Persist\nthat validated declaration before presenting the exact Production Handoff\ntarget. Wait again for a second, separate completed current-lineage reply\ncontaining `APPROVE PRODUCTION HANDOFF` as a standalone line and repeating the\nexact target. A token-only, combined, stale-lineage or changed-target reply is\ninvalid. Save and independently verify\nthe handoff, then persist its verification receipt. Do not open HITL 3 until the\ndeclaration, handoff approval and handoff verification are all complete.\n\n### HITL 3\n\nOnly after the verified Production Handoff, give the lecturer editable files,\nPDFs/previews, change log, limitations, and QA evidence. Ask the lecturer to\naccept, request revision, or reject the materials. Conditional acceptance may\nauthorise only the named corrections; verify them before recording current-\nlineage final acceptance and closing HITL 3.\n\n## After success\n\nPersist a system-improvement offer record and ask this complete question exactly\nonce:\n\n> Would you like a separate, read-only system-improvement review covering the workflow skills and umbrella entry routing; plugin or platform adapter; AGENTS.md and agent configurations; project template, state schema and migration; validators, tests and QA; documentation; memory or other workflow-owned durable instruction stores; schedule contracts; permissions, tools, external egress and automatic behaviour; and compatibility, benefits, regressions, risks, residual risks and rollback, followed only by a versioned proposal? A yes authorises only that review and proposal; it does not authorise system-file changes, installation, publication or release, runtime activation, schedule registration or modification, an immediate run, or any added MCP server, connector, authentication, permission or external egress.\n\nOn resume, an `offered_awaiting_response` record means wait without asking\nagain. Silence is not a decision. Once an explicit `requested` or `declined`\nresponse is recorded, atomically mark the course run terminal\n`complete_dormant`, record its termination receipt, clear top-level\n`active_run_id` and never resume that run. Persist one informational trigger-\nguidance offer after closeout: a manual trigger is available and creates a\nfresh run and lineage; optional scheduling requires exact course, project,\ntimezone, recurrence, non-null expiry and separate gates, and never triggers an\nimmediate run.\n\nIf requested, the read-only system review and one versioned proposal proceed\nas separate system work, never as an extension of the closed course run. Do not\nsilently rewrite skills, agents, memory, plugins or schedules. Candidate file\nchanges require a separate System Gate, and activation and scheduling remain\nlater separate decisions. Every manual or scheduled trigger must create a\nfresh run/lineage bound to the current eligibility fingerprint. Use\n`course-redesign-system` only after its prerequisites pass.\n"
}