Deep Dive
Go deep enough to be useful, not deep enough to drown. The output should clarify the system and expose decision points.
Workflow
- Define the investigation question.
- Find entry points: commands, routes, handlers, jobs, schemas, configs, docs.
- Map the flow: caller -> boundary -> core logic -> persistence -> side effects -> observability.
- Identify invariants: what must always be true.
For data-flow investigations, start at the destination: verify that the data actually arriving at the end of the flow (table rows, published messages, emitted files) satisfies the expected invariant, using the broadest valid query or artifact check. Then walk backwards: source payload -> runtime processing -> destination. Judge correctness by the payload content itself, never by who sent it — a trusted sender can still deliver a wrong payload.
- Identify coupling: shared state, dependencies, lifecycle, retries, ownership.
- Find sharp edges: ambiguity, hidden assumptions, failure modes, missing tests.
- Compare with prior art or established patterns when relevant.
- Produce a concise technical brief with evidence.
Evidence Standards
Prefer file references, tests, logs, docs, metrics, and commit history over guesses; separate confirmed facts from inferences; search current docs before concluding. Resolve competing explanations of a working system against code and runtime evidence inline. For active failures use the Morpheus troubleshooting reference. Use competing-hypotheses only to choose between architecture, technology or strategy options.
Output
## Question
## Executive Summary
## System Map
## Key Flows
## Invariants
## Dependencies
## Failure Modes
## Evidence
## Open Questions
## Recommendations
Rule
Do not produce a wall of notes. Synthesize. The user needs the shape of the system, the risks, and the next useful action.
1---2name: deep-dive3description: Deep technical investigation for complex systems, unfamiliar codebases, architecture, data flows, and dependencies - when the system works but is not understood. Use when the user asks for a deep dive, investigate deeply, map the system, understand how it works, break down complexity, or produce an evidence-backed technical brief. If something is failing right now use the troubleshooting reference in morpheus; for a past incident timeline and contributing factors use premortem-postmortem.4---56# Deep Dive78Go deep enough to be useful, not deep enough to drown. The output should clarify the system and expose decision points.910## Workflow11121. Define the investigation question.132. Find entry points: commands, routes, handlers, jobs, schemas, configs, docs.143. Map the flow: caller -> boundary -> core logic -> persistence -> side effects -> observability.154. Identify invariants: what must always be true.16 For data-flow investigations, start at the destination: verify that the data actually arriving at the end of the flow (table rows, published messages, emitted files) satisfies the expected invariant, using the broadest valid query or artifact check. Then walk backwards: source payload -> runtime processing -> destination. Judge correctness by the payload content itself, never by who sent it — a trusted sender can still deliver a wrong payload.175. Identify coupling: shared state, dependencies, lifecycle, retries, ownership.186. Find sharp edges: ambiguity, hidden assumptions, failure modes, missing tests.197. Compare with prior art or established patterns when relevant.208. Produce a concise technical brief with evidence.2122## Evidence Standards2324Prefer file references, tests, logs, docs, metrics, and commit history over guesses; separate confirmed facts from inferences; search current docs before concluding. Resolve competing explanations of a working system against code and runtime evidence inline. For active failures use the [Morpheus troubleshooting reference](../morpheus/references/troubleshooting.md). Use competing-hypotheses only to choose between architecture, technology or strategy options.2526## Output2728```markdown29## Question3031## Executive Summary3233## System Map3435## Key Flows3637## Invariants3839## Dependencies4041## Failure Modes4243## Evidence4445## Open Questions4647## Recommendations48```4950## Rule5152Do not produce a wall of notes. Synthesize. The user needs the shape of the system, the risks, and the next useful action.
CassioRoos