writing

Featurebooks

September 17, 2026

A feature is a story, that's why it begins with a user story. And the code alone does not tell the story. A product manager develops an idea, and solidifies it into a user story. Engineering and UX implement and test that story. CS ensures the story makes sense for customers, sales sells that story to prospects, and marketing tells the world about the story. A story is assembled, made of chapters, and so we have featurebooks.

A featurebook is a complete story: the idea, the code, the documentation, the runbook, the metrics, the alerts, and the onboarding materials, including the script to run the user story against the ui, so we can prove, anytime, that the story can still be told.

At Mondoo, we've implemented featurebooks using a claude skill. The idea is that if an engineer says a feature is done, they should use the featurebooks skill to prove the feature is done.

What the featurebook skill does

When an engineer is about to call a feature done, they ask Claude to "write a featurebook." The skill walks them through four steps.

  1. Gather the inputs, starting with the user story. Claude asks for the feature's name and its planning issue, then the user story ("As a …, I want …, so that …"). Nothing gets written until the story exists, because everything else comes from it. Claude then asks for a link for each "code complete" requirement:

    • the merged PRs, in every repo
    • a dashboard and alerts
    • a runbook
    • docs
    • the closed issue
    • proof the product manager was told
    • the feature flags: none allowed in the backend, and any UI flag named along with how to turn it on

    Any item that isn't done yet is recorded as a gap. Claude never invents a link.

  2. Write the test script from the story, not from the code. Each step proves part of what the story promises a user, and the rules are strict:

    • UI only. Start in the product, signed in, and do what a user would do. No API calls, no cluster access, no database queries.
    • One action per step. Each step names the exact menu entry, field label or button, plus what you should see.
    • Concrete expected results. "Status shows Active" or "4 repository assets appear", never "it works". Where something takes time, the step says how long to wait.
    • At least one negative check. For example, a bad credential should give a clean error.
    • Cleanup at the end, so every run starts from the same state.
    • People handle credentials. Any step that needs a secret is marked HUMAN:. Claude pauses there and never types the secret itself.

  3. Assemble the featurebook in a standard layout: a header with the owner and the date it was last verified, then the user story, the code-complete checklist with its gaps, the test environment, and the numbered script.

  4. Hand it back. Claude shows the gaps first, opens a PR, and asks the engineer to run the script before merging and record when it passed.

The script is written so an engineer can hand the whole thing to Claude with a browser extension and say "run this." The engineer who built the feature runs it once to prove it's done. After that, anyone in product, customer success or engineering can rerun it any time to check the feature still works. A featurebook is living proof of a feature, not a one-off sign-off.

How do we keep it all up to date over time? That's why we start with the user story. We always know the what and the why, so we can always recreate the entire experience, even if the ui changes underneath us.

← all writing