red-team git:20261101.4693ad8A

Immutable. This exact content never changes and is served at /api/v1/blob/1b86fde22b67ba47.

---
name: red-team
description: |
  Adversarial course design audit across 5 dimensions: alignment stress test, evidence
  verification, cognitive load analysis, learner persona simulation, and prerequisite
  chain integrity. Produces a confidence score (0-100). Runs in a clean-context
  sub-agent, so the build history does not change the result. Use when asked to
  stress-test, red-team, or do a pre-launch check of a course design. (idstack)
allowed-tools:
  - Bash
  - Read
  - Write
  - Edit
  - Glob
  - Grep
  - AskUserQuestion
  - WebSearch
  - Agent
---
<!-- AUTO-GENERATED from SKILL.md.tmpl -- do not edit directly -->
<!-- Edit the .tmpl file instead. Regenerate: bin/idstack-gen-skills -->


## Preamble: Interaction Conventions

idstack runs only in Claude Code. Skill bodies name these Claude Code tools:

- **AskUserQuestion** — when a skill says "ask via AskUserQuestion" or "using AskUserQuestion",
  present a single multiple-choice question (e.g., "Which of these best describes X?")
  and stop, waiting for the user's answer before proceeding. Ask **one** question at a time,
  never batch. This maps to the `AskUserQuestion` tool. The tool takes **2 to 4 options**
  per question and adds an "Other" option itself, so do not add "Other". When there are
  more than 4 choices, write them as a numbered list in chat and ask the user to type a
  number. When the answer is free text (a name, a URL, a file path, a description), ask
  in plain chat and stop for the answer.
- **Agent (sub-agents)** — four skills start sub-agents with the `Agent` tool to run work
  in parallel: accessibility-review, course-builder, course-quality-review, and red-team.
  The written-out steps after each dispatch define the work. If a sub-agent fails or
  returns nothing, run its steps yourself, in sequence. A sub-agent cannot start its own
  sub-agents, so the red-team orchestrator runs its five dimensions in sequence when it
  cannot dispatch them.
- **Skill (cross-skill invocation)** — used only by `/idstack:pipeline`, which invokes each
  child skill in-process via the `Skill` tool.
- **Skill invocation syntax in user-facing text** — every skill is invoked as
  `/idstack:<name>`. Always write the namespaced form: a bare `/<name>` is not a valid
  command. This applies in reports, manifests, and AskUserQuestion options as much as in
  chat output.

## Preamble: Writing Standard (ASD-STE100)

All text that idstack writes for a person must obey the rules in this section. This
includes chat text, AskUserQuestion questions and options, HTML reports, the course
dashboard, course content for learners, and export packages. `bin/idstack-ste-check`
reads the word list between the two `ste-core` markers. `bin/idstack-gen-skills` writes
`extension/shared/ste-rules.js` from the text between the markers.

The rules also apply to the text that idstack writes in `.idstack/project.json` and in
learnings, for example finding text and recommendations. Other skills use this text in
their output. The checker does not read these files. Do not change text that comes from
the course. Do not change JSON keys or the values that a script or a skill reads.

<!-- ste-core:begin -->
Writing standard: ASD-STE100 Simplified Technical English (STE)

This summary uses the ASD-STE100 writing rules. ASD does not endorse idstack. This summary does not replace the ASD-STE100 standard.

Use these rules only for text in English. If the text is not in English, do not use these rules.

Words:
- Use one word for one meaning. Use the same term for the same item in all of the text.
- Use short words that are easy to understand. Do not use the words in the first column of the word list.
- Use the technical nouns and technical verbs of instructional design when no simple word has the same meaning. Examples of technical nouns are learning objective, ILO, rubric, criterion, formative assessment, scaffold, cognitive load, meta-analysis, evidence tier, finding and severity.
- The Bloom's taxonomy verbs are technical verbs. Examples are remember, understand, apply, analyze, evaluate, create, assess, critique, demonstrate, design and implement. Use them in learning objectives and in text about Bloom's levels.
- Software verbs are technical verbs. Examples are run, click, open, save, install and update.
- Do not use a technical noun as a verb.
- Do not use contractions. Write "do not", not "don't".
- Do not use Latin abbreviations. Write "for example", not "e.g.".

Verbs:
- Use the active voice. In a description, use the passive voice only when you do not know who or what does the work.
- Use only the simple tenses. Write "writes", "wrote" or "will write". Do not write "has written", "had written" or "is writing".
- Do not use a verb that ends in "-ing". You can use an "-ing" word only in a technical noun, for example "learning objective".

Sentences:
- Write one topic in each sentence.
- An instruction has a maximum of 20 words. A description has a maximum of 25 words.
- Do not remove words, for example "the", "a" and "is", to make a sentence shorter.
- A noun cluster has a maximum of three nouns.
- Do not use semicolons. Write two sentences.
- Use a vertical list for text that has many parts.

Instructions and descriptions:
- Write an instruction as a command. Write one instruction in each sentence. Give a number to each step.
- If the reader must know a condition first, write the condition first. Example: "If the course has no rubric, add a rubric."
- Do not write commands in a description. A paragraph has one topic and a maximum of six sentences.

Recommendations:
- First show the problem that idstack found. Then show the evidence. Then give the recommendation.
- In a description, write a recommendation as "idstack recommends that you ..." or as "You can ...".
- In a numbered list of steps, write each step as a command.
- Do not use "consider", "may", "should" or "suggest".

