Claude-gpt-workflow plan-execute
Use when the user says "/plan-execute", "plan execute", "implement plan", or "execute plan" and provides a finalized plan file path to carry out. Claude orchestrates, Codex writes code, Claude reviews, and Codex fixes issues until the quality bar is met.
git clone https://github.com/longranger2/claude-gpt-workflow
T=$(mktemp -d) && git clone --depth=1 https://github.com/longranger2/claude-gpt-workflow "$T" && mkdir -p ~/.claude/skills && cp -r "$T/plan-execute" ~/.claude/skills/longranger2-claude-gpt-workflow-plan-execute && rm -rf "$T"
plan-execute/SKILL.mdPlan Execute Skill
Purpose
When the user runs
/plan-execute {plan-file-path}, start the "orchestrated plan execution" workflow:
- I (Claude Code) ask Codex to implement the code according to the plan.
- After Codex finishes, I review the generated code.
- I write the review into the
directory, then ask Codex to inspect and fix the issues.reviews/ - Repeat until the code quality bar is met.
Core principle: I do not write or edit code myself. I only do two things: review code and orchestrate Codex. All code changes, including implementation and fixes, are performed by Codex.
Usage
/plan-execute plans/my-feature-plan.md
Session Reuse
After each Codex invocation, extract
session_id=xxx from the script output and save it as the session ID for the current task. In later Codex calls for the same task, pass --session <id> to reuse context so Codex remembers prior implementation and fix history instead of rereading the entire codebase every time.
My Workflow (Claude Code)
Step 1: Read the Plan and Split Execution Steps
Read the specified plan file and understand:
- The overall goal and scope of the plan
- The list of files to create or modify
- The order of implementation steps
- Relevant project conventions, especially from
CLAUDE.md
If the plan already contains a checklist (
- [ ] / - [x]), use those items as execution units.
If it does not define clear steps, split the work into reasonable batches, with no more than 5 file changes per batch.
Step 2: Ask Codex to Implement the Code
Use the
/codex skill and give Codex the following instruction:
Implement the code according to the plan in {plan-file-path}. Current execution scope: {specific step or batch description} Requirements: - Follow the design in the plan exactly. Do not improvise beyond it. - Obey the Code Quality Hard Limits defined in `CLAUDE.md`. - Single file <= 800 lines, single function <= 50 lines, nesting <= 3 levels - Run `pnpm build` after implementation to confirm compilation succeeds - If the plan includes a checklist, mark completed steps as `[x]` After implementation, list all changed files and provide a summary of each change.
Step 3: Review Codex Output (My Core Responsibility)
After Codex finishes, I perform a code review. Important: I only read code and write reviews. I never directly modify source files.
- Read every changed file and review them one by one.
- Compare against the plan to verify the implementation matches the intended design.
- Check code quality, including:
- Whether it violates the Code Quality Hard Limits
- Whether it introduces security risks
- Whether error handling is missing
- Whether naming and organization are clear
- Whether it follows existing project patterns
- Run
to confirm the compilation status.pnpm build
Step 4: Write the Review and Hand Fixes Back to Codex
Append the review to
reviews/{topic}-review.md (shared with plan-review):
--- ## Code Review Round {N} — {YYYY-MM-DD} **Scope**: {code scope covered in this review} **Build Status**: PASS / FAIL ### Issues #### Issue 1 ({severity}): {title} **File**: {file-path:line} {issue description} **Fix**: {specific fix recommendation} ... ### Verdict: NEEDS_FIX / APPROVED
If
Verdict: NEEDS_FIX, call /codex and have Codex fix the issues instead of editing them myself:
Read the latest Code Review round in {review-file-path}. Check each issue one by one. Fix the valid issues, and explain why any disputed item is not actually a problem. After making fixes, run `pnpm build` to confirm compilation succeeds. List the issues that were fixed and the corresponding code changes.
If
Verdict: APPROVED, skip to Step 6.
Step 5: Verify Fixes and Iterate
After Codex applies fixes, I review again, still without editing code directly:
- Check whether each issue was truly fixed
- Check whether the fixes introduced new problems
- If issues remain, write a new review round and hand it back to Codex for another fix pass (repeat Step 4)
- If everything passes, mark the review as
Verdict: APPROVED
Step 6: Update Plan Progress
After each batch is completed, ask Codex to update the checklist in the plan file (
- [ ] -> - [x]).
If unfinished steps remain, go back to Step 2 for the next batch.
Once all work is complete, move to the wrap-up.
Step 7: Wrap Up
Report the following to the user:
- Which steps were completed
- How many code review rounds were needed
- Which major issues were fixed
- Final build status
- List of changed files
- Path to the review log file
Review Severity Levels
| Level | Meaning | Must Fix |
|---|---|---|
| Critical | Causes runtime failures or security vulnerabilities | Yes |
| High | Violates project conventions or has obvious design flaws | Yes |
| Medium | Code quality issue that should be improved | Recommended |
| Low | Style or preference issue | Optional |
| Suggestion | Optimization suggestion | Optional |
Verdict rules:
- If any Critical or High issue exists ->
NEEDS_FIX - If all issues are Medium or below ->
with optional improvement notesAPPROVED
File Convention
- Share the same review file as
:plan-reviewreviews/{topic}-review.md
is the plan file name without{topic}.md- Both plan review rounds and code review rounds are appended to the same file
- Distinguish them by heading:
for plan review and## Round {N}
for code review## Code Review Round {N}