Structure vague opportunities and unclear briefs
Ambiguity Resolver Skill

Structure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to…
--- name: ambiguity-resolver description: "Structure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to figure out what to do about X' or 'I've been asked to look into Y'. Produces a structured problem brief with reframed questions, scoped boundaries, and a minimum viable research plan." --- # 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 Ask the user for these if not provided: - **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
Overview
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.
Manual install (npx, ZIP)
npx skills add mohitagw15856/pm-claude-skills --skill ambiguity-resolver -g -a claude-codemkdir -p ~/.claude/skills && curl -sL https://codeload.github.com/mohitagw15856/pm-claude-skills/tar.gz/f6ca79348c55 \
| tar -xz -C ~/.claude/skills --strip-components=2 pm-claude-skills-f6ca79348c55/skills/ambiguity-resolverNew-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null; Invoke-WebRequest "https://m.agentalley.io/zip/7fa71df5f64cc8e51d15/ambiguity-resolver.zip" -OutFile "$env:TEMP\ambiguity-resolver.zip"; Expand-Archive "$env:TEMP\ambiguity-resolver.zip" -DestinationPath "$HOME\.claude\skills" -ForceConnects with Agent Alley MCP · agentalley.io/mcp
Files included
SKILL.md4.0 KB
Read the files here
mohitagw15856/
Show the full text88 lines
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
Ask the user for these if not provided:
- 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:
- [Question 1]
- [Question 2]
- [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:
| Activity | Time required | What it tells us | What 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:
- Are enterprise customers churning, underperforming on expansion, or both?
- Is this a product gap, a support/service gap, or a pricing/packaging issue?
- 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)
| 1 | |
| 2 | name ambiguity-resolver |
| 3 | description "Structure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to figure out what to do about X' or 'I've been asked to look into Y'. Produces a structured problem brief with reframed questions, scoped boundaries, and a minimum viable research plan." |
| 4 | |
| 5 | |
| 6 | # Ambiguity Resolver Skill |
| 7 | |
| 8 | 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. |
| 9 | |
| 10 | ## Required Inputs |
| 11 | |
| 12 | Ask the user for these if not provided: |
| 13 | **The vague brief or opportunity description** (even a single sentence is enough) |
| 14 | **Who asked for this** (stakeholder context shapes the framing) |
| 15 | **Known constraints** (timeline, budget, team size — if any are known) |
| 16 | |
| 17 | ## Three-Stage Process |
| 18 | |
| 19 | ### Stage 1: Reframe |
| 20 | Restate the vague input as 3-5 explicit questions that need answering |
| 21 | Identify the unstated assumptions hidden in the brief |
| 22 | Surface the real decision this feeds into (what will someone do differently once this is resolved?) |
| 23 | |
| 24 | ### Stage 2: Scope |
| 25 | Define what is explicitly IN scope |
| 26 | Define what is explicitly OUT of scope (equally important) |
| 27 | Identify the deadline pressure: is this urgent/important, important/not urgent, or unclear? |
| 28 | Name who owns the final decision and who needs to be consulted |
| 29 | |
| 30 | ### Stage 3: Action |
| 31 | Define the minimum viable research: 2-3 activities maximum that would give enough signal to move forward with confidence |
| 32 | Time estimate for each activity |
| 33 | What each activity would tell you (and what it wouldn't) |
| 34 | Proposed check-in point: when to regroup before committing to more |
| 35 | |
| 36 | **Validate** — Confirm every reframed question maps to at least one research activity. Verify scope boundaries are specific enough to say "no" to something concrete. |
| 37 | |
| 38 | ## Output Structure |
| 39 | |
| 40 | ### Problem Brief: [Opportunity Area] |
| 41 | |
| 42 | **Restated as questions:** |
| 43 | [Question 1] |
| 44 | [Question 2] |
| 45 | [Question 3] |
| 46 | |
| 47 | **Unstated assumptions we should surface:** |
| 48 | [Assumption 1] |
| 49 | [Assumption 2] |
| 50 | |
| 51 | **In scope:** [Clear boundary] |
| 52 | **Out of scope:** [Clear boundary] |
| 53 | **Decision owner:** [Name/role] |
| 54 | **Timeline:** [Real deadline if known, or "unclear — recommend setting one"] |
| 55 | |
| 56 | **Minimum viable research:** |
| 57 | | Activity | Time required | What it tells us | What it won't tell us | |
| 58 | |----------|--------------|------------------|-----------------------| |
| 59 | | [activity] | [time] | [insight] | [limitation] | |
| 60 | |
| 61 | **Proposed check-in:** After [activity], regroup to decide whether to proceed or pivot. |
| 62 | |
| 63 | ## Example (Partial) |
| 64 | |
| 65 | Input: *"We need to figure out what to do about our enterprise customers."* |
| 66 | |
| 67 | **Restated as questions:** |
| 68 | Are enterprise customers churning, underperforming on expansion, or both? |
| 69 | Is this a product gap, a support/service gap, or a pricing/packaging issue? |
| 70 | What does "do something" look like — a new initiative, a policy change, or a resource shift? |
| 71 | |
| 72 | **In scope:** Enterprise accounts ($50K+ ARR) showing declining health scores in the last two quarters |
| 73 | **Out of scope:** SMB segment, new enterprise acquisition strategy |
| 74 | |
| 75 | ## Anti-Patterns |
| 76 | |
| 77 | [ ] Do not reframe the brief into questions that are still too broad to research — each reframed question must be answerable by a specific activity |
| 78 | [ ] Do not list a research activity without stating what it would tell you and what it would NOT tell you |
| 79 | [ ] Do not leave the decision owner as "leadership" or "the team" — name a specific person or role |
| 80 | [ ] Do not omit an explicit out-of-scope boundary — without it, scope will expand organically and the brief becomes meaningless |
| 81 | |
| 82 | ## Quality Checks |
| 83 | |
| 84 | [ ] Every reframed question is specific enough to research (not "how do we improve things?") |
| 85 | [ ] Scope boundaries name something concrete that is excluded |
| 86 | [ ] Research activities are achievable within the stated timeline |
| 87 | [ ] Decision owner is identified (not "leadership" — a specific person or role) |
| 88 |
Details
- Updated
- Sep 23, 2026
- License
- MIT
- Stars on the repo
- ★ 1,395
- Checked
- Source
- mohitagw15856/pm-claude-skills ↗
- Creator
- mohitagw15856 · 193 listings
Made with ambiguity-resolver


Similar skills
See all →
SkillReverse engineer native, managed, Electron/JavaScriptREA
SkillBrainstorms ideas into designs before any creative workBrainstorming Ideas Into Designs
SkillRequires technical rigor and verificationCode Review Reception
SkillDiagnosis loop for hard bugs and performance regressionsDiagnosing bugs
SkillImplement the result of /to-spec and /to-tickets in codeImplement spec
SkillWriting a PR bodyMore from mohitagw15856
SkillDesign a 360-degree feedback survey or write a structured360-Degree Feedback Template Skill
SkillDesign statistically rigorous A/B tests for product featuresA/B Test Planner Skill
SkillGenerate a WCAG 2.2 accessibility audit checklistAccessibility Audit Skill
SkillBuild a structured account plan for any key customerAccount Plan Skill
SkillOptimize an article for Answer Engine Optimization so AIAEO Optimizer Skill
SkillConduct a structured ethical review of an AI or ML featureAI Ethics Review Skill