Plan Mode + Pursue Goal: A Better Workflow for Moving from Product Design to Codex Implementation

ChatGPT Use cases and examples
, ,
1

I have been thinking about the usefulness of Plan Mode and Pursue Goal as a workflow for building software with ChatGPT Projects and Codex.

The idea is simple: separate design thinking from execution, but keep both visible, traceable, and connected.

In this workflow, Plan Mode becomes the living design space for a project. This is where I would work with ChatGPT to define the product direction, tech stack, frontend design, database schema, API contracts, sprint scope, tradeoffs, rejected ideas, and implementation constraints.

For example, if I have an app idea, I could use Plan Mode inside ChatGPT Projects to create and maintain documents such as:

docs/product-plan.md
docs/architecture.md
docs/api-contract.md
docs/database-schema.md
docs/frontend-design.md
docs/sprints/sprint-3-api-auth.md

These documents would become the design and planning source of truth.

Then, once a design or sprint is approved, I would switch to Pursue Goal.

Pursue Goal would turn the planning context into executable engineering goals, for example:

Sprint title
Sprint 3 — API, AI/NLP Job Insights, and Product Validation

SDLC focus
API design, authentication contract, secured workflow access.

Business objective
Expose Trackly’s core job application workflow through a secured API that can support future clients.

Engineering objective
Add Django REST Framework, SimpleJWT, job application serializers, secured API routes, and database-backed API tests.

Tasks
Install and configure Django REST Framework.
Add JWT authentication.
Create serializers for job applications.
Add protected API routes.
Write API tests.

Concrete deliverables
Files created or modified:
- requirements.txt
- config/settings/base.py
- jobs/api/serializers.py
- jobs/api/views.py
- jobs/api/urls.py
- tests/test_jobs_api.py

Commands to run
docker compose exec web python manage.py makemigrations jobs --settings=config.settings.local
docker compose exec web pytest

Expected receipt
10 passed

This kind of goal document is extremely useful for Codex because it reduces ambiguity. Codex does not have to rediscover intent from scattered chat history. It can work from a concrete execution contract: files, commands, acceptance criteria, and expected test results.

The workflow becomes:

Plan Mode
Product idea -> architecture -> schema -> API contract -> UI flows -> sprint plan

Pursue Goal
Goal doc -> implementation -> tests -> review -> receipt -> update plan

I think the key detail is that ChatGPT Projects should not completely replace the repo as a source of truth. Instead, ChatGPT Projects can be the planning and orchestration source of truth, while the repo stores exported artifacts that Codex, VS Code, Git history, tests, and future contributors can all access.

That gives us a tighter loop:

Design -> Implement -> Test -> Review -> Update Plan

Each Pursue Goal could also have a lifecycle:

Draft -> Approved -> In Progress -> Implemented -> Tested -> Reviewed -> Done

And after implementation, Codex could write back a receipt:

Changed files
Commands run
Test results
Deviations from plan
Follow-up tasks

The biggest benefit is reducing drift. The design decisions, implementation work, test evidence, and review notes stay aligned across ChatGPT and Codex.

For solo builders and small teams especially, I think this could become a very practical SDLC workflow inside the ChatGPT/Codex ecosystem:

  • Plan Mode decides what should exist.
  • Pursue Goal makes it exist with evidence.
  • Codex implements against the approved goal.
  • The repo keeps durable project artifacts.
  • The plan is updated when implementation reveals new information.

This feels like a strong direction for turning ChatGPT Projects from a conversation space into a more structured software delivery workspace.

2

the step i keep losing is between Plan and Pursue Goal: someone outside the ChatGPT project reads the generated docs, then leaves “this assumption is wrong” in Slack. by the time that gets back to Codex, the paragraph + version context is gone.

i’ve been testing PreApp around that handoff: publish the actual md/html revision, let the reviewer comment on the exact block, then pull those notes into the next Codex run. do you keep the design docs as append-only revisions, or does Pursue Goal edit the same files in place? the second gets messy once review spans more than one version.

3

I think you’ve identified one of the biggest gaps in the current workflow. The planning itself is usually fine. The hard part is preserving review context as the implementation evolves.

Good question. I would keep the design docs as append only revisions.

Once a plan has been reviewed, I think it should become an immutable snapshot. Pursue Goal can consume those artifacts, but if assumptions change or reviewers find issues, I would generate a new revision instead of editing the original in place. Review comments only make sense if they remain attached to the exact text they were written against.

Your Slack example is exactly why. If someone says, “this assumption is wrong,” I want Codex to know which revision, which section, and ideally what changed since then. Without that lineage, the feedback becomes detached from the decision that triggered it.

I also like your idea of publishing the actual Markdown or HTML revision and collecting comments against specific blocks. Bringing those comments back into the next Codex run feels much closer to how code review already works with commits and pull requests. It gives the model structured context instead of asking it to reconstruct history from scattered messages.

My mental model is less “living document” and more “design commits.” Each revision captures the reasoning at a point in time, reviewers comment on that snapshot, and the next planning cycle explicitly incorporates or rejects the feedback with full traceability. I think Codex workflows become much more reliable when design history is treated with the same discipline as source code.

4

design commits is the right phrase for it. do you already have one real .md design doc in this flow? i can run a small pass with you: rev 1, one block-level correction, Codex pulls it, rev 2. would rather see where the anchor breaks on a real file than keep theorizing about it.

5

I will have to decline because the design document in question is an internal document and cannot be shared publicly. I agree that testing with a real file would be useful, but I am not able to use internal material for that purpose.

6

totally fair. don’t use internal material for this, and no need to make a fake doc just for the test. this is useful input by itself: private/controlled sharing has to be in place before this kind of review loop is useful. thanks for being clear.

7

all good, thanks for clarifying. definitely don’t share anything internal for this. your reply already answered what i was trying to understand.