{"slug": "how-i-use-codex-to-build-applications-without-losing-control", "title": "How I Use Codex to Build Applications Without Losing Control", "summary": "A developer ported Cole Medin's agentic coding workflow from Claude Code to OpenAI's Codex, converting Markdown commands into Codex Skills while preserving their semantics as user-initiated workflows. The adaptation uses an .agents/skills directory and disables implicit invocation for certain skills to maintain control, demonstrating a practical method for AI-assisted development without overengineering.", "body_md": "In 2026, there is a great deal of discussion around **Agentic Coding**.\n\nEvery 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.\n\nThis perspective can discourage both beginners and more experienced developers who are still hesitant about using AI.\n\nA few days ago, I watched **Cole Medin's** video, [ My COMPLETE Agentic Coding Workflow to Build Anything (No Fluff or Overengineering)](https://www.youtube.com/watch?v=goOZSXmrYQ4), in which he gives a very practical demonstration of how he organizes development with Claude Code.\n\nAs 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.\n\nThis article describes that port and what I learned during the process.\n\nIn the original workflow, Cole defines an **AI Layer** as the set of resources stored in the repository that help the coding agent understand:\n\nThis layer includes the PRD, global rules, reference documentation, commands, and any relevant Skills.\n\nOne particularly important detail is the distinction between **commands** and **Skills**.\n\nIn Cole's project, the main workflows are Markdown files stored in the `.claude/commands/`\n\ndirectory:\n\n```\n.claude/\n└── commands/\n    ├── commit.md\n    ├── create-prd.md\n    ├── create-rules.md\n    ├── execute.md\n    ├── init-project.md\n    ├── plan-feature.md\n    └── prime.md\n```\n\nCole 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.\n\nA command is a workflow that the user explicitly chooses to start:\n\n```\n/prime\n/create-prd\n/plan-feature\n/execute\n/commit\n```\n\nA Skill, on the other hand, represents a capability or a set of instructions that the agent can use when the context requires it.\n\nCole's distinction is particularly useful for the port because slash commands and Skills are also different concepts in Codex.\n\n**Slash commands** are actions that can be invoked from the interface using `/`\n\n. 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.\n\n**Skills**, by contrast, are reusable workflows organized into directories containing a `SKILL.md`\n\nfile. At a minimum, this file specifies the Skill's name, description, and operating instructions.\n\nCodex 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.\n\nTo 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**.\n\nThe resulting structure looks like this:\n\n```\n.agents/\n└── skills/\n    ├── agent-browser/\n    │   └── SKILL.md\n    ├── commit/\n    │   └── SKILL.md\n    ├── create-prd/\n    │   └── SKILL.md\n    ├── create-rules/\n    │   └── SKILL.md\n    ├── execute/\n    │   └── SKILL.md\n    ├── init-project/\n    │   └── SKILL.md\n    ├── plan-feature/\n    │   └── SKILL.md\n    └── prime/\n        └── SKILL.md\n```\n\nTo 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.\n\nFor example:\n\n```\nprime/\n├── SKILL.md\n└── agents/\n    └── openai.yaml\n```\n\nInside `openai.yaml`\n\n:\n\n```\npolicy:\n  allow_implicit_invocation: false\n```\n\nThis prevents Codex from implicitly activating `prime`\n\n, `execute`\n\n, or `commit`\n\nbased on the prompt. The Skills must be invoked explicitly, for example:\n\n```\n$create-prd\n$create-rules\n$prime\n```\n\nFrom this point onward, whenever I refer to `$create-prd`\n\n, `$create-rules`\n\n, `$prime`\n\n, `$plan-feature`\n\n, `$execute`\n\n, and `$commit`\n\n, I mean the custom Skills created for my port, not features preinstalled in Codex.\n\n`CLAUDE-template.md`\n\nto `AGENTS.md`\n\nConverting the commands was not the only necessary change.\n\nThe original repository included a `CLAUDE-template.md`\n\nfile, which served as the basis for the global instructions provided to Claude. In the port, I transformed it into an `AGENTS.md`\n\nfile at the root of the project.\n\n`AGENTS.md`\n\nis 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, loading any `AGENTS.md`\n\nor `AGENTS.override.md`\n\nfiles it encounters along the way. Instructions defined deeper in the directory tree can supplement or replace more general ones.\n\nPersistent instructions and Skills therefore have different responsibilities:\n\n`AGENTS.md`\n\ndefines how Codex should work within the repository;`prime`\n\n, `create-prd`\n\n, `plan-feature`\n\n, `execute`\n\n, and `commit`\n\n.Specialized documentation can live in separate files, provided that `AGENTS.md`\n\n, a Skill, or a plan clearly specifies when it should be consulted.\n\nOnce I had finished reclassifying the files, I still needed to verify whether the method actually worked with Codex.\n\nTo focus on the process rather than product complexity, I deliberately chose a simple application: a personal todo list.\n\nI launched Codex in the folder containing the base files and gave it a brief similar to this:\n\nI want to create a simple todo list application that allows me to add items, view the list, delete items, and mark them as completed.\n\nI do not need authentication. I would like to use Next.js and deploy the application to Vercel for personal use.\n\nI would like your recommendations regarding the architecture. I would also like a subagent to research best practices for this type of dashboard.\n\nOnce the research is complete, ask me all the questions necessary to clarify even the smallest product details.\n\nCodex began asking me questions until the main open points had been clarified.\n\nThe 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:\n\n```\n$create-prd\n```\n\nThe resulting `PRD.md`\n\nfile represents what we want to build. In my case, it contains:\n\nThe division into phases is particularly important. It makes little sense to ask Codex to implement the entire product in a single session.\n\nEach 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.\n\nAs mentioned earlier, the repository already contained a base `AGENTS.md`\n\nfile derived from the previous `CLAUDE-template.md`\n\n. This file includes the initial structure and general guidelines that I want to preserve across every project.\n\nAfter defining what needed to be built, I invoked:\n\n```\n$create-rules\n```\n\nIn my workflow, this Skill did not create `AGENTS.md`\n\nfrom scratch. It analyzed the PRD and the repository, then expanded the existing file with project-specific information, including:\n\nIt is important for the final result to remain concise enough. `AGENTS.md`\n\nshould contain instructions that are generally applicable to the repository. Specialized documentation can live in separate files, provided that `AGENTS.md`\n\n, a Skill, or a plan clearly indicates when it should be consulted.\n\n`$prime`\n\nOnce the initial project definition was complete, I opened a new session and invoked:\n\n```\n$prime\n```\n\n**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`\n\n, `AGENTS.md`\n\n, the repository, and the Git history.\n\nWhen I open the new session, Codex has already loaded the applicable instructions contained in `AGENTS.md`\n\n. The `$prime`\n\nSkill then completes its mental model by:\n\nAt the end, Codex provides a summary of its understanding of the project.\n\nThis phase should be reviewed carefully. If the agent's mental model is incorrect, it is best to intervene before moving on to implementation.\n\nAt this point, we reach the core of the **PIV** cycle:\n\n```\nPlan → Implement → Validate\n```\n\nEach phase of the PRD goes through these three steps.\n\nI selected the first phase identified by Codex and invoked:\n\n```\n$plan-feature\n```\n\nThis phase does not produce any code yet. Its purpose is to turn a PRD feature into a detailed technical plan.\n\nCodex analyzes the repository, consults the relevant documentation, and defines:\n\nIn my case, `$plan-feature`\n\nproduced a new persistent file:\n\n```\n.agents/\n└── plans/\n    └── implement-todo-dashboard-mvp.md\n```\n\nThis detail is important: the plan does not remain confined to the conversation but becomes an artifact stored in the repository.\n\nThe 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.\n\nBefore proceeding, I reviewed the file to verify that it:\n\nOnce the plan had been approved, I opened a new session dedicated to execution.\n\n**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.\n\nI then invoked:\n\n```\n$execute .agents/plans/implement-todo-dashboard-mvp.md\n```\n\nDuring this phase, Codex followed the tasks defined in the document, created the necessary files, implemented the todo list dashboard, and added the planned checks.\n\nThe purpose of `$execute`\n\nis to carry out an already approved plan. If an important unforeseen decision emerges during the work, the agent stops and asks for clarification.\n\nOnce implementation is complete, the third phase of the PIV cycle begins: validation.\n\nCodex runs the checks defined in the plan, for example:\n\n```\nnpm run typecheck\nnpm run lint\nnpm run build\nnpm run test\n```\n\nFor a web application, however, these checks are not sufficient. The actual behavior of the interface must also be verified.\n\nIn my case, the main scenarios were:\n\nAs in Cole's example, the `agent-browser`\n\nSkill can be used to automate these flows and test the application as a user would.\n\nAutomated 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.\n\nAfter verifying that the feature worked correctly, I invoked:\n\n```\n$commit\n```\n\nThe Skill standardizes the commit message, describing what was implemented and how it was validated.\n\nThe 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.\n\nDuring a future execution of `$prime`\n\n, the agent can review recent commits to understand how the project has evolved and which parts of the PRD have already been addressed.\n\nWith this methodology, the repository contains several layers of memory:\n\n```\nPRD.md          → what we want to build\nAGENTS.md       → how Codex should work\n.agents/plans/  → how to implement individual features\nGit history     → what was actually changed\nTests           → what must continue to work\n```\n\nFor the next feature, a new context is opened, `$prime`\n\nis run again, and another PIV cycle begins.\n\nAt this point, a comparison with more structured frameworks such as the [BMAD Method](https://docs.bmad-method.org/) is inevitable.\n\nBMAD 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.\n\nThe 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.\n\nA `PRD.md`\n\n, an `AGENTS.md`\n\n, 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.\n\nTo be clear, this does not mean that the workflow is inherently better than BMAD. It simply offers a different trade-off.\n\nA 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.\n\nThe 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.\n\nNaturally, 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`\n\n, tests, and rules remains with the developer.\n\nBefore starting a new project with a coding agent, the question should therefore be:\n\nHow much structure does this project actually need?\n\nFor 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.\n\nAnd 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.\n\nIf you're interested in using the ready-made scaffolding for Codex, you can find it here: [https://github.com/eleonorarocchi/codex-agentic-starter](https://github.com/eleonorarocchi/codex-agentic-starter)\n\n.. and please give it a star ;-)", "url": "https://wpnews.pro/news/how-i-use-codex-to-build-applications-without-losing-control", "canonical_source": "https://dev.to/eleonorarocchi/how-i-use-codex-to-build-applications-without-losing-control-18l7", "published_at": "2026-07-31 05:19:00+00:00", "updated_at": "2026-07-31 05:31:46.554381+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "artificial-intelligence"], "entities": ["Cole Medin", "Claude Code", "Codex", "OpenAI"], "alternates": {"html": "https://wpnews.pro/news/how-i-use-codex-to-build-applications-without-losing-control", "markdown": "https://wpnews.pro/news/how-i-use-codex-to-build-applications-without-losing-control.md", "text": "https://wpnews.pro/news/how-i-use-codex-to-build-applications-without-losing-control.txt", "jsonld": "https://wpnews.pro/news/how-i-use-codex-to-build-applications-without-losing-control.jsonld"}}