Deep Analysis
Run a four-step relevance gate before writing a deep diagnostic so the answer targets one real decision instead of dumping every angle.
Overview
Deep Analysis is a journey-wide agent skill that forces a four-step relevance filter before any deep diagnostic—usable whenever a solo builder needs one committed hypothesis instead of a multi-angle essay.
Install
npx skills add https://github.com/fearovex/claude-config --skill deep-analysisWhat is this skill?
- Four ordered mental steps before any long-form analysis response
- Identifies the real decision behind the user’s question, not the surface symptom
- Commits to one winning hypothesis instead of listing four-plus alternatives
- Scopes depth and role-boundary so analysis matches what the user can act on
- Explicit do-not-apply list for simple edits, lookups, and short clarifications
- 4 ordered process steps before writing the response
- Designed to prevent responses with more than ~5 sections or 4+ alternatives
Adoption & trust: 1 installs on skills.sh; 1 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You asked for a deep analysis and got a sprawling report of every possibility with no clear decision or root cause to act on.
Who is it for?
Non-trivial bugs, architecture forks, and strategic technical choices where you need diagnosis with a single recommended path.
Skip if: Simple questions, single-file edits, direct factual lookups, or quick clarifications where a short default reply is enough.
When should I use this skill?
User asks for análisis profundo, deep analysis, investigá a fondo, diagnose this, root cause this, or complex open-ended what-should-we-do questions.
What do I get? / Deliverables
The agent states the real decision, appropriate depth, and one winning hypothesis, then writes analysis that maps directly to your next move.
- Analysis anchored on one real decision and one winning hypothesis
- Depth- and role-scoped narrative without irrelevant angle dumps
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
User asks for deep analysis on a failing integration test suite before release.
Production incident needs root-cause diagnosis without a five-option essay.
Choosing between queue, cron, or inline worker for a new async job.
Open-ended what should we build first when three MVPs are all viable.
How it compares
Use instead of unconstrained “think step by step” dumps that list every alternative without choosing one.
Common Questions / FAQ
Who is deep-analysis for?
Solo builders and small teams using Claude-style agents who trigger long diagnostics on bugs, architecture, or trade-offs and want actionable focus.
When should I use deep-analysis?
On Ship review or Operate errors when you say deep analysis or diagnose this; during Build backend decisions for multi-path architecture; during Validate scope when choosing between prototypes.
Is deep-analysis safe to install?
It only constrains reasoning style and does not grant extra permissions by itself; check the Security Audits panel on this Prism page for the installing repo.
SKILL.md
READMESKILL.md - 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 go