Search decisions

What this is for

Jupi is where this team records decisions — the alternatives weighed, the rationale, who decided, and what was learned. A lot of that knowledge is invisible at the moment you need it: you're about to spec a feature or argue an approach, and the question was already settled (or deliberately left open) weeks ago. This skill pulls that history back into view before you commit to a direction.

The payoff is twofold: precedent (a past decision that supports or informs what you're doing) and contradiction (a finalized decision your current direction would violate). Surfacing the second one early is the whole point — it's much cheaper to notice a conflict now than in review.

This applies especially to upstream ideation and strategy work — brainstorming a feature, but equally a GTM plan, a pricing model, a hire, an org change, a positioning shift. The skill isn't product-specific; any time someone is generating ideas or shaping a direction in the business, there may be a recorded decision or business insight that bounds it. When the user is generating ideas rather than asking a direct question, don't wait to be asked: pull the relevant area and any adjacent business insights into view so the ideas they form are compatible with what's already been decided. In that mode, derive a query (or a few) from the theme they're exploring rather than from a literal request, and surface findings as context alongside their thinking rather than as a blocking interruption.

Tools you'll use

Both are provided by the Jupi MCP server. Depending on how it's connected they may appear namespaced (e.g. mcp__Jupi__search-decisions-tool or mcp__claude_ai_Jupi__search-decisions-tool) — use whichever the environment exposes.

• search-decisions-tool — hybrid semantic + keyword search over a workspace's STARTED and FINALIZED decisions. Returns ranked items, each with id, title, description?, status, relevanceScore, and insights ({fact, quote, authors, chunkId}). Inputs: query (required), groupSlug or groupId, topK (default 10, max 50).
• get-decision — full state of one decision: Postgres fields plus the live document (savedOptions, skippedOptions, criteria, decisionComments), selectedOptionIds, closingText, summary, insights. Inputs: decisionId (required), groupSlug or groupId.

Note search-decisions-tool already returns insights, so you often don't need get-decision at all. Reach for get-decision only on the handful of results worth a deep look — to read the actual options considered, the criteria, or the closing rationale.