De-slop: remove every em-dash + banned words across all modules + capstone (#94)

Co-authored-by: claude <claude@jpaul.io>
Co-committed-by: claude <claude@jpaul.io>

modules/23-working-with-existing-codebases/lab/orient.py

@@ -1,9 +1,9 @@
 #!/usr/bin/env python3
-"""orient.py — build a factual orientation pack for a repo you didn't write.
+"""orient.py: build a factual orientation pack for a repo you didn't write.
 
 Run it from the root of a cloned repo. It prints a Markdown summary of *ground truth*
-about the codebase — size, languages, project signals, the biggest (often most central)
-files, the top-level layout, and likely build/test commands — that you can paste in as the
+about the codebase (size, languages, project signals, the biggest (often most central)
+files, the top-level layout, and likely build/test commands) that you can paste in as the
 opening context for an AI session before asking it to map or change anything.
 
 The point is NOT to replace the AI's own exploration. It's to anchor that exploration in
@@ -46,10 +46,10 @@ SIGNALS: dict[str, str] = {
     ".gitea": "Gitea Actions",
     ".gitlab-ci.yml": "GitLab CI",
     "tox.ini": "Python test matrix",
-    "README.md": "Has a README — read it first",
-    "CONTRIBUTING.md": "Has contributor guidance — read before changing",
-    "ARCHITECTURE.md": "Has an architecture doc — rare and valuable",
-    # Committed AI-instruction files. Name the real ones across vendors — singling out one
+    "README.md": "Has a README; read it first",
+    "CONTRIBUTING.md": "Has contributor guidance; read before changing",
+    "ARCHITECTURE.md": "Has an architecture doc; rare and valuable",
+    # Committed AI-instruction files. Name the real ones across vendors; singling out one
     # would both miss files and cut against the vendor-neutral point (Module 5).
     "AGENTS.md": "Has a committed AI instructions file (Module 5)",
     "CLAUDE.md": "Has a committed AI instructions file (Module 5)",
@@ -142,9 +142,9 @@ def main() -> int:
     if present:
         for name in SIGNALS:
             if name in present:
-                w(f"- `{name}` — {SIGNALS[name]}")
+                w(f"- `{name}`: {SIGNALS[name]}")
     else:
-        w("- (none of the usual manifests/CI/docs at the root — look one level down)")
+        w("- (none of the usual manifests/CI/docs at the root; look one level down)")
 
     # --- likely test command ------------------------------------------------
     hints = [TEST_HINTS[name] for name in TEST_HINTS if name in present]
@@ -175,7 +175,7 @@ def main() -> int:
     w("\n## Top-level layout (entries by tracked-file count)\n")
     for name, n in sorted(top_dirs.items(), key=lambda kv: (-kv[1], kv[0])):
         kind = "dir" if "/" in next(p for p in files if p.split("/", 1)[0] == name) else "file"
-        w(f"- `{name}`{'/' if kind == 'dir' else ''} — {n}")
+        w(f"- `{name}`{'/' if kind == 'dir' else ''}: {n}")
 
     # --- recent activity ----------------------------------------------------
     recent = git("log", "--oneline", "-10")

modules/23-working-with-existing-codebases/lab/skills/map-this-repo.md

@@ -2,7 +2,7 @@
 
 A navigation playbook (a Module 21 skill) for orienting in a codebase you didn't write.
 Point Claude Code (or sub your own agent) at this file as a skill, or paste it in as instructions. The goal is a
-**read-only** mental model — no edits happen here.
+**read-only** mental model; no edits happen here.
 
 ## When to use
 At the start of any session on an unfamiliar repo, before any change is discussed.
@@ -19,7 +19,7 @@ At the start of any session on an unfamiliar repo, before any change is discusse
    `ARCHITECTURE`, or committed AI-instructions file. Treat these as claims to verify, not truth.
 2. Identify the **entry points**: how does this thing start? (CLI `main`, web server, library
    exports.) Name the exact file(s).
-3. Trace **one representative request/command end to end** — from entry point to where it does its
+3. Trace **one representative request/command end to end**, from entry point to where it does its
    real work and back. List the files it passes through, in order.
 4. Produce an **architecture summary** (max ~1 page):
    - One paragraph: what this project does and how it's structured.

modules/23-working-with-existing-codebases/lab/skills/safe-change.md

@@ -2,7 +2,7 @@
 
 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.
+skill is: small, scoped, tested, reviewable, never a sweeping rewrite.
 
 ## When to use
 When making a concrete change to an unfamiliar repo.
@@ -10,10 +10,10 @@ 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.
+  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
+- **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.
@@ -22,12 +22,12 @@ When making a concrete change to an unfamiliar repo.
 1. **State the change in one sentence** and the acceptance criterion ("done when X").
 2. **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.
-3. **Install the project's dependencies, then run the existing tests before touching anything** —
+3. **Install the project's dependencies, then run the existing tests before touching anything**;
    establish a green baseline. Tell two failures apart: if the suite errors with missing imports,
-   "no module named …", or "no tests ran," that's an **unconfigured environment**, not a baseline —
-   finish the documented install (and pick a different repo if it still won't go green on a clean
+   "no module named …", or "no tests ran," that's an **unconfigured environment**, not a baseline.
+   Finish the documented install (and pick a different repo if it still won't go green on a clean
    clone). A genuine **pre-existing failure** (install succeeded, but a real test fails) is the other
-   case — note it so it doesn't get blamed on you, and don't build on top of it.
+   case: note it so it doesn't get blamed on you, and don't build on top of it.
 4. **Make the minimal edit.** Keep it to the files identified in step 2.
 5. **Add or extend a test** that fails without your change and passes with it.
 6. **Run the full suite.** All green, including the baseline tests.