In 2026, there is a great deal of discussion around Agentic Coding.
Every week, a new framework, orchestrator, or multi-agent system appears. To anyone unfamiliar with these concepts, it may seem as though developing with AI requires an infrastructure that is almost more complex than the application itself.
This perspective can discourage both beginners and more experienced developers who are still hesitant about using AI.
A few days ago, I watched Cole Medin's video, My COMPLETE Agentic Coding Workflow to Build Anything (No Fluff or Overengineering), in which he gives a very practical demonstration of how he organizes development with Claude Code.
As I watched it, I realized that the real value of the video was not Claude, but the method. I therefore decided to run an experiment: apply the same principles to Codex, adapting the structure to its conventions.
This article describes that port and what I learned during the process.
In the original workflow, Cole defines an AI Layer as the set of resources stored in the repository that help the coding agent understand:
This layer includes the PRD, global rules, reference documentation, commands, and any relevant Skills.
One particularly important detail is the distinction between commands and Skills.
In Cole's project, the main workflows are Markdown files stored in the .claude/commands/
directory:
.claude/
└── commands/
├── commit.md
├── create-prd.md
├── create-rules.md
├── execute.md
├── init-project.md
├── plan-feature.md
└── prime.md
Cole explains that, in Claude Code, commands and Skills have become technically very similar concepts. However, he continues to distinguish between them from an operational perspective.
A command is a workflow that the user explicitly chooses to start:
/prime
/create-prd
/plan-feature
/execute
/commit
A Skill, on the other hand, represents a capability or a set of instructions that the agent can use when the context requires it.
Cole's distinction is particularly useful for the port because slash commands and Skills are also different concepts in Codex.
Slash commands are actions that can be invoked from the interface using /
. Many are built-in commands that change the mode or state of the session, although the list may also include enabled Skills and custom prompts.
Skills, by contrast, are reusable workflows organized into directories containing a SKILL.md
file. At a minimum, this file specifies the Skill's name, description, and operating instructions.
Codex initially loads only the Skill's metadata and reads the full instructions when it decides to use it. This mechanism prevents unnecessary use of the context window.
To bring the methodology to Codex, I converted the Claude Code Markdown commands into Codex Skills while preserving their semantics as workflows explicitly started by the user.
The resulting structure looks like this:
.agents/
└── skills/
├── agent-browser/
│ └── SKILL.md
├── commit/
│ └── SKILL.md
├── create-prd/
│ └── SKILL.md
├── create-rules/
│ └── SKILL.md
├── execute/
│ └── SKILL.md
├── init-project/
│ └── SKILL.md
├── plan-feature/
│ └── SKILL.md
└── prime/
└── SKILL.md
To preserve the semantics of user-initiated workflows, it is possible to disable implicit invocation for Skills that we do not want Codex to select autonomously.
For example:
prime/
├── SKILL.md
└── agents/
└── openai.yaml
Inside openai.yaml
:
policy:
allow_implicit_invocation: false
This prevents Codex from implicitly activating prime
, execute
, or commit
based on the prompt. The Skills must be invoked explicitly, for example:
$create-prd
$create-rules
$prime
From this point onward, whenever I refer to $create-prd
, $create-rules
, $prime
, $plan-feature
, $execute
, and $commit
, I mean the custom Skills created for my port, not features preinstalled in Codex.
CLAUDE-template.md
to AGENTS.md
Converting the commands was not the only necessary change.
The original repository included a CLAUDE-template.md
file, which served as the basis for the global instructions provided to Claude. In the port, I transformed it into an AGENTS.md
file at the root of the project.
AGENTS.md
is the native mechanism through which Codex receives persistent instructions and context. At the beginning of a session, Codex builds an instruction chain: it starts at the repository root and moves down to the current working directory, any AGENTS.md
or AGENTS.override.md
files it encounters along the way. Instructions defined deeper in the directory tree can supplement or replace more general ones.
Persistent instructions and Skills therefore have different responsibilities:
AGENTS.md
defines how Codex should work within the repository;prime
, create-prd
, plan-feature
, execute
, and commit
.Specialized documentation can live in separate files, provided that AGENTS.md
, a Skill, or a plan clearly specifies when it should be consulted.
Once I had finished reclassifying the files, I still needed to verify whether the method actually worked with Codex.
To focus on the process rather than product complexity, I deliberately chose a simple application: a personal todo list.
I launched Codex in the folder containing the base files and gave it a brief similar to this:
I want to create a simple todo list application that allows me to add items, view the list, delete items, and mark them as completed.
I do not need authentication. I would like to use Next.js and deploy the application to Vercel for personal use.
I would like your recommendations regarding the architecture. I would also like a subagent to research best practices for this type of dashboard.
Once the research is complete, ask me all the questions necessary to clarify even the smallest product details.
Codex began asking me questions until the main open points had been clarified.
The goal of this phase is not merely to describe what we expect, but to eliminate as many assumptions as possible. Once the requirements were sufficiently clear, I invoked the following Skill:
$create-prd
The resulting PRD.md
file represents what we want to build. In my case, it contains:
The division into phases is particularly important. It makes little sense to ask Codex to implement the entire product in a single session.
Each phase should be small enough to be planned, implemented, and validated separately. This makes the process easier to verify, while the PRD effectively also becomes a roadmap.
As mentioned earlier, the repository already contained a base AGENTS.md
file derived from the previous CLAUDE-template.md
. This file includes the initial structure and general guidelines that I want to preserve across every project.
After defining what needed to be built, I invoked:
$create-rules
In my workflow, this Skill did not create AGENTS.md
from scratch. It analyzed the PRD and the repository, then expanded the existing file with project-specific information, including:
It is important for the final result to remain concise enough. AGENTS.md
should contain instructions that are generally applicable to the repository. Specialized documentation can live in separate files, provided that AGENTS.md
, a Skill, or a plan clearly indicates when it should be consulted.
$prime
Once the initial project definition was complete, I opened a new session and invoked:
$prime
This is the first intentional context reset. The new session does not inherit the long initial conversation. Instead, it reconstructs the project through PRD.md
, AGENTS.md
, the repository, and the Git history.
When I open the new session, Codex has already loaded the applicable instructions contained in AGENTS.md
. The $prime
Skill then completes its mental model by:
At the end, Codex provides a summary of its understanding of the project.
This phase should be reviewed carefully. If the agent's mental model is incorrect, it is best to intervene before moving on to implementation.
At this point, we reach the core of the PIV cycle:
Plan → Implement → Validate
Each phase of the PRD goes through these three steps.
I selected the first phase identified by Codex and invoked:
$plan-feature
This phase does not produce any code yet. Its purpose is to turn a PRD feature into a detailed technical plan.
Codex analyzes the repository, consults the relevant documentation, and defines:
In my case, $plan-feature
produced a new persistent file:
.agents/
└── plans/
└── implement-todo-dashboard-mvp.md
This detail is important: the plan does not remain confined to the conversation but becomes an artifact stored in the repository.
The document must be complete enough to be executed by a new Codex session that did not participate in the discussion during which the plan was prepared.
Before proceeding, I reviewed the file to verify that it:
Once the plan had been approved, I opened a new session dedicated to execution.
This is the second intentional context reset. The new session does not need to know every question that was asked, every rejected alternative, or the intermediate reasoning that occurred during planning. It only needs the decisions consolidated in the plan and the persistent context stored in the repository.
I then invoked:
$execute .agents/plans/implement-todo-dashboard-mvp.md
During this phase, Codex followed the tasks defined in the document, created the necessary files, implemented the todo list dashboard, and added the planned checks.
The purpose of $execute
is to carry out an already approved plan. If an important unforeseen decision emerges during the work, the agent stops and asks for clarification.
Once implementation is complete, the third phase of the PIV cycle begins: validation.
Codex runs the checks defined in the plan, for example:
npm run typecheck
npm run lint
npm run build
npm run test
For a web application, however, these checks are not sufficient. The actual behavior of the interface must also be verified.
In my case, the main scenarios were:
As in Cole's example, the agent-browser
Skill can be used to automate these flows and test the application as a user would.
Automated verification does not eliminate the need for human verification. At the end of the process, it is still important to personally test the application's main flows.
After verifying that the feature worked correctly, I invoked:
$commit
The Skill standardizes the commit message, describing what was implemented and how it was validated.
The Git history therefore takes on an additional role: it does not merely preserve code changes but becomes a form of long-term memory for Codex.
During a future execution of $prime
, the agent can review recent commits to understand how the project has evolved and which parts of the PRD have already been addressed.
With this methodology, the repository contains several layers of memory:
PRD.md → what we want to build
AGENTS.md → how Codex should work
.agents/plans/ → how to implement individual features
Git history → what was actually changed
Tests → what must continue to work
For the next feature, a new context is opened, $prime
is run again, and another PIV cycle begins.
At this point, a comparison with more structured frameworks such as the BMAD Method is inevitable.
BMAD aims to cover the entire development lifecycle: from initial analysis and product definition to architecture, the breakdown into epics and stories, implementation, and review. To achieve this, it provides specialized agents, guided workflows, intermediate artifacts, and modules dedicated to specific areas.
The method presented by Cole, and adapted by me for Codex, starts from the opposite choice: use the smallest possible number of components and fully understand the role of each one.
A PRD.md
, an AGENTS.md
, a few persistent plans, and a small number of Skills make up almost the entire system. A small structure is easier to customize and evolve alongside the project.
To be clear, this does not mean that the workflow is inherently better than BMAD. It simply offers a different trade-off.
A complete framework may be useful when a standardized process, clearly defined roles, numerous project artifacts, and greater consistency across different people or initiatives are required.
The lighter approach may be more suitable when the goal is to get started quickly, maintain direct control over the process, and modify each component according to the needs of a specific repository.
Naturally, simplicity comes at a cost: there is no external framework deciding which documents to produce, which checks to apply, or how to handle every possible scenario. The responsibility for evolving the Skills, AGENTS.md
, tests, and rules remains with the developer.
Before starting a new project with a coding agent, the question should therefore be:
How much structure does this project actually need?
For my experiment, I did not need to adopt the complete process of a framework such as BMAD, even though I knew that BMAD also offered lighter workflows for more limited tasks. I wanted a process that was structured enough to avoid vibe coding, but simple enough to be understood, modified, and controlled directly.
And this may be the most important takeaway: using a coding agent without losing control does not necessarily require more automation. Sometimes, all it takes is a small number of clear artifacts, explicit steps, and the discipline not to skip planning and validation.
If you're interested in using the ready-made scaffolding for Codex, you can find it here: https://github.com/eleonorarocchi/codex-agentic-starter
.. and please give it a star ;-)