Files

T

claude fbec36cb67 feat(course): build out all 27 modules, capstone, scaffold, and conventions

Scaffold the course repo and author the full curriculum in dependency-chain
order, following the settled build decisions in handoff.md.

- Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5),
  _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config.
- Modules 1-2: reference exemplars (locked for tone/depth/lab style).
- Modules 3-27: full lessons + runnable labs, each following the template,
  respecting the chain, vendor/model-agnostic, with "feel the pain" labs.
- Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22),
  not written from memory; expansion-zone modules carry Verify-before-publish.
- Capstone: the full loop end to end on the running tasks-app example.

Lab code syntax-checked (Python/shell/YAML); every module has the 7 core
template sections.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT

2026-06-22 12:18:30 -04:00

2.3 KiB

Raw Blame History

Skill: Safe scoped change

A safe-change playbook (a Module 21 skill) for modifying a codebase you don't fully understand. Use it only after map-this-repo has produced an architecture summary. The whole bet of this skill is: small, scoped, tested, reviewable — never a sweeping rewrite.

When to use

When making a concrete change to an unfamiliar repo.

Rules

One change, one branch. Create a branch first (Module 6). Never work on the default branch.
Smallest diff that solves it. Touch the fewest files possible. If the change wants to sprawl, stop and re-scope — sprawl in code you don't understand is how you break things invisibly.
No drive-by edits. Do not reformat, rename, or "clean up" unrelated code. Those bury the real change and make the diff unreviewable (Module 10).
Match local conventions. Mirror the surrounding code's style, naming, and patterns — not your own defaults.
Tests are the contract. A change isn't done until it's covered (Module 13) and the existing suite still passes.

Steps

State the change in one sentence and the acceptance criterion ("done when X").
Find the blast radius first: search for every caller/usage of what you're about to touch. List them. If you can't enumerate them, you're not ready to change it.
Run the existing tests before touching anything — establish a green baseline. If they were already red, note it; don't let a pre-existing failure get blamed on you.
Make the minimal edit. Keep it to the files identified in step 2.
Add or extend a test that fails without your change and passes with it.
Run the full suite. All green, including the baseline tests.
Self-review the diff as if reviewing someone else's PR (Module 10): is every changed line necessary and explained? Revert anything that isn't.
Write the PR description: what changed, why, blast radius, how it was tested, what you did NOT touch and why.

Stop conditions (escalate to a human instead of pushing on)

The change requires touching more than ~3 files or a "core" file from the architecture summary.
You can't enumerate the callers of what you're changing.
A test you don't understand starts failing.
The fix needs a design decision the existing code doesn't settle.

2.3 KiB Raw Blame History