Setup & ways of working¶

Intro · ~half a day

This is the differentiator module. Every module after it teaches DevOps; this one teaches you to be productive inside an AI dev-team — the skill every later gate actually tests. The habit it builds: delegate freely, but verify and stay accountable.

TL;DR — in 30 seconds:

Work with Claude Code inside the repo, but verify everything before you commit — delegation isn't blind trust.
Learn the four PARA layers (Area/Project/Resource/Archive) and the team's git flow: branch → change → one small commit, never on main.
The gate: defend a real commit, place it correctly in PARA, recover from an accidental main commit, and show exactly how you verified the agent's contribution.

Learning objectives¶

By the end, the junior can:

Navigate the mono-repo's PARA structure and say where a given piece of work belongs.
Do the team git flow: branch → change → small commit, without touching main.
Use Claude Code + a skill to do a real task, and explain what the agent did and how they verified it.
State the team's AI rule in their own words: the human is accountable for the result; agent output is verified, not trusted.

Do it with Claude

Pair, Do and Prove run in Claude Code, with the onboarding-tutor skill. Click a button to copy the exact prompt, then paste it into Claude Code in this repo.

0. Set up your machine · do this first¶

Before the beats, get your environment ready (your mentor gives you repo access):

[ ] Clone the Simple Enough mono-repo (simple-enough/mono-repo) wherever you keep your repos.
[ ] Set your git identity: git config user.name "<Your Name>" and git config user.email "<you>@simpleenough.net" — every commit must be attributable to you.
[ ] Install Claude Code — your tutor and pair for every module runs here, inside the repo.
[ ] Install Anki + the AnkiConnect add-on (Tools → Add-ons → Get Add-ons → 2055492159), then git pull once. The onboarding deck (SE Onboarding) auto-imports so your spaced repetition is ready — see anki-sync.

Per-tool installs (podman, helm, terraform, …) come at the start of each module's Do beat — not now.

Done when: every box above is checked and Claude Code opens cleanly in your cloned repo.

Machine ready? Next you learn the two things every later module assumes you already know: where work lives in the repo, and how a change safely reaches it.

1. Learn · acquire the concept¶

Read: - the PARA rules — the four work layers (area → project → task → todo) and where things live. - the git-flow skill — branch/commit conventions. - the onboarding-tutor skill — your tutor for every later module. - the house rules agents (and you) follow.

