main-session-review-loop

name	main-session-review-loop
description	Keep the current Codex conversation as the primary coding session while running a code -> review -> code loop. Use this when the user wants the main session to stay in control, and review should be done by a spawned sub-agent or equivalent secondary reviewer instead of MCP or a separate top-level session.

Main Session Review Loop

Use this skill when the user wants:

• the current Codex conversation to remain the primary implementation session
• a code -> review -> code loop
• a configurable number of review/fix rounds
• review delegated to a sub-agent instead of an MCP server or a separate top-level Codex session

Do not use this skill when the user explicitly wants an external MCP server or a standalone shell runner to own the whole workflow.

Goal

Keep implementation authority in the main session.

• Main session owns code changes, integration, verification, and final summary.
• Review sub-agent owns review only.
• The reviewer must not modify files unless the user explicitly asks for that.

Default Workflow

Unless the user specifies a different count, run exactly 1 review/fix round.

1. Main session inspects the repo and implements the requested task locally.
2. After implementation reaches a coherent checkpoint, spawn one review-focused sub-agent.
3. Ask the review sub-agent to review the current changes for:
   • correctness
   • regressions
   • missing tests
   • security issues
4. Require findings first, ordered by severity, with concrete file paths and line numbers when possible.
5. If the reviewer reports no actionable issues, the main session states that explicitly and stops the loop early.
6. If findings exist, the main session evaluates them, applies the fixes it agrees with, and briefly explains any rejected finding.
7. If more rounds remain, repeat review -> fix until the requested round count is reached or a review returns NO_FINDINGS.
8. Run verification that is appropriate for the repo and summarize the outcome.

Loop Count

If the user specifies a loop count, follow it.

Examples:

• loop 1 time means one review/fix round after the initial implementation
• loop 2 times means review/fix can repeat twice
• run up to 3 loops and stop early on NO_FINDINGS means stop early on NO_FINDINGS

If the user does not specify a count, default to 1 round.

Review Sub-Agent Prompt Pattern

Use a review-only prompt similar to this:

Review the current repository changes only. Do not edit files.
Focus on correctness, regressions, missing tests, and security.
List actionable findings first, ordered by severity.
Include concrete file paths and line numbers when possible.
If there are no actionable findings, say exactly: NO_FINDINGS

If the user wants a diff-based review, tell the reviewer what to compare against:

• current uncommitted changes
• a specific branch or ref
• a specific commit range

Main Session Rules

• Do not delegate the implementation itself when the user wants the main session to stay in control.
• Do not let the review sub-agent edit files unless the user asks for that explicitly.
• Do not blindly apply every finding. Validate each one before changing code.
• Keep one review agent at a time unless the task clearly benefits from multiple independent reviewers.

Output Contract

When using this skill, the final response from the main session should cover:

• what was implemented
• whether the reviewer found issues
• what fixes were applied after review
• what verification was run
• any remaining risks or skipped findings

Fallback

If sub-agents are unavailable, keep the same structure but do the review in the main session and say that the review loop was collapsed into a single session.