agentleFS
Sign inStart free
fzfcleefzfclee/consulting-skills/skills/assumption-inventory/SKILL.md

assumption-inventory

Skill6 starsChanged 4 months agoApache-2.0View on GitHub

Use when a recommendation, plan, diagnosis, or stakeholder judgment depends on unstated assumptions that must be named and tested. Use when applying assumption inventory, assumption mapping, leap-of-faith assumption review, or critical assumption testing.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to expose the assumptions underneath a diagnosis or plan and decide which ones need testing first.

    line 9
  2. Distinctive:

    Not all assumptions require immediate testing.

    line 14
  3. Very specific:

    If an input is missing, mark it as missing, state the assumption used, and add a validation action.

    line 27
  4. Very specific:

    Do not use when the issue is primarily role ownership, numerical prioritization, or root cause analysis.

    line 31
  5. Distinctive:

    Do not list generic assumptions that would not change the plan.

    line 75
  6. Distinctive:

    Keep wording professional and practical.

    line 79

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Assumption Inventory

Use this skill to expose the assumptions underneath a diagnosis or plan and decide which ones need testing first.

Method Notes

  • An assumption is something the plan relies on but has not yet proven.
  • Not all assumptions require immediate testing. Prioritize assumptions by impact if wrong and uncertainty.
  • This skill is useful before investing effort, making stakeholder moves, or committing to a strategy.

Required Inputs

Collect or infer these inputs before execution:

  • current diagnosis, plan, or recommendation
  • intended outcome
  • key stakeholders or users
  • known facts and constraints
  • major risks if the plan is wrong

If an input is missing, mark it as missing, state the assumption used, and add a validation action.

When Not To Use

Do not use when the issue is primarily role ownership, numerical prioritization, or root cause analysis. Use raci-matrix, wsjf-prioritization, or five-whys-root-cause instead.

Step-by-Step Execution

StepRequired inputHow to executeOutput
State the plan or diagnosisCurrent recommendation, target outcome.Write the conclusion in one plain sentence.Plan / diagnosis statement.
Extract assumptionsPlan components, stakeholder beliefs, constraints, evidence gaps.Ask what must be true for this plan to work.Assumption list.
Classify assumptionsAssumption list.Label each as market, customer, stakeholder, capability, resource, timing, risk, economics, or compliance.Classified assumptions.
Rate criticalityImpact if wrong, uncertainty, reversibility.Score impact and uncertainty as high / medium / low. Mark whether the assumption is reversible.Critical assumption table.
Prioritize testsCritical assumptions, available access, deadline.Select the few assumptions that must be tested before action.Test priority list.
Define evidence neededAssumption, test method, success criteria.State what evidence would confirm, weaken, or disprove the assumption.Assumption test plan.

Output Template

### 1. Current Plan / Diagnosis
- Working conclusion:
- Desired outcome:
- Main consequence if wrong:

### 2. Assumption Inventory
| Assumption | Type | Evidence now | Impact if wrong | Uncertainty | Reversible? | Test priority |
|---|---|---|---|---|---|---|
|  | stakeholder / market / customer / capability / resource / timing / economics / risk / compliance |  | high / medium / low | high / medium / low | yes / no / partly | high / medium / low |

### 3. Critical Assumptions To Test First
1.
2.
3.

### 4. Test Plan
| Critical assumption | Evidence needed | Fastest test | Confirm signal | Disconfirm signal |
|---|---|---|---|---|
|  |  |  |  |  |

### 5. Decision Implication
- Proceed now:
- Wait until tested:
- Adjust plan:

Quality Gate

  • Do not list generic assumptions that would not change the plan.
  • Prioritize by impact and uncertainty, not by ease alone.
  • Separate assumption testing from action execution.
  • Name what decision can be made now and what should wait.
  • Keep wording professional and practical.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free