Overview
Paul’s journey building Impeccable begins with a familiar failure: AI can generate a plausible interface quickly, but the result gravitates toward recognizable stylistic clichés and is difficult to reconcile with a real design system. Simple prohibitions do not create originality; they merely move the model from one conventional choice to another. His central thesis is therefore that prompting is only the entry level of skill development, while harness engineering is the mature form. He demonstrates how Impeccable combines independent reviewers, deterministic design linting, random creative seeds, specialized routing, persistent project memory, dynamic script output, edit hooks, and browser-based visual interaction. These mechanisms reduce self-evaluation bias, force divergence, preserve decisions across sessions, and turn passive instructions into active feedback loops. However, portability introduces another layer of difficulty: Codex, Claude Code, Cursor, Gemini, and other environments differ in permissions, tools, background-job behavior, hooks, and model-specific tendencies. Impeccable consequently compiles tailored builds and tests them through end-to-end evaluation, model judges, and rule-level ablations. The broader conclusion is demanding but practical: distributable skills need stronger engineering, evaluation, and compatibility standards than personal prompts, while taste and final judgment still require human oversight.
Sections
Higher-Order Observations
Implications that emerge from the engineering techniques and evaluation results.
- Skill quality depends increasingly on orchestration rather than prompt eloquence: the strongest controls operate through independent contexts, executable checks, persisted state, and lifecycle events.
- Determinism and creativity are not opposites here. Deterministic routing, linting, and gates create a stable boundary within which randomized seeds can produce safer and more varied exploration.
- Cross-harness portability resembles compilation more than file copying because each target exposes different permissions, tools, execution semantics, and model failure modes.
- The weakest supported model often determines the architecture of a public skill: rules must be surfaced, gated, or enforced mechanically when prose compliance cannot be assumed.
- The current skill ecosystem may be optimized for quantity over reliability; broader distribution raises the required standard from personal usefulness to tested compatibility.
Practical Lessons
Reusable guidance for building and distributing agent skills.
- Do not let the same context create and independently judge an artifact; use blind reviewers with different evaluation roles.
- To obtain genuine variation, inject an unexpected seed instead of merely banning the model’s most common choice.
- Split broad skills into routed specialists and load only the rules relevant to the current task or audience.
- Persist critiques, decisions, preferences, and progress so future sessions can resume rather than rediscover context.
- Use hooks for recurring enforcement, but provide granular ignore mechanisms for legitimate exceptions and false positives.
- If a required gate can be skipped or compressed, assume that some models will skip or compress it; require explicit evidence of completing each gate.
- Test distributed skills across the actual harnesses and models they claim to support, including interactive flows and browser capabilities.
- Treat automated aesthetic evaluation as preliminary evidence, not a replacement for human taste and final review.
Tools and References
Projects, frameworks, and testing tools explicitly mentioned in the talk.
- Impeccable — Paul’s open-source design skill and harness-extension project, licensed under Apache 2.0.
- Impeccable Talks sample repository — contains the presentation, a starter folder, demos, checkpoints, and material for building a smaller Impeccable-like skill; the exact repository URL was not clearly preserved in the transcript.
- Anthropic frontend design skill — an early prompt-oriented design skill used as a starting point and comparison baseline.
- Radiant Shaders — Paul’s shader library, used to demonstrate creative seeding and independent ranking of generated ideas.
- Playwright — used for end-to-end testing of Impeccable features such as live mode.
- jQuery UI — Paul’s earlier framework whose orange default theme illustrated how defaults can propagate across the web.
- skills.sh / NPX skills — a cross-provider skill-distribution project discussed as promising but currently limited for harness-specific builds.