agentleFS
longranger2longranger2/claude-gpt-workflow/plan-execute/SKILL.md

plan-execute

Skill76 starsChanged 8 months agoMITView on GitHub

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.

We split this skill into the rules it gives an agent

18 rules. 0 are common, 9 are distinctive, and 9 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When the user runs /plan-execute {plan-file-path}, start the "orchestrated plan execution" workflow:

    line 10
  2. Distinctive:

    After Codex finishes, I review the generated code.

    line 12
  3. Distinctive:

    Read the specified plan file and understand:

    line 32
  4. Very specific:

    If the plan already contains a checklist (- [ ] / - [x]), use those items as execution units.

    line 38
  5. Distinctive:

    If it does not define clear steps, split the work into reasonable batches, with no more than 5 file changes per batch.

    line 39
  6. Very specific:

    Use the /codex skill and give Codex the following instruction:

    line 43
  7. Distinctive:

    After Codex finishes, I perform a code review.

    line 62
  8. Very specific:

    If Verdict: NEEDS_FIX, call /codex and have Codex fix the issues instead of editing them myself:

    line 98
  9. Very specific:

    If Verdict: APPROVED, skip to Step 6.

    line 107
  10. Distinctive:

    After Codex applies fixes, I review again, still without editing code directly:

    line 111
  11. Distinctive:

    Check whether each issue was truly fixed

    line 112
  12. Distinctive:

    Check whether the fixes introduced new problems

    line 113
  13. Distinctive:

    If issues remain, write a new review round and hand it back to Codex for another fix pass (repeat Step 4)

    line 114
  14. Very specific:

    If everything passes, mark the review as Verdict: APPROVED

    line 115
  15. Very specific:

    After each batch is completed, ask Codex to update the checklist in the plan file (- [ ] -> - [x]).

    line 119
  16. Distinctive:

    If unfinished steps remain, go back to Step 2 for the next batch.

    line 120
  17. Very specific:

    If any Critical or High issue exists -> NEEDS_FIX

    line 144
  18. Very specific:

    If all issues are Medium or below -> APPROVED with optional improvement notes

    line 145

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Plan Execute Skill

Purpose

When the user runs /plan-execute {plan-file-path}, start the "orchestrated plan execution" workflow:

  1. I (Claude Code) ask Codex to implement the code according to the plan.
  2. After Codex finishes, I review the generated code.
  3. I write the review into the reviews/ directory, then ask Codex to inspect and fix the issues.
  4. 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.

  1. Read every changed file and review them one by one.
  2. Compare against the plan to verify the implementation matches the intended design.
  3. 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
  4. Run pnpm build to confirm the compilation status.

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

LevelMeaningMust Fix
CriticalCauses runtime failures or security vulnerabilitiesYes
HighViolates project conventions or has obvious design flawsYes
MediumCode quality issue that should be improvedRecommended
LowStyle or preference issueOptional
SuggestionOptimization suggestionOptional

Verdict rules:

  • If any Critical or High issue exists -> NEEDS_FIX
  • If all issues are Medium or below -> APPROVED with optional improvement notes

File Convention

  • Share the same review file as plan-review: reviews/{topic}-review.md
  • {topic} is the plan file name without .md
  • Both plan review rounds and code review rounds are appended to the same file
  • Distinguish them by heading: ## Round {N} for plan review and ## Code Review Round {N} for code review

Download now (ZIP)

  • Other versions7 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 7

    1. okikusan-public/stock_skills★ 134same name
    2. allemaar/open-skills★ 15same name
    3. serbanghita/plan-critique-skills★ 13same name
    4. erhwenkuo/stock_skills★ 3same name
    5. Esi-Abolfazl/skills★ 3same name
    6. vanenshi/skills★ 2same name
    7. maxenko/claude-skills★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository2 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.