Prompt Engineering

Dependency Analysis Prompt — What It Needs, What Needs It

Before touching a shared module: what it depends on, what depends on it, and which of those dependencies are risky — direction mapped, cycles flagged.

Overview

The cost of changing shared code is set by its dependencies — and dependency knowledge is usually tribal. This prompt uses the architecture mode focused on one module's position: what it depends on (and how hard), what depends on it (and how visibly), dependency direction made explicit with cycles and inversions flagged, and the risk assessment a senior audience actually wants: which of these dependencies are fragile, version-locked, or carrying contracts that mostly exist by convention. The strategy's data-flow lens shows what information crosses each dependency edge — which is where breaking changes actually break.

Workflow

Map both directions
Dependencies and dependents — the module's real position, not its folder.
Follow the data across edges
What information crosses each dependency line — where breaking changes actually break.
Rank the risk
Fragile, version-locked, convention-only contracts named — the dependencies to fear, ordered.

Why This Works

Both-directions mapping is what folder structure and imports alone cannot show
Data-flow edges locate breakage more precisely than module names
A ranked risk list converts analysis into a pre-change checklist

Best for

Shared modules consumed by multiple systems
Pre-change impact assessment
Architecture cleanup planning

Not for

Breaking the cycles it finds — that's the Refactor Prompt Builder's Architecture Cleanup goal
Generating tests for the consumers — that's the Test Case Prompt Generator

Use cases

Assessing blast radius before changing a shared module
Finding the dependency cycle everyone suspects
Naming the consumers a "small change" would surprise

Customize This Resource

Opens this setup in Code Explanation Prompt. Generate to get the full understanding contract — then adjust the mode, audience, and depth.

Open in Code Explanation Prompt

Prompt Template

EXPLANATION OBJECTIVE
Explain what this module depends on, what depends on it, and which of those dependencies are risky.
Explanation mode: architecture explanation — layers, boundaries, dependencies, and data flow.
The goal is understanding, not judgment: explain what this code does and why it is built this way — and clearly separate what the code shows from what you infer.

CODE CONTEXT
System context: The shared pricing module; consumed by checkout, invoicing, and the partner API.
Code to explain:
```
[Paste the code to explain here]
```

AUDIENCE PROFILE
Audience: a senior developer — reads code fluently and wants rationale, not narration.
- Assume: anything readable from the code is already understood.
- Spend the explanation on what the code cannot say: why this design, what constraints shaped it, where it is fragile.
- Do not walk the code line by line — that would waste this reader's time.

EXPLANATION STRATEGY
1. Identify the layers or modules and the responsibility each one owns.
2. Trace the boundaries: what each module exposes, what it hides, and which contracts cross the lines.
3. Map dependency direction explicitly — what depends on what, and flag any cycles or inversions.
4. Follow the data: how information enters, how it transforms at each boundary, and where it ends up.
- Depth: detailed explanation — thorough coverage of behavior and structure.
- Cover every section of this contract with real content — no skipped or token sections.
- Go as deep as the code requires, but no deeper: detail serves understanding, not completeness theater.

KEY CONCEPTS
- Define the architectural vocabulary in use — the layer names, the patterns, the conventions this structure relies on.
- Order concepts by how load-bearing they are for understanding this code — not by where they appear in the file.

EXECUTION FLOW
- Trace one representative request or data item through every layer it touches, naming each handoff.
- Where the flow depends on state or configuration, say which, and what each setting changes.

DESIGN DECISIONS
- Explain why the boundaries sit where they sit: what changes together, what is isolated from what, and what that isolation buys.
- Discuss only decisions actually visible in the code; rationale you cannot evidence belongs under ASSUMPTIONS, labeled as inference.

ASSUMPTIONS
- Separate what the code DOES (verifiable from the source) from why it might be that way (inference).
- Label every statement about intent, history, or rationale as an INFERENCE unless the code itself evidences it — a comment, a test, a telling name.
- Where behavior cannot be determined from the provided code, say "cannot be determined from this code" — never fill the gap with a plausible story.

TRADEOFFS
- Identify the tradeoffs this code embodies: what it optimizes for, and what it sacrifices for that.
- Tie each tradeoff to its visible consequence in the code.

LEARNING NOTES
- Summarize the architecture in one paragraph a new architect could repeat — the shape, the key boundaries, and the one rule never to break.

NON-GOALS
- Do not review code quality — no findings, no severities, no verdicts.
- Do not debug failures — explain the behavior that exists without diagnosing it.
- Do not refactor the code or propose rewrites.
- Do not generate tests.
- Do not invent requirements or unstated intentions.
- If something looks defective, note it as a question for the team — investigating or fixing it is out of scope.
- Clearly separate facts from assumptions throughout.

OUTPUT REQUIREMENTS
- Structure the explanation with headings that mirror the sections above — a reader should be able to navigate it without reading all of it.
- Anchor every claim about behavior in the code: name the function, branch, or line it comes from when precision matters.
- Calibrate every section to the stated audience — too basic wastes their time, too advanced loses them.
- End with the open questions: what could not be determined from the provided code, and who or what could answer it.

Related Resources

Explore more resources that work well with this one.