New to Revelica? See how the product agent fits your team's workflow.
Read the introAI-assisted user story mapping for product teams. The product agent drafts the first map; you and your team refine the UX, surface assumptions, and slice releases; then export a requirements spec your coding agent builds from over MCP.
A story map turns a raw idea into a release-ready spec, moving between your coding agent and Revelica.
You hit a new idea while working on something else in your coding agent.
The agent uses this skill to save the idea to Revelica over MCP, so your team and other agents can see it.
In Revelica you refine the idea with the product agent and break it into releases.
Coding agents read the spec during implementation, save plans, and update status as they go.
See it in action
This one started as a design session in Claude Code. After some technical decisions were made, the agent saved the idea straight into Revelica through the MCP plugin: full treatment, wireframes and all.
The idea lands in the workspace with the problem, the bet, and the wireframes as the source of truth. No more digging through chat history to remember what was decided.
Any agent can turn ideas into a Revelica story map: users as rows, the activity backbone across the top, and a story in every cell. A complete first cut in one shot, ready for you to refine with the product agent.
The same story map is live in the Canvas and the coding agent plugin at once: you and a teammate, or just you moving between the two. Revelica tracks who changed what and syncs every edit across both in real time, so edits never clash and no one builds off a stale map.
Zoom in and each cell is a user story tied to a user and the opportunity it serves. Edit anything in place; the agent sees your changes and keeps the map coherent.
It’s usually wise not to build a whole idea at once, but it is still helpful to think about the future and document where things could go. Just prompt the agent to make a release and tag the stories for you!
The agent works the map with the classic prompts: what else might this user do? What about a different user? What could go wrong? On the riskiest cells it writes explicit assumptions you can test before anyone writes code.
Ask your coding agent to build one release knowing they can still see what’s coming next so they make smarter decisions that avoid tech debt.
The finished map exports as a requirements spec attached to the idea. Users, stories, releases, assumptions: everything a coding agent needs to build the right thing.
Back in Claude Code, the agent pulls the requirements over MCP, plans the build, and writes implementation plans and status back. Product context flows out, build context flows back.
A spec is not documentation for its own sake — it is a forcing function that surfaces implicit assumptions before implementation exposes them. The most valuable part is the Decisions log: each decision recorded with a one-line rationale so future readers know what was already considered and rejected. Without it, the same decisions get relitigated in every standup, design review, and code review. A good spec stops that cycle by making the thinking visible once and available to everyone who picks up the work.
Most valuable when an idea has passed discovery and the team is ready to commit to a direction. Too early and the spec will be rewritten; too late and the team has been building without alignment.
