82 cards in four hours — but which 82?

The boring checklist that saved my backlog.

This is part two of a three-part series about building a product backlog with Claude, five custom story mapping skills, and the StoriesOnBoard MCP server.

At the end of part one, I finally had the real product definition: an attention layer for managers that tracks who has the next move. There were two personas, an empty story map, and a story-map-creator skill that was supposed to turn one into the other.

Four hours later, there were 82 story cards on the board.

Speed was not the interesting part. The interesting question was: which 82?

The order of operations is part of the design

The creator skill follows a strict sequence:

1. Create the personas.
2. Create the releases.
3. Design the backbone: goals and steps.
4. Present the full plan for approval before story-card creation.
5. Create stories with their release and persona assignments.

Personas and releases must exist before the story cards that reference them. The StoriesOnBoard MCP tools can assign a persona and schedule a story as part of creation. If those references are missing, the stories land unscheduled and have to be repaired one by one.

The persona was more than a label. Claude wrote a compact profile for the Manager: context, job-to-be-done, pain points, and behavior. One line said the manager was mobile-first and usually captured work immediately after meetings.

That sounded sensible. It was also an assumption that would cause trouble later.

The backbone: nine goals and 26 steps

The product journey became nine goals:

Access the app → Capture commitments → Review detected commitments → Work through my tasks → Track what I’m waiting for → Manage my people → Stay on top of my day → Let AI agents track for me → Manage account and plan

The fourth and fifth goals represented the core product model: the ball is either with me or with somebody else. “Review detected commitments” became its own goal because AI-extracted commitments needed a quarantine state. Nothing should enter an active list until the manager confirms it.

Together, the nine goals contained 26 user steps. That was the product-shaped part of the backlog. Then the boring checklist arrived.

The foundations pass adds what specifications routinely omit

The story-map-creator carries a foundations checklist for requirements that almost every real product needs and almost no product specification remembers:

• registration and session management;
• empty states and error handling;
• feedback and support;
• plan and entitlement basics;
• data export and account deletion;
• privacy and GDPR considerations.

About 20 stories came from this pass. Most were routine. One was not.

The product stores personal data about third parties: names, email addresses, and companies belonging to people who never signed up and never consented to become users. In an EU product, that is not a footnote.

The foundations pass added a privacy story to registration. During later refinement, its acceptance criteria forced a precise statement: the manager may store personal data about non-user third parties and, for that data, the manager acts as the controller.

The specification did not contain that sentence. A checklist surfaced the topic; testable acceptance criteria turned it into a decision.

The approval checkpoint is the cheapest place to change your mind

Before Claude created the story cards, it presented the complete planned structure in the conversation: goals, steps, titles, personas, and release placement. Then it waited.

This can feel bureaucratic until you compare the cost of change. Moving a release boundary in a text preview takes one sentence. Correcting dozens of cards after they have been written requires dozens of tool calls.

I changed two things at the checkpoint. The generic collaboration goal disappeared because the specification explicitly excluded team features. Claude also flagged seven steps with no MVP story, including email capture, external identifiers, profile settings, and the entire AI-agent goal.

The quality checklist considered those empty MVP steps a defect. We accepted the defect deliberately. The first release was meant to be a single-user product with a tight loop: capture → two lists → follow up → complete. The complete backbone remained visible, while later capabilities stayed outside the first slice.

A checklist is useful when you can violate it with a reason. It is harmful when it replaces judgment.

The plan promised 76 stories; the board contained 82

The approval summary said 76 stories. After creation, the board contained 82.

No unauthorized card had appeared. Claude had undercounted its own goal-level totals in three places. The planned list contained 82 titles all along.

The important behavior happened at the end: the skill read the board back, compared it with the approved plan, noticed the mismatch, and reported that the summary—not the delivered content—was wrong.

This is the reliability pattern I want from an AI-generated backlog. I do not expect the model never to make a counting mistake. I expect it to verify the system of record and explain discrepancies instead of declaring success from memory.

Roughly 120 MCP calls, with a visible progress trail

There was no magic bulk operation behind the result. Each goal, step, story, persona, and release required a write. Nine goals, 26 steps, 82 stories, two personas, and the release structure added up to roughly 120 MCP calls.

The work ran in several rounds. After each round, Claude reported what had been created, what remained, and where the next round would continue. The skill’s failure policy was equally important: a failed card should be logged without abandoning the rest of the board, then reported during final verification.

That turns a long agentic action from a black box into an auditable process.

Two MCP constraints worth knowing before you start

At the time of this run—and still in the official MCP tool list as checked in August 2026—two UI actions were not exposed as MCP tools:

• Renaming the story map. The map name from my first lazy prompt was easy to change in the UI, but there was no UpdateStoryMap tool.
• Deleting a card. Cards could be created, updated, moved, reordered, and rescheduled, but there was no DeleteStoryMapCard tool.

Those constraints affected the workflow. The first makes naming an early decision. The second means the approval preview matters even more, because prevention is cheaper than reinterpretation.

The checklist I would keep

If I reduced the creator skill to its highest-value controls, I would keep these:

• Create reference objects before cards that depend on them.
• Build the journey backbone before brainstorming individual stories.
• Run a foundations pass that is separate from the product specification.
• Preview the full write plan and wait for approval.
• Write to the real system of record, not a disposable chat artifact.
• Read the board back and reconcile it with the approved plan.

The 82 cards were useful because of these controls, not because Claude created them quickly.

Next in the series: The gap finder found the hole I dug. The finished-looking board could create and complete work, but it had almost nothing in between.