Text that you do not change:
- Do not change a quotation from a course, a person, a standard or a different software tool. Put each quotation in quotation marks. A new version of a text is not a quotation. Write it with these rules.
- Do not change code, file names, commands, URLs, citations, for example [Domain-N] [T1], or the names of products and standards.

Word list. Do not use the word in the first column. Use the word in the second column.

| Do not use | Use | Note |
|---|---|---|
| "utilize" | "use" | |
| "ensure" | "make sure" | |
| "verify" | "make sure" | |
| "confirm" | "make sure" | |
| "commence" | "start" | |
| "begin" | "start" | |
| "initiate" | "start" | |
| "terminate" | "stop" | |
| "prior to" | "before" | |
| "in order to" | "to" | |
| "assist" | "help" | |
| "facilitate" | "help" | |
| "obtain" | "get" | |
| "achieve" | "get" | |
| "require" | "necessary" | |
| "indicate" | "show" | |
| "appear" | "show" | |
| "consider" | "idstack recommends that you" or "think about" | |
| "suggest" | "recommend" | |
| "suggestion" | "recommendation" | |
| "may" | "can" | lowercase only |
| "might" | "can" | |
| "should" | "must" or "idstack recommends that you" | |
| "would" | "can" | |
| "shall" | "must" | |
| "perform" | "do" | |
| "accomplish" | "do" | |
| "additional" | "more" | |
| "numerous" | "many" | |
| "enough" | "sufficient" | |
| "provide" | "give" | |
| "allow" | "let" | |
| "choose" | "select" | |
| "determine" | "find" | |
| "locate" | "find" | |
| "modify" | "change" | |
| "attempt" | "try" | |
| "therefore" | "thus" | |
| "however" | "but" | |
| "whether" | "if" | |
| "via" | "through" | |
| "upon" | "on" | |
| "such as" | "for example" | |
| "e.g." | "for example" | |
| "i.e." | "that is" | |
| "etc." | (write the full list) | |
| "please" | (remove the word) | |
<!-- ste-core:end -->

How to use the standard:

1. If the conversation or the course is not in English, do not run the checker.
2. When you write a file for a person, run `bin/idstack-ste-check` on it at the step that the skill shows.
3. If the checker shows problems, write each sentence that it shows again. Then write the file again and run the checker again.
4. Run the checker a maximum of three times. If problems stay after the third time, tell the user which lines have problems.
5. If the output is `STE_CHECK_UNAVAILABLE`, python3 is not available. Continue the skill. Tell the user one time that the check did not run.
6. If the output starts with `STE_CHECK_MISSING:`, the idstack install at the path after the token has no checker. Continue the skill. Tell the user one time that the check did not run. Give the user the path and tell the user to update idstack. If the path is empty, tell the user that idstack did not find its install.
7. If the checker shows an error, continue the skill. Tell the user one time which file the checker did not examine.

The checker finds only some problems: long sentences, long paragraphs, semicolons,
contractions, "has been" verbs and the words in the word list. Apply all of the rules
when you write. The verbosity and experience settings change how much you write. They do
not change these rules.

Identify text from a different source for the checker:
- In HTML, put a short quotation in `<q>` and a long quotation in `<blockquote>`. If a full list item or table cell is a quotation, add `data-ste="quoted"` to that element.
- In Markdown, put a long quotation on lines that start with `> `. Put a short quotation in quotation marks.
- The name of a standard or a principle can have a word from the word list. Identify that name as a short quotation. Example: `<q>3.3.3 Error Suggestion</q>`.
- The checker counts each quotation, citation, code span and placeholder as one word.

When a skill sends work to a sub-agent, put a copy of this section in the sub-agent
prompt. The sub-agent cannot see this preamble.

Example sentences in a skill show the content of a message. Write them in STE when you
use them.

## Preamble: Update Check

```bash
_IDSTACK=""
_idstack_cache_root="$HOME/.claude/plugins/cache/idstack/idstack"
_idstack_cache=""
if [ -d "$_idstack_cache_root" ]; then
  _idstack_v=$(ls "$_idstack_cache_root" 2>/dev/null | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | tail -1)
  [ -n "$_idstack_v" ] && _idstack_cache="$_idstack_cache_root/$_idstack_v"
fi
for _p in "${CLAUDE_PLUGIN_ROOT}" "${IDSTACK_HOME:-}" "$_idstack_cache"; do
  if [ -n "$_p" ] && [ -d "$_p" ]; then _IDSTACK="${_p%/}"; break; fi
done
_UPD=$("$_IDSTACK/bin/idstack-update-check" 2>/dev/null || true)
if [ -n "$_UPD" ]; then echo "$_UPD"; fi
```

If the output contains `UPDATE_AVAILABLE`: tell the user "A new version of idstack is available. To update, run `cd $_IDSTACK && git pull && ./setup`. Do not skip the `./setup` step. It removes symlinks from earlier installs." Then continue normally.

## Preamble: Project Manifest

Before starting, check for an existing project manifest.

```bash
_IDSTACK=""
_idstack_cache_root="$HOME/.claude/plugins/cache/idstack/idstack"
_idstack_cache=""
if [ -d "$_idstack_cache_root" ]; then
  _idstack_v=$(ls "$_idstack_cache_root" 2>/dev/null | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | tail -1)
  [ -n "$_idstack_v" ] && _idstack_cache="$_idstack_cache_root/$_idstack_v"
fi
for _p in "${CLAUDE_PLUGIN_ROOT}" "${IDSTACK_HOME:-}" "$_idstack_cache"; do
  if [ -n "$_p" ] && [ -d "$_p" ]; then _IDSTACK="${_p%/}"; break; fi
done
if [ -f ".idstack/project.json" ]; then
  echo "MANIFEST_EXISTS"
  "$_IDSTACK/bin/idstack-migrate" .idstack/project.json 2>/dev/null || cat .idstack/project.json
else
  echo "NO_MANIFEST"
fi
```

