Min Specs

Use this skill to define the smallest set of must-have conditions that make an action viable.

Method Notes

• Min Specs identify what is truly required, not a wish list.
• The method helps prevent overbuilding, over-negotiating, and pursuing deals that cannot work.
• A good Min Spec is binary enough to guide proceed / adjust / stop decisions.

Required Inputs

Collect or infer these inputs before execution:

• desired outcome
• proposed action, deal, solution, or change
• constraints and non-negotiables
• known failure modes
• stakeholder or customer requirements

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 user needs to rank attractive options rather than define viability. Use decision-matrix, weighted-scorecard, or wsjf-prioritization instead.

Step-by-Step Execution

Output Template

### 1. Success Definition
- Desired outcome:
- Decision boundary:
- What would count as failure:

### 2. Min Specs
| Minimum condition | Why it is required | Evidence now | How to verify | Pass / fail / unknown |
|---|---|---|---|---|
|  |  |  |  |  |

### 3. Nice-To-Haves Removed
- Nice-to-have:
- Why it is not required now:

### 4. No-Go Criteria
| No-go condition | Trigger signal | Response |
|---|---|---|
|  |  |  |

### 5. Decision Gate
- Proceed if:
- Adjust if:
- Stop if:
- First thing to verify:

Quality Gate

• Keep Min Specs few and strict. If everything is required, nothing is clarified.
• Avoid vague wording such as "good support" or "strong alignment"; define observable behavior.
• Separate minimum conditions from preferences.
• Include stop or redesign criteria.
• Keep the output usable in a real decision conversation.