before-we-make-a-mess

name

before-we-make-a-mess

description

Guide product discovery for uncertain opportunities, features, and UX/UI directions by framing the problem, target users, outcomes, alternatives, evidence, assumptions, and risks; choose focused research, experiments, or prototypes and define decision gates before interaction design or further product investment. Use when deciding whether or what to build, comparing opportunities, turning discovery evidence into a product decision, planning validation, or judging readiness to hand off. Do not use for research summaries without a decision, project management, detailed interaction patterns, standalone usability reviews, copy refinement, or standalone technical architecture and implementation.

Before We Make a Mess

Operating contract

Make an uncertain product decision explicit and evidence-aware before consolidating a UX/UI solution. Produce a decision, a focused learning action, or a bounded handoff—not a delivery roadmap or an encyclopedic checklist.

Never invent users, evidence, metrics, research findings, provenance, or confidence. Keep facts/evidence, inferences, assumptions, and unknowns visibly distinct.

If the request is solely about interaction patterns, interface usability, visible text, project delivery, or technical implementation, route it to the relevant specialist and stop. When discovery and design are mixed, resolve the blocking product decision first and hand off only the remaining responsibility.

Workflow

1. Define the decision. Rewrite the request as a concrete commitment to accept, defer, reframe, or reject. Name whether it concerns an opportunity, candidate solution, learning activity, or readiness gate.
2. Frame the opportunity. State target, situation, problem, current alternative, desired outcome, success signal, urgency, and material constraints. Separate the outcome from the proposed solution. Mark missing information rather than filling it plausibly.
3. Build the claim ledger. Classify each decisive claim as evidence, inference, assumption, or unknown. Preserve provenance, limitations, and contradictions. Treat stakeholder opinions and model output as claims, not evidence.
4. Prioritize risks. Translate assumptions into consequences if false. Consider problem/value, use/comprehension, feasibility, business/context, and harm only when they can change the decision. Keep at most five active risks by default.
5. Choose the next learning action. Target the highest-priority risk with the smallest credible research activity, experiment, prototype, spike, or bounded live test. Predeclare observable signals and the decision each result would change.
6. Take a position. Select proceed, continue discovery, reframe/pause, or stop. Explain the evidence used, residual risk, reversibility, and what the state authorizes now. Do not present proceed as proof or stop as permanent truth.
7. Define the handoff. Pass only the problem frame, decisive claims, accepted risks, constraints, prioritized principles, open questions, and review triggers. Do not perform the recipient skill’s work.

Ask a question only when its answer could materially change the next action. Otherwise proceed with explicit assumptions and a conditional recommendation.

Collaboration handoff

• Accept an optional handoff containing goal, evidence, constraints, decisions, open risks, artifact paths, and one next task; do not require an upstream skill or a fixed pipeline.
• Verify relevant artifacts and treat handoff statements as claims: preserve provenance and keep evidence, inference, assumption, unknown, and prior decision distinct.
• Keep prior decisions as constraints unless new evidence or a blocking contradiction requires them to be reopened; state any reversal explicitly.
• When discovery authorizes downstream work, produce a handoff of at most 400 words using those same fields rather than copying the discovery brief.
• Put only settled product decisions and confidence in Decisions; keep unresolved interaction questions and accepted exposure in Open Risks.
• Set Next Task to one precise responsibility that is now ready. Suggest another installed skill only when that responsibility is outside discovery; otherwise name the capability without making the suite mandatory.

Reference routing

Load only the references required by the current decision:

• Read opportunity-framing.md when the request begins with a feature, vague opportunity, unclear outcome, multiple stakeholders, or unordered product principles. Skip it when the problem frame is already decision-ready.
• Read evidence-and-risk.md when interpreting research or data, checking provenance, separating claim states, resolving contradictions, classifying reversibility, or prioritizing risks. Skip it for a simple framing request with no evidence to assess.
• Read experiments-and-prototypes.md when proposing a learning activity, selecting prototype fidelity, protecting participants, or interpreting test results. Skip it when no experiment or result is at issue.
• Read decision-gates-and-handoffs.md when issuing a go/no-go or readiness decision, recording a commitment, or handing work to interaction design or engineering. Skip it during early framing that does not authorize a transition.

Read more than one reference only when the request genuinely spans those responsibilities. Never load all four by default.

Decision criteria

Prioritize risks in this order:

1. cost of error, including harm and expensive reversal;
2. power to block downstream decisions;
3. weakness or contradiction of current evidence;
4. urgency of the real decision point;
5. information gained per unit of cost, time, and exposure.

Require stronger evidence for irreversible or difficult-to-reverse commitments. For bounded reversible decisions, allow lighter evidence only with an exposure limit, rollback path, owner, and trigger.

Avoid numeric scoring unless the user supplies a meaningful model. If risks remain tied, explain the trade-off and choose the one that can produce decision-changing learning sooner.

Authorize an interaction-design handoff only when the target, problem, outcome, alternatives, solution boundaries, constraints, decisive evidence, assumptions, critical residual risks, and open interaction questions are explicit enough that design can proceed without hiding a product gap. Do not claim readiness for engineering from discovery evidence alone.

Output

Title the default response Discovery decision brief. Include only useful sections, in this order:

1. Decision and state—decision question plus proceed, continue discovery, reframe/pause, or stop.
2. Problem, target, and outcome—concise frame and material constraints.
3. Claim ledger—state, claim, provenance or reasoning, limitation, and decision implication.
4. Priority risks—at most five by default, with consequence, evidence gap, and reversibility.
5. Next learning action—target risk, minimum method or artifact, participants/data, observable signals, safeguards, and affected decision.
6. Recommendation—what to do now, why, and which residual risk is being accepted.
7. Readiness or handoff—conditions met, conditions missing, recipient, and review trigger.

Compress simple cases and omit empty sections. If evidence is absent, foreground unknowns and the next learning action. Name user-provided artifacts directly; do not cite the source material behind this skill.

Quality rules

• Record observations separately from explanations; expose plausible alternative interpretations when they could change the decision.
• State what each piece of evidence or test does not establish. Never claim that one favorable test validates a product.
• Prefer behavior and operational outcomes over compliments, hypothetical preference, artifact completion, or stakeholder enthusiasm.
• Match prototype fidelity to the uncertainty being tested; higher fidelity is not stronger evidence by default.
• Refuse deceptive or live tests whose learning value does not justify privacy, safety, financial, accessibility, or trust exposure.
• Keep recommendations prioritized and conditional. Do not hide uncertainty behind generic best practices or fabricated confidence percentages.
• Route only the next unresolved responsibility; do not turn the UX/UI suite into a mandatory pipeline.
• Keep the core workflow tool-independent so it works in Codex and Claude Code.