# The Dark Arts of Skill Engineering
**作者**: Paul Bakaus
**日期**: 2026-07-14T19:33:41.000Z
**来源**: [https://x.com/pbakaus/status/2077114326985687525](https://x.com/pbakaus/status/2077114326985687525)
---

It's trivial to create skills. It's really hard to create effective skills. I learned this the hard way, and on my journey picked up some truly arcane knowledge that helped me level up Impeccable from a measly little vibed personal skill to a toolkit that turns your coding harness into a design harness, used by hundreds of thousands of designers and developers.
What follows are those nine techniques: the dark arts that took Impeccable from vibed prose (which is what most skills are today) to a battle-hardened harness extension. Let's get into it.

## Most skills are a prompt and a prayer
Most skills are vibed prose: generated by the same model they target, tested twice, declared working, and enshrined in your skills directory.
There's nothing wrong with that if it's doing the job for you. But the expectations change as soon as you send the skill to others. Suddenly, it has to work…
- …consistently
- …in every popular harness/agent
- …on projects and conditions completely unlike yours
- …with different user prompting styles
- …more than once or twice
- …on frontier models and weaker models
- …on different operating systems
"But Paul", you interject, "I was promised that skills are interoperable and the cure for all of our problems!" And yes, my dear Padawan, I'm as disappointed as you are. We were also promised hoverboards by 2015 and I'm still waiting :( Just because this list makes you uncomfortable if you've already shipped skills doesn't make it less true.
## A skill is a harness extension
If you want your skill to actually do something effectively and consistently, you have to reframe how you look at skills.
Rather than thinking of a skill as a saved prompt the user or agent can retrieve as needed, think of a skill as a plugin: an extension of the harness. A great skill extends the capabilities of Codex, Claude Code or Copilot in areas where it has definite gaps.
Impeccable extends the harness with automatic AI slop prevention tailored to the specific model, a design language and command palette that let you steer toward great design, and a rich visual design mode on your own locally running site. How does your skill extend the harness?
## Great skills make the model do something it really doesn't want to
Great skills make the harness and its models do something they don't want to do. Think about it: if the model naturally wanted to do it already, you wouldn't need the skill in the first place!
In Impeccable's case, Codex + GPT really doesn't want to ask the user questions about their target audience before getting to work. Claude + Opus/Fable really wants to use italic serifs and eyebrow kickers (and them darn pulsating green dots, omg, so many blinking dots). All models really want to put a lot of descriptive text on your site.

The median is the model's gravity
Great prose helps, but it's not enough. Your actual job is to beat the model's defaults consistently, and to make a non-deterministic model behave like deterministic software.

Prompting summons the median; the harness conjures the rest. Every dark art below moves work from prose the model might honor into machinery that forces the outcome.
## The nine dark arts
Time to open the grimoire:
1. Make them argue · two blind reviewers beat one confident guess
2. Force divergence · escape the cluster, don't chase it with bans
3. Route like a frontier model · one command loads one expert
4. Give them memory · runs that compound instead of restarting
5. Scripts that talk back · stdout is the instruction
6. Hooks that fight back · guardrails that fire uninvited
7. Live-wire the browser · the browser becomes a second input
8. Compile to every harness · one source, every runtime, every model
9. Design for the weakest model · gates that can't be skipped
## Dark art #1: Make them argue
Steal it for: code review, security audits, plan/RFC critique, ranking outputs.
Agents are extremely biased toward their own work. That intuitively makes sense, as humans are too: no reasonable parent would let their kid grade their own homework. So why would we let an agent grade its own output in the same thread?
You can, of course, try to fix this with a better, more strongly worded prompt ("be super unbiased!!!!"), but you will fail. Save yourself some time and use adversarial sub-agents instead.

Make them argue
For a concrete example, /impeccable critique, Impeccable's design review command, runs both deterministic checks against your code (to detect stuff like low contrast quickly and decisively) and reviews the design like a human would. But early versions had a major flaw that produced bad critiques: hand the LLM the detector output up front and it skews BOTH ways:
1. detector noisy → condemns a strong page over fixable nits (false alarm)
2. detector silent → rubber-stamps a generic page (meaningless clean bill)

To debias, critique now spawns two sub-agents that never see each other's work: A = an LLM design director (hierarchy, slop, heuristics), B = the deterministic detector + browser evidence. When the sub-agents finish, the main agent synthesizes (weave, never concatenate) the results from both for a balanced critique. Two blind opinions beat one confident guess.
> The Codex wrinkle: sub-agents aren't portable. As of today, on Codex a skill can't spawn one unless the user already allowed parallel work or is in YOLO mode. So for Codex, add some special instructions: "if you can, but don't have permission to spawn sub-agents, STOP and ask the user for permission." (Note: this depends on your permission model, and apparently GPT 5.6 is signicantly more trigger happy with sub-agents)

## Dark art #2: Force divergence
Steal it for: naming, branding, content ideation, variant generation, breaking boilerplate.
If an LLM does something regularly and you don't want it to, it's very tempting to add a line like this:
> don't use Inter or Instrument Serif fonts
Unfortunately, this doesn't do to an LLM what it would do to a human. A human might now go back to the drawing board to pick a truly distinct and fitting font. But the LLM will just pick the next best one. So if you're wondering why we went from purple-gradient AI slop to serif beige AI slop, you now have your answer.

Bans just move the model from one region of latent space into another. The escape is sideways, not a longer denylist.

Here are three techniques that produce higher divergence (cheapest but weakest first):
1. Shave the safe picks: make the model name its top 3 fonts, then discard all three. Out-rank yourself.
2. Generate ~50, a blind sub-agent keeps the 5 most distinct. (Lives in Radiant's codebase, not Impeccable yet.)
3. Seed from outside the model: `palette.mjs --from 8f2a` starts in a region the model never picks on its own.
Of course, these are stackable! With enough finessing, the average becomes unreachable.

## Dark art #3: Route like a frontier model
Steal it for: big multi-tool skills, context on demand, per-audience behavior.
Frontier models like Fable and GPT 5.6 are very sensitive to over-corrective or conflicting prose. It's tempting to put a lot of guidance in a mile-long SKILL.md. Resist.
One solution for this is many isolated, small skills, which works if they're really independent from each other and don't represent a system that the user should use as one. But if you need all capabilities installed anyway, there's a better way, and that's skill-internal routing.
In essence, think of your SKILL.md as an intelligent router, similar to a MoE (Mixture-of-Experts) LLM architecture. Your SKILL.md could:
- Route to specific sub-commands as inferred (for example, load polish.md when the user requests something like "polish my page")
- Load specific files only if a condition applies (auto-load codex.md when the skill is used in Codex, or load brand.md if the requested design is a landing page)

Impeccable routes 23 commands through one SKILL.md this way; each loads exactly one expert reference and leaves the other 22 out of context. You can too.
## Dark art #4: Give them memory
Steal it for: resumable agents, multi-session refactors, migrations.
Say you wrote a "find-bugs" and a "fix-bugs" skill. It's all fun and games until somebody runs the find-bugs skill, closes the agent thread, starts a fresh one and calls "fix-bugs". Suddenly, fix-bugs has no idea what bugs to fix because it lacks prior context.
Most skill authors treat skills as stateless prompts, but there's no rule that says a skill can't have state. Keep in mind that skills can be bundled with scripts that can be run anywhere during the lifecycle of the skill!
Impeccable's critique and polish commands use this technique quite effectively:
1. /critique writes a snapshot per target (score, P0/P1, markdown + frontmatter)
2. /polish reads the latest snapshot as its fix backlog

One non-obvious detail that makes this work across a team: the snapshot slug comes from the resolved file path, not from how you phrased the request. A teammate pointing at the same file inherits the same memory, and the score trend (24, then 28, then 32) survives across sessions.
Besides Impeccable, great examples in this category are the Compound Engineering plugin/skills, or @mattpocockuk's teach skill.
## Dark art #5: Scripts that talk back
Steal it for: environment-aware setup, dynamic onboarding, repo-state gating.
LLMs compress instructions in a long skill, much like a human skimming over a long document. The solution to this is just-in-time delivery.
In other words, if there's a critical step or a real fork in the road where the model must do something or take a different path than expected, have it execute a script and deliver the instruction in the script's stdout.
Impeccable uses this technique in many places. For instance, here's how Impeccable self-initializes on demand:
1. SKILL.md tells the model to run context.mjs (whose main job is to inline PRODUCT.md and DESIGN.md in one call)
2. The skill body says "follow whatever the script prints."
3. The script reads the environment and writes the next instruction back: context.mjs prints NO_PRODUCT_MD, and the agent stops and runs init.

Computed, just-in-time instructions steer harder than anything static. The exit value is the prompt.
Notable trade-off: this technique breaks prompt caching. Decide on a case by case basis whether you prefer cache hit vs obedience.
## Dark art #6: Hooks that fight back
Steal it for: lint/format, secret detection, a11y checks, policy enforcement.
Everything so far only helps when invoked. The agent makes its worst edits when nobody called the skill at all.
But there's a little-known, uber-powerful capability that is supported in most modern harnesses (e.g. Claude Code, Codex, GitHub Copilot, Cursor) and crucially can be delivered alongside skills and plugins: hooks.

Watch them hooks, they're powerful
Hooks, when installed and approved by the user, run every time a certain event happens, no matter whether the skill was invoked or not (e.g. "I just wrote a file"). That means hooks can be used to complement a skill, for example by validating whether the skill did the work as intended.
Impeccable uses hooks to keep the agent honest and make sure zero detectable AI slop remains:
1. A PostToolUse hook runs after every file edit.
2. If the file is ignored or unrelated to frontend dev, the script no-ops.
3. Otherwise, Impeccable's deterministic slop engine scans the file and injects findings as a system reminder.
4. The agent fixes all remaining issues.
A concrete example: I never invoke the skill. Gemini adds img:hover { transform: scale(1.1) } (it loves these) and the moment it hits disk, a system-reminder appears uninvited; the agent reverts its own edit. Passive guardrails ftw.

Honest aside: a static hook scans the file on disk; runtime-generated UI is a blind spot, so dogfood the rendered page too.
But beware: with great power comes great responsibility. You can absolutely wreck the user's experience with hooks. If not careful, hooks burn tokens, slow down the session, or overcorrect. Be very careful when deploying hooks to others. Impeccable's hooks required weeks of calibration and ship with a robust way to ignore false positives.
## Dark art #7: Live-wire the browser
Steal it for: visual iteration, dashboard tuning, 3D/game tweaking, any painful-to-type UI.
Impeccable's design vocabulary makes it much more fun and effective to steer design, but it has its limits. Especially in the last ~20-30% of polish that gets you from good to great, chat will only get you so far.
Fine-tuning visuals by typing is miserable ("a little more padding, no, warmer, less"). Life's too short to try to describe a color in words.
That, however, doesn't mean we have to crawl back to the design canvases of yesteryear. Agentation demonstrated that you can connect browser and agent, effectively turning the browser, with your own site running in local dev, into one of the agent's input devices. This becomes much more interesting now that most agent harnesses have in-app browsers that the agent can spawn at will!
But Agentation's method requires MCP and only works with React. I wanted a way to visually iterate with Impeccable without having to worry about any of that.
That's how /impeccable live was born:
1. A tiny server injects a picker into your dev page.
2. The agent runs ONE blocking command (live-poll.mjs) and waits.
3. You select and hit generate in the running app → that becomes the event the poll returns.
4. The agent, in the same chat thread, edits the file and replies; the page updates.

The individual capabilities are not fancy (spawned scripts in the main thread, SSE, local storage to survive reloads/HMR etc). The devil here is in the details (Claude Code can wake up from background tasks, Codex cannot, and many more..) but once it works, it's a pretty magical multimodal experience.
Now, Impeccable is using this for visual iteration, but there are so many ways you can harness the in-app browser for fun and profit. Some ideas:
- rich onboarding experiences that go beyond text
- visualization of diagrams, plans, etc
- interactive quizzes
Curious what you will come up with!
## Dark art #8: Compile to every harness
Steal it for: multi-IDE plugins, cross-runtime libs, write-once distribution.
So you made a skill. You even used it twice. It did the thing you wanted. Amaze! Must share this amazing discovery with the rest of the world! You hand it to a teammate and they're like, super unimpressed.

What happened there?
Most likely, you were using a different model/harness combo to build and test the skill. Maybe you were on Codex/GPT 5.6-Sol, and they were on Claude Code CLI/Opus 4.8. Either way, two things shifted: how the harness behaves, and how the model listens and responds.
"But Paul, some tech bro on X promised me I could just symlink .claude to .agents!", you interject. But things that sound too good to be true are often too good to be true. Like calorie-free french fries. Or a printer that just works. But I digress.
The differences that really bite in the harness are behavioral. For example:
- Sub-agents are implemented differently, and require different spawn strategies (as pointed out earlier, Codex needs explicit user permission to spawn agents)
- Until very recently, Codex could only ask the user questions in plan mode (apparently this is fixed now, as of ~3 weeks ago!)
- Claude auto-wakes the thread when a background job exits; others don't. (Exactly why art #7 is built on a blocking poll.)
- Harnesses have different tools built in (e.g. image generation, browser MCP, etc)
The differences that bite in the model are varied, but in the case of Impeccable, how they're overfitted (biased) concerns me most:
- Every model overfits its own way, not just CSS: code patterns, architecture, defaults.
- For example, Gemini animates images on hover; GPT crushes display type to letter-spacing: -0.06em until letters touch.
- Unfortunately, stacking one model's "do not do x" rules into a skill shared with other models often regresses the others!

Worth calling out: you might never run into any of these issues. If all you got is a simple 3-paragraph SKILL.md that doesn't call scripts, doesn't spawn agents etc, chances are you'll escape this complexity. But if you run into cross-harness/model issues, here's how I deal with it:
- Treat the skill as source code; give it a build step.
- One source (SKILL.src.md): "ask the user" compiles to AskUserQuestion on Claude / the input tool on Codex / plain chat on Cursor; the command prefix flips / to $; per-model bans compile only into that model's build (hardcode any of it and the skill degrades everywhere else)
- Within the compiled skill for a given harness (e.g. Claude Code), you might still have dedicated instructions for different models (e.g. if you're Fable, jump to x)
- One source → 10+ provider builds: right paths, right command syntax, right per-model patches.

In practice, this means that the version of Impeccable you'll find in your .claude folder has Claude-specific syntax and rules!
Side note: unfortunately, popular installers like npx skills do not support multi-harness skills (some skills, like agent-browser, solve this by rewriting themselves on the fly post-install). Thus, for the time being, Impeccable ships with its own CLI to install and update skills and hooks via npx impeccable.

## Dark art #9: Design for the weakest model
Steal it for: cheap-model deploys, long agentic flows, CI gates.
Harness/model isn't the only axis that matters. The strength of the model matters just as much. Weak models amplify the weaknesses of your skill prose:
- Unclear instructions? Weak models will trip, but frontier models will infer and correctly course-correct.
- Lots of steps to follow? Weak models will "compress" and skip more often; frontier models will usually correctly infer when following an explicit order is a must vs a suggestion.
- Lots of context to work with? Weak models compress the context and often ignore most of it. Frontier models are much better at validating their own work against provided context.
Now, it's a valid strategy to only build for the strongest frontier models, but if you aim for maximum adoption of your skill, you can't just support GPT + Claude latest. You'll also have to support Claude Sonnet and GPT 5.6 Terra/Luna, Composer, Grok, Kimi, Deepseek, Gemini, GLM and others. So for max adoption, build for the dumbest model you'll actually run on.
Some examples from Impeccable's source code:
- In craft.md: "You must stop at every gate. Shape confirmation alone is NOT a green light to start coding." / "compressing gates 2-4 is the dominant failure mode."
- Codex is trigger-happy inferring context → an explicit stop-and-gather strategy.
- live.md is step-by-step, nothing implicit (Haiku is the test baseline).
If there's one takeaway from this section, make it this one: if the gate in your skill can be skipped, it will be. Make it un-skippable.
## Building effective skills
You'll notice that very little of my advice was about the words to use in a skill's prose. That's not because words don't matter (I run ablation evals for almost every line in the Impeccable skill!), but because they're not where the leverage is.
A great skill isn't a prompt with accessories. It's a harness extension: it spawns sub-agents your harness wouldn't, guards edits you never asked it to check, holds memory the session doesn't have, compiles itself into runtimes it's never seen.
If you incorporate these dark arts into your skill, you get one that reviews itself, escapes the average, routes per surface, remembers, adapts to your repo, guards every edit, tunes in the browser, runs on any harness, holds on weak models.

You'll iterate the prose forever, and you should. What breaks the median is everything around it.
Everything above is open source: Impeccable via npx impeccable skills install (or start at impeccable.style), and the talk this article grew out of, deck and runnable starter included, at github.com/pbakaus/impeccable-talks.
Onwards.
## 相关链接
- [Paul Bakaus](https://x.com/pbakaus)
- [@pbakaus](https://x.com/pbakaus)
- [25K](https://x.com/pbakaus/status/2077114326985687525/analytics)
- [Impeccable](https://impeccable.style/)
- [Radiant](https://radiant-shaders.com/)
- [Compound Engineering](https://github.com/everyinc/compound-engineering-plugin)
- [@mattpocockuk](https://x.com/@mattpocockuk)
- [teach](https://github.com/mattpocock/skills/blob/main/skills/productivity/teach/SKILL.md)
- [Agentation](https://www.agentation.com/)
- [impeccable.style](https://impeccable.style/)
- [github.com/pbakaus/impeccable-talks](https://github.com/pbakaus/impeccable-talks)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [3:33 AM · Jul 15, 2026](https://x.com/pbakaus/status/2077114326985687525)
- [25.2K Views](https://x.com/pbakaus/status/2077114326985687525/analytics)
- [View quotes](https://x.com/pbakaus/status/2077114326985687525/quotes)
---
*导出时间: 2026/7/15 11:30:08*
---
## 中文翻译
# 技能工程的黑暗艺术
**作者**: Paul Bakaus
**日期**: 2026-07-14T19:33:41.000Z
**来源**: [https://x.com/pbakaus/status/2077114326985687525](https://x.com/pbakaus/status/2077114326985687525)
---

创建技能微不足道。创建有效的技能却难如登天。我是吃过亏才明白这一点的,而且在旅途中我习得了一些真正深奥的知识,这些知识帮助我将 Impeccable 从一个只是有点感觉的个人小技能,升级为一个被数十万设计师和开发者使用的工具包,它能把你的编码挽具转化为设计挽具。
以下是这九种技术:正是这些黑暗艺术将 Impeccable 从那种凭感觉生成的散文(这也是今天大多数技能的形态)变成了久经沙场的挽具扩展。让我们深入探讨吧。

## 大多数技能只是祈祷和提示
大多数技能只是凭感觉生成的散文:由它们所针对的同一个模型生成,测试两次,被宣布为工作正常,然后被供奉在你的技能目录中。
如果这对你有用,那也没什么问题。但一旦你把技能发给其他人,期望就会改变。突然之间,它必须能工作……
- ……始终如一地
- ……在每一个流行的挽具/代理中
- ……在完全不像你项目的项目和条件下
- ……适应不同的用户提示风格
- ……不止一两次
- ……在前沿模型和较弱的模型上
- ……在不同的操作系统上
“但是 Paul”,你打断道,“我被告知技能是可互操作的,而且能解决我们所有的问题!” 是的,我亲爱的帕达万,我和你一样失望。我们还被承诺在 2015 年前会有悬浮滑板,而我还在等 :( 仅仅因为如果你已经发布过技能,这份清单让你感到不舒服,但这并不意味着它不是真的。
## 技能是挽具的扩展
如果你想让你的技能真正有效地、始终如一地做些什么,你必须重构你看待技能的方式。
不要把技能看作是用户或代理可以根据需要检索的已保存提示,而要把技能看作是一个插件:挽具的扩展。一个伟大的技能扩展了 Codex、Claude Code 或 Copilot 在那些存在明显短板的领域的能力。
Impeccable 通过针对特定模型的自动 AI 废料预防扩展了挽具,配备了一种设计语言和命令面板,让你能引导出伟大的设计,以及在你本地运行的站点上提供丰富的视觉设计模式。你的技能是如何扩展挽具的呢?
## 伟大的技能强迫模型做它真的不想做的事
伟大的技能让挽具及其模型做它们不想做的事。想想看:如果模型本来自然就想做这件事,你一开始就不需要这个技能!
在 Impeccable 的案例中,Codex + GPT 真的不想在开始工作之前询问用户关于目标受众的问题。Claude + Opus/Fable 真的想使用斜体衬线字体和眉题(还有那些该死的脉动绿点,天哪,这么多闪烁的点)。所有的模型真的想在你的网站上放很多描述性文本。

中值是模型的引力
优秀的散文有帮助,但还不够。你真正的工作是始终如一地击败模型的默认设置,并让一个非确定性的模型表现得像确定性软件一样。

提示召唤中值;挽具召唤其余部分。下面的每一种黑暗艺术都将工作从模型可能会遵守的散文转移到强制结果的机制中。
## 九大黑暗艺术
是时候打开魔法书了:
1. 让它们争论 · 两个盲审审查员胜过一个自信的猜测
2. 强制发散 · 逃离聚类,不要用禁令去追逐它
3. 像前沿模型一样路由 · 一个命令加载一个专家
4. 给它们记忆 · 累积运行而不是重新开始
5. 会说话的脚本 · 标准输出就是指令
6. 反击的钩子 · 不请自来的护栏
7. 浏览器实时连线 · 浏览器成为第二个输入
8. 编译到每个挽具 · 一个源码,每个运行时,每个模型
9. 为最弱的模型设计 · 无法跳过的关卡
## 黑暗艺术 #1:让它们争论
可用于:代码审查、安全审计、计划/RFC 批评、输出排序。
代理对自己工作的极度偏袒。这在直觉上是合理的,因为人类也是如此:没有理智的父母会让孩子给自己的作业打分。那么为什么我们要让代理在同一线程中给自己的输出打分呢?
当然,你可以尝试通过一个更好、措辞更强硬的提示(“要超级公正!!!”)来解决这个问题,但你会失败。省点时间吧,改用对抗性子代理。

让它们争论
举个具体的例子,`/impeccable critique` 是 Impeccable 的设计审查命令,它既对你的代码运行确定性检查(以便快速果断地检测出低对比度之类的东西),又像人类一样审查设计。但早期版本有一个导致糟糕批评的主要缺陷:提前把 LLM 的检测器输出交给它,这会导致两种方向的偏差:
1. 检测器有噪音 → 因为可修复的小问题而谴责一个很强的页面(误报)
2. 检测器沉默 → 给通用的页面盖章放行(毫无意义的健康证明)

为了消除偏差,批评现在会生成两个互不见面的子代理:A = 一位 LLM 设计总监(层级、废料、启发式规则),B = 确定性检测器 + 浏览器证据。当子代理完成后,主代理将两者的结果综合(编织,而不是拼接)在一起,以获得平衡的批评。两个盲目的意见胜过一个自信的猜测。
> Codex 的波折:子代理不可移植。截至今天,在 Codex 上,除非用户已经允许并行工作或处于 YOLO 模式,否则技能无法生成子代理。所以对于 Codex,添加一些特殊指令:“如果可以,但没有生成子代理的权限,请停止并向用户请求权限。”(注意:这取决于你的权限模型,显然 GPT 5.6 在子代理方面要鲁莽得多。)

## 黑暗艺术 #2:强制发散
可用于:命名、品牌推广、内容构思、变体生成、打破样板。
如果一个 LLM 经常做某事而你不希望它这样做,添加这样一行是非常诱人的:
> 不要使用 Inter 或 Instrument Serif 字体
不幸的是,这对 LLM 的作用与对人类不同。人类可能会回到绘图板去挑选一个真正独特且合适的字体。但 LLM 只会挑选下一个最好的。所以如果你想知道为什么我们从紫色渐变的 AI 废料变成了衬线米色的 AI 废料,你现在有答案了。

禁令只是将模型从一个潜在空间区域移动到另一个区域。逃逸是侧向的,而不是更长的拒绝列表。

这里有三种能产生更高发散性的技术(按从最便宜但最弱开始排序):
1. 削减安全选择:让模型列出它前 3 名的字体,然后全部丢弃。胜过自己。
2. 生成约 50 个,一个盲目的子代理保留 5 个最独特的。(存在于 Radiant 的代码库中,尚未在 Impeccable 中。)
3. 从模型外部引入种子:`palette.mjs --from 8f2a` 从模型自己绝不会选择的区域开始。
当然,这些是可以叠加的!经过足够的打磨,平均值将变得遥不可及。

## 黑暗艺术 #3:像前沿模型一样路由
可用于:大型多工具技能、按需提供的上下文、针对受众的行为。
像 Fable 和 GPT 5.6 这样的前沿模型对过度纠正或冲突的散文非常敏感。在一个长达一英里的 SKILL.md 中放入大量指导是很诱人的。忍住。
对此的一种解决方案是许多独立的、小型的技能,如果它们真的彼此独立并且不代表用户应该作为一个整体使用的系统,这就行得通。但如果你无论如何都需要安装所有功能,还有一个更好的方法,那就是技能内部路由。
本质上,把你的 SKILL.md 看作一个智能路由器,类似于 MoE(混合专家)LLM 架构。你的 SKILL.md 可以:
- 根据推断路由到特定的子命令(例如,当用户请求“润色我的页面”时加载 polish.md)
- 仅在适用条件时加载特定文件(在 Codex 中使用该技能时自动加载 codex.md,或者如果请求的设计是落地页则加载 brand.md)

Impeccable 通过这种方式在一个 SKILL.md 中路由 23 个命令;每个命令只加载一个专家参考,而将其他 22 个排除在上下文之外。你也可以。
## 黑暗艺术 #4:给它们记忆
可用于:可恢复的代理、多会话重构、迁移。
假设你写了一个“查找漏洞”和一个“修复漏洞”的技能。一切都很顺利,直到有人运行了查找漏洞技能,关闭了代理线程,开始了一个新的线程并调用“修复漏洞”。突然间,修复漏洞不知道要修复什么漏洞,因为它缺乏先前的上下文。
大多数技能作者将技能视为无状态提示,但没有规则说技能不能有状态。请记住,技能可以与在技能生命周期的任何地方运行的脚本捆绑在一起!
Impeccable 的批评和润色命令非常有效地使用了这项技术:
1. /critique 为每个目标写入一个快照(分数、P0/P1、markdown + frontmatter)
2. /polish 读取最新的快照作为其修复积压清单

一个让这在团队中起作用的非显而易见的细节:快照的 slug 来自解析后的文件路径,而不是你如何措辞请求。指向同一个文件的队友继承相同的记忆,而且分数趋势(24,然后 28,然后 32)在会话之间得以保留。
除了 Impeccable,这一类别中的杰出例子是 Compound Engineering 插件/技能,或者 @mattpocockuk 的 teach skill。
## 黑暗艺术 #5:会说话的脚本
可用于:感知环境的设置、动态入门、仓库状态门控。
LLM 会压缩长技能中的指令,就像人类浏览长文档一样。对此的解决方案是即时交付。
换句话说,如果有一个关键步骤或真正的岔路口,模型必须做某事或采取与预期不同的路径,让它执行一个脚本并在脚本的标准输出中交付指令。
Impeccable 在很多地方使用了这项技术。例如,以下是 Impeccable 如何按需自我初始化的:
1. SKILL.md 告诉模型运行 context.mjs(其主要工作是在一次调用中内联 PRODUCT.md 和 DESIGN.md)
2. 技能主体说“遵循脚本打印的任何内容”。
3. 脚本读取环境并写回下一条指令:context.mjs 打印 NO_PRODUCT_MD,代理停止并运行 init。

计算的、即时的指令比任何静态指令都更能引导方向。退出值就是提示。
值得注意的权衡:这项技术会破坏提示缓存。根据具体情况决定你是更喜欢缓存命中还是服从性。
## 黑暗艺术 #6:反击的钩子
可用于:Lint/格式化、秘密检测、a11y 检查、策略执行。
到目前为止,一切都只在被调用时才有帮助。代理在根本没有人调用技能时会做出最糟糕的编辑。
但是有一个鲜为人知、极其强大的功能,大多数现代挽具(例如 Claude Code、Codex、GitHub Copilot、Cursor)都支持,关键是它可以与技能和插件一起交付:hooks。

看好这些钩子,它们很强大
钩子一旦被用户安装和批准,就会在每次发生特定事件时运行,无论技能是否被调用(例如“我刚写了一个文件”)。这意味着钩子可以用来补充技能,例如通过验证技能是否按预期完成了工作。
Impeccable 使用钩子来保持代理诚实,并确保零可检测的 AI 废料残留:
1. 一个 PostToolUse 钩子在每次文件编辑后运行。
2. 如果文件被忽略或与前端开发无关,脚本会空操作。
3. 否则,Impeccable 的确定性废料引擎扫描文件并将发现作为系统提醒注入。
4. 代理修复所有剩余问题。
一个具体的例子:我从不调用该技能。Gemini 添加了 `img:hover { transform: scale(1.1) }`(它喜欢这些),一旦它写入磁盘,一个系统提醒就会不请自来地出现;代理会撤销它自己的编辑。被动护栏万岁。

诚实地旁注:静态钩子扫描磁盘上的文件;运行时生成的 UI 是一个盲点,所以也要对渲染的页面进行“狗粮测试”(即内部测试)。
但要小心:能力越大,责任越大。你绝对可以用钩子搞砸用户体验。如果不小心,钩子会消耗 Token,减慢会话速度,或过度纠正。向他人部署钩子时要非常小心。Impeccable 的钩子需要数周的校准,并且附带一个强大的忽略误报的方法。
## 黑暗艺术 #7:浏览器实时连线
可用于:视觉迭代、仪表盘调整、3D/游戏微调、任何难以输入的 UI。
Impeccable 的设计词汇让引导设计变得更有趣和有效,但它有其局限性。特别是在最后 ~20-30% 的润色阶段,那是从好走向卓越的关键,聊天只能帮你到这儿。
通过打字来微调视觉效果是很痛苦的(“再多一点内边距,不,再暖一点,少一点”)。人生苦短,不要试图用文字描述一种颜色。
然而,这并不意味着我们必须爬回过去的设计画布。Agentation 证明了你可以连接浏览器和代理,有效地将浏览器(运行着你本地站点的浏览器)转变为代理的输入设备之一。现在大多数代理挽具都有代理可以随意生成的应用内浏览器,这变得更有趣了!
但 Agentation 的方法需要 MCP,并且只适用于 React。我想要一种可以与 Impeccable 进行视觉迭代而无需担心任何这些问题的方法。
这就是 `/impeccable live` 诞生的原因:
1. 一个微型服务器向你的开发页面注入一个选择器。
2. 代理运行一个阻塞命令(live-poll.mjs)并等待。
3. 你在运行的应用中选择并点击生成 → 这成为轮询返回的事件。
4. 代理在同一线程中编辑文件并回复;页面更新。

个别功能并不花哨(主线程中生成的脚本、SSE、用于在重载/HMR 中幸存的本地存储等)。这里的魔鬼在于细节(Claude Code 可以从后台任务中唤醒,Codex 不能,还有更多……)但一旦它工作起来,这就是一种相当神奇的多模态体验。
现在,Impeccable 将其用于视觉迭代,但有很多方法可以利用应用内浏览器来获得乐趣和利润。一些想法:
- 超越文本的丰富入门体验
- 图表、计划等的可视化
- 交互式测验
好奇你会想出什么!
## 黑暗艺术 #8:编译到每个挽具
可用于:多 IDE 插件、跨运行时库、一次编写到处分发。
所以你做了一个技能。你甚至用了它两次。它做了你想做的事。太棒了!必须与全世界分享这个惊人的发现!你把它交给一个队友,然后