Imported from ByronFinn/dev-skills (skills/have-a-try/SKILL.md). Install upstream with npx skills add ByronFinn/dev-skills --skill have-a-try. Copyright stays with the author.

Have-a-Try: Settle a Divergence with a Minimal Demo

🥷 The conflict decides the demo. The demo settles the conflict.

A divergence is multiple mutually exclusive options, or one claim pitted against doubt about it, that reasoning alone can't separate. This skill writes disposable code that produces the missing evidence: a minimal demo aimed at the contested point, run in one command, adjudicated on what it shows. A verdict that eliminates a wrong option is as valuable as one that selects the best.

This is the pipeline's adjudication-by-experiment service. /think generates options but writes no code; /grill challenges decisions by reasoning and reading; /research settles what documentation can settle. When the answer exists only in "run it and see" — on your machine, your load, your state machine, your eye — that's here.

Outcome Contract

• Outcome: One settled divergence — a candidate selected, one or more eliminated, or a tie/all-fail verdict — with evidence and rationale captured durably.
• Done when: The verdict is recorded (PRD ## Traceability / ADR / commit message / NOTES.md next to the demo) and the demo shell is disposed of (deleted, validated core absorbed, or archived).
• Evidence: The demo runs via one command; the verdict names what was selected or eliminated and why.
• Output: Divergence, tactic, verdict, evidence, where captured, disposition.

The Pipeline

Phase 1 — State the divergence. Write down the decision, the conflicting positions (a candidate set, or "this design holds" vs "it breaks"), and what evidence would settle it. If you can't name the divergence, that's /think's job, not this skill's.

Phase 2 — Build the minimal demo. Cover only the contested surface — anything in the demo that isn't disputed is scope creep. Pick the tactic from the table below; when none fits, synthesize one (CUSTOM, in REFERENCE.md).

Phase 3 — Verify the core conflict. Run it (one command). Push each position toward its worst case: the awkward scenario, the realistic load, the concern list. Watch what the evidence says.

Phase 4 — Adjudicate and fix the evidence. Select, eliminate, or call a tie/all-fail — all three are valid verdicts. Record decision + evidence + one-line rationale where the divergence was born (see below). Then dispose of the shell.

Divergence type → tactic

The tactics are walked paths, not a closed enum — any decision that running code can settle belongs here, on one of these paths or a synthesized one.

Route out (this is the wrong skill when…)

• The divergence hasn't formed — candidates can't be named, concerns can't be listed → /think.
• Documentation or an authoritative source settles it as-is (no my-machine / my-load factor) → /research.
• No divergence — behavior is already accepted and needs a proper implementation → /tdd.
• Open-ended performance tuning with no candidates to compare ("just make it faster") → /debug.

Where This Skill Sits

Evidence flows back to where the divergence was born:

Rules

1. Throwaway from day one. Locate the demo close to its target code; name it to signal prototype, not production. Follow project routing conventions. State the demo's file location explicitly (anti-pattern #13 — no unsolicited or unannounced files).
2. One command to run. Use the project's existing task runner. (anti-pattern #29 — run command is the success contract.)
3. No persistence by default. In-memory state. If persistence IS the contested point, use a scratch store with a clear "PROTOTYPE" name.
4. Minimal — cover only the contested surface. Skip the polish: no tests, no error handling beyond runnability, no abstractions. Anything uncontested inside the demo is scope creep. (Prototype-scoped; the opposite of /tdd discipline — don't let it leak.)
5. Surface the evidence. State panel (LOGIC), variant switch (UI), numbers with environment (BENCH), concern matrix (SPIKE) — after every action, show what changed or what was measured.
6. Adjudicate, then dispose. Capture verdict + evidence + rationale; delete the shell or absorb the validated core into real code. Only when the verdict is contested or the losing samples have archive value: commit the demo to a throwaway branch off main and leave a pointer at the verdict record. Don't leave it rotting on main.

Process Summary

Step 0 — Bootstrap. Apply the Skill Entry Protocol — it reads CONTEXT.md and docs/adr/ and reports what's missing.

Step 1 — State the divergence. Decision, conflicting positions, deciding evidence, acceptable outcomes — including elimination. A demo answering the wrong divergence is pure waste.

Step 2 — Pick the tactic. From the table above, or CUSTOM. If ambiguous and the user isn't reachable, default by matching surrounding code (backend module → LOGIC/BENCH/SPIKE; page/component → UI) and state the assumption at the top of the demo.

Step 3 — Build the minimal demo. Follow the tactic chapter in REFERENCE.md. Match the project's existing language, tooling, conventions — don't add new runtimes or structures. (anti-pattern #19)

Step 4 — Hand it over. Give the user the run command (LOGIC/BENCH/SPIKE) or URL + ?variant= keys (UI). They drive it. The interesting moments are "wait, that shouldn't be possible" — those are bugs in the idea, which is the point.

Step 5 — Adjudicate, fix the evidence, dispose. Record verdict + evidence + rationale where the divergence was born (PRD Prototyped by / ADR / commit / NOTES.md). Then delete the shell, absorb its validated core, or archive it per Rule 6.

See REFERENCE.md for the full LOGIC / UI / BENCH / SPIKE processes and the CUSTOM synthesis rules.

Gotchas

Output

Have-a-try complete.

Divergence: <the decision and its conflicting positions, one sentence>
Tactic:     LOGIC | UI | BENCH | SPIKE | CUSTOM
Run:        <the one command, URL + ?variant= keys, or results location>

Verdict:    Selected <X> because <evidence-based reason>
            | Eliminated <Y> because <evidence-based reason>
            | Tie / all failed — <what this means for the plan>

Evidence:   <what was observed: state transitions, chosen variant,
             numbers + environment, concern×option matrix>

Captured at: <PRD-NNNN ## Traceability Prototyped by | ADR <NNNN> (see docs/adr/) | commit | NOTES.md>

Demo disposition:
- Deleted (shell only, nothing worth keeping)
- Absorbed core into <real module/route> (shell deleted)
- Archived to throwaway branch <name> (pointer left at <verdict record>)

Next (route by where the divergence was born):
- /think → close the PRD Open Question; /grill (or /think if the plan broke)
- /grill → fold the verdict into an ADR; resume /grill
- /research → cross-ref the research record; /think or /grill
- mid-build → record on the issue/commit; continue the seam via /implement

PRD Traceability: If a PRD exists for the feature, fill the Prototyped by field in its ## Traceability section so downstream skills know a demo adjudicated (selected or eliminated) a design option:

- **Prototyped by**: `/have-a-try` (<YYYY-MM-DD>) — <divergence> → <selected X / eliminated Y>, because <evidence>