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.

  • p4rd turns 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."
  • obsidian keeps project notes and architecture context synced into my vault instead of leaving decisions scattered across chats and commits.
  • skill-creator helps me turn a repeated workflow into a reusable skill instead of solving the same problem from scratch every week.
  • full-output-enforcement is 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-doctor is 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-practices keeps the code aligned with modern React and Next.js or Vercel patterns.
  • react-state-management and zustand-state-management help Codex pick the right state shape instead of inventing a store on the fly.
  • react-performance-optimization keeps an eye on rendering cost, bundle pressure, and the places where memoization actually matters.
  • tanstack-query-best-practices, tanstack-router-best-practices, and tanstack-start-best-practices matter 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-design
  • design-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:

  • audit to find accessibility, performance, responsive, and anti-pattern issues
  • adapt to make the design work across mobile, tablet, and desktop contexts
  • harden to handle long text, bad data, errors, empty states, and real-world messiness
  • optimize to improve rendering, asset strategy, and interaction performance
  • polish to 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, extract
  • animate, delight
  • bolder, quieter, distill, colorize, critique
  • redesign-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-browser and browser-use let 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-fixture turns 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-pass for cleanup after implementation
  • grepai-search-advanced and find-skills to navigate codebases and locate the right tool for the next step
  • list-npm-package-content when I want to inspect what will actually ship in a package or understand what a dependency contains
  • develop-ai-functions-example when 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-sdk
  • websocket-engineer
  • python-performance-optimization
  • remotion-best-practices

But lately the stack has expanded further into custom domains:

  • polyx for X or Twitter intelligence gathering, sentiment analysis, and report generation
  • polybot for 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:

  1. p4rd to shape the work
  2. frontend-design and design-taste-frontend to build the first pass
  3. audit, adapt, harden, optimize, and polish to make it production-ready
  4. agent-browser to validate behavior in a real browser
  5. react-doctor to catch React-specific regressions
  6. blog-content-api or 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.