Codependency Analyzer

Contributed by: Mark Whaley · Source: PM Starter Kit

Use this when a PM needs to understand how systems, services, or components depend on each other to make sequencing and prioritization decisions. Inspects the identified repositories and service paths to extract internal service-to-service calls, external third-party dependencies, database tables touched, and event/topic contracts produced and consumed.

This skill produces the dependency snapshot that reveals hidden coupling, critical paths, and independent work streams. It sits at the end of the Feature Impact Radar pipeline: /technical-intent-parser → /architecture-context-reviewer → /repository-discovery → /codependency-analyzer.

Process

Step 1: Gather inputs

Ask the user:

1. Repositories — The repos identified by /repository-discovery (e.g., payments/billing-service, messaging/notification-platform). If coming from the pipeline, these are already available.
2. Backend actions — The actions identified by /technical-intent-parser (e.g., schedule_reminder, send_notification, store_user_preferences).
3. Data entities — The business objects identified by /technical-intent-parser (e.g., invoice, reminder_preferences, user).
4. Service paths (recommended) — Where each service lives in its repo, from /repository-discovery.
5. Event streams (if known) — From /architecture-context-reviewer.
6. Org context (optional) — Languages/frameworks, monorepo/polyrepo, runtime environment.

If repositories, backend actions, and data entities are missing, stop and request them (or run the upstream skills first).

Step 2: Identify which personas are affected

Before generating the analysis, prompt the user:

Persona check: Which user persona(s) are affected by these systems? If you have defined personas (e.g., from /persona-create or /persona-draft), name them. If not, describe who uses the features powered by these components.

This ensures the dependency map highlights what matters to users — not just internal coupling — and helps prioritize which dependency chains to address first.

Step 3: Analyze code dependencies

For each service path, inspect code and metadata to extract dependencies. Use backend actions and data entities as search anchors to reduce noise.

Evidence sources (priority order):

1. Direct client usage (HTTP/gRPC SDK calls), explicit producers/consumers
2. API/event schema references + routing config
3. Dependency manifests + infra config (Helm, Terraform, env vars)
4. Naming inference (lowest — use only as "suspected", not fact)

What to look for:

• Internal service-to-service calls: HTTP clients calling internal hostnames, gRPC stubs, shared API client libraries, gateway routing config, service URL config vars
• External third-party dependencies: SaaS APIs (email, SMS, push), cloud-managed services (queues, storage), external partner APIs, SDK usage
• Database tables touched: Migrations, ORM models, query targets in DAOs/repositories
• Event dependencies: Producers (publishing events), consumers (subscriptions, handlers), topic names, schema references

Step 4: Present the dependency snapshot

## Dependency Analysis — (Feature/Context Name)

**Date:** (Date)
**Repos analyzed:** (List)
**Confidence level:** (High / Medium / Low)

---

### Internal Service Dependencies

| Caller | Callee | Mechanism | Evidence |
|---|---|---|---|
| (service-a) | (service-b) | (http / grpc / event / lib) | (File or config where this was found) |

### External Dependencies

| Service | External system | Type | Evidence |
|---|---|---|---|
| (service-name) | (e.g., SendGrid, Stripe, AWS SQS) | (saas / cloud / partner) | (SDK usage, client code, config) |

### Database Tables Touched

| Service | Database.Table | Access pattern | Evidence |
|---|---|---|---|
| (service-name) | (db.table or table if db unknown) | (read / write / migrate) | (Migration file, ORM model, query) |

### Event Dependencies

| Service | Role | Event / Topic | Evidence |
|---|---|---|---|
| (service-name) | (produces / consumes) | (event.name) | (Publisher/handler code, config) |

Step 5: Map the critical path and independent streams

### Dependency Map

(Text diagram showing which systems depend on which.)

[billing-service] ──http──→ [notification-service] │ │ └──http──→ [user-preferences-service] │ [billing-service] ──produces──→ invoice.due_soon ──consumed by──→ [notification-service]

### Critical Path

For (the feature/initiative): (Component A) → (Component B) → (Component C)

This means: (Plain-language explanation of the sequencing constraint.)

### Independent Work Streams

These can be worked on in parallel without blocking each other:
- **Stream 1:** (Components) — (Why they're independent)
- **Stream 2:** (Components) — (Why they're independent)

### Change Blast Radius

| If you change... | These also need to change | Ripple size |
|---|---|---|
| (Component) | (Affected components) | (Small / Medium / Large — with explanation) |

### Coupling Risks

| Risk | Components | Why it's risky | Mitigation |
|---|---|---|---|
| (e.g., shared database) | (Components sharing it) | (What goes wrong) | (How to mitigate) |

Step 6: Review and validate

Ask the user:

• Does this dependency map match your understanding?
• Are there dependencies engineers have mentioned that aren't captured here?
• Does the critical path align with your team's capacity and sequencing?
• Are there external dependencies (vendor APIs, partner systems) that should be on this map?

Adjust as needed.

Related skills

• /repository-discovery — upstream: provides the repos and service paths this skill analyzes.
• /architecture-context-reviewer — upstream: provides verified services, databases, and event streams.
• /technical-intent-parser — pipeline entry point: decomposes a feature into technical signals.
• /pre-mortem — when you want to stress-test sequencing decisions for failure modes.
• /ipm-plan — when you're ready to turn the sequencing into an iteration plan.

Output location

Present the dependency snapshot, critical path, and independent streams as formatted text in the conversation. The user copies the output into planning documentation, shares it in roadmap discussions, or uses it to facilitate sequencing conversations with engineering leads.