min-specs

name	min-specs
description	Use when a plan, partnership, deal, product, change, or stakeholder move needs the minimum necessary conditions for success. Use when applying Min Specs, minimum specifications, must-have constraints, no-go criteria, or success conditions.
license	Apache-2.0

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

Step	Required input	How to execute	Output
Define success	Desired outcome, decision boundary.	State what must be true for the initiative to be considered successful.	Success definition.
List possible requirements	Stakeholder needs, constraints, risks, operating needs.	Create a broad list of candidate conditions.	Requirement pool.
Remove nice-to-haves	Candidate requirements, success definition.	Ask whether success fails without this condition. If not, move it to nice-to-have.	Trimmed requirements.
Convert to minimum specs	Must-have conditions.	Rewrite each condition as observable, testable, and binary where possible.	Min Specs list.
Define no-go criteria	Failure modes, risk tolerance, constraints.	State what would make the action non-viable or require redesign.	No-go list.
Link to next action	Current plan, validation access, owners.	Decide what to confirm first and what action is allowed before confirmation.	Decision gate.

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.