Purpose

Inputs expected

Useful source material includes:

• an RFC or architecture note
• a plan or rollout document
• a ticket or epic description
• a product brief
• a migration proposal

If the input is only a single sentence, the output should be a short assumption inventory, not a fake full audit.

Operating procedure

1. Read for claims, not just tasks. Highlight statements that imply "this will work because..." even when the because-clause is unwritten.

2. Classify each assumption. Use the categories in references/assumption-taxonomy.md:

   • user or product behavior
   • dependency or integration behavior
   • operational environment
   • data quality or measurement
   • resourcing or ownership
   • policy, legal, or security approval

3. Mark support level. For each assumption, decide whether it is:

   • explicitly-supported
   • plausible-but-unproven
   • contradicted
   • unknown

4. Rank danger. Prioritize using three questions:

   • how wrong could this be
   • how much damage would it cause
   • how late would we discover it

5. Convert dangerous assumptions. For high-risk assumptions, turn them into one of:

   • a validation question
   • an approval gate
   • a prerequisite task
   • a monitoring requirement
   • an explicit note in the plan

6. Return an assumption register. Keep it small and sharp. The goal is not to catalog every background fact. The goal is to isolate the assumptions that can break execution.

Decision rules

• Prefer assumptions with high blast radius over assumptions that are merely interesting.
• Treat external vendor behavior, data cleanliness, and cross-team coordination as higher-risk than local code details unless the task context proves otherwise.
• If an assumption is already supported by a cited document, keep it in the register but lower its risk.
• If a statement is actually a decision, do not call it an assumption; capture only what that decision still relies on.
• If the plan says "we can just..." or "we only need to...", look for the hidden dependency being compressed by that phrase.

Output requirements

Return:

1. Top Assumptions
2. Why They Are Risky
3. Evidence Status
4. Required Conversions

Use a table when there are more than three assumptions.

Scripts

This skill is judgment-heavy. Do not add or use a script unless the input already exists in a structured register that needs deterministic reshaping.

References

• Read references/assumption-taxonomy.md to classify assumptions cleanly.
• Read references/danger-signals.md when the source document feels overconfident or compressed.
• Read references/conversion-patterns.md when turning assumptions into gates, questions, or tasks.

Failure handling

• If the source material is too thin, return only the highest-probability assumptions and say the audit is shallow because the source is shallow.
• If you cannot tell whether something is an assumption or a known fact, mark it as unknown and identify the evidence needed.
• If the document is already explicit and well-supported, say that the audit found low hidden-assumption risk instead of forcing drama into the output.

Named failure modes of this method

• Assumption inflation: Listing obvious background facts ("we assume users have internet access") alongside genuinely hidden dependencies, making the real risks hard to find. Fix: only include assumptions with non-trivial blast radius.
• Taxonomy without ranking: Classifying assumptions by category but not by danger, producing a flat list that doesn't guide action. Fix: always rank by the three danger questions (step 4).
• Conversion failure: Identifying dangerous assumptions but not converting them into gates, tasks, or monitoring—the audit becomes an academic exercise. Fix: every high-risk assumption must produce a conversion (step 5).
• Assumption-decision confusion: Calling a deliberate choice an "assumption" when it was already decided. Fix: if it was an explicit decision, capture what that decision still depends on, not the decision itself.