I have been putting more of my LLM workflow into skills lately.
Not "clever prompts I paste into whichever agent I happen to be using", but small reusable instruction packages that an agent can load when a task needs a specific workflow. The nice part is that these are made with a fork of Codex's built-in skill creator. I tweaked that fork so it does not assume Codex is the only target.
So the same general shape works in Codex, Cursor, Claude Code, and other harnesses that understand filesystem-style agent skills.
Four of them are public now.
aso-optimizer
aso-optimizer is my practical take on AI search optimization.
It is deliberately boring: make the page useful to humans, crawlable to Google, and understandable to browser agents. No llms.txt cargo cult, no keyword soup, no fake citation games.
Example uses: drafting a product page so it answers the buyer's question early, or auditing a blog post before publishing to make sure it has original value, useful headings, working internal links, and images that actually help.
be-thorough
be-thorough is for the moments when I do not want an agent to declare victory just because the happy path compiled.
It turns "be thorough" into an actual completion workflow: verify, audit, fix, verify again, and do a final requirement check against the source prompt.
I use it for bigger coding changes, UI work, long issue lists, PRDs, or anything where "close enough" is how future me gets punished.
planetable
skill-planetable lets an agent talk to my local Planet/Planetable API.
It can discover the local port, list planets, search existing content, create or update articles, attach images, and publish when I explicitly ask for that.
I used it for this post, which is the satisfying kind of dogfooding. The agent drafted the text, generated the header image, uploaded the attachment, and wrote the article into my bruno.eth Planet without me clicking through the UI.
audit-code
agent-skills-audit is a stricter code-audit workflow.
It pushes the agent into a two-pass audit with security, performance, UX, DX, edge cases, and a tie-breaker lead. The output is findings first: severity, confidence, evidence, and concrete fixes.
I use this when I want a repo treated less like a casual review and more like a search for the uncomfortable stuff: missing invariants, route parity bugs, stale docs, edge cases hidden behind happy paths.
why bother
The boring reason: I got tired of re-explaining the same standards to every agent and every harness.
A skill is nicer than a long prompt because it can carry workflow, examples, guardrails, helper scripts, and references. Once the shape is stable, the harness matters less. Codex, Cursor, Claude, the next thing: load the same skill, adapt the tool names, keep the judgment.
That is also why the skill creator fork matters. I do not want Codex-only skills. I want portable operating procedures for agents.
The agents are getting better, but they still benefit from being told how to work. These skills are my attempt to make that instruction layer less disposable.