From 65c6c6b2b69a8599251ce2f4b9fb1c9fd53cf23e Mon Sep 17 00:00:00 2001 From: Justin Paul Date: Tue, 23 Jun 2026 09:53:05 -0400 Subject: [PATCH] docs: sort Prerequisites lists numerically ascending (#100) Reorder the `## Prerequisites` bullets in 9 modules so prior modules are listed lowest number first instead of by pedagogical importance or at random. A trailing "Helpful but not required" group stays last and is sorted within itself; multi-module bullets sort by their lowest number. Intro/closing paragraphs are left in place. Prose is unchanged; only bullet order moves. Modules touched: 7, 9, 14, 15, 22, 24, 25, 26, 27. The other 18 modules were already ascending (or have one/zero prereqs) and are untouched. Module 19's "Helpful but not required: Module 16" correctly trails its ascending 8/14/18 main list, so it stays as is. Closes #100 Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01CamgR4HaVpfaqUViuHUcWw --- .../README.md | 12 +++++------ .../09-issues-and-the-task-layer/README.md | 10 +++++----- modules/14-continuous-integration/README.md | 2 +- modules/15-security-scanning/README.md | 10 +++++----- .../README.md | 18 ++++++++--------- modules/24-assistive-agents/README.md | 4 ++-- modules/25-autonomous-agents/README.md | 18 ++++++++--------- .../README.md | 20 +++++++++---------- modules/27-evals/README.md | 4 ++-- 9 files changed, 49 insertions(+), 49 deletions(-) diff --git a/modules/07-worktrees-running-agents-in-parallel/README.md b/modules/07-worktrees-running-agents-in-parallel/README.md index 6d942b2..df59cf5 100644 --- a/modules/07-worktrees-running-agents-in-parallel/README.md +++ b/modules/07-worktrees-running-agents-in-parallel/README.md @@ -8,15 +8,15 @@ ## Prerequisites -- **Module 6: Branches.** You can create a branch, switch to it, merge it back, and resolve a - conflict. A worktree is the physical counterpart to the logical isolation a branch already gives - you, so this module makes no sense without it. -- **Module 4: Getting the AI out of the browser.** The agents in this module edit real files in a - folder. You'll point an editor-integrated AI session at each worktree directory. +- **Module 1: the `tasks-app`.** The running example continues here. - **Module 2: Version control.** The `tasks-app` is already a Git repo with commits, and you read a project's state from `git status` / `git diff` / `git log`. Each worktree has its own answer to those, which is the whole point. -- **Module 1: the `tasks-app`.** The running example continues here. +- **Module 4: Getting the AI out of the browser.** The agents in this module edit real files in a + folder. You'll point an editor-integrated AI session at each worktree directory. +- **Module 6: Branches.** You can create a branch, switch to it, merge it back, and resolve a + conflict. A worktree is the physical counterpart to the logical isolation a branch already gives + you, so this module makes no sense without it. If you parachuted in: you minimally need a Git repo with at least one commit and a working understanding of branches. diff --git a/modules/09-issues-and-the-task-layer/README.md b/modules/09-issues-and-the-task-layer/README.md index b1fdf25..8fa6439 100644 --- a/modules/09-issues-and-the-task-layer/README.md +++ b/modules/09-issues-and-the-task-layer/README.md @@ -8,14 +8,14 @@ ## Prerequisites +- **Module 1**: the `tasks-app` project. The lab writes issues against it. +- **Module 2**: the repo-as-durable-memory reframe. Issues are the team-scale version of the same + idea: shared memory for the work that *hasn't happened yet*. +- **Module 5**: you committed your AI instructions file. That file plus a good issue is what gives + an agent enough context to attempt a task; this module puts that pairing to work. - **Module 8**: you have a repo on a remote forge (GitHub or any alternative). Issues live on the forge, alongside the code, so this module needs the remote you set up there. Everything here is provider-neutral: issues exist on every forge. -- **Module 5**: you committed your AI instructions file. That file plus a good issue is what gives - an agent enough context to attempt a task; this module puts that pairing to work. -- **Module 2**: the repo-as-durable-memory reframe. Issues are the team-scale version of the same - idea: shared memory for the work that *hasn't happened yet*. -- **Module 1**: the `tasks-app` project. The lab writes issues against it. You do **not** yet need pull requests (Module 10) or the full collaboration loop (Module 11). This module produces the *input* to that loop. We'll point forward to it, not teach it here. diff --git a/modules/14-continuous-integration/README.md b/modules/14-continuous-integration/README.md index d63fced..21441de 100644 --- a/modules/14-continuous-integration/README.md +++ b/modules/14-continuous-integration/README.md @@ -8,13 +8,13 @@ ## Prerequisites +- **Module 2: Version Control.** Pushes, commits, and the diff habit are the substrate CI sits on. - **Module 8: Remotes and Hosting.** CI runs *on the forge*, triggered by pushes. You need a repo pushed to a remote (any forge: GitHub, GitLab, a self-hosted Forgejo/Gitea, whatever you set up in Module 8) for there to be anything to trigger. - **Module 13: Testing in the AI Era.** CI is mostly "run the tests, automatically." You need tests to run. If you skipped writing them, this module's lab ships a small suite so you're not blocked, but the real payoff is automating *your* tests. -- **Module 2: Version Control.** Pushes, commits, and the diff habit are the substrate CI sits on. You do **not** need Docker, secrets management, or your own runner yet; those are Modules 16, 17, and 19. On a **SaaS forge** (GitHub, GitLab.com, Bitbucket, and the rest) this module uses the diff --git a/modules/15-security-scanning/README.md b/modules/15-security-scanning/README.md index ec16244..f77f3ba 100644 --- a/modules/15-security-scanning/README.md +++ b/modules/15-security-scanning/README.md @@ -9,14 +9,14 @@ ## Prerequisites -- **Module 14: Continuous Integration.** You have a pipeline that runs lint, build, and tests on - every push. Security scanning is *more gates on that same pipeline*, so you need somewhere to bolt - them on. +- **Module 1: the `tasks-app`.** The running example. We'll let the AI bolt a "cloud sync" feature + onto it and watch it introduce all three failure modes at once. - **Module 2: Version Control as a Safety Net.** Scanners flag findings in a diff; you'll commit, re-scan, and confirm a gate goes red then green. Secret scanning in particular cares about *history*, not just the working tree; that only makes sense once you think in commits. -- **Module 1: the `tasks-app`.** The running example. We'll let the AI bolt a "cloud sync" feature - onto it and watch it introduce all three failure modes at once. +- **Module 14: Continuous Integration.** You have a pipeline that runs lint, build, and tests on + every push. Security scanning is *more gates on that same pipeline*, so you need somewhere to bolt + them on. Helpful but not required: **Module 8 (remotes/hosting)** gives you host-native scanning (Dependabot-style alerts, push protection) that lives on the remote; **Module 10 (reviewing code you didn't write)** frames diff --git a/modules/22-securing-third-party-mcp-and-skills/README.md b/modules/22-securing-third-party-mcp-and-skills/README.md index 28fc985..6218de6 100644 --- a/modules/22-securing-third-party-mcp-and-skills/README.md +++ b/modules/22-securing-third-party-mcp-and-skills/README.md @@ -8,20 +8,20 @@ ## Prerequisites +- **Module 2, Version Control as a Safety Net.** `git restore` and a clean commit are part of the + blast-radius story when something an agent did needs undoing. +- **Module 15, Security Scanning for AI-Generated Code.** Module 15 scans the code the AI *writes*. + This module secures the AI *as an actor*. Same instinct (automated gates against AI-shaped + failure), different target. The hallucinated-package supply-chain risk from Module 15 has a direct + cousin here. - **Module 20, MCP Servers.** You've connected the AI to real tools and data over MCP. That connection is exactly the attack surface this module defends. - **Module 21, Skills.** You've installed and authored skills (and seen that a skill is just instructions plus, often, scripts the AI runs). A third-party skill is someone else's code and someone else's instructions. -- **Module 15, Security Scanning for AI-Generated Code.** Module 15 scans the code the AI *writes*. - This module secures the AI *as an actor*. Same instinct (automated gates against AI-shaped - failure), different target. The hallucinated-package supply-chain risk from Module 15 has a direct - cousin here. -- **Module 2, Version Control as a Safety Net.** `git restore` and a clean commit are part of the - blast-radius story when something an agent did needs undoing. -- Helpful but not required: **Module 16** (containers, for sandboxing untrusted servers), - **Module 17** (secrets, for scoping the tokens you hand a server), and **Module 5** (committed - config; your MCP/skill setup is itself a reviewable, versioned artifact). +- Helpful but not required: **Module 5** (committed config; your MCP/skill setup is itself a + reviewable, versioned artifact), **Module 16** (containers, for sandboxing untrusted servers), and + **Module 17** (secrets, for scoping the tokens you hand a server). --- diff --git a/modules/24-assistive-agents/README.md b/modules/24-assistive-agents/README.md index 29dda03..0e406de 100644 --- a/modules/24-assistive-agents/README.md +++ b/modules/24-assistive-agents/README.md @@ -25,14 +25,14 @@ trusting an agent in the loop, before Module 25 lets one actually open a PR. ## Prerequisites +- **Module 5: Commit the AI's config.** The review rubric and the label taxonomy in this lab are + committed, versioned config: change how the agent behaves and it arrives as a reviewable diff. - **Module 9: Issues and the task layer.** You have issues describing work, and the idea that an assignee can be a human *or* an agent. The triage half of this module is the agent that sorts the incoming pile and decides which is which. - **Module 10: Reviewing code you didn't write.** You learned to read an AI's diff for plausibility traps, not just correctness. The review half hands the *first pass* of exactly that skill to an agent, so your attention lands where it matters. -- **Module 5: Commit the AI's config.** The review rubric and the label taxonomy in this lab are - committed, versioned config: change how the agent behaves and it arrives as a reviewable diff. - **Module 22: Securing third-party MCP servers and skills.** The least-privilege and prompt-injection thinking from there is what keeps an assistive agent inside its lane. We lean on it directly in "Where it breaks." diff --git a/modules/25-autonomous-agents/README.md b/modules/25-autonomous-agents/README.md index be98d47..c24f3ac 100644 --- a/modules/25-autonomous-agents/README.md +++ b/modules/25-autonomous-agents/README.md @@ -11,25 +11,25 @@ This is the module the whole back half of the course was load-bearing for. It assumes a lot, on purpose; each piece is a wall the autonomous agent has to land behind. -- **Module 24**: assistive agents, where the AI helped and *you* decided every step. This module is - the escalation: the agent now takes a step on its own. The only reason that's responsible is the - rest of this list. +- **Module 5**: your committed AI instructions file: the agent's standing brief, the half of the + spec that isn't in the issue. +- **Module 6**: branches. The agent's work goes on a branch, never straight onto `main`. - **Module 9**: issues as an agent's task specification, including the `ready` label and the idea of an agent as an *assignee*. An issue is the agent's input here. -- **Module 6**: branches. The agent's work goes on a branch, never straight onto `main`. - **Modules 10 and 11**: the PR review gate and the full issue → branch → implementation → PR → review → merge → close loop. The PR *is* the unit of supervision in this module. +- **Module 12**: revert, reset, recovery. The backstop for when a gate misses something. - **Modules 13 and 14**: tests and CI. The automated gate that runs on the agent's PR. - **Module 15**: security scanning as another gate on the same pushes. Autonomy makes this non-optional, not optional. -- **Module 19**: runners. A triggered or scheduled agent is just a runner job; you need to know - what's executing it and whose compute it's burning. -- **Module 12**: revert, reset, recovery. The backstop for when a gate misses something. -- **Module 5**: your committed AI instructions file: the agent's standing brief, the half of the - spec that isn't in the issue. - **Modules 16, 17, 22**: containers (sandboxing), secrets (scoped credentials), and the prompt- injection attack surface. An unattended agent with a push token is a security boundary; these are why. +- **Module 19**: runners. A triggered or scheduled agent is just a runner job; you need to know + what's executing it and whose compute it's burning. +- **Module 24**: assistive agents, where the AI helped and *you* decided every step. This module is + the escalation: the agent now takes a step on its own. The only reason that's responsible is the + rest of this list. If you skipped straight here, the lesson will read as reckless, because without those gates, it *would* be. diff --git a/modules/26-orchestrating-multiple-agents/README.md b/modules/26-orchestrating-multiple-agents/README.md index 9bc6a1f..27b5f81 100644 --- a/modules/26-orchestrating-multiple-agents/README.md +++ b/modules/26-orchestrating-multiple-agents/README.md @@ -9,27 +9,27 @@ ## Prerequisites +- **Modules 2, 5, 6.** Durable memory per worktree, the committed AI config every agent inherits, + and conflict resolution for the inevitable merge. - **Module 7, Worktrees.** The primitive everything here rests on. One repo, many working directories, each on its own branch, each safe for an agent to edit without touching the others. Module 7 proved this on *two* agents and told you the scale-up lived here. This is here. If `git worktree add` / `list` / `remove` aren't muscle memory yet, go back; everything below is that, multiplied. -- **Module 25, Autonomous agents.** You can hand an agent an issue and get a reviewable PR back, - supervised. This module runs *several* of those at once. If you can't trust one unattended agent, - you have no business running five. +- **Module 8, Remotes.** The PRs in this lab live on a forge. (A local-only fallback is given.) +- **Module 9, Issues.** The unit of work you split across agents. A clean fan-out is a set of clean + issues. +- **Module 10, Reviewing code you didn't write.** The skill that becomes the bottleneck. N agents + produce N diffs; one human reviews them one at a time. - **Module 11, Collaboration: humans and agents on one repo.** The issue → branch → implementation → PR → review → merge → close loop. Orchestration is that loop run N times in parallel and fanned back into one `main`. Parallel agents are just contributors who happen to share a clock. -- **Module 10, Reviewing code you didn't write.** The skill that becomes the bottleneck. N agents - produce N diffs; one human reviews them one at a time. -- **Module 9, Issues.** The unit of work you split across agents. A clean fan-out is a set of clean - issues. - **Module 14, Continuous integration.** The automated gate every parallel branch passes through before it's yours to review. With many agents, CI stops being a nicety and becomes the only thing keeping the merge queue honest. -- **Module 8, Remotes.** The PRs in this lab live on a forge. (A local-only fallback is given.) -- **Modules 2, 5, 6.** Durable memory per worktree, the committed AI config every agent inherits, - and conflict resolution for the inevitable merge. +- **Module 25, Autonomous agents.** You can hand an agent an issue and get a reviewable PR back, + supervised. This module runs *several* of those at once. If you can't trust one unattended agent, + you have no business running five. If you parachuted in: you minimally need worktrees, the PR loop, and one agent you'd let run on its own. This module is about coordinating many of those, not about any one of them. diff --git a/modules/27-evals/README.md b/modules/27-evals/README.md index 8301fe2..f579c1c 100644 --- a/modules/27-evals/README.md +++ b/modules/27-evals/README.md @@ -13,12 +13,12 @@ This is the closer. It assumes the whole course, but it leans hardest on: - **Module 1**: the thesis (the model is the cheap, swappable part; the workflow is the durable skill) and the `tasks-app` we've carried the whole way. This module is where the thesis gets its proof. +- **Module 10, Reviewing Code You Didn't Write**: the human review skill evals partially automate + and partially *replace* once a human isn't in the loop. - **Module 13, Testing in the AI Era**: you can write a deterministic pass/fail check. Evals are the next thing up the ladder: scoring output that a single test can't fully pin down. - **Module 14, Continuous Integration**: running checks automatically on every change, with an exit code that gates. Evals run the same way and gate the same way. -- **Module 10, Reviewing Code You Didn't Write**: the human review skill evals partially automate - and partially *replace* once a human isn't in the loop. - **Modules 24–26, the Unit 5 agent ladder**: assistive agents (24), autonomous-but-supervised agents (25), and orchestrated fleets (26). Evals are what decide how far up that ladder any given agent is allowed to climb.