melech-market-validation

Files (6)

• SKILL.md
• evals.json · evals/
• artifacts.md · references/
• fieldwork.md · references/
• orchestration.md · references/
• research.md · references/

SKILL.md (first lines)

# Market Validation

Start with the opportunity as the user actually has it. If the premise is open,
help shape it without manufacturing certainty. Once it is testable, validate it
from plausibility to the strongest real-world evidence the user can obtain. Do
not mistake research, enthusiasm, interviews, or one pilot for a validated
market.

The skill has two connected modes:

- **Shape** — clarify and reframe an open opportunity until the next useful
  product or market hypothesis is visible. A verdict is optional.
- **Validate** — test one provisional hypothesis against customer, behavioral,
  and commercial evidence until an explicit market decision is possible.

When the user asks for full validation, the work is complete only when it has:

1. made the hypothesis falsifiable
2. mapped evidence for and against every decision-carrying claim
3. closed the most important evidence gap with primary or behavioral evidence
   when access permits
4. separated what is known from what remains merely plausible
5. produced an explicit **Advance / Reshape / Hold / Stop** decision

Market validation may span multiple sessions because customers and experiments
exist outside the chat. Preserve one living validation brief so the work can
resume without restarting.

## Boundary first

Choose this skill based on the state of the user's thinking:

| User has | Use |
|---|---|
| A concrete requested solution that may not serve the real need | Distill the real need first — not this skill |
| An open product or business opportunity and wants to discover a testable market premise | Shape it here, then validate when useful |
| A specific customer/problem/value hypothesis and wants to know whether reality supports it | Start at the validation contract |
| A market-backed direction and needs a shared build concept | Move on to shaping a buildable concept — not this skill |

Do not force an open idea into a validation contract before its important
pieces are legible. Conversely, do not keep ideating after one hypothesis has
stabilized when customer or commercial evidence now carries the decision.

## Validation model

Validation is not one binary badge. Track the evidence state of each claim:

- **Unsupported** — asserted, with no meaningful evidence
- **Plausible** — supported by credible secondary or first-party signals
- **Behavior-supported** — target customers repeatedly demonstrate the problem,
  workaround, switching, or relevant action
- **Commitment-supported** — the intended buyer gives scarce commitment such as
  money, signed pilot, procurement effort, data access, or meaningful time

The claims that usually carry a market decision are:

1. **Customer and situation** — a reachable segment encounters a specific
   triggering situation.
2. **Problem** — the situation creates frequent, severe, or costly consequences.
3. **Existing demand** — people already spend money, time, risk, or political
   capital to make progress.
4. **Buyer and budget** — an identifiable decision-maker owns the outcome and
   can fund change.
5. **Offer fit** — the proposed value and delivery shape beat the current
   alternative enough to motivate action.
6. **Reachability** — there is a credible path to repeatedly find and engage the
   segment.

Not every claim needs commitment-level evidence before proceeding. The riskiest
claim that would reverse the decision does.

## End-to-end workflow

### 0. Shape an open premise

Use this step when the user has an opportunity, aspiration, market question, or
vague product idea rather than a testable hypothesis. Treat the first idea as a
movable premise, not a contract.

Maintain a compact working map:

- **Aim** — the outcome the user wants
- **Relationship** — current-product opportunity, standalone product, adjacent
  product, or deliberately undecided
- **Premise** — current customer, situation, problem, product shape, and value
  mechanism, including blanks
- **Evidence and tensions** — observed facts, user claims, inference,
  contradictions, and consequential unknowns
- **Next decision** — the choice that most changes what should happen next

Work on only the uncertainty carrying that decision. Depending on the context:

- ask one to three questions only the user can answer
- inspect relevant product, repository, or first-party evidence
- research users, alternatives, competitors, market conditions, or feasibility
  proportionately
- compare one to three materially different premise shapes

Existing code proves capability, not need. Public complaints and feature
requests can reveal mechanisms and language, but not prevalence or willingness
to pay.

Give value in every turn: a synthesis, reframe, meaningful option, or next
decision—not an intake questionnaire. When the premise changes:

1. state the new shape in one sentence
2. preserve what remains valid
3. name what became invalid or uncertain
4. continue from the updated map without restarting

If the user only wants orientation, stop with the strongest current shape,
supporting evidence, remaining tension, and next useful move. Do not manufacture
a validation verdict. If customer, costly situation, current alternative,
buyer, and proposed value are legible enough to test, move into the validation
contract.

When the user requests a durable opportunity map, positioning, MVP boundary,
pitch narrative, or decision memo, read the relevant section of
`references/artifacts.md` and preserve the active evidence state.

From AdirD/agent-shell-hamelech, MIT.

More from AdirD/agent-shell-hamelech