mcpField
A
ambiguity-resolver

ambiguity-resolver

github.com/mohitagw15856Productivity1.5k47 installsUpdated 5d ago
Repository

About ambiguity-resolver

ambiguity-resolver is a skill for people handling vague briefs or early-stage opportunities. It turns them into researchable questions, explicit scope boundaries and a small set of actions tied to a decision.

Key features

  1. 01Reframes briefs as answerable questions
  2. 02Surfaces unstated assumptions
  3. 03Defines in-scope and out-of-scope areas
  4. 04Identifies decision owners and timelines
  5. 05Plans focused research activities

Use cases

  1. 01Clarify an undefined project request
  2. 02Set boundaries for opportunity research
  3. 03Plan next steps before committing resources

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill ambiguity-resolver

After installing, type/ambiguity-resolverin Claude Code to confirm it loaded.

Details

From the project README

Ambiguity Resolver Skill

Turn vague briefs and half-formed opportunities into structured, actionable problem statements — so you can reply with clarity instead of asking for three more meetings.

Required Inputs

Work from what is given. If any of these is missing, still produce the complete output: fill each gap with a reasonable assumption marked (assumed, confirm) and list those assumptions at the end. Ask a question first only when the core subject itself is missing (there is nothing to write about).

  • The vague brief or opportunity description (even a single sentence is enough)
  • Who asked for this (stakeholder context shapes the framing)
  • Known constraints (timeline, budget, team size — if any are known)

Three-Stage Process

Stage 1: Reframe
  • Restate the vague input as 3-5 explicit questions that need answering
  • Identify the unstated assumptions hidden in the brief
  • Surface the real decision this feeds into (what will someone do differently once this is resolved?)
Stage 2: Scope
  • Define what is explicitly IN scope
  • Define what is explicitly OUT of scope (equally important)
  • Identify the deadline pressure: is this urgent/important, important/not urgent, or unclear?
  • Name who owns the final decision and who needs to be consulted
Stage 3: Action
  • Define the minimum viable research: 2-3 activities maximum that would give enough signal to move forward with confidence
  • Time estimate for each activity
  • What each activity would tell you (and what it wouldn't)
  • Proposed check-in point: when to regroup before committing to more

Validate — Confirm every reframed question maps to at least one research activity. Verify scope boundaries are specific enough to say "no" to something concrete.

Output Structure

Problem Brief: [Opportunity Area]

Restated as questions:

  1. [Question 1]
  2. [Question 2]
  3. [Question 3]

Unstated assumptions we should surface:

  • [Assumption 1]
  • [Assumption 2]

In scope: [Clear boundary] Out of scope: [Clear boundary] Decision owner: [Name/role] Timeline: [Real deadline if known, or "unclear — recommend setting one"]

Minimum viable research:

ActivityTime requiredWhat it tells usWhat it won't tell us
[activity][time][insight][limitation]

Proposed check-in: After [activity], regroup to decide whether to proceed or pivot.

Example (Partial)

Input: "We need to figure out what to do about our enterprise customers."

Restated as questions:

  1. Are enterprise customers churning, underperforming on expansion, or both?
  2. Is this a product gap, a support/service gap, or a pricing/packaging issue?
  3. What does "do something" look like — a new initiative, a policy change, or a resource shift?

In scope: Enterprise accounts ($50K+ ARR) showing declining health scores in the last two quarters Out of scope: SMB segment, new enterprise acquisition strategy

Anti-Patterns

  • Do not reframe the brief into questions that are still too broad to research — each reframed question must be answerable by a specific activity
  • Do not list a research activity without stating what it would tell you and what it would NOT tell you
  • Do not leave the decision owner as "leadership" or "the team" — name a specific person or role
  • Do not omit an explicit out-of-scope boundary — without it, scope will expand organically and the brief becomes meaningless

Quality Checks

  • Every reframed question is specific enough to research (not "how do we improve things?")
  • Scope boundaries name something concrete that is excluded
  • Research activities are achievable within the stated timeline
  • Decision owner is identified (not "leadership" — a specific person or role)

Example Trigger Phrases

  • "Clarify a vague brief."
  • "Frame an undefined problem."
  • "Make sense of an unclear opportunity."
  • "We need to figure out what to do about X."
  • "I've been asked to look into Y."

Comments

Markdown supported