fearovex/deep-analysis

Triggers

Apply this skill when the user requests:

• "análisis profundo" / "deep analysis" / "investigá a fondo" / "diagnose this"
• Root-cause investigation on a complex bug
• Architecture decision with multiple viable paths
• Open-ended "what should we do about X?" on non-trivial scope
• Any response that would otherwise produce more than ~5 sections or list 4+ alternatives

Do NOT apply for: simple questions, single-file edits, direct factual lookups, or quick clarifications. Default response style stays direct and short.

---

Process

Run these 4 steps IN ORDER, mentally, BEFORE writing the response. Skipping a step produces the exact failure mode this skill exists to prevent (irrelevant dumps).

Step 1 — Identify the real decision

Ask yourself: what decision is the user actually trying to make right now? Not the symptom. Not the surface-level question. The decision.

Examples:

• Symptom: "this bug is weird" → Decision: "do I patch it now or escalate to product?"
• Symptom: "should we use library X?" → Decision: "am I committing to this stack for the next year?"
• Symptom: "the test is flaky" → Decision: "do I invest in fixing the root cause or quarantine it?"

If you cannot articulate the decision in one sentence → STOP and ask the user. Do not produce analysis without knowing what decision it serves.

Step 2 — Verify requested depth

Match output depth to what the user asked for:

| User signal | Output depth | |-------------|--------------| | Direct question, no qualifier | Short, decisive answer | | "qué pensás", "what do you think" | 1 recommendation + 1 tradeoff | | "análisis profundo", "deep analysis", "investigá a fondo" | Full structured analysis (this skill) | | "todas las opciones", "all options", "exhaustive" | Expanded — multiple alternatives allowed |

Default is NOT deep analysis. Deep analysis is a tool the user requests — not a default mode. If the depth is unclear, ASK before going deep.

Step 3 — Filter by role-scope

Cut anything the user does not personally decide.

The user is a developer/architect. They decide:

• Code structure, technical approach, refactor scope, library choice
• Bug diagnosis and fix strategy
• Trade-offs between technical solutions

They do NOT decide (do not include unless explicitly asked):

• Marketing copy / button labels (note as "needs marketing review", do not propose copy)
• Product decisions on user flow (note as "product call", do not weigh in)
• Business priority / roadmap order
• Legal / compliance language

Sections about other roles' decisions = noise. Cut them or compress to a single "flag for X team" line.

Step 4 — Commit to one winning hypothesis

You must produce ONE clear recommendation with conviction.

If you find yourself listing 4+ "equally valid" options → you lack context. That means: STOP, do not list. Instead, ASK the one question whose answer collapses the option space.

When you DO recommend:

• State the recommendation FIRST, before evidence
• Explain WHY it wins over the closest alternative (one tradeoff sentence)
• Mention at most 2 alternatives, one line each, only if they have real merit
• Drop alternatives whose tradeoff is "no real downside" — those aren't alternatives, they're complementary actions you should just include

---

Rules

• Length is allowed. Long is fine when the problem is genuinely complex. Short-by-default is NOT the goal — relevance is.
• Conclusion first, evidence after. Inverted hierarchy is mandatory. The user must be able to stop reading after the first section and still have the answer.
• No duplication. If a section repeats content from earlier, cut it. This is a hard rule, not a preference.
• One winning hypothesis. Six equivalent options = signal that you should ask, not list.
• Filter ruthlessly by role. What the user does not decide does not appear in the body — at most as a one-line flag.
• Tradeoffs must be real. "Pro: more data, Con: zero downside" is not a tradeoff, it's filler. Cut it.
• One closing question. The one that unblocks the next real step. Not a 4-question survey at the end.
• Recommended structure (use unless context demands otherwise):
  1. Recommendation (1 paragraph) — what to do + why it wins
  2. Diagnosis (3-5 lines) — root cause / leading hypothesis
  3. Evidence (max 3-5 bullets) — only the clues that move the needle
  4. Alternatives considered (max 2, one line each, only if they have real merit)
  5. Closing question (1 only) — the unblocking question
• When in doubt about depth, ASK. Asking one question costs nothing. Producing a 600-line dump the user won't read costs everything.