Product notes usually live in a chat, requirements in a document, and the backlog in Jira. Nothing connects them, so the same decisions get made three times and the reasons get lost on the way.
I built Yeti, an open-source MCP server that lets Claude run a product design from the problem to a verified scope, and then hand the result to Jira. This post walks through one example project, Mastro, which covers quotes for independent craftsmen.
What Yeti does
A project moves through five phases, in order:
- Discovery: the problem, the users and the goal.
- Definition: requirements with a MoSCoW priority, and user stories linked to them.
- Prioritisation: RICE scores for the ideas.
- Flows: Mermaid diagrams, with Yes and No branches.
- Verification: every must requirement is done and covered by a user story.
In strict mode, a phase advances only when it is complete. When it is not, Yeti says exactly what is missing. That is the part I care about most: the project does not look finished while it is not.
The Mastro example
Create the project. The problem, the users and the goal go into one sentence each. Yeti puts the project in the discovery phase.
Requirements and stories. Four musts: dictating quote lines on site, sending the quote, a customer register, and numbering with a PDF. Each must gets a user story with two or three acceptance criteria, linked to the requirement it covers.
Prioritisation. RICE orders the ideas: reach, impact, confidence and effort. Yeti sorts the scores; it does not estimate them. The numbers in the example are illustrative.
Flow. A diagram of how a quote is accepted, with a decision point for the customer and a branch for a quote that needs editing.
Verification. While a must has no story, or is not done, the project cannot close. This is the step that catches gaps before they reach a developer.
Preview and send to Jira. A dry run lists the issues without writing anything. Then the send creates a Task for each requirement and a Story for each user story. MoSCoW maps to Jira priority: Highest, High, Medium and Low. Sending again skips the items already created, so there are no duplicates.
Keep the status in sync. When an issue is marked done in Jira, the matching item is marked done in Yeti. Jira stays the place where the team tracks the work.
A dashboard you can keep open
Yeti includes a local, read-only dashboard. It shows the phase of each project, what is missing to move on, which musts have a story, the criteria progress, the RICE scores and the flows. It refreshes by itself, so you can see the effect of a change while you are talking to Claude.
What it does not do
Yeti does not estimate effort, and it is not a task board. Execution stays in Jira, and the estimates are your responsibility. I think that split is the right one: design decisions are easier to review in a structured form, and the team keeps the tool it already uses to build.
I should be clear about the example. The RICE values, the flow and the acceptance criteria come from a simulated run, not from a real project that was built. The point of the example is the workflow, not the numbers.
Try it
You need Node.js 22.13 or later:
npx -y yeti-mcp
Add it to Claude Desktop, and the tools appear in any chat. Jira is optional; it needs three environment variables, documented in the README.
The phase rules and the Jira mapping are the parts I most want feedback on. If you try it, an issue on the repository is the best place to say what worked and what did not.
Top comments (0)