Reality Check

Strong Trigger Signals

Use this skill when the real question is about:

• hidden rules — admissions filters, hiring screens, status markers, gatekeepers, distribution control, reputation games, or institutional politics
• information asymmetry — one side knows the real score while the user is reasoning from public narratives only
• survivability — whether the downside, timeline, burn, or reputational cost is survivable if the optimistic story is wrong
• resource mismatch — the path assumes more capital, network, credentials, stamina, distribution, or patience than the user really has
• platform ceiling — the apparent upside is capped by channel dependence, customer concentration, gatekeeper control, or a structurally weak position

Do Not Use

Do not use this skill for:

• startup GTM, CAC, churn, runway, pricing, or unit-economics teardowns — use greenfield-product/startup-pressure-test
• vague situations where the main job is to define the actual problem — use using-reasoning/problem-definition
• distorted reasoning states driven by attachment, urgency, or defended identity — use using-reasoning/thinking-ground
• source-heavy fact gathering, market sizing, or evidence synthesis requests — use the appropriate research skill
• general advisory memos once the problem is already clear and the user wants a structured recommendation — use using-reasoning/domain-expert-consultation
• clear operational diagnosis where the job is to analyze a defined problem through lenses and choose the next move — use using-reasoning/dynamic-problem-solving

Analysis Workflow

1. State the Actual Bet

Say plainly what the user is betting:

• money
• time
• reputation
• career option value
• relationship or social capital
• platform dependence

If the bet cannot be stated in one or two sentences, stop and route to using-reasoning/problem-definition.

2. Surface the Hidden Rule Set

Ask which non-obvious rules decide outcomes here:

• Who really gets filtered in or out?
• What does the public story say versus what gatekeepers actually reward?
• Which credentials, signals, or relationships matter more than merit claims?
• Where is the selection bias hiding?
• Which incentives make the official story incomplete or misleading?

Label each major claim as Observed pattern, Supported hypothesis, or Uncertain.

3. Run the Survivability Check

Assume the optimistic narrative is partly wrong.

Check:

• What is the most likely failure path?
• How expensive is being early, naive, under-networked, under-credentialed, or under-capitalized?
• Can the user survive the timeline, downside, and opportunity cost?
• Does one failed attempt merely delay them, or does it close doors?

The key question is not whether the upside exists. It is whether the user survives being wrong.

4. Check Resource Match and Platform Ceiling

Compare the path's implied requirements against the user's actual position.

Look for mismatch in:

• money and burn tolerance
• distribution and audience access
• credibility, credentials, and references
• execution stamina and learning curve
• willingness to do low-status or slow compounding work
• dependence on one platform, gatekeeper, or customer segment

Name any ceiling that makes the path look larger than it is.

5. Separate Structural Truth from Tactical Fixes

Do not overcorrect into cynicism.

Ask:

• Which constraints are structural versus temporary?
• Which hidden rules can be worked with, and which ones make this a bad bet for this user?
• What would have to change for the answer to improve materially?

If the main need becomes a structured recommendation, route next to using-reasoning/domain-expert-consultation. If the hidden-rule check succeeds and the remaining problem is a clear operational decision, route next to using-reasoning/dynamic-problem-solving.

Output Format

Use this structure by default:

[The Bet]
What the user is actually staking.

[Hidden Rules]
The non-obvious filters, incentives, asymmetries, and gatekeepers that matter most.

[Survivability]
How the decision fails, what it costs, and whether the downside is survivable.

[Resource Match and Ceiling]
Where the user's real resources fit or fail, and what caps the upside.

[Confidence Labels]
Observed pattern vs supported hypothesis vs uncertain.

[Bottom-Line Reality Check]
A blunt verdict in plain language.

[Next Move]
Proceed, proceed only if specific conditions are met, choose a safer path, or stop.

Quality Bar

• Name the real constraint early.
• Do not pretend elite selection, gatekeeper behavior, or platform incentives are fully knowable from one prompt.
• When evidence is thin, downgrade the claim instead of performing certainty.
• Blunt means precise and decision-useful, not theatrical or contemptuous.
• Favor survivability over fantasy upside.
• If the right answer is "this may work, but not from your current position," say that plainly.

Failure Modes to Avoid

• treating social or institutional patterns as proven facts when they are only plausible hypotheses
• confusing generic negativity with a hidden-rule analysis
• drifting into startup commercial teardown territory that belongs to greenfield-product/startup-pressure-test
• assuming the user needs a memo when they really need a survivability check
• giving a cynical answer that names constraints but ignores possible counter-positioning
• hiding the real verdict behind polite fog