The Dark Arts of Skill Engineering — Paul Bakaus, Renaissance Geek (Impeccable)

Paul Bakaus says Impeccable began with a practical problem in a large application he was building. Agents could quickly generate something visible, but returning the result to the application's design system was difficult. His first skill, Normalize, addressed that gap.

As the collection grew, he stopped thinking of a skill as a packaged prompt and began treating it as an extension to the coding harness. The workshop presents nine techniques that combine prose with tools, scripts, state and feedback.

He also explains why a growing list of aesthetic bans was insufficient. Banning one familiar font or style can merely move a model toward another familiar default. That is his explanation of convergence, supported by his own experience with design defaults, rather than a measured law about every model or website.

Bakaus describes two critique failures. A strong design with many detected polish issues can be rated badly because the model anchors on the issue count. An empty or poor page can appear good because a detector finds little to flag.

His response is to separate the inputs. One independent review examines hierarchy, coherence and design quality with browser evidence. Another collects deterministic findings and technical evidence. The main process then synthesizes the reports without letting one reviewer anchor the other's initial assessment.

The goal is better separation of evidence, not a guarantee that two models agree with a human. His live demonstration did not clearly show the intended subagent behavior, and he acknowledged an older repository version. The article preserves that limitation instead of presenting the stage attempt as a verified success.

He calls his divergence techniques anti-attractors. One simple method asks for familiar choices and discards them repeatedly; he also acknowledges that this can eventually converge again.

A stronger creative cue can come from outside the model's immediate defaults. His shader example uses unexpected associations to generate many ideas, followed by ranking in a fresh context. Another approach uses a script to select from hand-curated starting colors, then asks the model to build around that seed.

The seed supplies variation, not quality by itself. The user may still reject the result. The technique is meant to create a different starting direction from which judgment and iteration can proceed.

A large skill with every possible rule can become ambiguous. Bakaus's example is typography: a rule discouraging system fonts for a distinctive landing page can be inappropriate when a product should feel native.

Impeccable therefore routes both by operation, such as critique or polish, and by register, such as brand-facing work or product UI. Different documents and rules become relevant depending on the brief.

His mixture-of-experts comparison is an organizational analogy for skill routing, not a claim that Markdown files implement the same architecture as a neural model. The practical objective is to load the needed guidance without forcing incompatible instructions into one enormous document.

Bakaus stores critiques and other artifacts in files so later work can use the earlier findings. A polish pass can read a prior critique even when it happens in another session.

User disagreement is part of that memory too. If someone deliberately prefers a choice a critique rejected, the next pass should not mechanically repeat the same objection as though no decision had been made.

This is explicit stored state, not magical long-term memory. The workflow has to choose where artifacts live, whether they belong in version control and how later runs interpret them. A saved opinion remains context to evaluate, not an unquestionable permanent rule.

The workshop's context script gathers product and design information. When a file is missing, it can return structured information about the gap and the next step, instead of relying on a buried sentence in the main skill to be remembered.

Bakaus says he finds instructions returned at that moment more effective than a long list of static rules. He also describes update handling that asks the user's permission, rather than treating a detected update as permission to install it.

There is a cost. Dynamic output changes the conversation prefix and can reduce caching opportunities. In the questions afterward, he clarifies that static skill content may still be cached; it is not a claim that one dynamic script eliminates every form of prompt caching.

Hooks address a different problem: users and agents may forget to invoke the skill. A check tied to an edit can return immediate feedback or prevent a disallowed operation before it happens.

Bakaus distinguishes a post-edit message from a pre-tool block. He says some models did not reliably correct the issue after feedback, so a stronger intervention was needed in particular runtimes. This is his experience of those environments at the time, not a current capability chart.

He explicitly warns about false positives. Ignore rules and configuration at useful levels of granularity are necessary, or a supposedly helpful check quickly becomes disruptive. A hook is valuable when it supplies an appropriate feedback loop, not merely because it can block work.

For design, Bakaus wants more than a chat instruction about pixels. His live mode connects a page interaction with an event consumed by the agent, which can then generate variants or change the selected element.

He explains a small polling process that waits for an event and exits with information the thread can read. The agent follows instructions for handling that event, and the result returns to the browser. The demo shows selecting a page element, reviewing variants and accepting or dismissing a choice.

37:10View full image

The broader point is to use the harness's available interfaces to fit the work. It does not require every skill to run a browser bridge, and the author later admits this implementation still has problems and might work better as a native integration.

Bakaus lists differences in subagent permission, question tools, task completion, hooks and installation. A symlink can share text, but it cannot make different execution environments behave identically.

He also sees model-specific habits, so a rule that corrects one model can overcorrect another. His builds substitute runtime-specific tools and load selected guidance rather than indiscriminately apply every warning to every model.

These observations describe his workshop experience. They should not be read as a freshly verified statement about current provider behavior or permission rules. The enduring engineering question is whether the installed artifact calls the tools and follows the process available in its actual environment.

When distributing a skill, Bakaus tests weaker instruction-following models as well as the one he prefers. He describes explicit checkpoints with recorded outcomes so the model cannot silently compress a workflow into a few convenient steps.

A list of checkpoints is still an instruction, not a cryptographic guarantee of completion. The recorded evidence must correspond to something that happened. A model saying it passed a check cannot replace the underlying tool result or artifact.

He does not ask everyone to adopt all nine techniques. The workshop's recommendation is to use the mechanisms the problem actually needs, especially when shipping a skill to people with different models and harnesses.

In the question period, Bakaus describes end-to-end tests, browser automation and a separate evaluation harness that recreates selected runtimes and tools. Simulated user turns handle interactive parts, and design judges compare results across different business niches and models.

He also describes ablation: remove a tagged rule, rerun the evaluation, then compare the behavior with the rule restored. A deterministic check can reveal whether an instruction changed a specific property such as contrast.

The setup is his reported method; the private evaluation harness is not independently reproduced here. Ablation is expensive, and a change in one measurable behavior does not establish the entire design's quality. It does offer a more concrete basis for retaining a rule than whether the sentence sounds persuasive.

Asked directly about taste, Bakaus says his evaluations are not particularly good. He describes a judge that tended to reward a crowded first viewport, an example of a proxy moving in the wrong direction.

His experiments with compensating for that bias are heuristics in his system, not a general recipe to invert model scores. He still uses human inspection and annotation, and distinguishes functional observations from the more contextual question of taste.

That admission changes how to read the earlier mechanisms. Better routing, hooks and tests can improve control without establishing a universal aesthetic evaluator. The system can support judgment while leaving important parts unresolved.

Bakaus ends by arguing that widely shared skills need more testing than a personal prompt. Packaging, updates and the target runtime can break a process that worked for its author.

He also acknowledges things he has not tried, including the server-delivered skills question raised by the audience. He does not pretend the distribution ecosystem has a settled answer, and would prefer not to maintain every piece of a custom installer himself.

The workshop's central shift is therefore from instruction-writing to software behavior: make state explicit, connect feedback to the place it is needed, test the actual environment and tell the user when a capability did not run. A more elaborate skill earns its complexity only if that work produces a more dependable result.