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

Release impact check — agent workflow

• Use it when: the user asks "did the release work?", "did complaints about exports go down after we shipped?" or "check the impact of this Project".
• Outcome: the user has Deck's totals for each target theme in two equal windows, Deck's trend data, quotes from after the release and a short verdict. Deck changes only when the user approves a write in step 9.
• Needs: Deck MCP and the release date. Subtheme trends and NPS need the Starter plan or higher. The check is more reliable when 14 days or more have passed since the release.

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. Pin the release

Ask for the release date (YYYY-MM-DD) and what shipped.

If the release belongs to a Deck Project, call explore_build_projects with its project_id. Read the success metrics, completed_at and evidence.active_references. When the user gives no date, propose the date in completed_at and ask the user to confirm it.

3. Pick the signal

• From a Project: call explore_insights with each evidence insight_id, at the same time, for at most 20 insights. Read theme_id and theme_associations. Keep the 1 to 3 themes that come up most often.
• From a topic: call explore_themes with query set to the topic.
• Subthemes: on the Starter plan or higher, call explore_subthemes with the theme_id and segment_scope: "all_customers". Keep a subtheme only when it matches what shipped.

Show the list and get a yes. Ask if the check is for all customers or for some segments. Use the same segment_ids on every later call. For all customers, set no segment_ids, and add segment_scope: "all_customers" to each explore_subthemes call. Without it, an organization with segments gets the subthemes of every segment.

4. Set two equal windows

• After: from the release date to today. Use date_from and date_to.
• Before: the same number of days, and it ends on the day before the release.

Deck dates each insight by when the customer said it: the interview date, else the import date. Call list_sources with created_after set to the release date. Read the processing summary. When sources still process or wait for credits, say that the after totals can still grow.

5. Get Deck's totals

For each theme and each window, make these calls at the same time. Use limit: 1, because you need only total.

• explore_insights with theme_id, date_from and date_to.
• The same call with sentiment: "NEGATIVE".
• The same call with category: "BUGS_AND_ERRORS", when the release fixes a bug.

Also call explore_insights with only date_from and date_to for each window. This total shows if the full feedback volume changed. Read total and applied_scope in each result.

6. Read Deck's trends

Make these calls at the same time:

• explore_themes with query set to each theme name. Each list row has Deck's surge stats and sentiment shares.
• explore_subthemes with the theme_id and sort: "trending". Each subtheme shows Deck's trend for the last 14 days against the 14 days before. These windows are fixed, so they can differ from your windows.
• explore_nps with focus: "trends", only when the release targets an NPS driver.

On the Free plan, the last two calls return feature_unavailable. Leave those parts out and say why.

7. Read the quotes from after the release

Call explore_insights with each theme_id, the after window and sentiment: "NEGATIVE", with limit: 20. Sort each quote into one of three groups:

• The same problem is still there.
• A new problem, which can be a regression.
• Not related to the release.

Then call it again with sentiment: "POSITIVE" and limit: 10 to find praise of the change.

8. Report

Show one table for each theme: the window, Deck's total, the negative total and the bug total. Add the full feedback total for each window. Then add:

• Deck's surge, trend and NPS data from step 6.
• 3 to 5 quotes, each with its deck_url.
• A verdict in words: fewer, about the same, more, or too early to tell.
• Caveats: short windows, sources that still process, a change in full feedback volume, and other changes in the same period.

9. Record the result (optional)

Make each write only after a yes:

• update_project_section with project_id and section_key: "success_metrics". Read the section first. The call replaces the whole section, so keep the current content and add the result as a new paragraph. content is an array of editor block nodes.
• update_project_status with status: "completed", when the release shipped and the Project is not completed yet.

Then offer the Customer follow-up workflow.

Rules

• Both windows have the same length and the same segment scope.
• Quote Deck's numbers. Do not compute your own. Show the totals side by side. Do not compute percent changes.
• Call a change "fewer" or "more" only from Deck's totals. When the after window is shorter than 7 days, the verdict is "too early to tell".
• Do not claim that the release caused a change. Name other events in the same period.
• Show the plan and get a yes before you call write tools.
• Never ask for a dk_ API key.

Done when

• The user has the table, the trend data, the quotes and the verdict.
• Each number comes from a Deck tool result in this session.
• Nothing changed in Deck without a yes.

See also: Themes, Subthemes, Projects and NPS Score.