Course Skills

The most expensive mistake in a sprint is confidently building the wrong thing. /think is a forcing function — it makes you restate the problem in your own words, list the assumptions you're making, and identify what you don't know before you commit to an approach.

In security work this matters more than most domains. A threat model built on a wrong assumption doesn't just waste time — it creates false confidence. An incident response tool designed for the wrong attacker profile misses the actual threat. /think makes the assumptions visible so you can challenge them before they're baked into code.

The updated skill ends with a Harness Audit: three questions you answer before moving to /build-spec. What guardrails does this work need? What constraints already exist (tests, linters, CI gates)? What is the verification strategy — and if you can't name a specific check, you can't delegate this work to an agent yet. Think of this phase as the manager handing off to a capable but context-less contractor.

Claude is an exceptional builder — but it builds what you describe, not what you meant. Without a spec, "build a vulnerability scanner" produces something. With a spec, it produces the right something: the right agents, the right tools, the right data flow, with security controls defined before the first line of code.

The updated skill now requires two things that most specs omit. First: anti-requirements — an explicit list of what the agent must NOT do (don't touch this module, don't add dependencies, don't refactor outside scope). Every ambiguity you leave in the spec is a decision the agent makes without you. Anti-requirements shrink that space. Second: verifiable acceptance criteria — observable checks, not prose. "The API returns 200 with a valid token" is a criterion. "Authentication should work" is a wish.

The spec is also your scope enforcer. Sprint labs give you 60 minutes to build. Without a written scope, every new idea that surfaces during the build phase looks reasonable to add. The spec gives you something to point to: "That's not in scope — deferred to next sprint." This is not a constraint — it's what lets you finish.

In a team context, the spec is the shared contract. If two people are building different components in parallel worktrees, the spec is what keeps them compatible. If you're using Claude Code to build one component and doing another yourself, the spec is what keeps you aligned with your own work.

The skill also forces a cost optimization verdict per component: caching (does this component send repeated stable context?), batching (does it require real-time response, or can it run async for a 50% token discount?), and model match (is the assigned model the cheapest that meets the quality bar, or does it need a Stage 0 trial at the next tier down?). Cost becomes a design constraint at spec time — not a billing surprise at the end of a sprint.

Git worktrees let you check out multiple branches simultaneously into separate directories. In a sprint with three components — say a triage agent, an enrichment agent, and a reporting layer — you don't have to build them sequentially. Each lives in its own directory, on its own branch, and can be developed (or delegated to a separate Claude Code session) in parallel.

This is how the sprint's 60-minute build phase stays achievable. Sequential builds of three components would require 60 minutes each. Parallel worktrees compress that into the time of the longest single component.

It also keeps your main branch clean. Nothing gets merged until a component is complete and passing. If one component hits a dead end, you abandon that worktree without touching anything else. The /worktree-setup skill generates the exact shell commands for your specific spec — you don't have to remember the git worktree syntax, and every component gets consistent structure from the start.

The updated skill configures two harness elements in each worktree: pre-commit hooks (linting, type checks, fast unit tests that run during agent execution, not after you review) and output suppression (pytest configured to surface only failures — passing tests rot the context window and distract the agent). These constraints make correct behavior the easy path before code ever reaches review.

Note: Worktree management via /worktree-setup is a Claude Code skill — it works in Claude Code sessions. The underlying git worktree commands work in any terminal or IDE, but the skill automation is Claude Code-specific.

AI-generated code has predictable failure modes. Claude prioritizes "never crash" over "fail informatively," producing silent error swallowing. It generates happy-path loops with no termination guards, module-level global state that races under concurrency, and eval()-based dispatch that becomes RCE when an attacker controls the input. These patterns look correct in isolation — they pass code review, they pass unit tests — and then they fail silently in production or get exploited in a red team exercise.

The skill audits four layers in order: L1 Code Quality (silent errors, unbounded loops, missing assertions, naive retry), L2 Architecture (connection pools, idempotency, unbounded collections, global state in tool scope), L3 Operations (structured logging, correlation IDs, health checks, graceful shutdown), and L4 Security (timing attacks, log injection, input bounds, secret rotation, eval/exec, audit trail gaps). Each layer has grep-detectable checks and code analysis checks. Findings are classified CRITICAL / HIGH / MEDIUM / LOW. CRITICAL findings block deployment.

The skill was built from the Power of 10 rules (Holzmann, NASA/JPL) adapted for Python agent code: fixed loop bounds (R2), assertion density (R5), smallest possible scope (R6), and restricted metaprogramming (R8) map directly to the four patterns most likely to cause failures in production agentic systems.

Run it before the red team finds your mistakes. CRITICAL findings discovered by Garak or PyRIT count against your blue team score — they were preventable before the exercise started.

Parallel worktrees compress build time — three components built simultaneously instead of sequentially. But they create a merge problem: three PRs exist, they have dependencies, and merging them in the wrong order causes regressions that are hard to attribute. Manually managing the sequence, rebasing after each merge, and running tests between merges is exactly the kind of mechanical coordination work that should be automated.

/merge-worktrees reads the merge order you defined in sprint-progress.md when you set up the sprint. It presents the plan and waits for confirmation before touching anything. Then it merges one PR at a time: check for conflicts, rebase if needed, merge, pull main, run tests. If tests fail after a merge, it stops and surfaces the failure with options — investigate, continue at risk, or revert. It never silently continues past a broken state.

The skill ends with a cleanup prompt: run /retro, push main, remove worktree branches. This ensures the sprint is fully closed — no dangling branches, no uncommitted decisions, no context left in worktree directories that will confuse the next sprint.

Critical constraint: run this from your main Claude Code session, not from inside any worktree. Worktree panes should be closed or idle before /merge-worktrees runs.

Most developers move straight from one build to the next. The retro is the step that makes the next cycle faster than the current one. Without it, you repeat the same mistakes because you never examined them. Without it, patterns that worked disappear because you never captured them.

The retro compares what you set out to build (the spec's success criteria) against what you actually built. That gap — what you cut, what you deferred, what took longer than expected — is your most valuable input for the next sprint. A retro that says "the tool detection worked but the enrichment step took 40 of 60 build minutes" tells you exactly where to focus Week 12 hardening.

The updated skill adds gap classification to every problem you find. Each problem is one of four types: a spec gap (you didn't tell the agent something), a constraint gap (nothing prevented the mistake), a context gap (the agent couldn't see what it needed), or a process gap (a phase was skipped or out of order). Each type maps to a specific fix location — spec template, CI hook, AGENTS.md, or harness. Naming the gap type tells you exactly where to prevent it next time.

The Three Strikes Rule: when the same gap category appears three times across retros, stop noting it and build a permanent harness component instead. Three spec gaps of the same type → update the spec template. Three constraint gaps → add the rule to CI. Three context gaps → build the MCP or update AGENTS.md permanently.

The retro also generates your context library. Every sprint produces reusable patterns — a tool definition that worked, a system prompt structure that produced clean output, an agent orchestration approach worth keeping. The retro captures these before you move on and they're gone. Over time, your context library becomes the institutional knowledge that makes every new tool faster to build than the last.

The inside/outside loop distinction is the key security concept in this course. Controls inside the reasoning loop (CLAUDE.md, skills, agents, plans) are probabilistic — the agent CAN ignore them under goal pressure. Controls outside the loop (hooks, permissions.deny, CLI flags) are deterministic — they always fire regardless of what the model decides.

/harness-build makes that distinction concrete by reading what you have, showing you which column each control sits in, and scaffolding the enforcement layer that most projects skip. A project with a polished CLAUDE.md and no hooks has guidance, not a harness. /harness-build closes that gap.

The harness grows across the course: minimal in Unit 1 (one hook, one deny rule), fully declared by Unit 7 (blueprint.yaml + all fixed_steps implemented + AIUC-1 controls mapped). /harness-build advances it from wherever you are to the next level.

The course teaches harness fundamentals, which means students need a way to inspect whether a harness actually exists. A repo can have polished prompts and good docs while still being weak on permissions, state control, auditability, or misuse resistance. /harness-assess makes those gaps visible.

/harness-assess reviews the real control surface: entrypoints and orchestration, tool control, permissions and approval gates, state and memory handling, prompt and instruction control, logging and auditability, policy and environment separation, and resistance to prompt injection or tool abuse. It distinguishes what is implemented in code or config from what is only implied in prose.

The key diagnostic question is: "What is actually enforced here?" If a safeguard only lives in markdown, it is guidance, not control. That distinction is central to good harness engineering.

Use /harness-assess to review a course setup, repo, multi-agent workflow, or deployment environment. Use the Think → Spec → Build → Retro cycle to do the work; use /harness-assess to judge whether the surrounding environment makes safe, correct behavior easier and more auditable.

Building a capable agent system and building a compliant agent system are different problems. Most practitioners discover the gap at deployment — when a stakeholder asks "is this AIUC-1 compliant?" and the answer is "I don't know." /audit-aiuc1 makes the answer knowable before that conversation happens.

The skill walks through all six AIUC-1 domains: Data & Privacy, Security, Safety, Reliability, Accountability, and Society. For each domain it asks structured audit questions, collects evidence, identifies gaps, and scores each finding using OWASP AIVSS severity levels (Critical, High, Medium, Low). Critical and High findings in the Security and Safety domains are blocking — they must be resolved before PeaRL will approve elevation to a higher autonomy mode.

The audit is tier-scoped. A Tier 1 embedded AI feature (Copilot-style, no autonomous actions) only requires domains A and F. A Tier 2 supervised agent requires A, B, C, and E. A Tier 3 delegated agent or Tier 4 multi-agent pipeline requires all six. You answer two questions — what is the system, and what is its tier — and the skill audits exactly what's in scope.

The output report ends with a machine-readable Elevation Gate Status block. This is the artifact that Cedar's elevation policies parse when evaluating a request to move from ASSISTIVE to SUPERVISED_AUTONOMOUS mode, or from SUPERVISED_AUTONOMOUS to DELEGATED_AUTONOMOUS. The report is saved to reports/AUDIT-{system-name}.md in the project. Without it, elevation is blocked. With it, the gate has a dated, domain-scoped, reviewer-attested baseline to evaluate against.

As a learning tool, running the audit once against a system you built is one of the best ways to internalize what AIUC-1 actually requires. The questions surface assumptions you made during the build — about data handling, access control, output safety — and make them explicit so they can be evaluated rather than assumed.

Think about the tasks you repeat every session. Every time you find yourself doing the same thing — structuring an analysis, setting up a project, writing a certain type of report — that's a skill waiting to be built. Use this prompt: