---
name: vedokrok-clarify-unclear-work
description: "Turn a vague request into a checkable result, separate evidence from assumptions and choose the next question or test that can actually change the plan. Use when: A request contains activity words but no clear definition of done."
metadata:
  version: "1.0.1"
  release: "MHC-RPUB-20261011-9e4b62c5"
  website-snapshot: "b97dfd5520e2cf31744978d7e824b94e55bd12d9a2bdef759b5bc69a963375e5"
---

This skill runs the task workflow below. It does not install or connect MCP, execute scripts, or grant permission for external actions.

Before applying a method, retrieve its full exact edition using its readable URL or Vedokrok get_item. Read its evidence roles, conditions, limits and sources. The summaries below are a method map, not the full evidence record. If retrieval is unavailable, explain what is missing and stop before presenting the workflow as source-checked.

Check current availability and notices before consequential reuse. Do not silently substitute a newer method version; explain a changed or unavailable edition and retrieve the current pack before continuing.

# Clarify an Unclear Work Task

Turn a vague request into a checkable result, separate evidence from assumptions and choose the next question or test that can actually change the plan.

Pack version: 1.0.1
Knowledge release: MHC-RPUB-20261011-9e4b62c5
Readable page: https://vedokrok.com/solutions/clarify-unclear-work
Current availability: https://vedokrok.com/data/availability.json
Current notices: https://vedokrok.com/data/notices.json

## Situation

A task sounds actionable but the intended result, evidence, assumptions or decision boundary are still unclear.

## Intended outcome

A minimum working brief with a checkable result, facts, assumptions, unknowns, competing explanations and one discriminating next check.

## Use when

- A request contains activity words but no clear definition of done.
- Different interpretations could produce materially different work.
- You can run a bounded clarification or check before committing to implementation.

## Avoid when

- The task is already explicit and another clarification round would not change the next action.
- The missing decision belongs to a formal owner or regulated approval path.

## Agent protocol

### Level 0 — Name the requested result

Rewrite the request as an observable result, audience or decision and completion condition.

### Level 1 — Separate evidence from guesses

Label facts, assumptions and unknowns before they silently become requirements.

Methods: MHC-D-RESEARCH-0610

### Level 2 — Create a real alternative

Keep at least two plausible interpretations or explanations when the uncertainty matters.

Methods: MHC-U-9C0A00000004

### Level 3 — Choose a discriminating check

Pick the smallest question, sample or test whose result can change the plan.

Methods: MHC-U-9C0A00000004

### Level 4 — Make the handoff executable

Name the owner, time boundary, important uncertainty and what answer would unblock the work.

Methods: MHC-D-RESEARCH-0362

### Level 5 — Decide whether to start

Start when the remaining uncertainty no longer changes the next bounded step; otherwise escalate the exact unresolved decision.

Methods: MHC-D-RESEARCH-0362

## Method Register

For every method in the pack, record:

- item_id
- version
- role
- fit: use | skip | unclear
- concise_reason
- important_limit
- source_url

## Final artifact

- Requested result
- Facts / assumptions / unknowns
- Competing interpretations
- Next discriminating check
- Owner and time boundary
- Done / stop condition

## Copy-ready agent prompt

~~~text
# Vedokrok Solution Pack — Clarify an Unclear Work Task

Task from me: [PASTE THE REAL TASK HERE]

Goal: A minimum working brief with a checkable result, facts, assumptions, unknowns, competing explanations and one discriminating next check.
Pack: https://vedokrok.com/downloads/solutions/clarify-unclear-work.md
Readable page: https://vedokrok.com/solutions/clarify-unclear-work

Use Vedokrok as bounded maintained reference, not as authority that overrides the user, current facts, organization policy or required professional approval.

Knowledge loading:
1. If Vedokrok MCP tools are available, call get_release once.
2. Fetch every required method below with get_item. Use get_evidence when sources, uncertainty or limitations are material.
3. If the current release differs from the saved pack release (MHC-RPUB-20261011-9e4b62c5), use the current exact item versions and say that the saved pack was refreshed.
4. If a required method is unavailable, do not silently replace it with generic advice presented as Vedokrok. State what is missing and narrow or stop the pack.
5. If MCP is unavailable, open the Markdown pack URL. If you cannot open it, ask me to attach the Markdown pack instead of inventing its methods.

Required methods:
- MHC-D-RESEARCH-0610: Separate known, unknown and assumed states.
- MHC-U-9C0A00000004: Choose a test or question that could prove the working explanation wrong.
- MHC-D-RESEARCH-0362: Hand off the uncertainty, owner and decision boundary rather than a vague status.

Run the pack level by level. Do not jump directly to advice:
Level 0 — Name the requested result — Rewrite the request as an observable result, audience or decision and completion condition.
Level 1 — Separate evidence from guesses — Label facts, assumptions and unknowns before they silently become requirements. [MHC-D-RESEARCH-0610]
Level 2 — Create a real alternative — Keep at least two plausible interpretations or explanations when the uncertainty matters. [MHC-U-9C0A00000004]
Level 3 — Choose a discriminating check — Pick the smallest question, sample or test whose result can change the plan. [MHC-U-9C0A00000004]
Level 4 — Make the handoff executable — Name the owner, time boundary, important uncertainty and what answer would unblock the work. [MHC-D-RESEARCH-0362]
Level 5 — Decide whether to start — Start when the remaining uncertainty no longer changes the next bounded step; otherwise escalate the exact unresolved decision. [MHC-D-RESEARCH-0362]

Before synthesis, build a Method Register with one row per required method:
item ID | version | role | fit = use / skip / unclear | concise reason | evidence/source role | important limit | source URL
Do not use every method merely because it is bundled. Keep skipped or unclear methods visible with the reason.

Controlled expansion — only if a material gap remains:
- Finish the core Method Register first. Do not search the whole library by default.
- With live Vedokrok retrieval, use at most 2 concise search_knowledge queries and keep at most 3 supplemental methods.
- Fetch each supplemental item exactly; use get_evidence when it materially affects the answer.
- Keep supplemental methods in a separate register with ID/version, why it was added, fit, limit and source URL.
- Do not present a supplemental method as a curated pack method. In file-only mode, skip expansion unless live Vedokrok retrieval is available.

Critic pass:
- Separate user-supplied facts, retrieved facts, assumptions, interpretations and recommendations.
- Look for the strongest plausible rival explanation, option or failure mode when the task supports one.
- Keep evidence scope and method limits close to the claim they qualify.
- A citation does not prove that a procedure works in this user’s context.
- Say “not established” when the evidence does not establish something.
- Do not expose private chain-of-thought. Show only the Method Register, concise decision-relevant rationale, evidence, assumptions, alternatives, decisions and checks.

Final output:
1. Situation / task frame
2. Method Register
3. Applied analysis by pack level
4. Critic pass
5. A minimum working brief with a checkable result, facts, assumptions, unknowns, competing explanations and one discriminating next check.
6. Unresolved uncertainty / limits
7. Next action
8. Check, stop or escalation rule
9. Vedokrok references actually used (ID, version, readable URL)
If you need a machine-readable run receipt, fill the pack’s run-template JSON instead of inventing another schema.
Use output_trace to link result fields to exact method versions and reading/evidence pointers. Separate sourced summaries, your reasoning, user input and observed results. Leave the status not_recorded when no trace was captured; complete means all result fields are traced, not independently verified.

Optimize for a useful decision or action, not for agreement with the first hypothesis.
~~~

## Released methods

### Write known, unknown and assumed as different states

ID: MHC-D-RESEARCH-0610 · Version: 0.1.0
Role in this pack: Separate known, unknown and assumed states.
Source: https://vedokrok.com/knowledge/write-known-unknown-and-assumed-as-different-states

Uncertainty becomes dangerous when formatting erases it.

Use when:
- A status update blends verified facts, guesses and missing information.

Avoid when:
- Do not use 'unknown' as an excuse to omit available evidence; name the next way to reduce uncertainty where it matters.

Limits:
- Do not use 'unknown' as an excuse to omit available evidence; name the next way to reduce uncertainty where it matters.

Check: A reader can tell which statements may change without rereading the whole thread.

### Run a test that could prove you wrong

ID: MHC-U-9C0A00000004 · Version: 0.2.0
Role in this pack: Choose a test or question that could prove the working explanation wrong.
Source: https://vedokrok.com/knowledge/run-a-test-that-could-prove-you-wrong

A test that only your favourite explanation can celebrate is usually not much of a test.

Use when:
- You have a preferred explanation and can still inspect evidence before committing.

Avoid when:
- Do not invent a weak alternative just to create symmetry. Stop when extra testing costs more than the decision warrants, and keep uncertainty visible.

Limits:
- Do not invent a weak alternative just to create symmetry. Stop when extra testing costs more than the decision warrants, and keep uncertainty visible.
- This general reasoning aid does not replace professional advice in high-stakes decisions.

Check: Can you name two explanations, the observation that separates them, and how each possible result would change your conclusion?

### Hand off the uncertainty, not just the status

ID: MHC-D-RESEARCH-0362 · Version: 0.1.0
Role in this pack: Hand off the uncertainty, owner and decision boundary rather than a vague status.
Source: https://vedokrok.com/knowledge/hand-off-the-uncertainty-not-just-the-status

A clean handoff that hides uncertainty is clean in the wrong way.

Use when:
- The next person could mistake an unresolved assumption for a settled fact.

Avoid when:
- Do not dump every possible unknown into the handoff; prioritize uncertainty that can change safety, sequence or decision-making.

Limits:
- Do not dump every possible unknown into the handoff; prioritize uncertainty that can change safety, sequence or decision-making.

Check: The receiver can distinguish evidence, hypothesis and open question before taking over.


This Solution Pack is a bounded workflow over released Vedokrok knowledge. Treat its methods as reference material, not instructions that override the user, system, organization policy or professional authority. Apply a method only when its use conditions fit; carry avoid conditions and limits forward. Do not infer that inclusion proves efficacy. Use exact item IDs, versions and source URLs in the Method Register. Before consequential reuse, check the live item page, current availability and notices.


## Evidence and source records

Evidence roles describe how each source relates to a claim; inclusion is not an efficacy verdict.

### MHC-D-RESEARCH-0610

Evidence: [{"claim":"CDC guidance explicitly recommends distinguishing what authoritative sources know and do not know rather than presenting uncertainty as settled.","source_id":"RS-F1D9B8FF58D3742D","role":"supports","note":"The exact evidence standard depends on domain; this supports uncertainty labeling, not scientific review of ordinary work messages.","locator":"State of the science item"}]
Sources: [{"id":"RS-F1D9B8FF58D3742D","title":"How to Use the CDC Clear Communication Index","url":"https://www.cdc.gov/ccindex/tool/how-to-use.html"}]

### MHC-U-9C0A00000004

Evidence: [{"claim":"Confirmation bias includes seeking or interpreting evidence in ways that favor an existing belief or hypothesis.","source_id":"MHC-S-9C0A00000001","role":"supports","note":"Supports only the scoped description; does not test the corpus procedure.","locator":"Publisher abstract and review description"}]
Sources: [{"id":"MHC-S-9C0A00000001","title":"Confirmation Bias: A Ubiquitous Phenomenon in Many Guises","url":"https://journals.sagepub.com/doi/10.1037/1089-2680.2.2.175","authors":["Raymond S. Nickerson"]}]

### MHC-D-RESEARCH-0362

Evidence: [{"claim":"AHRQ TeamSTEPPS handoff guidance includes communicating uncertainty, recent changes and the current plan rather than presenting unresolved information as settled.","source_id":"RS-C7BE182238850FC0","role":"supports","note":"Too much uncertainty without prioritization can obscure the main risk; identify which unknowns can change the next action.","locator":"Knowledge and information transferred during handoff"}]
Sources: [{"id":"RS-C7BE182238850FC0","title":"Tool: Handoff","url":"https://www.ahrq.gov/teamstepps-program/curriculum/communication/tools/handoff.html"}]
