home / skills / wellapp-ai / well / dependency-mapping

dependency-mapping skill

/cursor-rules/skills/dependency-mapping

This skill maps dependency relationships with a DSM, scores risk, and recommends safe implementation sequences for multi-slice features.

npx playbooks add skill wellapp-ai/well --skill dependency-mapping

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.0 KB
---
name: dependency-mapping
description: Map slice dependencies using DSM matrix and prioritize by risk
---

# Dependency Mapping Skill

Map dependencies between implementation slices using Design Structure Matrix (DSM), calculate risk scores, and recommend implementation sequence.

## When to Use

- During Ask mode Phase 2 (CONVERGE)
- When planning multi-slice features
- Before phasing to understand risk order

## Instructions

### Phase 1: Build DSM Matrix

Create a square matrix with slices on both axes. Mark dependencies with `*`:

```
         | #1.1 | #1.2 | #2.1 | #2.2 | #2.3 | #3.1 |
---------+------+------+------+------+------+------+
#1.1     |  -   |      |      |      |      |      |
#1.2     |  *   |  -   |      |      |      |      |
#2.1     |      |  *   |  -   |      |      |      |
#2.2     |      |      |  *   |  -   |      |  *   |
#2.3     |      |  *   |  *   |      |  -   |      |
#3.1     |      |      |      |      |      |  -   |

Legend: * = row depends on column
Reading: Row #2.2 has * in columns #2.1 and #3.1 = #2.2 depends on #2.1 AND #3.1
```

### Phase 2: Calculate Dependency Score

For each slice, count:

| Metric | Formula | Meaning |
|--------|---------|---------|
| **Fan-in** | How many slices depend ON this? | High = blocker, ship early |
| **Fan-out** | How many slices does this DEPEND on? | High = risky, ship later |
| **Dependency Score** | Fan-out count | Lower = safer |

### Phase 3: Calculate Leverage Score

Score each slice on reuse of existing patterns:

| Level | Score | Description |
|-------|-------|-------------|
| Full Reuse | 0 | Uses existing component from design system/Storybook as-is |
| Extend | 1 | Extends existing component with new props/variants |
| Compose | 2 | Composes multiple existing components |
| New Pattern | 3 | Creates new component following design system tokens |
| New System | 5 | Requires new patterns not in design system |

**Check these sources before scoring:**
- `/docs/design-system/components.md` - Existing components
- `Glob **/*.stories.tsx` - Storybook patterns
- `SemanticSearch` for similar implementations in codebase

### Phase 4: Calculate Risk Score

```
Risk Score = (Dependencies x 2) + Leverage + PriorityTier

Where PriorityTier:
- P1 (Frontend-only) = 0
- P2 (Frontend + Backend non-breaking) = 1
- P3 (Backend contract changes) = 2
- P4 (Data model changes) = 3
```

### Phase 5: Identify Blockers

Flag slices that block others (high fan-in):

```
#3.1 WorkspaceInvite Entity
  Fan-in: 3 (blocks #2.2, #2.3, #2.4)
  RECOMMENDATION: Consider stub/mock for Phase 1, or ship early despite risk
```

### Phase 6: Rank by Risk

Sort slices by Risk Score (lowest first = ships first):

| Rank | Slice | Deps | Leverage | Tier | Risk Score |
|------|-------|------|----------|------|------------|
| 1 | #1.1 Workspace Switcher | 0 | Extend (1) | P1 (0) | 1 |
| 2 | #1.2 Members Page UI | 1 | Compose (2) | P1 (0) | 4 |
| 3 | #2.1 List Members API | 1 | N/A | P2 (1) | 4 |

## Output Format

```markdown
## Dependency Analysis

### DSM Matrix

[Matrix as shown above]

### Risk Scoring

| Slice | Deps | Leverage | Tier | Risk | Rank |
|-------|------|----------|------|------|------|
| [Slice] | [N] | [Level (score)] | P[N] | [Score] | [#] |

### Blockers Identified

| Slice | Blocks | Fan-in | Recommendation |
|-------|--------|--------|----------------|
| [Slice] | [List] | [N] | [Stub/Ship early/etc] |

### Recommended Sequence

1. [Lowest risk slice] - [Why safe]
2. [Next slice] - [Dependencies satisfied by #1]
...

### Existing System Leverage

| Component | Source | Slices Using | LOC Saved |
|-----------|--------|--------------|-----------|
| [Component] | [design-system/Storybook] | [List] | ~[N] |
```

## Invocation

Invoke manually with "use dependency-mapping skill" or follow Ask mode Phase 2 (CONVERGE) which references this skill.

## Related Skills

- `phasing` - Uses risk scores to group into phases
- `design-context` - Identifies existing patterns to leverage
- `gtm-alignment` - May override risk-based order for GTM priority

Overview

This skill maps implementation slice dependencies using a Design Structure Matrix (DSM), computes risk and leverage scores, and recommends an execution sequence. It helps teams identify blockers, prioritize safe ships, and surface where reusing design patterns reduces risk. The output is a ranked list of slices with clear remediation recommendations.

How this skill works

Build a square DSM with slices on both axes and mark dependencies (row depends on column). Calculate fan-in and fan-out for each slice, then score leverage by checking existing design-system components and Storybook patterns. Combine dependency count, leverage score, and priority tier into a Risk Score to rank slices and surface blockers and recommended sequencing.

When to use it

  • During Ask mode Phase 2 (CONVERGE) when planning multi-slice features
  • Before phasing or sprint planning to determine safe implementation order
  • When you need to identify blockers that force early shipping or stubbing
  • When evaluating reuse opportunities versus building new patterns
  • When backend contract or data-model changes may increase scope

Best practices

  • Populate the DSM collaboratively with engineers and designers to capture implicit dependencies
  • Verify leverage scoring against /docs/design-system/components.md and Storybook (.stories.tsx)
  • Treat high fan-in slices as blockers—consider stubs or early delivery
  • Prefer shipping low-risk slices first to unblock iterative testing
  • Revisit the DSM as design or API contracts change; risk is dynamic

Example use cases

  • Plan rollout for a members experience that spans UI, API, and data changes
  • Decide whether to implement a shared WorkspaceInvite entity early or stub it
  • Prioritize frontend-only widgets that reuse design-system components
  • Choose safe order for features requiring backend contract updates
  • Quantify trade-offs when composing multiple design-system components vs creating new patterns

FAQ

How is Risk Score calculated?

Risk Score = (Dependencies x 2) + Leverage + PriorityTier, where PriorityTier reflects impact level from frontend-only to data-model changes.

What indicates a blocker?

High fan-in (many slices depend on this slice) marks a blocker; recommend stubbing or shipping it early despite risk.