claude
fbec36cb67
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
33 lines
1.8 KiB
Markdown
33 lines
1.8 KiB
Markdown
# Skill: Map this repo
|
|
|
|
A navigation playbook (a Module 21 skill) for orienting in a codebase you didn't write.
|
|
Point your agentic tool at this file as a skill, or paste it in as instructions. The goal is a
|
|
**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.
|
|
|
|
## Rules
|
|
- **Read only.** Do not edit, create, or delete files while mapping. No exceptions.
|
|
- **Cite real paths.** Every claim about the code must point to a file and, ideally, a line range.
|
|
If you can't cite it, say "unverified" instead of guessing.
|
|
- **Breadth before depth.** Establish the whole shape before diving into any one area.
|
|
- **No conclusions from file names alone.** A file called `auth.py` may not be where auth lives.
|
|
|
|
## Steps
|
|
1. Read the orientation pack (from `orient.py`), the README, and any `CONTRIBUTING`,
|
|
`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
|
|
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.
|
|
- A "where things live" table: concern -> directory/file.
|
|
- The build/test/run commands, confirmed against the README or CI config.
|
|
- 3-5 things that surprised you or look risky to touch.
|
|
5. List **open questions** you could not resolve from the code. Do not paper over them.
|
|
|
|
## Output
|
|
A single Markdown summary. End with: "Verified against: <list of files actually read>."
|