This page is an agent-readable workflow for Deck. Humans can follow along. Coding agents should treat the steps as the source of truth.

Roadmap evidence check — agent workflow

• Use it when: the user asks "which roadmap items have no customer evidence?", "is our roadmap backed by feedback?" or "what are we building on gut feel?"
• Outcome: each roadmap item in scope has an evidence status, with Deck's counts and links. Evidence that Deck has but did not link is linked, if the user says yes.
• Needs: Deck MCP. The check only reads. Links to evidence are optional writes. Subtheme search needs the Starter plan or higher.

1. Probe Deck MCP

Call get_user_context. This must be a real tool call.

• 401 Unauthorized: tell the user to connect Deck MCP in this client (Settings → Connections). Stop.
• No Deck tools: fetch and follow https://docs.getdeck.io/docs/agents/getting-started/prompts/ai-pm.md. Stop this workflow until the tools work.

2. Set the scope and the threshold

Ask the user for the scope. Typical answers are all active work, one initiative, one owner, or one segment.

Ask for the evidence threshold. The default is fewer than 3 linked insights. The Deck Backlog page uses the same line: it hides opportunities with fewer than 3 pieces of evidence.

Roadmap items that are only in Linear or Jira have no Deck evidence. Import them first with Import the Linear roadmap or Import Jira epics.

3. Read the roadmap

Make these calls at the same time. Add the filters that the user named, for example owner or segment_id. For one initiative, call explore_build_initiatives and add initiative_id to list_projects.

• list_initiatives with status: "active". Read leveraged_insights_count and the Projects of each initiative.
• list_projects with status: "not_started".
• list_projects with status: "in_progress".

Each Project row has evidence_count and external_link. Page with offset or cursor until you have every item in scope.

4. Shortlist the thin items

Put an item on the shortlist when Deck's count is below the threshold. Do not compute a count of your own.

Open each shortlisted item. Make these calls at the same time:

• A Project: explore_build_projects with project_id. Read the evidence, the linked opportunity and the parent initiative.
• An initiative: explore_build_initiatives with initiative_id. Read leveraged_insight_ids, evidence_provenance and the Projects. An initiative can have little evidence while its Projects have a lot. Report both counts as Deck gives them.

5. Look for evidence that Deck already has

For each thin item, take 2 or 3 keywords from its title and description. Make these calls at the same time:

• search_deck with query. It returns matching insights, themes, subthemes and opportunities, each with a link.
• explore_insights with query. Add segment_ids when the item has segments.
• explore_themes with query.
• explore_subthemes with query. On the Free plan this returns feature_unavailable. Then skip it.

A keyword match is a candidate, not proof. Before you propose a link, read the insight with explore_insights and insight_id. Keep only insights that support the item.

To see related opportunities, call explore_opportunity_backlog with min_evidence: 0. An opportunity with evidence can back the item.

6. Report

Give each item one status:

• Evidence found, not linked: Deck has supporting insights or an opportunity that the item does not link. List them.
• Thin evidence: Deck has a few related insights. Give Deck's counts.
• No evidence in Deck: no search found support.

Show one table: item, type, Deck's evidence count, status, candidate evidence with links, and a recommendation. Some items have no customer evidence for a good reason, for example security, compliance or platform work. Say so when the description shows it. Do not call an item wrong because it has no evidence.

7. Link the evidence (optional)

Show the exact links that you will make and get a yes. Then make one call for each item:

• A Project: add_project_insights with project_id, insight_ids and a short reason.
• An initiative: add_initiative_insights with initiative_id and insight_ids (1-100).

Then read Deck's new count and report it. For a Project, call list_projects again and read evidence_count. For an initiative, call explore_build_initiatives again and read leveraged_insights_count.

generate_project_evidence_story rewrites the Evidence section and spends credits. Call it only when the user asks for it, and get a yes each time.

Rules

• Show the plan and get a yes before you call write tools.
• Quote Deck's numbers. Do not compute your own.
• Use only insight IDs from Deck results. Never invent IDs.
• Link an insight only after you read it and it supports the item.
• Low evidence is a signal to check, not a verdict. Recommend customer research when Deck has no evidence.
• If the user has more than one Deck organization, call select_organization first and pass org_id on every call.

Done when

• Each item in scope has a status and Deck's evidence count.
• Each candidate insight, theme or opportunity in the report has a Deck link.
• The links that the user approved are written, and the new counts come from Deck.

See also: Initiatives, Projects, Opportunity Backlog and Model Context Protocol.