Verification-first parallel session loop
Use parallel sessions to increase useful throughput while making verification, not session count, the definition of progress.
Prepare the repository
Confirm that the repository provides:
- a shared instruction file such as CLAUDE.md or AGENTS.md;
- isolation through checkouts, worktrees, branches, or cloud environments;
- fast build, lint, typecheck, and test commands;
- browser, simulator, device, or other domain-specific verification where needed;
- a safe permission policy for every environment.
Do not use unrestricted permissions outside a sandbox whose blast radius the user accepts.
Plan meaningful changes
For any pull-request-sized change, keep the agent in a read-only planning state while it inspects the codebase. Iterate until the plan identifies the outcome, affected areas, approach, non-goals, checks, and important risks. Approve the plan before implementation.
Small mechanical changes may skip a written plan only when their scope and verification are already explicit.
Launch isolated sessions
Give each session one bounded responsibility and its own writable environment. Record:
| Session | Environment | Responsibility | Plan | Verification | Status |
|---|
Run only as many sessions as can be reviewed. Do not assign overlapping file ownership without an explicit integration sequence.
Reuse the inner loop
When a procedure repeats throughout the day, encode it as a repository command, skill, or script. Good candidates include:
- commit, push, and pull-request preparation;
- code simplification;
- application verification;
- formatting and focused checks;
- collection of a final review packet.
Keep these workflows in version control. Make their output compact and actionable.
Verify in the real medium
Every implementation session must receive a feedback loop that can prove the behavior it changed:
- run focused and regression tests for logic;
- exercise web behavior in a browser;
- exercise native behavior in a simulator or device;
- inspect generated output when the task changes artifacts;
- repeat until the checks pass or return a blocker.
A second agent may review or verify, but it does not replace deterministic checks or human product judgment.
Compound stable corrections
When review finds a recurring mistake, add a concise rule or tool reference to the applicable repository instruction file. Do this only for stable guidance that future sessions need. Keep transient facts and one-off debugging history out of global instructions.
Return a review packet
For each session return:
- the approved plan or scoped assignment;
- changed files and why;
- commit or pull-request reference;
- checks, environments, and results;
- manual evidence;
- unresolved risk;
- any new shared instruction or reusable workflow.
Do not merge unless the user separately authorizes it.
Source attribution
Independently compiled by XSkills from Boris Cherny's thread describing how he uses Claude Code. Cherny did not author or review this skill. Parallel local and web sessions, plan-first pull-request work, shared CLAUDE.md corrections, reusable commands and subagents, safe permission configuration, and strong domain verification come from the source. The ownership ledger, review-capacity limit, and merge boundary are XSkills adaptations. Attribution does not imply endorsement.