| type | output | |||||
|---|---|---|---|---|---|---|
| status | active | |||||
| created | 2026-07-08 | |||||
| updated | 2026-07-08 | |||||
| sources |
|
|||||
| tags |
|
Use garrytan/gstack as a reference architecture for repeatable AI engineering loops in the Codex App.
This is not a claim that gstack is a native Codex App plugin. gstack is Claude Code-first. The practical move is to port the workflow shape into Codex-native surfaces: AGENTS.md, .agents/skills, Local and Worktree threads, Codex review, browser checks, Git tools, and automations.
Published Gist: https://gist.github.com/oruenboi/ce054a31355474d3647f13778cf18c31
Loop engineering means replacing ad hoc prompts with named loops:
idea -> product review -> engineering plan -> implementation -> review -> QA -> ship -> retro -> learn
gstack is useful because it makes those loops explicit. Codex App is useful because it gives each loop a workspace, thread, worktree, terminal, browser, diff, and Git surface.
Use gstack as the pattern library. Use Codex as the operating environment.
Use Codex Goal mode for the outcome. Use loops for the current operating mode.
Goal = the persistent delivery objective
Loop = the current phase of work inside that objective
Do not set tiny goals like "run a product loop." Set a goal for the delivery arc:
/goal
Deliver the onboarding redesign safely using loop engineering:
product loop, engineering loop, scoped build, review, QA, and ship summary.
Stop before pushing, publishing, or deploying unless I explicitly approve.
If the goal is still fuzzy, start with /plan first:
/plan
Shape this work into a loop-engineering goal with success criteria, constraints, and stop conditions.
Then set the refined /goal.
Once the goal is active, steer Codex with loop commands:
Start with the product loop. No code yet.
Now run the engineering loop. Inspect the repo and produce a decision-complete plan.
Move to a Worktree and run the build loop using the approved plan.
Run the review loop on the current diff. Findings first. No edits.
Run the QA loop in browser. Fix only confirmed bugs.
Run the ship loop. Prepare final summary and PR text. Do not push unless I ask.
Goal mode is most useful when the task spans multiple loops and you want Codex to keep the finish line visible. For single-turn work, a normal prompt or one loop is usually enough.
/goal
Deliver <outcome> using loop engineering.
Success criteria:
- Product loop has clarified scope and non-goals.
- Engineering loop has produced a decision-complete plan.
- Build loop has implemented only the approved scope.
- Review loop has no unresolved blocking findings.
- QA loop has verified the primary workflow.
- Ship loop has prepared the final summary, commit/PR text, and release risks.
Constraints:
- Use Worktree mode for speculative implementation.
- Use Local mode for final integration.
- Do not push, publish, deploy, or merge without explicit approval.
- Update AGENTS.md or a project skill only for recurring lessons.
Directly reusable ideas:
- specialist roles for product, engineering, design, QA, security, release, and docs
- slash-command-style prompts as repeatable workflow entrypoints
- stop conditions for each loop
- second-opinion review using Codex or another model
- browser-driven QA and visual inspection
- retrospectives and learnings that update durable project guidance
Use with care:
- gstack install commands and Claude Code paths such as
~/.claude/skills/gstack - Claude-specific slash commands
- browser daemons or cookie flows
- scripts that assume Claude Code state
For Codex App, prefer porting the smallest useful loop first.
Open the target repository as a Codex App project. Keep the project root narrow so sandboxing and search stay scoped to the codebase.
Use these Codex surfaces:
AGENTS.mdfor durable loop rules and verification commands..agents/skills/<loop-name>/SKILL.mdfor repeatable workflows worth reusing.- Local threads for direct edits, final integration, and publishing.
- Worktree threads for parallel experiments, reviews, QA passes, and speculative fixes.
- In-app browser for unauthenticated local previews and browser comments.
- Computer Use or Chrome only when the workflow needs signed-in state or real desktop/browser control.
- Automations for recurring lint, release, QA, or monitoring loops.
Clone gstack as a reference, not necessarily as production project dependency:
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/src/gstackInspect the skills before porting:
find ~/src/gstack -maxdepth 3 -name SKILL.mdFor Windows PowerShell:
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git $HOME\src\gstack
Get-ChildItem $HOME\src\gstack -Recurse -Filter SKILL.md | Select-Object FullNameDo not blindly copy the whole repository into Codex. Start by translating one loop into a Codex skill or AGENTS.md section.
Add this to the project root and tune the commands for the repo:
## Loop Engineering
- Treat work as named loops: clarify, plan, build, review, QA, ship, retro.
- Before coding, state which loop is active and what output will close it.
- Use Worktree mode for speculative or parallel loops.
- Use Local mode for final integration and publishing.
- Keep each loop small enough to review in one diff.
- After a repeated correction, update this `AGENTS.md` or a project skill.
- Before shipping, run the repo's lint, test, and build commands.
- For UI work, verify in a browser and include screenshots or notes.
- For risky changes, run a separate review loop before merging.| gstack-style loop | Codex App move | Output |
|---|---|---|
| Office hours / idea shaping | Start a planning thread in Local | reframed problem, options, recommendation |
| CEO review | Ask for product critique before implementation | sharper target outcome |
| Eng review | Ask Codex for architecture, data flow, edge cases, tests | implementation plan |
| Build | Worktree thread for feature implementation | diff and verification notes |
| Review | Codex /review or review prompt against branch diff |
findings ordered by severity |
| QA | Browser or Computer Use thread | bugs found, fixes, screenshots |
| Security | Security review thread or Codex Security skill/plugin | validated findings |
| Ship | Local thread for final check, commit, push, PR | PR or release notes |
| Retro / learn | Documentation thread | updated AGENTS.md, skill, or wiki note |
Start with a review loop because it is low-risk and immediately useful.
Create .agents/skills/loop-review/SKILL.md:
---
name: loop-review
description: Run a structured pre-merge review loop for a branch diff. Use when asked to review, challenge, or prepare a change for shipping.
---
# Loop Review
1. Identify the base branch and current diff.
2. Read `AGENTS.md` and relevant changed files.
3. Review for correctness, regressions, missing tests, UX issues, and unsafe assumptions.
4. Lead with findings ordered by severity.
5. Include file and line references when possible.
6. If no blocking findings exist, say so clearly and list residual risks.
7. Do not edit files unless the user asks for fixes.Then invoke it in Codex:
$loop-review review this branch before I ship it
Run a product loop on this idea.
Reframe the user problem, identify the smallest useful version, name the top tradeoffs, and end with one recommendation. Do not write code.
Run an engineering loop for this feature.
Inspect the repo first. Produce a decision-complete implementation plan covering affected surfaces, data flow, tests, and risks. Do not edit files yet.
Run a build loop in a Worktree.
Implement the approved plan only. Keep the diff scoped. Run the agreed checks. Stop with a summary of changed files and verification.
Run a review loop on the current diff.
Prioritize bugs, regressions, security issues, missing tests, and UX breaks. Findings first. No edits.
Run a QA loop.
Start the app, exercise the primary workflow in a browser, capture failures, fix only confirmed bugs, and re-test. Include screenshots or concrete observations.
Run a ship loop.
Check git status, run final tests, summarize the diff, prepare commit/PR text, and call out release risks. Do not push unless I ask.
Run a retro loop.
Review what happened in this thread, identify reusable lessons, and propose updates to `AGENTS.md` or `.agents/skills`. Do not add broad rules unless the lesson is likely to recur.
If you use Claude Code with gstack and Codex App side by side:
- Let gstack/Claude run its native slash-command loop.
- Use Codex App for independent review, challenge, QA, or implementation in a separate worktree.
- Use gstack's pairing/browser ideas only when you actually need a shared browser session.
- Keep each agent's authority clear. One agent should own the final diff at a time.
- Put durable cross-agent rules in
AGENTS.md, not only in chat.
- Do not import all gstack skills blindly into a production repo.
- Do not let two agents edit the same checkout at the same time.
- Do not give browser-cookie or authenticated-session access to broad prompts.
- Do not skip repo-native tests just because a loop "looks done."
- Do not treat generated role feedback as authority; use it as review input.
- Keep Claude-specific setup in Claude-specific files and Codex-specific setup in Codex-native files.
- Every task enters through a named loop.
- The loop has a clear output and stop condition.
- Codex uses Local/Worktree mode intentionally.
- Repeated loop behavior becomes
AGENTS.mdguidance or a Codex skill. - Reviews and QA happen before ship, not after.
- Retros update durable project memory.
- garrytan/gstack: https://github.com/garrytan/gstack
- gstack README: https://raw.githubusercontent.com/garrytan/gstack/main/README.md
- gstack AGENTS.md: https://raw.githubusercontent.com/garrytan/gstack/main/AGENTS.md
- gstack Codex skill: https://raw.githubusercontent.com/garrytan/gstack/main/codex/SKILL.md
- OpenAI Codex manual: https://developers.openai.com/codex/codex-manual.md