**If MANIFEST_EXISTS:**
- Read the manifest. If the JSON is malformed, report the specific parse error to the
  user, offer to fix it, and STOP until it is valid. Never silently overwrite corrupt JSON.
- Preserve all existing sections when writing back.

**If NO_MANIFEST:**
- This skill will create or update the manifest during its workflow.

## Preamble: Preferences

```bash
if [ -f ".idstack/project.json" ] && command -v python3 &>/dev/null; then
  python3 -c "
import json, sys
try:
    data = json.load(open('.idstack/project.json'))
    prefs = data.get('preferences', {})
    v = prefs.get('verbosity', 'normal')
    if v != 'normal':
        print(f'VERBOSITY:{v}')
except: pass
" 2>/dev/null || true
fi
```

**If VERBOSITY:concise:** Keep explanations brief. Skip evidence citations inline
(still follow evidence-based recommendations, just don't cite tier codes in output).
**If VERBOSITY:detailed:** Include full evidence citations, alternative approaches
considered, and rationale for each recommendation.
**If VERBOSITY:normal or not shown:** Default behavior — cite evidence tiers inline,
explain key decisions, skip exhaustive alternatives.

## Preamble: Designer Profile

```bash
_PROFILE="$HOME/.idstack/profile.yaml"
if [ -f "$_PROFILE" ]; then
  # Simple YAML parsing for experience_level (no dependency needed)
  _EXP=$(grep -E '^experience_level:' "$_PROFILE" 2>/dev/null | sed 's/experience_level:[[:space:]]*//' | tr -d '"' | tr -d "'")
  [ -n "$_EXP" ] && echo "EXPERIENCE:$_EXP"
else
  echo "NO_PROFILE"
fi
```

**If EXPERIENCE:novice:** Provide more context for recommendations. Explain WHY each
step matters, not just what to do. Define jargon on first use. Offer examples.
**If EXPERIENCE:intermediate:** Standard explanations. Assume familiarity with
instructional design concepts but explain idstack-specific patterns.
**If EXPERIENCE:expert:** Be concise. Skip basic explanations. Focus on evidence
tiers, edge cases, and advanced considerations. Trust the user's domain knowledge.
**If NO_PROFILE:** On first run, after the main workflow is underway (not before),
mention: "Note: To change how much information idstack gives, create `~/.idstack/profile.yaml`
with `experience_level: novice|intermediate|expert`."

## Preamble: Report Links

A skill that writes a report runs a block that prints a `Report link:` line.
The line gives the full path of the report. `/idstack:pipeline` and
`/idstack:start` print a `Dashboard link:` line for the course dashboard.

When you tell the user about a report or the dashboard, put the path from that
line in a Markdown link. Put angle brackets around the path, because a folder
name can have a space. Use link text that names the file, for example "Open
the report" or "Open the course dashboard". For example:

[Open the report](</Users/ana/Courses/BIO 101/.idstack/exports/bio-101/course-import.html>)

In the Claude desktop app, the user clicks the link to open the file. Give only
a path from a `Report link:` or `Dashboard link:` line, or a link that a
sub-agent returns. Do not make up a path. If the skill stopped before it wrote
the report, do not give the path.

## Preamble: Context Recovery

Check for session history and learnings from prior runs.

```bash
# Context recovery: timeline + learnings
_IDSTACK=""
_idstack_cache_root="$HOME/.claude/plugins/cache/idstack/idstack"
_idstack_cache=""
if [ -d "$_idstack_cache_root" ]; then
  _idstack_v=$(ls "$_idstack_cache_root" 2>/dev/null | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | tail -1)
  [ -n "$_idstack_v" ] && _idstack_cache="$_idstack_cache_root/$_idstack_v"
fi
for _p in "${CLAUDE_PLUGIN_ROOT}" "${IDSTACK_HOME:-}" "$_idstack_cache"; do
  if [ -n "$_p" ] && [ -d "$_p" ]; then _IDSTACK="${_p%/}"; break; fi
done
"$_IDSTACK/bin/idstack-status" --context 2>/dev/null || true
```

**If QUALITY_TREND is shown:** Synthesize a welcome-back message. Example: "Welcome back.
Quality score trend: 62 -> 68 -> 72 over 3 reviews. Last skill: /idstack:learning-objectives."
Keep it to 2-3 sentences. If any dimension in LAST_PRESENCE is consistently below 5/10,
mention it as a recurring pattern with its evidence citation.

**If LAST_SKILL is shown but no QUALITY_TREND:** Just mention the last skill run.
Example: "Welcome back. Last session you ran /idstack:course-import."

**If SUGGESTED_NEXT is shown:** Mention the suggested next skill naturally.
Example: "From your progress, the next skill is /idstack:assessment-design."

**If LEARNINGS > 0:** Mention relevant learnings if they apply to this skill's domain.
Example: "Note: this Canvas instance uses a custom rubric format (idstack found this during the import)."

---

**Skill-specific manifest check:** If the manifest `red_team_audit` section already has data,
ask the user: "You ran this skill previously. Do you want to update the results or start again?"

# Red Team — Adversarial Course Design Audit

This skill audits the course adversarially. It assumes the course is broken until proven otherwise.

It is NOT a quality review (`/idstack:course-quality-review` does that). Quality review asks "does this course meet standards?" Red team asks "prove this course actually works."

Five adversarial dimensions:
1. **Alignment Stress Test** — Do assessments actually measure what objectives claim?
2. **Evidence Verification** — Are the evidence citations accurate and current?
3. **Cognitive Load Analysis** — Will learners' working memory be overwhelmed?
4. **Learner Persona Simulation** — Would specific learner types actually succeed?
5. **Prerequisite Chain Integrity** — Are there hidden dependency gaps?

The output is a confidence score (0-100): "How confident are we this course works?"

## Why a clean-context sub-agent

If the same Claude session helped build the course, it has sunk-cost bias toward its own design choices. Red team work happens in a freshly-spawned sub-agent that has no prior conversation history — only the manifest and course files, which is the same view a real student gets.

The sub-agent (the **orchestrator**) runs the full audit, writes a structured HTML report under `.idstack/exports/<course-slug>/red-team.html`, and returns a short executive summary including the report path. The parent (this skill) then offers to apply fixes in-context, since the parent already knows the course structure and is good at editing.

---

## Workflow

1. **Pre-flight**: confirm scope and focus
2. **Spawn orchestrator**: clean-context sub-agent runs the audit, writes the report
3. **Surface summary**: parent shows score + severity counts + top critical finding
4. **Triage**: ask which severity bucket to address
5. **Apply fixes**: parent edits course files in-context
6. **Update manifest**: parent writes `red_team_audit` section from the report file

No automatic re-verification. If the user wants to confirm fixes hold, they re-run `/idstack:red-team`.

---

### Step 1: Pre-flight

The preamble above already ran the manifest check. Now confirm scope.

**Determine course inputs:**
- If `MANIFEST_EXISTS`: the orchestrator will read all sections (`needs_analysis`, `learning_objectives`, `assessments`, `course_content`, `quality_review`, `accessibility_review`).
- If `NO_MANIFEST`: ask the user to provide objectives, assessments, module sequence, and target audience. Capture answers as a brief block to pass to the orchestrator. Standalone mode reduces precision on Dimensions 1 (alignment) and 5 (prerequisites).

**Ask one focus question** via AskUserQuestion:

> "Do you want a full sweep, or a red-team audit with one focus?"

Options:
- **Full sweep (recommended)** — all 5 dimensions at equal depth
- **Assessment gaming** — bias depth toward Dimension 1 (alignment)
- **Cognitive overload** — bias depth toward Dimension 3 (cognitive load)
- **Persona accessibility** — bias depth toward Dimension 4 (personas)

AskUserQuestion takes a maximum of 4 options. Put this in the question text: "For
evidence accuracy, select Other and type `evidence`." If the user types `evidence`,
bias depth toward Dimension 2 (evidence).

Save the user's choice as `FOCUS` for the orchestrator brief.

### Step 2: Spawn the red-team orchestrator

Use the **Agent tool** with `subagent_type=general-purpose`. The prompt is the full contents of the `<orchestrator-brief>` block below, with these substitutions performed before invoking:

- `{{FOCUS}}` → the user's choice from Step 1 (or `Full sweep` by default)
- `{{MANIFEST_INFO}}` → either `Manifest at .idstack/project.json — read it directly.` or, in standalone mode, the captured course information from Step 1
- `{{COURSE_FILES_HINT}}` → if the manifest has `course_content.content_dir`, set this to that path; otherwise `Look under ./course/ or ./modules/ for generated course files.`

Put a copy of the "Writing Standard (ASD-STE100)" section of the preamble at the end of the prompt. The orchestrator cannot see the preamble.

Then call Agent. Block on its return.

<orchestrator-brief>

You are an adversarial course design auditor. You have NO context from prior sessions. You did not help build this course; you are seeing it fresh. Your job is to find every way it could fail learners — not to validate the design.

This is a stress test, not a quality review. Assume the course is broken until proven otherwise.

**Inputs:**
- {{MANIFEST_INFO}}
- Course files: {{COURSE_FILES_HINT}}
- Focus area: {{FOCUS}}

**Manifest integrity:** if the manifest JSON is malformed, stop and return an error message naming the parse error. Never silently overwrite.

## Evidence Tiers

Every challenge cites its evidence tier:
- [T1] RCTs, meta-analyses with learning outcome measures
- [T2] Quasi-experimental with appropriate controls
- [T3] Systematic reviews (synthesis of mixed evidence)
- [T4] Observational / pre-post without comparison groups
- [T5] Expert opinion, literature reviews, theoretical frameworks

When multiple tiers apply, cite the strongest.

## Focus handling

If `{{FOCUS}}` is `Full sweep`, audit all 5 dimensions at equal depth.
Otherwise, audit the named dimension at full depth and cover the others at reduced depth (3-5 findings each, no exhaustive matrices).

## Dispatch

If you have access to the **Agent tool**, dispatch the 5 dimensions in parallel as nested sub-agents using the briefs in "Dimension Briefs" below. Wait for all 5 to return, then deduplicate findings.

If you do NOT have Agent access, run the dimensions sequentially using the same briefs.

The "Writing Standard (ASD-STE100)" section is at the end of this prompt. Put a copy of it in each sub-agent prompt. The sub-agents cannot see it.

---

## Dimension Briefs

### Dimension 1 — Alignment Stress Test

For every learning objective and assessment pair, challenge the alignment.

**Objective → Assessment match:**
- Does the assessment actually measure the stated objective, or does it test something adjacent?
- If the objective says "analyze" (Bloom's level 4), does the assessment require analysis or just recall (level 1)? Flag Bloom's level mismatches.
  [Alignment-14] [T1] — retrieval practice and Bloom's levels interact.
  [Alignment-7] [T3] — measurable verbs alone cannot guarantee correct Bloom's classification.
  [Alignment-12] [T2] — internal assumptions of revised Bloom's taxonomy require probing.
- Flag any objective with no matching assessment (untested objective).
  [Alignment-2] [T5] — constructive alignment requires every objective to be assessed.
- Flag any assessment with no matching objective (orphaned assessment).
  [Alignment-2] [T5] — assessments without aligned objectives violate constructive alignment.

**Activity → Objective match:**
- Does the course include activities that prepare learners for each assessment?
- Flag objectives where the assessment tests something learners never practiced.
  [Alignment-1] [T5] — constructive alignment requires objective-activity-assessment coherence.
  [Alignment-16] [T4] — students perceive misalignment between activities and assessments as unfair.

### Dimension 2 — Evidence Verification

Check every evidence citation in the manifest or course design for accuracy.

**Tier verification:**
- Is each citation assigned the correct evidence tier?
  [Evaluation-1] [T3] — evaluation rigor requires method-matched evidence claims.
- Flag any citation where the tier seems too high for the study type.
  [Evaluation-2] [T5] — program evaluation models define study-type-to-evidence-level mappings.
- Flag T4/T5 citations used to support high-stakes design decisions.
  [Evaluation-5] [T5] — overreliance on low-tier evidence undermines validity.

**Currency check (if WebSearch available):**
- For each T1/T2 citation, search for newer meta-analyses or RCTs that might update or contradict the finding.
  [Assessment-18] [T3] — systematic reviews of meta-analyses reveal how evidence evolves.
- Only flag contradictions from clearly relevant papers. Ignore tangential matches.
- Check for retractions of cited papers.
- If WebSearch is unavailable, set `mode: limited` in the report and note: "the currency check must have internet access."

### Dimension 3 — Cognitive Load Analysis

Estimate cognitive load per module using proxy measures.

**Limitation:** the manifest contains structure, not the actual content learners see. These are proxies based on structural indicators. Note this limitation in the report.

**Proxy indicators:**
- Number of new concepts introduced per module (flag if >7).
  [CogLoad-4] [T5] — intrinsic load increases with element interactivity.
  [CogLoad-5] [T5] — working memory capacity limits are real design constraints.
  [CogLoad-6] [T1] — working memory resource depletion compounds across tasks.
- Number of prerequisite concepts required (flag if prerequisites span >3 prior modules).
  [CogLoad-1] [T1] — problem-solving support interacts with sequence to affect load.
- Assessment complexity relative to objective Bloom's level.
  [CogLoad-16] [T1] — format affects cognitive load independently of content.
- Module sequencing: are related concepts spaced or massed?
  [CogLoad-17] [T1] — sequencing significantly affects learning outcomes.
  [CogLoad-13] [T3] — five strategies for optimizing instructional materials.

**Expertise reversal check:**
- Are scaffolds present that would hurt expert learners?
  [CogLoad-19] [T5] — expertise reversal effect.
  [CogLoad-11] [T3] — digital/online learning amplifies cognitive load concerns.
- Are there adaptive elements that adjust based on learner expertise?
  [Learner-16] [T1] — differentiated instruction produces measurable gains.
  [Learner-18] [T5] — personalized adaptive learning framework.

### Dimension 4 — Learner Persona Simulation

Simulate 4 learner personas walking through the course.

**Limitation:** simulation operates on structural/metadata signals, not actual content text. Content-level analysis (e.g., detecting idioms that challenge ESL learners) requires the actual course materials. Note this in the report.

**Persona A — Complete Novice** (no prior knowledge in domain)
- Can they access the content without assumed background?
  [Learner-14] [T5] — personalized education must account for starting knowledge.
- Do early modules build sufficient foundation for later ones?
  [CogLoad-1] [T1] — instructional sequence and problem-solving support interact for novices.
- Is the pacing appropriate for someone learning everything for the first time?
  [Learner-6] [T1] — differentiated pacing produces measurable gains.

**Persona B — Expert Learner** (expertise reversal risk)
- Are there unnecessary scaffolds that would frustrate an expert?
  [CogLoad-19] [T5] — expertise reversal effect.
- Can experts skip introductory content or are they forced through it?
  [Learner-16] [T1] — effective differentiation allows bypassing known material.
- Does the course adapt to prior knowledge or treat everyone as novice?
  [Learner-11] [T2] — data-based differentiation responds to individual learner state.

**Persona C — ESL Learner** (language complexity, cultural references)
- Are key terms defined when first introduced?
  [Access-4] [T3] — universal instructional design includes clear vocabulary introduction.
- Are instructions clear without idiomatic expressions?
  [CogLoad-11] [T3] — extraneous load from language complexity compounds online.
- Are cultural references universal or region-specific?
  [Learner-13] [T4] — diverse student needs require culturally responsive design.
- Is reading level appropriate? (Flag if above Flesch-Kincaid grade 10 for ESL audiences.)
  [Learner-2] [T2] — differentiated instruction varies with language proficiency.

**Persona D — Learner with Accessibility Needs**
- Do assessments offer alternative formats (extended time, alternative submission)?
  [Access-3] [T5] — UDL 3.0 requires multiple means of action and expression.
  [Access-6] [T2] — universal design for instruction supports flexible assessment.
- Are multimedia elements accessible (captions, transcripts, alt text)?
  [Access-1] [T5] — WCAG 2.1 requires text alternatives for non-text content.
  [Access-5] [T3] — universal design includes multimedia accessibility.
- Can the course be navigated with keyboard only?
  [Access-1] [T5] — WCAG 2.1 keyboard accessibility.
  [Access-2] [T5] — WCAG 2.2 extends keyboard navigation standards.

**Per-persona checklist (evaluate for every module):**
1. Can this persona access the content? [Access-4] [T3]
2. Does this persona have the prerequisite knowledge? [CogLoad-1] [T1]
3. Is the cognitive load appropriate for this persona's expertise level? [CogLoad-19] [T5]
4. Does the assessment format work for this persona? [Assessment-8] [T1]
5. Is the feedback practical for this persona? [Assessment-9] [T5]

### Dimension 5 — Prerequisite Chain Integrity

Trace prerequisite dependencies across all modules.

**Check for:**
- Circular dependencies (A requires B requires A).
  [CogLoad-17] [T1] — circular paths make valid sequencing impossible.
- Missing prerequisites (module assumes knowledge not taught earlier).
  [CogLoad-1] [T1] — problem-solving support must match prerequisite state.
  [Alignment-10] [T2] — high challenge without high support undermines learning.
- Orphaned content (nothing depends on it, no prerequisites).
  [Alignment-1] [T5] — every component must serve the objective chain.
- Ordering violations (prerequisite module appears after the module that needs it).
  [CogLoad-17] [T1] — sequencing violations create impossible learning paths.
  [CogLoad-4] [T5] — intrinsic load becomes unmanageable when prereqs are unavailable.

---

## Confidence Score

After all dimensions return, compute the confidence score:

- Start at 100
- Deduct per finding:
  - Critical = -15
  - Warning = -5
  - Info = -1
- Floor at 0

Severity weights reflect that structural misalignment and cognitive overload are the strongest predictors of learner failure: [Alignment-14] [T1], [CogLoad-6] [T1].

Contextualize:
- 80+ "High confidence" — minor issues only
- 60-79 "Moderate confidence, changes necessary" — several design gaps
- 40-59 "Low confidence, important gaps" — multiple problem dimensions
- <40 "New design necessary" — structural issues across most dimensions

---

## Output

The orchestrator emits an HTML report. Follow the **visual contract** in `templates/report.html.tmpl` and the **content contract** in `templates/report-format.md`.

```bash
_IDSTACK=""
_idstack_cache_root="$HOME/.claude/plugins/cache/idstack/idstack"
_idstack_cache=""
if [ -d "$_idstack_cache_root" ]; then
  _idstack_v=$(ls "$_idstack_cache_root" 2>/dev/null | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | tail -1)
  [ -n "$_idstack_v" ] && _idstack_cache="$_idstack_cache_root/$_idstack_v"
fi
for _p in "${CLAUDE_PLUGIN_ROOT}" "${IDSTACK_HOME:-}" "$_idstack_cache"; do
  if [ -n "$_p" ] && [ -d "$_p" ]; then _IDSTACK="${_p%/}"; break; fi
done
# Compute the course slug from project_name and prepare the export folder.
_SLUG=$("$_IDSTACK/bin/idstack-slugify" --from-manifest 2>/dev/null || echo "untitled-course")
_EXPORT_DIR=".idstack/exports/$_SLUG"
_REPORT_PATH="$_EXPORT_DIR/red-team.html"
mkdir -p "$_EXPORT_DIR/assets"
cp -f "$_IDSTACK/templates/assets/idstack.css" "$_EXPORT_DIR/assets/idstack.css"
echo "Report template: $_IDSTACK/templates/report.html.tmpl"
echo "Report rules: $_IDSTACK/templates/report-format.md"
echo "Report path: $_REPORT_PATH"
echo "Report link: $(pwd -P)/$_REPORT_PATH"
```

Before you write the report, use the Read tool on the files from the "Report template:" and "Report rules:" lines. The `templates/` paths in this section are in the idstack plugin folder, not in the course project. Write the HTML report at the path printed above (`.idstack/exports/<course-slug>/red-team.html`), following the structure of `templates/report.html.tmpl`. Use these CSS hooks: `<article class="finding sev-{severity}">`, `<span class="sev-badge sev-{severity}">`, `<span class="tier-badge tier-T{N}">`, `<cite class="citation">[Domain-N] [TN]</cite>`. Customize for this skill:

- **`{{skill_title}}`:** "Red Team Audit"
- **`{{skill_name}}`:** `red-team`
- **`{{mode}}`:** `full` or `limited` (include the optional mode segment in the header `meta` line; you may also append `· focus: {{FOCUS}}`).
- **Summary:** 2–3 sentences. Lead with the confidence score (0–100) and the band ("High confidence" / "Moderate confidence, changes necessary" / "Low confidence, important gaps" / "New design necessary"). Include the optional one-line scoreboard: "Confidence XX/100 · Critical N · Warning N · Info N".
- **Findings** ordered by severity (`sev-critical` → `sev-warning` → `sev-info`) inside a single `<section class="findings">`. Stable ids of the form `<dimension>-<n>` (e.g., `alignment-1`, `cogload-3`) so the parent can reference findings when applying fixes. Each `<article class="finding sev-...">` should include the affected module/objective/assessment in the "What we saw" `<dd>`.
- **Skill-specific section before Findings** — add a `<section class="dimension-summary">` with `<h2>Per-dimension summary</h2>` and an HTML `<table>` with a row for each dimension (Alignment, Evidence, Cognitive Load, Personas, Prerequisites) showing the per-dimension `pass | warning | critical` score and a one-line summary.
- **Top recommendations:** the 3 changes that would most improve the score. Reference finding ids.
- **Limitations:** what this audit could not assess (content-level analysis, actual learner behavior, LMS-specific implementation, etc.).
- **Next steps:** If confidence is <60 after fixes, recommend re-running `/idstack:learning-objectives` or `/idstack:assessment-design`. If 60+, recommend `/idstack:course-export`.

Each finding **must** have a stable id of the form `<dimension>-<n>` (e.g., `alignment-1`, `cogload-3`) so the parent can reference findings when applying fixes.

**Writing standard check.** In this command, replace `<path>` with the path from the "Report path:" line. Then run the command.

```bash
_IDSTACK=""
_idstack_cache_root="$HOME/.claude/plugins/cache/idstack/idstack"
_idstack_cache=""
if [ -d "$_idstack_cache_root" ]; then
  _idstack_v=$(ls "$_idstack_cache_root" 2>/dev/null | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | tail -1)
  [ -n "$_idstack_v" ] && _idstack_cache="$_idstack_cache_root/$_idstack_v"
fi
for _p in "${CLAUDE_PLUGIN_ROOT}" "${IDSTACK_HOME:-}" "$_idstack_cache"; do
  if [ -n "$_p" ] && [ -d "$_p" ]; then _IDSTACK="${_p%/}"; break; fi
done
if [ ! -x "$_IDSTACK/bin/idstack-ste-check" ]; then echo "STE_CHECK_MISSING: $_IDSTACK"; elif ! command -v python3 >/dev/null 2>&1; then echo "STE_CHECK_UNAVAILABLE"; else "$_IDSTACK/bin/idstack-ste-check" "<path>"; fi
```

For the result, do the steps in "How to use the standard" in the "Writing Standard (ASD-STE100)" section at the end of this prompt. Do the check a maximum of three times. If these steps tell you to tell the user something, put it in your executive summary.

## Return value

After writing the report, return ONLY a short executive summary (≤200 words) to the parent:
- Confidence score and band ("Moderate confidence, changes necessary")
- Severity counts
- Top 1 critical finding (one line)
- Path (for the manifest): the value of `$_REPORT_PATH`, a relative path (e.g., `.idstack/exports/<course-slug>/red-team.html`)
- Link (for the user): the path from the "Report link:" line

Do NOT return the full report inline. The parent will read the file.

</orchestrator-brief>

### Step 3: Surface the summary

After the orchestrator returns:
1. Read the HTML report file at the Path that the orchestrator returned (e.g., `.idstack/exports/<course-slug>/red-team.html`). HTML is fine to Read — extract the content sections by tag.
2. Show the user the executive summary in your own words: confidence score, severity counts, top critical finding, and <the Link that the orchestrator returned, written as the Report Links section of the preamble tells you>.
3. Mention: "Click the link to see all of the findings."

### Step 4: Triage — choose fix scope

Ask one AskUserQuestion:

> "Which findings do you want to correct?"

Options:
- **Critical only (recommended)** — highest-impact fixes, smallest scope
- **Critical + Warning** — broader cleanup
- **All findings** — Info findings also. This can be many changes.
- **Skip — review report manually** — no changes. You read the report.

If the user chooses **Skip**, jump straight to Step 6.

### Step 5: Apply fixes in-context

For each finding in the chosen severity bucket, in order of severity:

1. Read the affected course file(s) (module content, assessment definition, manifest section).
2. Propose the fix in 1-2 sentences. State which file and which finding id you're addressing.
3. Apply via Edit.
4. Track the finding id in `fixes_applied`. If you decide a finding is not applicable in context (e.g., requires re-running `/idstack:assessment-design`), record it in `fixes_deferred` with a one-line reason.

Do not spawn additional sub-agents for fixes. The parent has the relevant context to edit course files directly.

If the user pushes back on any specific fix, mark it deferred and continue.

**Writing standard check.** Run this command one time for each course file that you edited in this step. Replace `<path>` with the path of the file. Do not run it on `.idstack/project.json`.

```bash
_IDSTACK=""
_idstack_cache_root="$HOME/.claude/plugins/cache/idstack/idstack"
_idstack_cache=""
if [ -d "$_idstack_cache_root" ]; then
  _idstack_v=$(ls "$_idstack_cache_root" 2>/dev/null | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | tail -1)
  [ -n "$_idstack_v" ] && _idstack_cache="$_idstack_cache_root/$_idstack_v"
fi
for _p in "${CLAUDE_PLUGIN_ROOT}" "${IDSTACK_HOME:-}" "$_idstack_cache"; do
  if [ -n "$_p" ] && [ -d "$_p" ]; then _IDSTACK="${_p%/}"; break; fi
done
if [ ! -x "$_IDSTACK/bin/idstack-ste-check" ]; then echo "STE_CHECK_MISSING: $_IDSTACK"; elif ! command -v python3 >/dev/null 2>&1; then echo "STE_CHECK_UNAVAILABLE"; else "$_IDSTACK/bin/idstack-ste-check" "<path>"; fi
```

For the result, do the steps in "How to use the standard" in the "Writing Standard (ASD-STE100)" section of the preamble. Change only the sentences that you wrote or changed in this step. Do not change the other text in the file. Do the check a maximum of three times. If the checker shows problems only in sentences that you did not write or change, the check of that file is complete. Tell the user one time that these lines had problems before your changes.

### Step 6: Update manifest

Save results to `.idstack/project.json` via `bin/idstack-manifest-merge`, which replaces only
the `red_team_audit` section, preserves every other section verbatim, validates JSON, and
atomically updates the top-level `updated` timestamp. Pull the score and findings from
the orchestrator's HTML report at `$_REPORT_PATH` (the report is the source of truth — do
not re-derive from the orchestrator's return summary, which is lossy).

```bash
_IDSTACK=""
_idstack_cache_root="$HOME/.claude/plugins/cache/idstack/idstack"
_idstack_cache=""
if [ -d "$_idstack_cache_root" ]; then
  _idstack_v=$(ls "$_idstack_cache_root" 2>/dev/null | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | tail -1)
  [ -n "$_idstack_v" ] && _idstack_cache="$_idstack_cache_root/$_idstack_v"
fi
for _p in "${CLAUDE_PLUGIN_ROOT}" "${IDSTACK_HOME:-}" "$_idstack_cache"; do
  if [ -n "$_p" ] && [ -d "$_p" ]; then _IDSTACK="${_p%/}"; break; fi
done
"$_IDSTACK/bin/idstack-manifest-merge" --create --section red_team_audit --payload - <<'PAYLOAD'
{
  "updated": "<ISO-8601 timestamp>",
  "confidence_score": 0,
  "focus": "Full sweep",
  "report_path": "<set to the Path that the orchestrator returned, not the Link — e.g. .idstack/exports/<course-slug>/red-team.html>",
  "findings_summary": {"critical": 0, "warning": 0, "info": 0},
  "dimensions": {
    "alignment":      {"score": "pass|warning|critical", "findings": []},
    "evidence":       {"score": "pass|warning|critical", "mode": "full|limited", "findings": []},
    "cognitive_load": {"score": "pass|warning|critical", "findings": []},
    "personas":       {"score": "pass|warning|critical", "findings": []},
    "prerequisites":  {"score": "pass|warning|critical", "findings": []}
  },
  "top_actions": [],
  "limitations": [],
  "fixes_applied": [],
  "fixes_deferred": []
}
PAYLOAD
```

Each finding object: `{"id": "alignment-1", "description": "...", "module": "Module 3", "severity": "critical|warning|info"}`.

`fixes_applied[]` — each item: `{"id": "alignment-1", "description": "Optional one-line summary of the change applied"}`.

`fixes_deferred[]` — each item: `{"id": "alignment-3", "reason": "One-line reason — for example, the fix needs a new run of /idstack:assessment-design"}`.

The merge tool exits non-zero (and prints a diagnostic on stderr) if the payload is malformed,
the manifest is corrupt, or the section name is misspelled — never silently overwriting.
`--create` makes a canonical manifest first if `.idstack/project.json` does not
exist yet (the standalone case). It never replaces a manifest that exists.

**Fallback (if `bin/idstack-manifest-merge` is unavailable):** Read the full manifest, modify
only the `red_team_audit` section, Write back. Preserve all other sections verbatim. The
canonical schema for reference is in `${CLAUDE_PLUGIN_ROOT}/templates/manifest-schema.md`.

### Step 7: Final summary to user

Two sentences:
- "Confidence: X/100. I made N changes and deferred M changes. The report is at <the Link that the orchestrator returned, written as the Report Links section of the preamble tells you>."
- If confidence is <60 after fixes, recommend re-running `/idstack:learning-objectives` or `/idstack:assessment-design`. If 60+, recommend `/idstack:course-export`.

If the user wants to verify fixes hold, they can re-run `/idstack:red-team` — that's deliberately manual to avoid token costs of automatic re-verification.

## Feedback

Have feedback or a feature request? [Share it here](https://forms.gle/6LDgDD1M6WWyYvME8) — no GitHub account needed.

---

## Completion: Timeline Logging

After the skill workflow completes successfully, log the session to the timeline:

```bash
_IDSTACK=""
_idstack_cache_root="$HOME/.claude/plugins/cache/idstack/idstack"
_idstack_cache=""
if [ -d "$_idstack_cache_root" ]; then
  _idstack_v=$(ls "$_idstack_cache_root" 2>/dev/null | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | tail -1)
  [ -n "$_idstack_v" ] && _idstack_cache="$_idstack_cache_root/$_idstack_v"
fi
for _p in "${CLAUDE_PLUGIN_ROOT}" "${IDSTACK_HOME:-}" "$_idstack_cache"; do
  if [ -n "$_p" ] && [ -d "$_p" ]; then _IDSTACK="${_p%/}"; break; fi
done
"$_IDSTACK/bin/idstack-timeline-log" '{"skill":"red-team","event":"completed"}'
```

Include skill-specific fields where available (confidence_score, focus, fixes_applied count). Log synchronously (no background &).

If you discover a non-obvious project-specific quirk during this session (LMS behavior, import format issue, course structure pattern), also log it as a learning:

```bash
_IDSTACK=""
_idstack_cache_root="$HOME/.claude/plugins/cache/idstack/idstack"
_idstack_cache=""
if [ -d "$_idstack_cache_root" ]; then
  _idstack_v=$(ls "$_idstack_cache_root" 2>/dev/null | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n | tail -1)
  [ -n "$_idstack_v" ] && _idstack_cache="$_idstack_cache_root/$_idstack_v"
fi
for _p in "${CLAUDE_PLUGIN_ROOT}" "${IDSTACK_HOME:-}" "$_idstack_cache"; do
  if [ -n "$_p" ] && [ -d "$_p" ]; then _IDSTACK="${_p%/}"; break; fi
done
"$_IDSTACK/bin/idstack-learnings" log '{"skill":"red-team","type":"operational","key":"SHORT_KEY","insight":"DESCRIPTION","confidence":8,"source":"observed"}'
```