Keeping AI coding work reviewable across sessions

The problem and my role

A long-running implementation can span several conversations and tools. The next session needs to know which constraints still apply, what actually changed, what was checked, and which work remains. Reconstructing those facts from chat history makes continuation harder to review.

I organized the workflow around a small set of repository files, wrote reusable templates, and documented when each file should be used. The project reflects my approach to scoping and reviewing AI-assisted work. It is an operating method for a maintainer, not a background agent service.

How do you preserve context between AI coding sessions?

Keep durable project rules separate from the current handoff. A new session can read the rules, inspect the repository, and use the handoff as a concise map of the latest state. The code and verification results still need to be checked; a handoff is a starting point, not proof by itself.

1. Read project constraints and the latest handoff.
2. Write a short spec for a non-trivial change.
3. Implement a bounded slice against that spec.
4. Run the relevant checks and review the result.
5. Record what changed, what passed, and what remains.

The same files can be read by Claude Code or Codex. The workflow does not depend on one conversation retaining the entire project history.

Give each file one job

Standing rules and scoped intent

The repository’s CLAUDE.md holds project-specific constraints and sensitive areas. A spec records the problem, smallest useful change, non-goals, and validation path. Keeping those concerns separate avoids turning every feature request into a rewrite of standing instructions.

Review criteria and restart context

REVIEW.md owns the checks for sensitive changes. HANDOFF.md records the latest work, blockers, and next actions. BACKLOG.md holds deferred priorities. The handoff stays short enough to read at the start of a session.

One source of truth per concern

If a skill or command wraps a review gate, it should point to the authoritative criteria rather than embed a second copy. Otherwise two versions of the same rule can drift, leaving the next session to guess which one matters.

What the workflow establishes, and what it does not

The public artifacts include file-role documentation, review and validation guidance, reusable templates, and example handoffs. Support Triage Starter documents a concrete use of the method: specification, implementation, review, and human approval within a small reference project.

The review guidance calls for reproducing a bug before changing it and rerunning the relevant check afterward. For sensitive changes, criteria should be explicit enough to produce a pass or fail rather than a vague feeling that the work looks finished.

Markdown instructions do not mechanically prevent a bad commit or enforce permissions. Their effectiveness depends on the tools and maintainer following the workflow. Automated checks and access controls can support that process, but this repository does not claim to provide an autonomous enforcement system or measured productivity gains.

Inspect the project

• Project overview and adoption steps
• File roles and boundaries
• Review and validation guidance
• Reusable templates