Welcome! Register below to get the join link and a calendar invite by email.
Most people use Claude Code like a chat: ask, get code, correct it, repeat. It works for small things and falls apart on anything real. Context gets lost between sessions, Claude invents its own defaults, and two agents edit the same file.
In this session I'll show a different way of working: treat Claude Code like a small team. You write the operating manual, Claude plans before it codes, bugs live in a tracker, and sprints run several agents in parallel without collisions.
The method was tested on a real project: a web remake of Championship Manager 2, the 1995 football management classic. One person acting as product owner, 12 days, 12 production releases, 26 written plans, 47 tracked bugs (46 fixed) and 966 automated tests.
What we will cover
- CLAUDE.md as your operating manual: the six things worth writing down, and how every repeated correction becomes a rule
- Define "correct" before Claude builds: name your source of truth (spec, design, legacy app) and make Claude cite it
- Project memory: three files (bugs, plans, sprint log) that let any new session pick up where the last one stopped
- The sprint loop: plan → overlap check → parallel lanes in git worktrees → one controller merges → honest log
- Users in the loop: in-app feedback becomes a tracked bug, a fix and a release, often on the same day
- Guardrails: a person approves anything irreversible, and the logs say plainly what hasn't been verified
Then we'll see it live in the project itself.
What you will walk away with
Six habits you can apply to any codebase on Monday morning, plus a CLAUDE.md structure you can copy.
Who it is for
PMs and builders who already use Claude Code (or Cursor) and want to move from one-off prompting to a repeatable process that ships real software.