You don’t know what your specs cover until you’ve shipped them.
Specs accumulate in a backlog with no shape. You can’t tell which parts of your codebase are well-specced and which are blind spots. You can’t tell which work is contained — a leaf, safe to ship — and which work touches half the system. So planning runs on gut, and risk shows up in production.
The spec map shows you the shape. Every spec ever produced, organised three ways, with each one classified by how much of your codebase it touches. You see the coverage and you see the risk before you start.
Three views, one underlying map.
Each view organises the same specs differently.
A folder tree of every file your specs touch. Click a folder to see the specs in it. Click a spec to open it.
Specs grouped by the cluster theme they came from — so you see the shape of what your customers asked for, not just where it landed.
Specs grouped by the product page they affect, parsed from your component paths. “What have we shipped on the priorities page?” is one click.
Every spec is labelled contained, moderate or cross-cutting, based on how many files and folders it touches.
Coverage and risk, mapped from your specs.
No competitor can show this view because none of them read your codebase. Annsa reads it, classifies every spec by what it touches, and lets you navigate the map three different ways.
Annsa builds a live tree of your codebase from every spec’s Files-to-Touch section, so the map reflects what you’ve planned to build.
Contained (≤ 2 files, ≤ 1 folder), moderate, or cross-cutting (≥ 5 files, ≥ 3 folders). You see surgical work and system-wide work at a glance.
Annsa parses your component file paths to group specs by product page. No tagging, no mapping table — the structure of your codebase is the structure of the map.
What’s in the map.
Folder tree, recursively expandable. Click a node, see the specs.
Specs grouped by cluster theme.
Specs grouped by parsed product page name.
Specs that don’t map to a page land here cleanly, not forced into the wrong group.
Two side-by-side tables for the safest work and the riskiest, so you can choose your week.
Every node opens the same spec panel. One artifact, many entry points.
Asked and answered.
A view of every spec your team has ever produced, organised by where it lives in your codebase, what theme it came from, or what product page it touches. Each spec is classified by blast radius.
How much of your codebase a spec touches. Contained means two files or fewer in one folder — safe, leaf-node work. Cross-cutting means five files or more across three folders — surgical, system-wide. Moderate is everything in between.
From the Files-to-Touch section of every spec annsa has ever produced. It’s a live map of where your planned work lands in the codebase, not a separate tag taxonomy.
It parses your component file paths. “src/components/pages/{Name}Page.tsx” becomes “{Name}”. Specs that don’t match a page rule land in a “Backend / shared” group, so nothing is forced into the wrong place.
Yes. Every spec row, every folder node, every tile opens the same spec panel — the one you’d open from the priority list. Same artifact, different entry point.
Learn more about the annsa Delivery suite.
The full feature overview — specs, roadmap, ship and share back.
One build-ready spec from the feedback behind a priority, cited line by line.
Sequenced by impact, not by date — hand any card to Cursor or Claude Code.
Ships specs to your editor over MCP and closes the loop with the customers who asked.
When a spec ships, drafts each customer who asked a follow-up in their words.