Focus: how PARA decides where work goes, and the "never work on main, small commits" rule. Skip for now: the Tana supertag/field mechanics in para-rules.md (#Area, the Goal field, edit_node, native node descriptions). This curriculum is PARA-native and your dev work is tracked in GitHub, not Tana — you only need the PARA concepts: the four work layers, the three storage layers, and where things live.

PARA at a glance¶

Four layers answer "where does this belong": two are work (they hold what's being done), two are storage (they hold what you consult or keep):

Layer	Kind	Lifespan	Example
Area	work	never ends	`SE.Marketing`, `SE.AI` — something the team does continuously
Project	work	has an end	a v1, a migration, a sprint of work that iterates on an Area
Resource	storage	reference material	this course, a glossary, `para-rules.md` itself
Archive	storage	done / deprecated	a closed project's leftover notes

A Task (and its Todo checklist items) is the actual unit of work — it sits inside a Project, or directly inside an Area when it's small enough to skip a Project. When you're unsure where something goes, ask: is this an ongoing responsibility (Area), a chunk of work with an end (Project), something to consult later (Resource), or something finished (Archive)?

Check yourself — where does an ongoing team responsibility live in PARA?

Area — it never ends. A Project has a defined end (a v1, a migration, a sprint); an Area is a continuous responsibility (e.g. SE.Marketing, SE.AI).

Check yourself — what's the difference between a Resource and an Archive?

A Resource is live reference material you still consult (this course, para-rules.md). An Archive is something finished or deprecated — you keep it, but you don't work from it anymore.

2. Pair · passive → active¶

Open Claude Code in the repo and drive the onboarding-tutor skill:

"Explain PARA in this repo with one example of an area vs a project vs a task."
"Walk me through the exact git flow the team uses for a one-line change."
"What does the team mean by verify, don't trust agent output? Give me a concrete example."

Done when: you can explain PARA and the git flow unprompted, and state the verify-don't-trust rule.

3. Do · produce an artifact (your first PR-shaped change)¶

Exercise — ship a trivial real change, AI-native:

The shape of it — branch off main, make the change, land one small commit; main itself is never touched directly:

flowchart LR
    M["main (protected — never commit here)"] -->|create a branch| B["docs/topic or fix/topic"]
    B -->|make the change| C["one small, clear commit"]

If a commit ever lands on main by mistake, don't push — recover in 3 steps:

git branch fix/topic — point a new branch at your current commit, without moving anything yet.
git checkout fix/topic — switch onto that branch; your work now lives there safely.
git checkout main && git reset --hard origin/main — snap main back to match the remote. Safe, because a full copy of the commit is already on fix/topic.

flowchart LR
    X["oops: commit landed on main"] -->|git branch fix/topic| S["fix/topic now points at that commit"]
    S -->|git checkout fix/topic| W["switch onto fix/topic"]
    W -->|git checkout main && git reset --hard origin/main| R["main back in sync with origin"]

This is the minimum git flow to get moving. For the rest of it — branching & merging, merge vs. rebase, resolving conflicts, and the full GitHub PR/review flow — see Module 24 · Version Control · Git & GitHub.

With the tutor's help, pick a genuinely tiny, safe improvement (e.g., fix a typo in a doc, or add a missing row to a small table). Confirm the choice with your mentor.
Do the git flow yourself: create a branch (docs/<topic> or fix/<topic>), make the change, and land one small commit with a clear message. Do not work on main.
Have an agent draft part of it (e.g., the commit message, or the edit). Then verify it: read every character it produced and confirm it's correct before committing.
The tutor coaches the mechanics; you run the commands and own the result.

Done when: you have a branch with one clean, correct commit that you fully understand.

Common gotchas

Committing straight to main. Fix: branch first, always — git checkout -b docs/topic (or fix/topic) before you touch a file. If it already happened, use the 3-step recovery above.
Trusting agent output because "it looked fine." Fix: read every character the agent produced before you commit it. The gate tests how you verified it, not whether it ran.
Skipping the git identity setup. Fix: set user.name/user.email before your first commit — an unattributed or wrongly-attributed commit can't be traced back to you.
Misplacing work in PARA — filing a one-off task as a Resource, or ongoing work as a Project. Fix: ask "does this ever end?" (Project vs. Area) and "do I do this or consult it?" (Area/Project vs. Resource/Archive).

Check yourself — you just committed directly on main. What three commands recover safely?

git branch fix/topic (point a new branch at the current commit) → git checkout fix/topic (switch onto it) → git checkout main && git reset --hard origin/main (snap main back to the remote). Safe because the commit is already preserved on fix/topic before main is reset.

4. Prove · understanding gate¶

Mandatory. Pass bar in the Socratic gate.

Walkthrough: Show your commit. What exactly changed, and why is the message accurate?
Alternative: Where in PARA would this change live if it were a project instead of a doc fix? Why?
Failure & debug: You accidentally committed on main. What went wrong and how do you recover safely?
Provenance: Which part did the agent draft? Read it back and tell me how you verified it — not that it "looked fine."

Pass bar: you can defend the change, place it in PARA, recover from the main mistake, and describe how you verified the agent's contribution. "The agent did it and it worked" = fail — that's the exact habit this module exists to prevent.

5. Retain · fight forgetting¶

Build ~8 Anki cards: PARA's four work layers, the three storage layers, the branch-naming convention, "never work on main", and the verify-don't-trust rule.

Done when: those cards are in your deck.

Key takeaways¶

Delegate freely, but verify and stay accountable. The gate tests how you verified an agent's output, not whether it ran — "the agent did it and it worked" is a fail by design.
PARA has two work layers and two storage layers. Area (never ends) and Project (has an end) hold what's being done; Resource (reference) and Archive (done/deprecated) hold what you consult or keep.
To place something in PARA, ask two questions: does this ever end (Project vs. Area), and do you do this or consult it (Area/Project vs. Resource/Archive)?
The team git flow is branch → change → one small commit — main is never touched directly.
A commit landing on main by mistake recovers in 3 steps without losing work: git branch fix/topic (preserve the commit on a new branch first) → git checkout fix/topic → git checkout main && git reset --hard origin/main (safe because the commit already lives on fix/topic).
Set your git identity before your first commit — an unattributed or misattributed commit can't be traced back to you.

Go deeper — curated resources¶

Hand-picked external material to take this topic further — the best books, courses, talks, and writing. Cost is tagged Free, Free online (full text/course free on the web), or Paid.

For a deeper look at Git itself — the data model, branching, merging vs. rebasing, and the GitHub flow — see Module 24 · Version Control · Git & GitHub, which carries the curated Git reading list.

Docs · Claude Code documentation — Anthropic. How to actually work with an AI agent in your terminal — the exact skill this module builds. Free.

Gate log (mentor fills on pass)¶

Date passed:
Passed by: / checked by:
Weak spots noticed (feeds system improvement):