I build things on monday.com for a living, which means I spend a lot of time turning half-formed product ideas into something a development team can actually work from. When Claude started supporting MCP connectors and custom skills, I wanted to find out how far I could push that specific job: from a rough idea to a properly structured, release-sliced backlog — not as text in a chat window, but as real cards in a real tool.
The tool is StoriesOnBoard, and it has an MCP server. That combination turned out to be the interesting part. What follows is how I built a family of five skills around it, what I got wrong on the first attempt, and why each design decision ended up where it did.
This isn't a list of prompt tricks. It's the reasoning behind a small system.
1. The starting point: why "make me a backlog" isn't enough
Ask any competent LLM to break a product description into user stories and you'll get a decent list. The format will be right, the stories will be plausible, and it will take about twenty seconds.
Then what?
The list lives in a chat window. Nobody on your team can drag a card. You can't slice a release. You can't hand it to a PM. And two weeks later, when the product has moved on, the list is a fossil.
There are two things missing, and they're at opposite ends of the process. At the front, there's no thinking: the model happily generates stories for an idea nobody has stress-tested, which means you get a beautifully structured backlog for a product that shouldn't be built. At the back, there's no destination: the output isn't in the tool where the work actually happens.
The StoriesOnBoard MCP solves the second problem — it lets Claude create the map, the personas, the releases and the cards directly. My job was to solve the first one, and to connect the two ends into something you can run end to end.
2. The first version, and what was wrong with it
I already had a story-map-creator skill. It followed the Jeff Patton story mapping method, it produced a sensible hierarchy of goals, steps and stories, and it rendered the whole thing as a nice HTML artifact.
That last part was the mistake.
It's worth sitting with the question for a second, because it's the fork the whole design hangs on: why would I render an HTML artifact when the StoriesOnBoard MCP is right there?
The honest answer is that the artifact is easier. It always works, it looks good, it doesn't depend on a connector being enabled, and it gives you something satisfying to look at immediately. It feels like a deliverable.
But it's a picture of a backlog, not a backlog. You can't drag a story from Release 2 into the MVP. Your PM can't open it. Nobody can comment on a card, assign an owner, or mark something done. It doesn't survive the conversation — close the tab and it's gone. And critically, it can't be edited by the process that comes next: the whole point of a story map is that it's a living artifact you keep re-slicing as you learn.
An HTML rendering is a simulation of the output. The MCP produces the output. Once I framed it that way, the decision made itself: every visual that stood in for the deliverable came out, and the skill's job became writing to the board.
(There's one legitimate use for a visual in this system, and I'll come back to it in section 11 — but it isn't the backlog.)
The other thing I hit immediately was a terminology trap. In the StoriesOnBoard UI, the hierarchy is Goal → Step → Story. In the MCP tools, the same three things are called activity → task → subtask. If you don't pin this down, the model drifts between vocabularies and starts explaining "subtasks" to a user who's looking at a screen that says "Story". So the mapping went into the skill as a fixed table, with a rule: UI terms when talking to the user, MCP terms when calling tools.
The general lesson from this first cleanup: decide what the deliverable is before you write anything else. Every other decision in the skill follows from that one, and if you get it wrong, you get a skill that does impressive work in the wrong place.
3. First principle: the agent must not write immediately
The moment the skill started writing to a real board, a new failure mode appeared. A medium-sized product generates something like sixty cards. If the agent creates all sixty and then shows you the result, you're not reviewing a plan — you're cleaning up a mess. Deleting cards is slower than not creating them.
So every skill in the family that writes to the board has the same structure: draft, present, wait, then write.
The approval checkpoint is a plain markdown preview in the chat — goals, steps, stories with release labels, personas, and any assumptions the model made. You approve it, edit it, or throw parts out. Nothing touches the board until you say so.
Note that the preview is text, not a rendered visual. That's the same principle from section 2 applied one level down: a visual preview would be prettier, but the preview isn't the product either — it's a review surface, and text is the fastest thing to read and correct.
Two smaller rules came out of practice:
- Partial failures don't abort the run. If one card fails to create, the skill notes it, keeps going, and reports the failures at the end. Half a backlog plus an error message is much worse than a full backlog with three known gaps.
- Re-confirmation is scoped. If you change something in the preview, the skill confirms the change, not the entire plan again.
This pattern got copied into every writing skill in the family. It's the single highest-value convention in the whole set.
4. Why discovery became its own skill
The creator skill expects a PRD. In real life, the PRD is the thing that doesn't exist yet.
I could have bolted a "if the input is vague, ask some questions" branch onto the creator. I didn't, for two reasons.
First, it's a different phase of work. Discovery is a conversation that can take twenty minutes and change the product; backlog building is a structured transformation that takes two. Bundling them means every backlog request drags a discovery interview behind it.
Second, it's a different trigger. "I have an idea, help me think it through" and "here's the PRD, build the backlog" are different sentences with different intents. Keeping them separate makes both skills fire more accurately.
So product-discovery became its own skill, running a structured interview: problem framing → personas and jobs-to-be-done → assumptions and risks → differentiation → scope and journey outline → success metrics. Its output is a discovery brief — a compact mini-PRD that becomes the creator's input.
The handoff is explicit. At the end of discovery, the skill offers to build the backlog, and if you say yes, the brief is passed to the creator as the PRD.
5. The fine-tune that made discovery useful: make it picky
The first version of the discovery skill was polite and useless.
It asked its questions, wrote down whatever I said, and produced a tidy brief. The problem is that an LLM's default conversational mode is agreeable, and a discovery conversation where everything you say is accepted is just dictation with extra steps. I told it my target users were "small businesses" and it wrote down "small businesses."
So I gave it a stance. The skill now opens with an explicit instruction that it is not a note-taker but a skeptical product coach, and the job is to make the idea survive scrutiny before anyone builds a backlog from it. Concretely:
- Vague answers get rejected. "Everyone", "users want it", "it saves time" are non-answers. Push for a specific person, a specific situation, a specific number.
- Challenge the premise. How do they solve this today, and why isn't that good enough? If the current workaround is fine, say so.
- Play devil's advocate at least once per phase. Offer the strongest reason the idea fails, and make the user respond to it.
- Question scope creep. When features pile up, ask which one gets cut first and why the rest belong in v1.
- Name what's missing. If the user can't say who pays or what success means, put it on the record as an open risk instead of papering over it.
- The hardest one: "What evidence do you have for this, other than that you like the idea?"
This made the skill dramatically more useful and slightly unbearable, which brings me to the part I consider the actual design work: the brake.
An instruction to "be critical" with no exit condition produces an interrogation. Every weak answer spawns a follow-up, every follow-up spawns another, and you never reach the brief. So the skill has hard limits: one follow-up challenge per weak answer. If the second answer is still thin, the question is recorded as an open risk and the conversation moves on. If the user is impatient, the skill compresses — it states its assumptions and the risks you're accepting, then hands off.
The general principle, which I've since applied everywhere: any instruction to be critical, thorough, or detailed needs a matching exit condition. Personality is configuration, but unbounded personality is a loop.
6. What almost became its own skill: uniqueness
Halfway through, I hit a design question I genuinely went back and forth on. Where does "is this product actually different from what exists?" belong? Its own skill, or part of discovery?
I put it in discovery, as a dedicated step, and I think that's right.
Differentiation isn't a separate phase of work — it's the most common form of the riskiest assumption. "Why would anyone switch?" is exactly the desirability question the discovery interview is already circling. Splitting it out would mean discovery produces a brief with no positioning in it, which is a weak input for a backlog: the differentiating features are precisely the ones that should anchor the MVP.
The step asks three things. What are the real alternatives — including "do nothing", spreadsheets and manual workarounds, not just direct competitors? What's the one thing this does meaningfully better, in a single sentence? And the switch test: why would someone already using the strongest alternative pay the cost of switching, and if that alternative shipped this feature tomorrow, what's left?
One specific rule earns its place here: no differentiation by adjective. "Simpler", "better UX", "AI-powered" are not answers. The skill demands a concrete capability or workflow the alternatives structurally can't or won't match. And if no credible differentiation emerges, that gets recorded as a top open risk — possibly the riskiest assumption — and stated plainly.
The output feeds forward: the differentiating capabilities are marked to become MVP-priority stories, because the first release exists to validate exactly those.
There is a version of this that deserves its own skill — a research-driven competitive analysis with actual web search, real competitors and a feature matrix. That's a different kind of work: research-heavy rather than conversational, and runnable against existing products. It's on my list, but it isn't this.
7. The logic of splitting the skills
By this point I had a rule of thumb I applied to every new capability. Three questions:
1. Is it a different phase of work? 2. Would I trigger it with different words? 3. Would it run at a different time?
Three yeses means a new skill. Fewer means a step inside an existing one.
The failure modes on either side are real. One giant skill has a fuzzy trigger and runs steps you don't need — every request drags the whole pipeline behind it. Ten tiny skills mean the chain falls apart and the burden of knowing what to call lands on the user, which defeats the point.
Two examples of the rule in action:
The gap-finder passed. Auditing a story map for missing journey phases and missing stories is the same domain as building one, but it runs against an existing map, at a different time, triggered by completely different language ("what's missing from the backlog?"). Different phase, different trigger, different time — new skill.
The description template failed the split test in an interesting way. More on that next, because it turned out to be the most important structural decision in the set.
8. The decision that mattered most: who is allowed to write descriptions
Here's the observation that reorganized everything.
Two different skills create story cards: the creator builds the initial backlog, and the gap-finder adds the stories that were missing. If both of them know how to write a full story description — the expanded narrative, the acceptance criteria — then I have the same template in two places. A month later, after I've tweaked one of them, I have two different templates and no idea which one produced any given card.
So the rule became: exactly one skill in the family is allowed to write card descriptions. That skill is story-refiner. The creator and the gap-finder both carry an explicit guardrail: cards are title-only, descriptions are not their job.
This isn't just anti-duplication hygiene — it happens to match how story mapping actually works. Refinement is just-in-time. You don't write acceptance criteria for sixty stories; you write them for the ten in the next release, when you're about to build them. A creator that wrote full descriptions for everything would generate an enormous amount of text nobody reviews, and would make the approval checkpoint unusable.
The refiner's template is deliberately simple:
**As a** [persona]
**I want to** [action]
**so that** [benefit]
**Acceptance criteria**
- [criterion 1]
- [criterion 2]
- [criterion 3]The quality bar for the criteria is where the tuning went. Three to seven bullets. Each one independently verifiable — a tester can answer yes or no to it. Cover the happy path, the key variations, and the most important error case. Stay at the level of what, not how: "the user receives an email within one minute" beats "the system notifies the user."
And my favourite rule in the entire set, which fell out of writing that spec: if a story needs more than about seven acceptance criteria, it isn't a refinement problem, it's a splitting problem. The skill says so and proposes a split instead of forcing it. Refinement became a size check for free.
9. The boring parts I never think about during discovery
Run a discovery conversation about any product and notice what you talk about: the interesting part. The thing that makes it different. The clever bit.
Notice what you never mention: login. Password reset. Roles and permissions. Audit logs. GDPR data export. Empty states. These are unglamorous, universally necessary, and completely absent from every PRD I've ever written.
My first instinct was a separate skill — something like "add the baseline items." That instinct was wrong, and for a specific reason: I would never invoke it. Nobody starts a message with "add the boring parts." The entire point is that it should happen without me remembering, precisely because I didn't remember during discovery.
So it became a step inside the creator: a foundations pass that runs after the structure is designed but before the approval preview. It walks a checklist of ten categories — authentication, account and profile, roles and permissions, audit and traceability, notifications, settings and administration, data and GDPR, error and empty states, billing, and support — and adds the applicable items as normal stories.
Two details make it work rather than just adding noise.
The checklist lives in a separate bundled file (references/foundations.md), not in the skill's main logic. When I think of a new recurring category — internationalization, rate limiting for API products — I add a section to that file and touch nothing else. The SKILL.md holds the logic; the reference file holds the knowledge. Those age at different rates, and separating them is what makes the thing maintainable.
Every category has an "applies when" condition. An internal tool doesn't need public registration — it needs SSO. Billing only applies if the product implies revenue. Adding an inapplicable foundation item is as much a mistake as missing a needed one, and the checklist says so explicitly. Each category also carries default release guidance: authentication and consent belong in the MVP because the product is unusable (or illegal) without them, while audit logs and data export usually sit in Release 2 unless the domain is compliance-sensitive.
Finally, foundation stories are marked in the approval preview with a distinct label, so you can see at a glance what came from your PRD and what came from the checklist — and drop anything that doesn't apply to your product.
10. What the MCP could do, and what I only found out by looking
At some point I stopped guessing and actually read the tool schemas. This is a boring recommendation that had an outsized effect: before writing a skill for an MCP server, look at what its tools genuinely accept.
I had assumed personas were basically names. They're not. CreateStoryMapPersona takes a markdown description, a group label, custom fields defined on the map, and personality slider values. And separately, CreateStoryMapCard accepts a personas parameter — meaning a story can be tagged with its persona at creation time, not patched afterwards.
That changed two things in the design. The discovery skill now writes its persona profiles — context, job-to-be-done, pain points — as self-contained markdown blocks, specifically so they can go straight into the persona's description field without reformatting. And every story card the creator or gap-finder produces gets tagged with the persona named in its narrative, so the board shows who each story is for.
None of this was in my original plan. It came from reading the schema.
11. The fifth skill: how do I know where I am?
With four skills in place, a practical problem showed up: when should I still be talking, and when can I start building?
Discovery has no natural end. You can always ask another question. And I kept catching myself either jumping to the backlog too early — building a beautiful structure on assumptions I hadn't tested — or looping in discovery long after the picture was clear.
So the fifth skill, story-map-navigator, holds a shared phase model:
1. Discovery — fundamentals, users, uniqueness, journey sketch 2. Journey building — the goal/step backbone on the board 3. Backlog building — stories under the steps, plus the foundations pass 4. Story brainstorming — edge cases, error states, secondary personas 5. Release slicing — MVP / R2 / R3, with refinement following just-in-time
The visible output is an inline tracker showing where you are, but the tracker is the cheap part. What makes it work is the gate criteria — an objective exit condition for each phase. Without them, a progress bar is decoration; the agent moves on exactly when it would have anyway.
The gates are concrete. Discovery is done when there's a brief with a specific problem and target user, one to four non-generic personas with JTBD, alternatives plus a one-sentence unique value, and a four-to-eight phase journey sketch — where each item is either answered or explicitly recorded as an open risk. Journey building is done when the backbone covers entry → core loop → exit and every goal has at least two steps. Backlog building is done when every step has at least one story and the foundations pass has run. Story brainstorming is done when every persona has stories and no step has zero MVP stories. Release slicing is done when the MVP is coherent and shippable on its own, and the differentiating capabilities sit inside it.
Why a fifth skill rather than a section in each of the other four? The same reason as the description template: all four need the phase model, and four copies of a criteria list is four lists that diverge. One place, maintained once.
12. The artifact that is not a database
My original idea for the tracker was this: the skills watch the artifact, evaluate my answers, and update it as questions get resolved.
That isn't how it works, and finding out why produced a better design.
The widget is one-way. Claude renders it; Claude cannot read it back. There's no channel from a rendered artifact into the model's context. Skills can't "watch" it, and clicking a checkbox inside it tells the model nothing. The only bridge in the other direction is sendPrompt, which sends a message into the chat as if you'd typed it.
So instead of storing state in the artifact, I made the open questions derived. On every render, they're recomputed from the conversation against the gate criteria: each unmet criterion becomes an open question. Nothing is stored, so nothing can drift. If you answer something, revise it, or contradict yourself three messages later, the next render reflects reality automatically — no sync problem, because there's no state to sync.
This is genuinely better than what I originally wanted. A stored checklist would have needed maintenance and would eventually have been wrong.
Two details make the tracker useful rather than decorative:
- Questions are tiered. Ones blocking the current phase's gate are separated from ones needed later, so you can see what actually stops you versus what's merely pending.
- Clicking a question sends a pre-filled answer opener, not the question itself. Clicking the unique-value question sends "The one-sentence unique value is: " and you complete the sentence. The loop closes in one action.
And it renders sparingly — on phase changes, on request, or when the picture visibly moves. The rest of the time a one-line status prefix is enough. A widget on every turn is slow and noisy.
Note the distinction from section 2, because it's the whole point: this visual doesn't replace the deliverable. It's navigation. The backlog still lives on the board; the tracker just tells you when it makes sense to start building it.
13. The most important brake: gates are recommendations, not gatekeepers
The thing I was most worried about building was an assistant that tells me I'm not allowed to proceed.
Nothing would make this system more annoying than a phase model that enforces itself. So the navigator carries a set of non-blocking rules that explicitly override everything else in the file:
1. Never refuse to move on. If I want to advance, we advance. State once what's missing and what risk that carries, then proceed. Don't ask twice, don't raise it again three turns later. 2. Phases aren't one-way. Remembering a new persona during backlog building is normal. Record it, continue, don't reset progress or restart a phase. 3. Don't cut a conversation short. A satisfied gate means I may move on, not that I should. Never interrupt an ongoing discussion with a prompt to advance. 4. Unanswered is a valid answer. Questions I decline to answer become accepted open risks in the brief — not an endless nag loop. 5. The tracker is optional. If I never ask for it and the flow runs fine, the one-line status is enough.
The underlying principle: the agent's job is to serve me, not to defend its own process. A workflow that protects itself from the user has stopped being a tool.
14. How the five skills connect
The full path, in one sentence: idea → brief → backbone → backlog → gap fill → slicing → refinement.
product-discovery is the only skill that never touches the board; its output is a text brief that flows into story-map-creator. The creator, story-map-gap-finder and story-refiner all write through the MCP, but to different layers: the creator builds the structure (personas, releases, title-only cards), the gap-finder adds what's missing, and the refiner fills in descriptions and acceptance criteria. story-map-navigator wraps all four — it writes nothing, it just tracks where you are and renders the tracker.
One practical caveat worth knowing if you build a skill family: the cross-references aren't hard links. A skill can't programmatically invoke another. What happens is that the agent reads a skill name in the instructions, and because that skill is also installed, it loads and follows it. The chain only works if all five are installed. If one is missing, the agent will describe what it would do and then not do it.
15. What I learned about building a skill family
- Define the deliverable first. Everything else follows from it, and getting it wrong means building something impressive in the wrong place.
- One thing lives in exactly one place. A duplicated template is a guaranteed future inconsistency. This produced both the description-ownership rule and the shared phase model.
- Every "be critical" needs an exit condition. Personality without a brake is a loop.
- Separate logic from knowledge. SKILL.md holds the process; bundled reference files hold the content that changes. They age at different rates.
- Approval checkpoints aren't friction. They're what makes a writing agent usable on a real system of record.
- Read the tool schemas. Half my better design decisions came from discovering what the MCP could already do.
- A skill is a product, not a prompt. You version it, test it, and tune it — and the tuning is mostly about limits, not capabilities.
16. What's next
I'll be writing up each phase as its own piece: discovery in practice, PRD to backlog, auditing a map for gaps, and just-in-time refinement.
Two things are still on my list. A research-driven competitive analysis skill — the version of section 6 that actually goes and looks at competitors. And more foundations categories: internationalization, rate limiting, and the other things I'll keep forgetting during discovery until a checklist remembers them for me.