The Ritual

Most development workflows fall apart because they're too complicated to remember. Six commands for a bug fix. A different sequence for a feature. A third process for hotfixes. Eventually nobody follows any of them, and the team drifts back to ad-hoc habits.

The playbook's daily workflow is three steps. That's a ritual, not a process. Rituals are small enough to become automatic. The steps apply whether you're using the playbook's command-line tools, a different development environment, or no tooling at all. Scope your work. Write code. Review before committing.

scope → code → review

Scope captures what you're building and how complex it is. You code without interruptions. Review examines what you changed, checks it against the relevant quality perspectives, and commits when it passes. The third step is usually automatic, triggered by the review when things are clean.

Scope: Two Minutes of Clarity

Every piece of work begins with a short conversation. Not a planning meeting. Not a requirements document. Just a few questions: What are you building? How complex is it? Is this expanding scope, hardening existing code, or simplifying? Any blockers?

Your answers determine the review depth later. A two-file bug fix gets a lighter touch than a new API endpoint. Once scope is captured, you code. No more decisions, no ceremony.

Code: No Interruptions

Between scope and review, you just write code. The ritual protects flow state by front-loading scope questions and back-loading quality checks. Nothing interrupts you in between.

Two things matter while you code. First: atomic changes. One concern per commit, always deployable, explain the why. Second: tests alongside code, not after. If you write the test while the logic is fresh, you catch edge cases you'd forget an hour later.

Review: Depth Matches Risk

When you're done coding, review examines what you changed and decides how deep to look. It doesn't ask you what kind of review you want. It figures it out from the diff.

A small bug fix gets a quick pass: does it address the root cause, is there a regression test, are there unrelated changes mixed in. A new feature gets the full treatment: architecture review, security check, test coverage, documentation, product alignment. The depth matches the risk.

If the review finds issues, you decide what happens next. Fix and commit? Surface the issues and decide manually? If the review passes clean, it commits. One less decision. You're already thinking about the next thing.

Session Boundaries

The ritual has a rhythm beyond individual features. Pausing and resuming work are part of the practice, not afterthoughts.

Before stepping away, capture where you are: last commit, in-progress work, next steps, blockers, anything you'd need to remember when you come back. It's a note to your future self. When you return, load that context back, check if the main branch has moved, and flag anything that went stale.

This matters more than it sounds. Context recovery is one of the most expensive parts of development. Every time you sit down and spend twenty minutes figuring out where you left off, that's time the ritual could have saved with a thirty-second pause the day before.

Shipping

Shipping isn't a handoff. It's the final act of the ritual, and it belongs to the person who wrote the code.

The full journey: specialized reviews from different perspectives, PR creation, peer review, merge, release, verification in production. The person who started the work carries it through to "verified and running." That ownership is the difference between "I pushed my code" and "I shipped a feature."

For larger changes, a dedicated shipping flow orchestrates the full sequence: quality gates first, then specialized reviews, then the final gate, then PR and peer review, then merge and release. Each step builds on the confidence of the previous one.

A Day in Practice

Morning. You open your editor. Load yesterday's context. You see your last commit, your next task, and a note that main moved ahead overnight. Quick rebase. Back in flow within two minutes.

Midday. Feature is done. Review examines your changes, consults the relevant perspectives, finds one issue with error handling on a new endpoint. You fix it. Review passes. Commit happens.

Afternoon. PR is up. Peer review comes back with a question about the caching strategy. You explain the trade-off, make a small adjustment, push. Approved. Merge. Quick smoke test in staging.

End of day. You note where you are, what's next tomorrow, and one thing that's been bugging you about the database schema. Thirty seconds. Tomorrow's context recovery will take two minutes instead of twenty.

Three steps. One habit. Quality by default.