Journal entry
The Skill Stack Behind My Codex Workflow
The Skill Stack Behind My Codex Workflow
If you only use Codex as a raw autocomplete engine, you miss the best part: you can give it reusable operating context. My workflow today is not one prompt and one assistant. It is a stack of skills that turns Codex into a planner, frontend engineer, reviewer, QA tester, publishing tool, and domain specialist depending on the job.
Some of these skills came from the community. Some are custom skills built around workflows I repeat often. The important shift is that I no longer think in terms of "What should I prompt?" I think in terms of "What operating mode should Codex enter for this task?"
That stack has grown a lot through recent work. It now covers planning, React architecture, frontend refinement, browser testing, terminal-first publishing, and domain-specific operating workflows.
Here are the skill groups I reach for most often right now.
1. Start with structure, not code
When I am starting a feature or project, I want Codex to understand scope before it writes anything.
p4rdturns vague ideas into a real plan, roadmap, and task sequence. It is the difference between "build something like X" and "ship a project with a clear execution path."obsidiankeeps project notes and architecture context synced into my vault instead of leaving decisions scattered across chats and commits.skill-creatorhelps me turn a repeated workflow into a reusable skill instead of solving the same problem from scratch every week.full-output-enforcementis the guardrail I use when partial answers would be worse than no answer at all. It pushes Codex to finish the job instead of handing back a stub.
This planning layer has changed how I work more than anything else. Better context at the start means less cleanup later.
2. React work is safer when the rules are explicit
A lot of AI-generated React code looks fine for five minutes and then falls apart under real complexity. My React stack is there to stop that.
react-doctoris my post-change sanity check. After a React pass, I can run it and get a score plus actionable issues around correctness, architecture, performance, and security.vercel-react-best-practiceskeeps the code aligned with modern React and Next.js or Vercel patterns.react-state-managementandzustand-state-managementhelp Codex pick the right state shape instead of inventing a store on the fly.react-performance-optimizationkeeps an eye on rendering cost, bundle pressure, and the places where memoization actually matters.tanstack-query-best-practices,tanstack-router-best-practices, andtanstack-start-best-practicesmatter when the app grows up and needs disciplined data loading, routing, SSR, and server boundaries.
This is the difference between "AI can build React" and "AI can help maintain a React codebase I actually trust."
3. Frontend quality is now a stack, not a single prompt
The biggest change in my setup recently is that frontend work is no longer handled by one design skill. It is a layered system.
A lot of that recent expansion came from Impeccable, Paul Bakaus's design-skill bundle for AI harnesses. It builds on the original frontend-design foundation and packages a much richer design vocabulary around typography, color, layout, motion, critique, and anti-patterns. That mattered a lot for me because it turned frontend prompting from "make this nicer" into a real sequence of targeted design passes.
The recently added Impeccable set in my stack includes adapt, animate, audit, bolder, clarify, colorize, critique, delight, distill, extract, harden, normalize, onboard, optimize, polish, quieter, and redesign-existing-projects. Together they gave Codex a much more usable language for refinement instead of forcing everything through one catch-all design prompt.
I still start with:
frontend-designdesign-taste-frontend
Those two push Codex away from generic AI layouts and toward stronger visual direction.
But the real upgrade comes from the follow-up passes:
auditto find accessibility, performance, responsive, and anti-pattern issuesadaptto make the design work across mobile, tablet, and desktop contextshardento handle long text, bad data, errors, empty states, and real-world messinessoptimizeto improve rendering, asset strategy, and interaction performancepolishto clean up the last 10 percent of spacing, rhythm, consistency, and state detail
Then I can layer in targeted refinements depending on what feels off:
clarify,onboard,normalize,extractanimate,delightbolder,quieter,distill,colorize,critiqueredesign-existing-projects
That stack feels much closer to working with a design team than asking for "a nice landing page."
4. Browser automation closes the loop
One of the most useful things about a skill-based workflow is that the same assistant can build and test.
agent-browserandbrowser-uselet Codex interact with the app like a user: open pages, click buttons, inspect flows, and validate the experience in a real browser.capture-api-response-test-fixtureturns live API responses into test fixtures, which is a very practical bridge between exploratory work and repeatable tests.
That makes QA less of an afterthought. The assistant can help implement the feature, then help verify the feature in the same session.
5. I now have skills for the operational work around the product
This is another area where my stack changed a lot recently. I no longer use Codex only for writing application code. I also use it for the workflow around the product.
A perfect example is this blog. I added a custom blog-content-api skill so Codex can inspect posts, update them, manage slugs, and publish through the content API with an API key. That turns content operations into something I can do from the terminal instead of clicking around in an admin UI.
I also lean on utility skills like:
refactor-passfor cleanup after implementationgrepai-search-advancedandfind-skillsto navigate codebases and locate the right tool for the next steplist-npm-package-contentwhen I want to inspect what will actually ship in a package or understand what a dependency containsdevelop-ai-functions-examplewhen I am prototyping tool or function-calling examples around the AI SDK
This category matters because a lot of real work lives outside the happy path of "build component, ship component."
6. Specialist skills are where the setup starts to feel personal
The most interesting part of a custom skill stack is when it stops looking generic.
I still use specialist skills like:
ai-sdkwebsocket-engineerpython-performance-optimizationremotion-best-practices
But lately the stack has expanded further into custom domains:
polyxfor X or Twitter intelligence gathering, sentiment analysis, and report generationpolybotfor operating and verifying a trading system safely, with a bias toward exact commands and real environment checks instead of made-up answers
That is the point where skills stop being prompt templates and start becoming operational memory. Codex can switch contexts without me re-explaining the whole domain every time.
7. The real benefit is composition
The biggest lesson for me is that no single skill is the magic trick. The magic is in chaining them.
A typical workflow now looks like this:
p4rdto shape the workfrontend-designanddesign-taste-frontendto build the first passaudit,adapt,harden,optimize, andpolishto make it production-readyagent-browserto validate behavior in a real browserreact-doctorto catch React-specific regressionsblog-content-apior another domain skill to operate the surrounding workflow
That is a much better use of an AI assistant than hoping a single giant prompt carries the whole project.
Wrapping up
My Codex setup is no longer just a bag of interesting skills from skills.sh. It is a working system: some community skills, some custom skills, and a growing set of specialist playbooks built around the problems I actually solve.
If you are building your own stack, my advice is simple: do not start by collecting as many skills as possible. Start by noticing repeated workflows. The best skills are the ones that remove explanation debt from your day-to-day work.