deep-analysis

What this skill does

**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.