Fast with AI, right by the book

On the afternoon of Monday, 5 October 2026, I asked Claude a deliberately naïve question: walk me through how to create a skill, step by step. I had made one before—a friend helped me generate my first in March—but this time I wanted to go through the whole process myself and see it from the inside. By that night my book had been checked for logic, cleaned of duplicate rules, given seven new subcategories in draft, and built as a working website. Over the next eight days it became a Claude skill, a guide to it, and a site that passes an audit against the book it publishes. AI made the first day possible. A written system made the next eight right.

The miss

I asked Claude to build a consent banner for Google Analytics, then audit it against my book, The Blue Book of UX Directives. The audit passed. I opened the banner from the footer and found I could not leave it without making a choice.

The book had the rule all along: 18/06—Allow decisions to be deferred. The skill knew it. It missed it because the agent that built the banner also judged it. I ran the same audit four more times with fresh agents that had never seen the build. All four found the missing exit, under the same directive.

So I changed the rule of the work: the agent that builds never gives the verdict.

Day one

I start new work with a naïve question on purpose. It sorts what I know and want to verify, what I know I don’t know, and what I don’t yet know I don’t know—a distinction US defense engineers were drawing by the late 1960s: known unknowns and unknown unknowns. It also shows how long each will take and what I can hope for. The book lived in Notion. In late September I saved its pages and left them. On Monday afternoon I turned them into Markdown and asked the question. Within hours the work changed shape.

Claude ran a classical concept analysis of the book: one basis of division per level, species that add up to their genus, no overlaps. It found duplicate rules across chapters and gaps against each chapter’s own promise. I made the calls: three duplicates repealed with their IDs kept, seven new subcategories drafted—Decision-Making, Search & Labeling, Input, Motion, Privacy, Non-Manipulation, Personalization. By evening the book was a website, searchable and readable on a phone.

Then I pointed Claude at the site with the book as the checklist. The site broke 18 of the book’s own rules. The constraint from then on was not speed. It was being right by the book.

The same question I ask of every brief—see Do you solve the right problem?

The constraint moved

For more than thirteen years my work ended where someone else’s began: I designed, I explained, I waited for engineering to find the time, I accepted what shipped. Polish was always the first thing cut—nobody had the hours for a tooltip that opens the right way or a button that darkens instead of fading.

Here, nobody had to find the hours. Every refinement I could name, I could have—that same day, in a preview on my phone. The scope of the product grew with it: a page about the skill, interactive diagrams, a consent flow done properly on two sites.

But the constraint did not disappear. It moved—from “can engineering build this” to “can I say exactly what I want, and prove that I got it”. That is why the rest of this case is about specification and verification, not code.

The system

I split the work across three surfaces, each with one job.

• A planning conversation where decisions are made. Every task starts as a reformulation—what I will see, not what will be done—and nothing runs until I give a command.
• Claude Code as the executor. One piece of work, one branch, one session. A commit per pass, a preview on Vercel, a report that names every number it measured and everything it did not check.
• My terminal and my eyes. I open and close branches. I check every preview on a Mac and an Android phone against a checklist written as “do this → see that”. Nothing reaches main without my sign-off, and the merge checks the fingerprint of what I approved.

The rules live in files, not in memory: how we talk, how work is ordered, how reports read. Claude Code loads them on every run.

1. Step 1

   Reformulation

   Step 1 of 6

   I see what will change before anything runs.

   Request 142—reformulation (what you will see):

   1. Banner at the bottom. On the first visit a bar appears with the text and two equal buttons…

   2. Silence until a choice. No requests to googletagmanager.com, no _ga cookies.

   Waiting for the command.

2. Step 2

   Task

   Step 2 of 6

   the executor gets decisions, not questions.

   Request 142, branch consent-banner [1.1]. Read CLAUDE.md first.

   Task: gate Google Analytics behind a consent banner on the portfolio, with a footer link to change the choice.

   Stop if any existing check moves.

3. Step 3

   Report

   Step 3 of 6

   every number measured, every gap named.

   consent-banner [1.1]—2 passes committed, round stopped before push: the skill's verdict found a violation.

   25/03—Make sure state is inspectable. The banner reopened from the footer after “granted” says “It stays off unless you allow it.”

4. Step 4

   Fresh-agent verdict

   Step 4 of 6

   someone who did not build it.

   Missing way out of the reopened banner—found in 4 of 4 runs, under 18/06—Allow decisions to be deferred.

5. Step 5

   My check

   Step 5 of 6

   do this, see that.

   3. Close. Press “GA on” → Close in the banner's corner, hover → “Close”, press → the banner closes, the footer still says “GA on”.

