📏The Session Ritual & Ten Rules

The session ritual

BEFORE (2 min)   cd project → git checkout main && git pull → git checkout -b feat/thing
                 → claude → [Re-Entry prompt if it's been a while]

WORK (the loop)  one task → plan (Shift+Tab) → approve → review the diff
                 → verify → commit → /clear → next task

AFTER (2 min)    [End-of-Session prompt] → push the branch → check the preview deploy
                 → merge when happy → exit

Every piece has appeared earlier in this track — the session prompts, the plan step, the /clear rhythm, the branch habit from the safety chapter. The ritual is just those pieces in a fixed order, so none of them depends on you remembering.

Ten rules to tape above your monitor

1. Never commit what you haven't glanced at. The diff view is your seatbelt. An unexpected file in the diff → ask Claude why before committing.
2. Git before, git after. Every task starts from a clean committed state and ends in a commit. /rewind checkpoints exist — but Git is the real safety net.
3. One task per session, /clear between. Context hygiene is quality and cost control.
4. Plan Mode for anything structural. Thirty seconds of plan review saves thirty minutes of wrong code.
5. Secrets never enter the chat. No pasting API keys or tokens into prompts — they live in .env (gitignored), and Claude reads them from there if truly needed. Rotate any key you ever leak.
6. Be careful with permission auto-accept. Convenient, but you're handing over the keys. If you use it: on a branch, in a project with nothing to lose, never with production credentials connected.
7. Outcome-goals beat step-lists. Describe what should be true; let Claude choose how. But constrain what must NOT change.
8. Point at examples. "Follow the pattern in @Header.astro" outperforms three paragraphs of style description.
9. Stuck in a fix-loop (3+ failed attempts)? Stop. /clear, restate the problem fresh, or discard the changes and approach differently. Sunk-cost sessions burn the most tokens and produce the worst code.
10. Ask "why" constantly. You're building two things at once: a project and a developer. Don't ship the first and skip the second.

Where to go next

When static sites start feeling small, the tempting move is jumping to a whole new framework ecosystem. The smarter move is the smallest step that still grows you:

• Add server features inside the framework you already know. Most static-site frameworks also do server rendering, API endpoints and form actions, and most hosts offer a small database, key-value storage and serverless functions on free tiers. You learn databases and request/response thinking with ~20% new material instead of ~90%. Classic first projects: a feedback form that stores submissions, a URL shortener, a public counter or poll.
• Learn interactive UI one component at a time. Drop interactive "islands" into pages you already have instead of migrating anything.
• Adopt a bigger framework when a job or product demands it — with databases, APIs and components already in your hands, it becomes a two-week "learn the conventions" exercise instead of a three-month wall.

Your Claude Code setup evolves with each step: database work → connect the database MCP read-only first and add the rule "all schema changes via migration files, reviewed by me"; interactive UI → the Playwright MCP becomes essential (behaviour needs testing, not just markup); auth or anything sensitive → a security review joins every VERIFY block. And lean on the Teach-Me prompt hardest here — requests, state, migrations and auth transfer to every framework you'll ever touch.