Skip to content
Back to skills

Assumption And Risk Hunter

ASecurity

Surfaces hidden assumptions and prioritizes systemic risks to prevent project failure. Use after initial designs or specifications.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 27, 2026
databasesgosqlapi

Works with

  • api

Security analysis

A100/100

Scanned September 27, 2026

npx -y skills add David-Li0406/meta-skill-evloving --skill assumption-and-risk-hunter --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Assumption And Risk Hunter?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Assumption And Risk Hunter
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/david-li0406-assumption-and-risk-hunter/badge)](https://www.skillsdirectory.com/skills/david-li0406-assumption-and-risk-hunter)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: assumption-and-risk-hunter
description: Surfaces hidden assumptions and prioritizes systemic risks to prevent project failure. Use after initial designs or specifications.
triggers: [spec-freeze-prep, design-review, pre-migration-audit]
outputs: [risk-log, assumption-validation-plan]
---

# Assumption and Risk Hunter

## Purpose

Acts as a "red team" for plans and specifications. It identifies what we *think* is true but haven't verified, and what could go wrong if those assumptions fail.

## When to use this skill
- After an initial MVP design or specification is drafted
- Before moving from "Planning" to "Execution" phase
- Before executing a high-risk migration or cutover

## Hunting Steps

1. **Surface Implicit Assumptions**: Look for phrases like "assuming X", "users will...", "it should...".
2. **Rank Risks**: Evaluate each risk based on its Probability and its Impact on the project goals.
3. **Identify Irreversible Decisions**: Flag "one-way doors" that are hard to undo once implemented.
4. **Do Not Solve Yet**: Stay in "Hunter" mode. The goal is detection, not remediation.

## Decision Tree

```mermaid
flowchart TD
    A[Review Design/Spec] --> B{Unverified Assumptions?}
    B -->|Yes| C[Add to Assumption Log]
    B -->|No| D{Single Point of Failure?}
    D -->|Yes| E[Log as Critical Risk]
    D -->|No| F{Irreversible Change?}
    F -->|Yes| G[Log as High-Impact Risk]
    F -->|No| H[Approve for Execution]
```

## Review Checklist

1. **Brutal Honesty**: Does the risk log include "taboo" risks (e.g., "The legacy API is completely broken")?
2. **Specifics**: Are risks tied to specific spec IDs or code modules?
3. **Externalities**: Are dependencies on 3rd party services or other teams accounted for?
4. **Validity**: Has the assumption been tested or is it just "developer intuition"?

## How to provide feedback
- **Be specific**: "The risk 'DB is slow' is too vague."
- **Explain why**: "Vague risks cannot be mitigated with a validation plan."
- **Suggest alternatives**: "Replace with: 'PostgreSQL instance version is outdated, may not support JSONB indexing used in REQ-4'."

Brutal honesty over optimism.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…