メニュー
Identify what situation you are actually in before attempting to solve it. Prevents the most dangerous failure: solving the wrong problem perfectly.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Route any input through a branching question tree to narrow down the optimal response strategy before writing. Two stages — PERCEIVE (classify input) then ACT (select response). Covers all prompt types.
Generate exhaustive guesses about user input using ALL search methods with coverage tracking. Guessing is SEARCH through possibility space. Tracks space created vs space covered to ensure comprehensive exploration.
Systematically evaluate and select from a set of guesses, options, or possibilities. Combines ARAW analysis with prioritization to determine which guesses are strong, weak, actionable, or eliminable.
Extract hidden assumptions from any content. Surfaces what must be true for claims to hold, enabling deeper analysis.
Sub-orchestrator for analytical requests. Routes to decomposition, systems analysis, comparison, risk assessment, or synthesis based on what kind of analysis is needed.
Assume Right - Deep recursive rightness search. For every claim, assume it's right — find what must follow, then assume THOSE implications are right too. Recurse until bedrock. Track every claim found.
| name | sid - Situation Identification |
| description | Identify what situation you are actually in before attempting to solve it. Prevents the most dangerous failure: solving the wrong problem perfectly. |
| output | {"format":"prose"} |
Input: $ARGUMENTS
Before executing, identify which interpretation matches the user's input:
Interpretation 1 — Confused about what is happening: The user faces a novel or ambiguous situation and needs to build an accurate description from raw observations before choosing how to respond. Interpretation 2 — Competing narratives: Multiple people (or the user's own conflicting instincts) offer different accounts of what is going on, and the user needs to determine which framing is most accurate. Interpretation 3 — Pattern-match validation: The user thinks they recognize the situation from past experience but wants to verify they are not misclassifying it based on superficial similarity.
If ambiguous, ask: "I can help with making sense of a confusing situation, sorting out conflicting accounts of what is happening, or checking whether your pattern recognition is accurate — which fits?" If clear from context, proceed with the matching interpretation.
Every decision procedure has a Step 0: classify the situation so you know which procedure to follow. If you misclassify at Step 0, you execute the wrong procedure perfectly and arrive at the wrong answer with high confidence. This is the most dangerous failure mode in decision-making -- not making bad decisions, but making good decisions about the wrong problem.
This procedure answers one question: What is actually happening here?
Answer the following three questions out loud or in writing. Do not skip this.
0.1 How much time do I have before I must act?
0.2 Are other people telling me different things about what is happening?
0.3 Have I seen something that looks like this before?
Use this when you genuinely do not recognize what is happening. The goal is to build an accurate description from raw observation before applying any framework.
Write down what you can directly observe. No interpretations, no causes, no judgments.
WHAT YOU SHOULD SEE: A list of facts that a camera or microphone could record. "Revenue dropped 15% in Q3." NOT "The business is failing." "My partner did not respond to three messages." NOT "My partner is pulling away."
Binary check: Read each item. Does it contain a verb like "is," "feels," "seems," or "means"? If yes, rewrite it as a pure observable. Only proceed when every item passes.
For each observable from A.1, write down what additional information would change your interpretation of it.
WHAT YOU SHOULD SEE: A list of questions, not answers. "Did the revenue drop happen across all segments or just one?" "Was my partner's phone working during that period?"
Binary check: Do you have at least one unknown for each observable? If not, you are likely treating assumptions as knowns. Go back and add genuine unknowns.
Using only the observables from A.1, write three different one-sentence descriptions of the situation that are all consistent with the evidence.
WHAT YOU SHOULD SEE: Three descriptions that are meaningfully different from each other, not cosmetic variations. Example: (1) "The company is losing product-market fit." (2) "The company's go-to-market motion broke when the sales lead left." (3) "The market contracted and this has nothing to do with us."
Binary check: Would each description lead you to a different action? If two descriptions lead to the same action, they are not different enough. Replace one.
Write down which of the three descriptions you are drawn to, and why.
WHAT YOU SHOULD SEE: An honest statement like "I want it to be #3 because that means it is not my fault" or "I want it to be #1 because that is the one I know how to fix."
Binary check: Does your preferred description also happen to be the most comfortable one for you personally? If yes, flag this as a bias risk and do not weight it higher.
Of the three descriptions, which one can you gather evidence for or against most quickly and cheaply?
WHAT YOU SHOULD SEE: A specific action you can take in the next 24 hours to get data. "Pull the revenue by segment." "Ask my partner directly if something is wrong." "Check if competitors saw the same drop."
Binary check: Does the test have a clear outcome that distinguishes between at least two of your three descriptions? If no, find a better test.
Execute the test from A.5. Based on the results:
Use this when your brain immediately says "I know what this is." This is the most dangerous section because the confidence of recognition suppresses further investigation.
Write down in one sentence what you think this situation is, and when you last saw it.
WHAT YOU SHOULD SEE: Something like "This is a scope creep problem, same as the Q2 project last year" or "This is my mother being manipulative, same pattern as always."
Between this situation and the one you are matching it to, write down three things that are different. They can be small.
WHAT YOU SHOULD SEE: At least three concrete differences. "Different team members." "Higher stakes." "I am more tired this time." If you cannot list three differences, you are not looking hard enough -- every situation has differences.
Binary check: Is any of the three differences structural rather than cosmetic? (A structural difference changes how the situation works, not just how it looks.) If yes, proceed to B.3 with heightened caution. If all three are cosmetic, the pattern match may be valid -- proceed to B.4.
Write down three observable things that would be present if your pattern match is wrong.
WHAT YOU SHOULD SEE: Specific, checkable indicators. "If this is NOT scope creep, I would expect the original requirements to still be ambiguous even if no new requests came in." "If this is NOT manipulation, I would expect my mother to accept my boundary when I state it clearly."
Binary check: Can you check for each indicator right now or within 24 hours? If yes, check them. If any indicator is present, your pattern match is wrong. Go to SECTION A and start fresh.
If the situation involves another person you have dealt with before, answer: Am I classifying the situation based on who is involved rather than what is happening?
Binary check: If you removed the identity of the person and described only the behavior, would you classify the situation the same way? If no, you are pattern-matching to the person, not the situation. Go to SECTION A.
If you have passed all checks, your pattern match is likely valid. Proceed. The goal is accurate classification, not maximum self-doubt. If your pattern match survives the checks, trust it. But set a concrete future checkpoint: "If [specific observable] has not occurred by [date], I will reclassify."
WHAT YOU SHOULD SEE: A written statement with a specific observable and a specific date. Not "I will reassess if things do not improve" but "If the client has not signed by February 15, this is not a timing problem and I will reclassify as a fit problem."
Use this when you have less than 10 minutes before you must act. This is a stripped-down version designed for speed.
Do not deliberate. Write or say the first classification that comes to mind.
The alternative must be the most dangerous plausible interpretation. Not the most likely -- the most dangerous.
WHAT YOU SHOULD SEE: Your original classification and one alternative. "I think this is a server outage" vs. "This could be a security breach." "I think my child is overtired" vs. "My child could be having a medical event."
Once the immediate pressure has passed, return to SECTION A or SECTION B and do a full assessment. Urgent classifications are provisional. Never let them harden into permanent ones.
Use this when different people are telling you different things about what is happening.
Write down every distinct description of the situation offered by anyone involved. Use their words, not your paraphrases.
WHAT YOU SHOULD SEE: A numbered list of direct quotes or near-quotes. "Marketing says: 'Sales is not following up on our leads.'" "Sales says: 'Marketing is sending us unqualified leads.'"
Do not evaluate which is "right." For each one, identify what observable evidence supports it.
WHAT YOU SHOULD SEE: Evidence listed under each classification. Not "Marketing is right because..." but "Evidence supporting Marketing's view: lead response time data shows 48-hour average. Evidence supporting Sales' view: lead qualification score data shows 60% below threshold."
Binary check: Does each classification have at least some supporting evidence? If a classification has zero evidence, discard it. If every classification has some evidence, continue.
For each person or group offering a classification, write down what it would cost them personally or professionally if their classification turned out to be incorrect.
WHAT YOU SHOULD SEE: Concrete stakes. "If Marketing is wrong, it means their campaign strategy failed." "If Sales is wrong, it means their follow-up process is broken."
Binary check: Is there a classification where the person has nothing to lose by being wrong? That person's classification is more likely to be accurate (less motivated reasoning). Weight it accordingly.
Write down one description of the situation that no involved party has suggested.
WHAT YOU SHOULD SEE: A description that would be uncomfortable for everyone. "Both Marketing and Sales are performing fine, but the product is no longer competitive." This is often the correct classification because it is the one nobody is incentivized to see.
Binary check: Is the missing classification one that would require systemic change rather than blaming a specific party? If yes, investigate it seriously.
Identify one metric, fact, or experiment that would distinguish between the top two competing classifications. Execute it. Return to D.2 with the new evidence and reassess.
Run this after any section produces a classification.
V.1 -- State your classification in one sentence.
V.2 -- What action does this classification imply?
V.3 -- If you took that action and the situation got worse, what would that tell you?
WHAT YOU SHOULD SEE: An answer that would cause you to reclassify. "If I treat this as a performance problem and coach the employee, and their performance gets worse, that would tell me it is actually a motivation or structural problem."
V.4 -- Set a reclassification trigger. Write down: "I will reclassify if [specific observable] by [specific date]."
V.5 -- Proceed to the appropriate decision procedure for your classified situation.
SITUATION IDENTIFICATION -- QUICK REFERENCE
============================================
BEFORE ANYTHING ELSE:
1. How much time? (<10 min -> Section C)
2. Do people disagree? (Yes -> Section D)
3. Do I recognize this? (Yes -> Section B / No -> Section A)
SECTION A (NOVEL):
Write observables -> List unknowns -> 3 descriptions ->
Which do I WANT? -> Test cheapest -> Act or loop
SECTION B (FAMILIAR -- DANGER):
Name the pattern -> 3 differences -> What if I am wrong? ->
Person vs. situation check -> Proceed with checkpoint
SECTION C (URGENT):
One-sentence classification -> Worst case if wrong? ->
One dangerous alternative -> Cover both or minimax -> Reassess later
SECTION D (CONTESTED):
Collect all views -> Evidence for each -> Stakes per person ->
Missing classification -> Test to distinguish
ALWAYS END WITH:
Classification sentence -> Implied action ->
What if it gets worse? -> Reclassification trigger
RED FLAGS:
- Classified in <30 seconds with high confidence
- Classification makes a "good story"
- You are never the cause in your classification
- Someone else handed you the classification
- Your preferred classification is the comfortable one
You see someone crying and classify the situation as "person is sad." The situation may be: person is frustrated, person is relieved, person is manipulating, person is having an allergic reaction. The crying is an observable. The situation is what produced it. Always separate the observable from the interpretation.
If you are a hammer, every situation looks like a nail. Engineers classify interpersonal problems as systems problems. Therapists classify systems problems as interpersonal problems. You will unconsciously classify the situation as something within your skillset. Ask: "Would someone from a completely different background classify this the same way?"
In any group, one person typically speaks first, speaks loudest, and speaks with the most confidence. Their classification becomes the default. This has nothing to do with accuracy. Actively solicit the classification of the quietest person in the room.
You start with classification A. New information arrives that is mildly inconsistent with A. You do not reclassify -- you subtly shift A to accommodate the new information, creating A', then A'', then A'''. By the end, your classification has drifted far from where it started, but you feel like you have been consistent. Write your classification down at the start. Compare it to your current classification periodically.
Situations that resist classification feel uncomfortable. The most common escape from that discomfort is to minimize: "It is probably nothing." "I am probably overthinking this." If you cannot classify it, that is information. Something that resists classification deserves MORE attention, not less.
Saying "There is a 70% chance this is a market problem" sounds rigorous but is often a disguise for "I think this is a market problem and I want to sound calibrated." Unless you have a real base rate (from data, not intuition), your probability estimate is your confidence dressed up as math. Say "I believe" rather than "there is an X% chance" unless you can justify the number.
Situations evolve. The correct classification on Monday may be wrong by Friday. Every classification is provisional. The checkpoint you set in the procedure is not optional -- it is the mechanism that prevents stale classifications from driving current decisions.
True emergency with lives at stake. If someone is in physical danger, act on instinct. Assess later. Do not run a procedure while someone is bleeding.
The situation is genuinely trivial. If the consequences of misclassification are less than the cost of running this procedure, skip it. Use judgment: "What's the worst that happens if I'm wrong?" If the answer is "I waste 20 minutes," do not spend 30 minutes on classification.
You have domain expertise and verified track record. If you are an emergency room doctor assessing a patient, you have earned the right to pattern-match fast. But only within your domain.
The system is already providing feedback. If you are in an environment with fast, clear feedback loops (writing code with tests, cooking with tasting, playing a sport with a scoreboard), let the feedback loop correct your classification rather than front-loading analysis.
You are stuck in a recursive loop. If applying this procedure is itself creating paralysis, stop. Pick the most reversible classification, act on it, and let reality tell you whether you were right.
Step 0 -- Triage:
Section B:
Section A:
Validation: If still distant in two months after work calms down, reclassify.
Step 0 -- Triage:
Section D:
Result: The product does not have market demand. Every team's classification was a downstream symptom.
Validation: "If inbound interest increases to 50+/month after implementing improvements, demand exists and my classification is wrong."
Step 0 -- Triage:
Hybrid C+D approach:
Result: Missing index on a table that grew past a threshold from a batch import. Not "system is slow" -- one query pattern became O(n) instead of O(log n). The situation is "data growth exceeded an architectural assumption."
Validation: After adding the index, if response times do not return to normal within 30 minutes, reassess. (They returned in 4 minutes.)