You write a skill for Claude Code: a SKILL.md file of instructions the agent loads when a task matches it. You test it on the model you use every day. It works, so you share it with your team. Then a colleague installs it in Codex (OpenAI’s coding agent), or runs it on a cheaper model to save money, and the skill quietly does something else. Nothing errors. The output is just worse. Everyone blames the model.
Paul Bakaus hit this at scale. He builds and maintains Impeccable, an open-source design skill that installs into Claude Code, Codex, Cursor (an AI code editor) and several other harnesses [1]. A harness is the program wrapped around a model that gives it tools, files and rules, so Claude Code, Codex and Cursor are all harnesses. In “The Dark Arts of Skill Engineering,” a workshop he gave at the AI Engineer World’s Fair in late June 2026, he walked through what it took to make one skill behave the same in all of them [2], [3], [4]. The recording went up on YouTube on September 21. His summary of the job: “prompting is sort of like the starter level, but harness engineering is where you should end up” [2].
We checked every harness claim in the talk against the vendors’ own docs and source code on October 6, 2026, and some had already changed in the three months since he gave it. We flag each change where it comes up, since those changes are what this article is about.
Figure 1 - One File, Three Programs: The same SKILL.md runs in three harnesses on different models. Each harness has its own rules.
The skill that worked in one harness and quietly failed in another
Bakaus’s clearest example is Impeccable’s critique command. Asking one model to review its own design is, in his words, “like grading your own homework” [2]. So critique starts two sub-agents (separate model sessions, each with its own context, launched by the main agent) that never see each other’s work. One plays a design director and inspects the live page. The other runs Impeccable’s detector, a script that flags known bad patterns. The main agent then reconciles the two. His slide sums it up: “two blind opinions beat one confident guess” [3]. The idea of splitting the maker from the judge is the one we covered in The Adversarial Evaluator [5].
In Claude Code this works, because the agent may start sub-agents on its own when a task fits [6]. In Codex, when Bakaus built it, it didn’t. Codex delegated only when the user explicitly asked for sub-agents, so a skill that asked on its own got nothing [2]. Nothing told the user, either. “If there is no punishment for not spawning sub agents it will simply not spawn them,” he said [2]. The critique ran in one context, graded its own homework, and reported a result.
Figure 2 - The Critique That Lost Its Second Opinion: In Claude Code the critique spawns two reviewers that never see each other’s work. In Codex, as Bakaus first built it, one model reviewed its own output, and nothing said so.
The prose was identical in both places. What differed was a rule the skill file never mentions, one its author never had to think about while testing in a single harness: who is allowed to start a sub-agent. Bakaus found several more rules like it [2]:
- Asking the user a question. Codex has a tool for putting one to three short questions to the user, but only in plan mode (a mode where the agent proposes a plan before it touches any files). Outside plan mode, a skill that wants to ask usually just guesses from context. Codex’s own source still describes the tool as “only available in Plan mode” by default [7], and the switch that would allow it elsewhere is marked as under development and turned off [8].
- Waking up when background work ends. When a background command finishes, Claude Code sends the model a notification so it can react [6], [9]. Bakaus reports that Codex and other harnesses don’t, so the user has to prompt the model to go and look [2]. No Codex doc we found settles it, so that half is his finding.
- Which model reads the file. Bakaus found that GPT models in Codex favour tight letter-spacing and very rounded borders, and that Gemini (Google’s model) adds a hover zoom to every image [2]. His talk materials name the exact tells,
letter-spacing: -0.06emandimg:hover { scale(1.1) }[3]. When he told Claude not to tighten letter-spacing so much, it overcorrected in the opposite direction [2].
Each one is an assumption baked into a skill that looks portable. One file run in three harnesses on three models behaves like three programs, and its author tested only one.
Figure 3 - What the File Never Says: Four rules decide how a skill behaves, and none of them appears in the skill. Each harness answers them differently.
The obvious fix: write better instructions
The first thing most of us reach for is better prose. Bakaus started where many of us did, with Anthropic’s frontend-design skill: a list of named bans, with no scripts and no routing [2], [3]. The original told the model never to use “overused font families (Inter, Roboto, Arial, system fonts)” [10].
It worked some of the time. Mostly it didn’t, he said [2]. For any brief, a model has a default answer: the most typical output its training pulls it toward. His slide calls this “the median is the model’s gravity” [3]. A ban doesn’t remove the pull. As he put it, “a ban only moves the model around inside its own cluster” [2]. Forbid one font and you get the next most typical font, not a fresh idea. His slide is blunt about how far prose can go: “Even 250 lines of real taste can’t out-write it” [3].
Two changes inside the skill helped. The first is to hand the model a starting point it would never choose. Impeccable ships a script holding over 100 hand-picked colours, and it gives the model one at random when a project starts, so the same brief produces different palettes [2]. Bakaus calls this an anti-attractor. We’d use the same trick in any skill that keeps converging on the same answer, such as one that brainstorms test cases.
Figure 4 - A Ban Moves, a Seed Escapes: Banning the model’s first choice moves it to its second choice in the same cluster. A random seed from a script starts it somewhere it would never go on its own.
The second change is to stop loading rules that don’t apply. “Avoid system fonts” is sound advice for a landing page and poor advice for an app’s settings screen, where system fonts look native [2]. One big file full of if-this-then-that branches wastes tokens (the units a model reads and is billed by) and gets followed poorly, he argues. So Impeccable uses a small router: a short root file that loads other instruction files only when a task needs them. The critique and polish commands each load their own file, and the skill quietly decides whether a brief is brand work or product work, then loads a different rule set for each [2]. Anthropic rewrote its frontend-design skill in June, and the system-fonts line is gone [11].
The same shape fits a code-review skill. A small root file sends an authentication change to a security rules file and a UI change to a style rules file, so neither set of rules gets in the other’s way.
Figure 5 - Load Only the Rules the Task Needs: A router loads only the file the current task needs. In this illustrative code-review skill, an authentication change gets the security rules and a UI change gets the style rules.
These fixes still leave a gap. Each one is text the model has to choose to read and follow. Strong models mostly do. Weak ones skim. Bakaus calls GPT-5 mini (a small OpenAI model) “not a very good rule follower” and says it consistently fails to load some of Impeccable’s files [2]. If a skill has to survive the cheapest model someone on your team runs, better prose can’t carry the rules that matter.
The second fix: move the rules into things the harness runs
Bakaus’s next move was to put instructions where the model can’t skip them, starting with script output. His context.mjs script runs at the start of every call to gather the project’s design notes. When those notes are missing, the script doesn’t leave the model to find the right rule somewhere in the prose. It prints structured output that tells the model the exact next step [2]. His finding was that when an instruction comes “from the standard out of a script,” the model follows it “a lot more” than a rule buried in the skill [2]. Claude Code supports this directly: a skill can contain a !`command` line, and Claude Code runs the command and puts its output into the skill before the model sees it [12]. Anthropic’s skill-writing guide makes a similar case for bundled scripts, which it calls “More reliable than generated code” [13].
This has a cost, and Bakaus names it on his slide: “it breaks prompt caching” [3]. Prompt caching lets a provider reuse the processed start of a prompt it has already seen, which saves time and money. The cache works on the beginning of the prompt, and in Anthropic’s words, “Changes at each level invalidate that level and all subsequent levels” [14]. So output that changes on every run can’t come from an earlier run’s cache. The cache stops helping at the point where the script output begins. Bakaus’s advice is to skip the technique for a skill you call very often and need cached [2].
Figure 6 - The Rule the Model Actually Reads: A rule in the middle of the prose gets skimmed. The same rule printed by a script gets followed. The price is the cache, which stops where the changing output begins.
Hooks came next. A hook is a script the harness runs on its own at a fixed point, such as just before or just after a file is written. Even an installed skill gets forgotten when the user doesn’t mention it, so Impeccable also ships a design-lint hook that checks every edit. His slide: “passive guardrails beat a command no one remembers to run” [3]. He found that the right timing depends on the model. A PostToolUse hook fires after the file is written and asks the model to fix what it finds. A PreToolUse hook fires before the write and can refuse it. With weaker models (his example is Composer, Cursor’s own fast model), the after-the-fact warning wasn’t followed reliably, so Impeccable blocks the write instead [2]. Claude Code’s docs confirm the mechanism: a PostToolUse hook “cannot undo” a tool call that already ran [15]. He also warns that hooks throw false positives, so any hook you ship needs a way for users to add ignore rules [2].
We run the same idea on this site. Our writing rules ban em dashes, a rule written into our project instructions. A PostToolUse hook now checks every file write for them and hands any hits back to the agent, which fixes them on the spot. In August we found 7 dash violations that had reached visible copy on our page templates, 2 of them in meta tags, because the hook had never checked those files. We widened it to cover them. Ours is an after-the-write warning, and it holds on a strong model, which fits Bakaus’s point that only the weaker models needed the hard block.
Figure 7 - Warn After, or Block Before: A PostToolUse hook can only ask the model to fix a file it already wrote. A PreToolUse hook can refuse the write, which Bakaus found weaker models needed.
Memory was the third piece. A skill starts fresh every time it runs. Impeccable writes each critique into a .impeccable folder in the project, and a later polish run, maybe days later, reads those notes, including a user’s earlier objection to a font change [2].
Claude Code’s docs now draw the line between these pieces: pick a skill when “You keep pasting the same instructions into chat,” and a settings hook when “You want to block, allow, or log an event with a script you already have” [16]. We covered Claude Code’s newer mods (plugin code that stays running inside the session) in Hooks Run Once. Mods Stay Resident [17].
So the machinery works, but all of it belongs to a harness, and the harnesses don’t match:
- The skill’s own folder. Claude Code gives a skill
${CLAUDE_SKILL_DIR}, a variable that resolves to the skill’s own folder, so its scripts can find their files [12]. Codex tells the model the skill’s file path but offers no such variable [18]. Cursor uses paths relative to the skill folder [19], and Gemini CLI (Google’s command-line agent) adds the folder to the agent’s allowed paths [20]. Impeccable’s harness notes put it flatly: “No other harness supports substitution in skills” [21]. - Hooks. These look alike now. Codex and Claude Code use near-identical JSON, and both let a PreToolUse hook deny a call [22], [15]. The differences moved elsewhere. The config files live in different places. Codex documents 12 hook events and Claude Code documents 33. Codex reports file edits as
apply_patch, so a script that checks the tool name has to branch by harness [22], [15]. Codex also states that “Non-managed hooks must be reviewed and trusted before they run” [22]. A hook you ship isn’t live on Codex until each user approves it, and Impeccable’s README tells Codex users to do that at/hooks[1].
So the fix that made the skill reliable also tied more of it to each harness. Every piece that leans on one harness is a piece you have to rewrite for the next.
Figure 8 - One Hook, Two Installs: The JSON has converged. What differs is where the file lives, 33 events against 12, the apply_patch name, and Codex’s trust step.
KEY INSIGHT: Move any rule that has to hold out of the prose and into a script’s output or a hook. Then write down which harness each of those pieces depends on, because that list is what it costs you to support the next harness.
The third fix: make the skill say when it can’t do the job
The Codex sub-agent problem had no machinery fix, so Bakaus wrote a behavioural one. If Codex has sub-agents available but no permission to use them, the skill tells it to stop and ask the user [2]. If it still can’t use them, it must tell the user it is giving them a degraded experience. Codex, he said, hates admitting that, so he uses it to his advantage [2]. Impeccable’s current critique file asks once whether it may use sub-agents, and if the answer is no, it prints a DEGRADED: single-context banner before the critique [23]. The user still gets the weaker critique, but now the report says so.
He applied the same thinking to weaker models. “A weaker model has opinions just fine, but what it loses is the discipline to follow yours,” his slide reads [3]. GPT-family models (the OpenAI models Codex runs on), he found, respond to the word “gate,” so Impeccable’s Codex-only instructions give the model 8 numbered gates. It has to pass every gate, log the result of each one, and is not allowed to compress them. Without that, it skims the list, does gates 1, 2 and 5, and reports success [2]. His rule: “If the gate can be skipped, it will be” [3]. The logs make it hard for the model to quietly take the easier route.
Figure 9 - Gates That Log Their Own Result: A long checklist gets skimmed, and the model reports success after doing 3 of 8. Gates that each log a result leave a record of every skipped step.
Then the ground moved. Codex reads AGENTS.md (a plain instructions file at a repository’s root that coding agents read at startup). On June 26, 2026, three days before the World’s Fair opened, Codex merged a change titled “allow AGENTS.md and skills to authorize delegation” [24]. Codex’s docs now say: “Current local Codex releases delegate when you ask directly or when applicable AGENTS.md or skill instructions request it” [25]. The rule Codex gives its model still forbids spawning sub-agents unless the user or those instructions “explicitly ask” [26]. Codex made Bakaus’s workaround the rule. The skill asks, and that counts. At most intelligence levels, Codex still won’t delegate on its own judgement the way Claude Code and Cursor do [25], [6], [27]. Its docs say only the top Ultra level delegates proactively [25].
That’s good news for Impeccable, and it also shows the problem, since by the time most people watched the talk, its lead example had partly aged. Claude Code moved as well, and since v2.1.277 it reads AGENTS.md directly [28].
Figure 10 - The Harness Moved Under the Talk: Codex changed its sub-agent rule on June 26, 2026, three days before the conference opened. When we checked on October 6, Codex’s docs confirmed that a skill’s own instructions can authorize delegation.
What’s still broken: the skill now carries a Codex branch, a GPT gate block and a Gemini block, all in one place, and those branches don’t stay right. OpenAI’s blog post on rethinking skills for GPT-6 Astra, its newest model, warns that guidance written for its other models (it names Sol and Luna) “may overconstrain GPT-6 Astra” [29]. That cuts against the numbered gates Bakaus wrote for the GPT models Codex ran when he built them [2]. Anthropic says the same of Opus and Haiku, its largest and smallest models: “What works perfectly for Opus might need more detail for Haiku” [13]. Shipping the branches is hard too. The common npx skills command-line installer finds one build by name and points every agent at a single copy. Bakaus has an open pull request to change that, and it notes that “pbakaus/impeccable ships ~12 per-agent builds” [30].
KEY INSIGHT: Give every shared skill a fallback that prints a visible warning when a harness or model can’t run the full version. Then a user who gets the reduced result knows it.
Treat a shared skill as a small cross-platform product
The skill that holds up is built the way you’d build any program that ships to three operating systems. It has four parts:
- One shared body, plus small per-harness and per-model pieces added at install time. Impeccable compiles about 12 builds from one source, each carrying blocks for the drift its model shows [30], [2]. Octen (a search-API company) ships a lighter version anyone can open: one shared
SKILL.mdper skill plus a smallagents/openai.yamlfile that carries only Codex’s display text, installed to either harness by changing one flag,-a codexor-a claude-code[31]. - Machinery for every rule that must hold, from the second fix, with each harness dependency written down.
- A loud fallback, from the third fix.
- Evidence for each line. Bakaus says “every line of impeccable is ablation tested” [2]. Ablation means removing one part to see if the result changes. His private eval harness (a test rig that runs the skill and scores its output) mimics the Claude Code, Codex and Gemini tool sets, removes one tagged rule at a time, and re-scores the output across models with Impeccable’s detector [2]. It isn’t public. Don’t Ship Skills Without Evals covers how to build evals (repeatable tests that score a skill’s output) for your own skill [32].
This fixes the problem from the first section. The hidden assumptions used to be written down nowhere. Now each one sits in a place you can see. The sub-agent rule lives in the Codex branch. The letter-spacing drift lives in the Codex model block. The missing folder variable is handled at install. When a vendor changes one of them, you know which small file to edit, and your evals tell you whether the edit worked.
Figure 11 - Shared Body, Small Differences: One instruction body, written once, with per-harness and per-model pieces attached at install. Octen does it with one small Codex file, Impeccable with about 12 compiled builds.
A skill that writes its own notes changes over time, so those changes need review too. On a first run, Anthropic’s /verify skill writes the steps that worked to .claude/skills/verify/SKILL.md [12], and Anthropic advises extending that file rather than accepting it as is [33]. Before v2.1.205, it folded in everything each run learned, which “caused frequent merge conflicts,” so Anthropic narrowed it to edit the file only when a run went wrong [12]. At Warp, Suraj Gupta, who leads harness development there, describes an outer-loop agent that watches another agent’s runs and user feedback, then opens a pull request against that agent’s skill file for a person to review, though he gives no numbers for it [34]. A skill change becomes a diff you can read and revert.
One result suggests a skill can carry across models and harnesses when it is learned rather than written. GEPA (an open-source optimizer for prompts and other text) has a feature called GSkill that learns a skill from an agent’s own attempts instead of having a person write it. Lakshya A. Agrawal, one of GEPA’s creators, presented it [35]. In the team’s write-up, a skill learned on a simple agent called Mini-SWE-Agent, running the cheap gpt-5-mini model, lifted its resolve rate (the share of tasks it fixed) on the Bleve Go repository from 24% to 93%. That was on a held-out test set: about 60 synthetic tasks the skill never learned from [36]. The same skill, dropped into Claude Code with Anthropic’s Sonnet 4.5 model, raised the pass rate from 94.8% to 100% and cut average time from 285 to 169 seconds, about 41% [36]. Read the 100% as a ceiling, since Sonnet was already close to it. The time saving is the useful number. What transferred, across both a model and a harness, was knowledge about the repository: where things live and how to run its tests. It only works where every attempt can be scored, which brings you back to evals.
Figure 12 - A Learned Skill That Travelled: A skill learned on gpt-5-mini took it from 24% to 93% on about 60 held-out Bleve tasks. On Sonnet 4.5 in Claude Code it moved 94.8% to 100% and cut average time by about 41%.
KEY INSIGHT: Keep one shared skill body and put each harness or model difference in its own small, named file beside it. When a vendor changes a behaviour, you edit that one file and rerun your evals instead of hunting through prose.
Where this stops working
Most per-harness findings come from one maintainer, using evals nobody else can run. We confirmed the ones the vendors document. The Codex background-wake gap, the finding that weaker models need a PreToolUse block, and every model’s drift remain Bakaus’s observations.
Harness behaviour also moves in point releases. We checked the docs and source on October 6, 2026, so read every harness fact here as true on that day.
Every fix also has a running cost. Script output gives up part of the prompt cache, hooks need ignore rules and a trust step on Codex, and per-model blocks need retesting whenever a model changes. GSkill’s skills hold knowledge about one repository, and its 100% sits on about 60 synthetic tasks.
Bakaus is candid: “I would rather see less skills in the ecosystem that are really battle tested and proven,” he said [2].
Conclusion
Bakaus’s critique skill failed in Codex without a word of warning. What made it dependable was a set of named pieces: a shared body, a small branch for each harness and model, scripts and hooks for the rules that must hold, a visible fallback, and evals behind each line. Built that way, a skill survives a vendor changing the rules under it, which Codex did three days before the conference opened.
Start with one skill your team already shares. Run it in the second harness, or on the cheapest model, that someone on your team actually uses. When it finishes, ask the agent which tool it actually called, because a success message doesn’t prove the skill ran. Then move the one rule that has to hold out of the prose and into a script or a hook, and make the skill say out loud when it is running the reduced version.
References
[1] P. Bakaus, “Impeccable,” GitHub repository (Apache-2.0), accessed Oct. 6, 2026. https://github.com/pbakaus/impeccable
[2] P. Bakaus, “The Dark Arts of Skill Engineering,” AI Engineer World’s Fair 2026 workshop, YouTube, published Sep. 21, 2026. https://www.youtube.com/watch?v=SQMCtZX3trg
[3] P. Bakaus, “impeccable-talks: dark-arts,” talk materials for the AI Engineer World’s Fair workshop, GitHub, Jul. 2026. https://github.com/pbakaus/impeccable-talks/tree/main/dark-arts
[4] AI Engineer, “AI Engineer World’s Fair 2026,” ai.engineer, accessed Oct. 6, 2026. https://ai.engineer/worldsfair/2026
[5] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “The Adversarial Evaluator: GAN-Inspired Harness Architecture from Anthropic,” Dotzlaw Consulting, June 23, 2026. /insights/ai-03-adversarial-evaluator/
[6] Anthropic, “Create custom subagents,” Claude Code Documentation, accessed Oct. 6, 2026. https://code.claude.com/docs/en/sub-agents
[7] OpenAI, “request_user_input_spec_tests.rs,” openai/codex repository, GitHub, commit c0c230e, accessed Oct. 6, 2026. https://github.com/openai/codex/blob/c0c230e6730b3b3c9101b8aff4b9aea4027cea5b/codex-rs/core/src/tools/handlers/request_user_input_spec_tests.rs#L176-L181
[8] OpenAI, “features/src/lib.rs,” openai/codex repository, GitHub, commit c0c230e, accessed Oct. 6, 2026. https://github.com/openai/codex/blob/c0c230e6730b3b3c9101b8aff4b9aea4027cea5b/codex-rs/features/src/lib.rs#L1739-L1743
[9] Anthropic, “Tools reference,” Claude Code Documentation, accessed Oct. 6, 2026. https://code.claude.com/docs/en/tools-reference
[10] Anthropic, “frontend-design SKILL.md” (original version), anthropics/claude-code repository, GitHub, Nov. 2025. https://github.com/anthropics/claude-code/blob/62c3cbc47147ddbf666b210be13a91133e7d449e/plugins/frontend-design/skills/frontend-design/SKILL.md
[11] Anthropic, “Update frontend-design skill,” Pull Request #1293, anthropics/skills repository, GitHub, merged June 9, 2026. https://github.com/anthropics/skills/pull/1293
[12] Anthropic, “Extend Claude with skills,” Claude Code Documentation, accessed Oct. 6, 2026. https://code.claude.com/docs/en/skills
[13] Anthropic, “Skill authoring best practices,” Claude Platform Documentation, accessed Oct. 6, 2026. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices
[14] Anthropic, “Prompt caching,” Claude Platform Documentation, accessed Oct. 6, 2026. https://platform.claude.com/docs/en/build-with-claude/prompt-caching
[15] Anthropic, “Hooks reference,” Claude Code Documentation, accessed Oct. 6, 2026. https://code.claude.com/docs/en/hooks
[16] Anthropic, “Mods overview,” Claude Code Documentation, accessed Oct. 6, 2026. https://code.claude.com/docs/en/plugins/mods/overview
[17] G. Dotzlaw, “Hooks Run Once. Mods Stay Resident: Where a Rule Should Live in Claude Code,” Dotzlaw Consulting, October 9, 2026. /insights/claude-code-22-mods-vs-hooks-resident-guardrails/
[18] OpenAI, “Build skills,” Codex Documentation, learn.chatgpt.com, accessed Oct. 6, 2026. https://learn.chatgpt.com/docs/build-skills
[19] Cursor, “Skills,” Cursor Documentation, accessed Oct. 6, 2026. https://cursor.com/docs/skills
[20] Google, “Agent Skills,” Gemini CLI Documentation, accessed Oct. 6, 2026. https://geminicli.com/docs/cli/skills/
[21] P. Bakaus, “HARNESSES.md,” Impeccable repository, GitHub, accessed Oct. 6, 2026. https://github.com/pbakaus/impeccable/blob/main/docs/HARNESSES.md
[22] OpenAI, “Hooks,” Codex Documentation, learn.chatgpt.com, accessed Oct. 6, 2026. https://learn.chatgpt.com/docs/hooks
[23] P. Bakaus, “critique.md,” Impeccable repository, GitHub, accessed Oct. 6, 2026. https://github.com/pbakaus/impeccable/blob/main/skill/reference/critique.md
[24] OpenAI, “[codex] allow AGENTS.md and skills to authorize delegation,” Pull Request #30274, openai/codex repository, GitHub, merged June 26, 2026. https://github.com/openai/codex/pull/30274
[25] OpenAI, “Subagents,” Codex Documentation, learn.chatgpt.com, accessed Oct. 6, 2026. https://learn.chatgpt.com/docs/agent-configuration/subagents
[26] OpenAI, “multi_agents_spec.rs,” openai/codex repository, GitHub, commit c0c230e, accessed Oct. 6, 2026. https://github.com/openai/codex/blob/c0c230e6730b3b3c9101b8aff4b9aea4027cea5b/codex-rs/core/src/tools/handlers/multi_agents_spec.rs#L738-L739
[27] Cursor, “Subagents,” Cursor Documentation, accessed Oct. 6, 2026. https://cursor.com/docs/subagents
[28] Anthropic, “Manage Claude’s memory: AGENTS.md,” Claude Code Documentation, accessed Oct. 6, 2026. https://code.claude.com/docs/en/memory#agents-md
[29] E. Provencher, “Rethinking skills and prompts for GPT-6 Astra,” OpenAI Developers Blog, Sep. 11, 2026. https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra
[30] P. Bakaus, “feat: honor per-provider skill variants on install,” Pull Request #1291 (open), vercel-labs/skills repository, GitHub, opened May 28, 2026. https://github.com/vercel-labs/skills/pull/1291
[31] Octen, “octen-skills,” GitHub repository (MIT), accessed Oct. 6, 2026. https://github.com/Octen-Team/octen-skills
[32] G. Dotzlaw, “Don’t Ship Skills Without Evals: A Reproducible Way to Prove Your Claude Code Skills Work,” Dotzlaw Consulting, September 9, 2026. /insights/claude-code-18-skill-eval-methodology/
[33] Anthropic, “Building verification loops in Claude Code,” Claude (YouTube), Sep. 25, 2026. https://www.youtube.com/watch?v=mQZB0l-rhxE
[34] S. Gupta, “Building Self-Improving Agent Software Factories,” AI Engineer, YouTube, Sep. 27, 2026. https://www.youtube.com/watch?v=TN3mj92oZ8I
[35] L. A. Agrawal, “Beating RL With Reflection: GEPA and Optimize Anything,” AI Engineer, YouTube, Sep. 26, 2026. https://www.youtube.com/watch?v=OA-Mc60Rboo
[36] S. Tan, L. A. Agrawal, R. Sandadi, D. Klein, K. Sen, A. G. Dimakis, and M. Zaharia, “Automatically Learning Skills for Coding Agents,” GEPA Blog, Feb. 18, 2026. https://gepa-ai.github.io/gepa/blog/2026/02/18/automatically-learning-skills-for-coding-agents/
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.