6. Step 6

   Merge

   Step 6 of 6

   only what I approved.

   test "$(git rev-parse --short consent-banner)" = c9cdbcf && git switch main && git merge --ff-only consent-banner && git push

For me, Human-Centered Systems Engineering as a discipline began with the NASA Systems Engineering Handbook. The ambition is a handbook of its own, but for UX in digital systems. For now it is a code—A Uniform Code for Human-Centered Digital Systems, the rules. This project was the first time I ran the rest of the discipline around them: verification, validation, configuration control, lessons learned.

Borrowed from NASA Systems Engineering Handbook: Design, Test, Integrate, Fly.

The book inside the loop

The loop closed on itself. Claude packaged the book as a skill. Then the skill audited the site that publishes the book—and found 18 places where the site broke the book’s own rules. Every refinement after that went through the same audit, including the page that explains the skill: the skill reviewed its own guide. The doctrine was not a reference on a shelf. It was the reviewer in every round.

Outer ring: the book

1. book
2. skill
3. audit
4. site
5. skill guide
6. audit again

Inner ring: the working cycle

1. task
2. executor
3. fresh-agent verdict where the miss was caught
4. my check
5. merge

Every round that changes behaviour carries a state table—input × element × state × theme—measured before push. The verdict on it comes from the book: a directive ID and title, verbatim, for every finding. Since the banner, that verdict comes from a separate agent with a clean context. It gets the page, the source, the skill and the list of decisions I accepted on purpose. It does not get the task or the history.

🫡

Fresh-agent verdict. The verdict on the state table is given by a separate agent with a clean context. It gets the built page, the source, the skill and the list of accepted decisions, but not the task or the round’s history: whoever built it gets used to it and misses behaviour that is not there. The executor triages its findings in the report. A violation stops the round before push.

1. Prologue · late September—The book’s pages saved from Notion. Nothing more, for a week.

2. Day 1 · Mon 5 Oct—From “what is a skill?” to a website.

   Study the documents in the folder and walk me step by step through how to create a skill…

   Shipped: the book in Markdown, a concept analysis, duplicates repealed, seven subcategories drafted, a working site.

   Number: 492 directive IDs checked, none reused.

3. Day 2 · Tue 6 Oct—The skill, and the book audits its own site.

   Shipped: the skill, tested on four prompts—110 IDs cited, 0 invented, an audit of the site—18 findings, the first fixes merged. The working rules written down.

   Number: 18 findings in one 9-minute audit.

4. Day 3 · Wed 7 Oct—Search that speaks the reader’s language.

   Shipped: a 404 page, chapter titles in search, a reader vocabulary, a “Did you mean” for empty results, a one-line banner on phones.

   Number: requests 59 to 72.

5. Day 4 · Thu 8 Oct—Touch, tooltips and a link checker.

   Shipped: chevrons for touch in six rounds, hover only where there is hover, tooltips for every icon, a checker for every link and anchor.

   Miss → rule: a command hidden inside a task stopped the executor. The command now comes in its own message.

6. Day 5 · Fri 9 Oct—The rules get stricter.

   Shipped: WAVE on the live site—0 errors, AIM score 10 of 10 (was 7.9), 44-pixel targets, tooltips on long press.

   Miss → rule: a report came with no preview address. Every report now ends with one, checked against the built site.

   Miss → rule: a task went out without a branch. Every task now gets its own.

7. Day 6 · Sat 10 Oct—Details.

   Shipped: hover states, a footer, a quiet easter egg. Sixteen amendments to the working rules accepted in one review.

8. Day 7 · Sun 11 Oct—A portfolio of its own.

   Shipped: the About page, moved into its own repository and site shell.

9. Day 8 · Mon 12 Oct—Off Notion.

   Shipped: alehhaiko.com moved to its own hosting, the book under /ux/, 62 old Notion addresses redirected, an old server shut down.

10. Day 9 · Tue 13 Oct—The miss, and the rule.

    Shipped: GA consent on both sites, the skill guide with its diagrams, a new README.

    Miss → rule: the builder’s audit missed a banner with no way out. The verdict now comes from a fresh agent.

    Miss → rule: a component and a colour were reinvented. Ported components now come with their source, and new colours are listed.

What it produced

• The Blue Book of UX Directives—alehhaiko.com/ux
• Skill for Claude—alehhaiko.com/ux/skill.html
• The portfolio you are reading, moved from Notion with its old addresses redirected.

Limits

Checked in Chrome on a Mac and on an Android phone. Not checked: Safari, iPhone, real screen readers beyond two spot checks (VoiceOver and TalkBack). Severity is the skill’s judgment, not user research. The fresh-agent result is four runs on one page: a strong signal, not a statistic.