miles-knowbl

dependency-mapping

1
0
# Install this skill:
npx skills add miles-knowbl/orchestrator --skill "dependency-mapping"

Install specific skill from multi-skill repository

# Description

Map cross-pipeline dependencies and handoffs (X-series). Identifies where pipelines connect, share data, or have timing dependencies. Documents failure modes at integration boundaries that span multiple pipelines.

# SKILL.md


name: dependency-mapping
description: "Map cross-pipeline dependencies and handoffs (X-series). Identifies where pipelines connect, share data, or have timing dependencies. Documents failure modes at integration boundaries that span multiple pipelines."
phase: INIT
category: core
version: "1.0.0"
depends_on: [pipeline-discovery, ui-pipeline-discovery]
tags: [audit, pipeline, dependencies, integration, cross-cutting]


Dependency Mapping

Map cross-pipeline dependencies (X-series).

When to Use

  • After pipeline discovery β€” Runs after P-series and U-series are identified
  • Understanding integration points β€” Document where pipelines connect
  • Identifying cross-cutting failures β€” Find failure modes at boundaries
  • When you say: "map the dependencies", "find integration points", "what connects these?"

Reference Requirements

MUST read before applying this skill:

Reference Why Required
dependency-identification.md How to find cross-pipeline dependencies
dependency-diagram.md Visualization format

Read if applicable:

Reference When Needed
x-series-patterns.md Common cross-pipeline failure patterns

Verification: All pipeline handoffs are documented with failure modes.

Required Deliverables

Deliverable Location Condition
Dependency map AUDIT-SCOPE.md Always (X-series section)
X-series failure modes PIPELINE-FAILURE-MODES.md Always

Core Concept

Dependency Mapping answers: "Where do pipelines connect and what can fail there?"

Cross-pipeline failures occur at:
- Data handoffs β€” One pipeline's output is another's input
- Shared state β€” Multiple pipelines read/write same data
- Timing dependencies β€” One pipeline must complete before another starts
- Event chains β€” One pipeline triggers another

These are often the most dangerous failures because:
- No single pipeline "owns" them
- They're invisible in unit tests
- They only appear under specific conditions

Dependency Types

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                  DEPENDENCY TYPES                           β”‚
β”‚                                                             β”‚
β”‚  DATA HANDOFF                                               β”‚
β”‚    P1 produces data β†’ P2 consumes it                        β”‚
β”‚    X-001: P1 output missing field P2 expects               β”‚
β”‚                                                             β”‚
β”‚  SHARED STATE                                               β”‚
β”‚    P1 and U1 both read/write user.preferences               β”‚
β”‚    X-002: Race condition on concurrent updates              β”‚
β”‚                                                             β”‚
β”‚  TIMING DEPENDENCY                                          β”‚
β”‚    P2 must wait for P1.source_schema to exist              β”‚
β”‚    X-003: P2 runs before P1 completes                       β”‚
β”‚                                                             β”‚
β”‚  EVENT CHAIN                                                β”‚
β”‚    P3.publish triggers U2.notification                      β”‚
β”‚    X-004: Event lost, notification never shows              β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Discovery Process

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚             DEPENDENCY MAPPING PROCESS                      β”‚
β”‚                                                             β”‚
β”‚  1. FOR EACH PIPELINE                                       β”‚
β”‚     β”œβ”€β†’ What data does it consume? (inputs)                β”‚
β”‚     └─→ What data does it produce? (outputs)               β”‚
β”‚                                                             β”‚
β”‚  2. FIND CONNECTIONS                                        β”‚
β”‚     └─→ Where output of one = input of another             β”‚
β”‚                                                             β”‚
β”‚  3. IDENTIFY SHARED STATE                                   β”‚
β”‚     └─→ Tables/state accessed by multiple pipelines        β”‚
β”‚                                                             β”‚
β”‚  4. MAP TIMING DEPENDENCIES                                 β”‚
β”‚     └─→ What must exist before pipeline can run            β”‚
β”‚                                                             β”‚
β”‚  5. DOCUMENT FAILURE MODES                                  β”‚
β”‚     └─→ What can go wrong at each boundary                 β”‚
β”‚                                                             β”‚
β”‚  6. ASSIGN X-SERIES IDS                                     β”‚
β”‚     └─→ X-001, X-002... per dependency                     β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Dependency Documentation Format

### X-001: P1 β†’ P2 (source_schema handoff)

**Type:** Data Handoff
**From:** P1 (Source Ingestion)
**To:** P2 (Content Generation)

**Dependency:**
P2 reads `source_schema` produced by P1 to build prompts.

**Failure Modes:**

| ID | Failure | Severity | Detection |
|----|---------|----------|-----------|
| X-001a | source_schema is null | S4-Blocking | P2 throws |
| X-001b | source_schema is stale | S1-Silent | Lower quality output |
| X-001c | source_schema format changed | S3-Visible | Parse error |

**Validation:**
- [ ] P2 checks source_schema exists before use
- [ ] P2 handles null gracefully
- [ ] Schema version is validated

Output Format

In AUDIT-SCOPE.md

## Cross-Pipeline Dependencies (X-series)

### Dependency Map

P1 (Source Ingestion)
β”‚
β”œβ”€β”€[source_schema]──► P2 (Content Generation)
β”‚ β”‚
└──[source_id]β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Ίβ”œβ”€β”€[artifact_id]──► U1 (Chat-to-Edit)
β”‚
└──[artifact_id]──► P3 (Publishing)
β”‚
└──[post_status]──► U3 (Status Display)

### Dependencies

| ID | Type | From | To | Data | Risk |
|----|------|------|----|----|------|
| X-001 | Data Handoff | P1 | P2 | source_schema | High |
| X-002 | Shared State | P2, U1 | - | artifact.content | Medium |
| X-003 | Timing | P1 | P2 | source ready | High |
| X-004 | Event Chain | P3 | U3 | publish event | Medium |

In audit-state.json

{
  "dependencies": [
    {
      "id": "X-001",
      "type": "data_handoff",
      "from": "P1",
      "to": "P2",
      "data": "source_schema",
      "failure_modes": ["X-001a", "X-001b", "X-001c"]
    }
  ]
}

Common X-Series Patterns

Pattern Example Typical Failures
Schema Handoff P1 schema β†’ P2 prompt Missing fields, format changes
ID Reference P2 artifact_id β†’ U1 edit Invalid ID, deleted entity
Status Sync P3 status β†’ U3 display Stale status, race condition
Event Propagation P3 event β†’ U2 notification Lost event, duplicate delivery
Context Sync U1 selection β†’ U2 action Stale context, wrong entity

Failure Mode Format

X-series failure modes follow the same MECE taxonomy:

id: X-001a
dependency: X-001
location: L4-Integration  # Always L4 for cross-pipeline
type: T1-Data
severity: S4-Blocking
description: source_schema is null when P2 runs
impact: Generation fails completely
detection: Error thrown in P2
status: UNVALIDATED

Validation Checklist

  • [ ] All P-series outputs mapped to consumers
  • [ ] All U-series context dependencies documented
  • [ ] Shared state identified and race conditions analyzed
  • [ ] Timing dependencies have validation checks
  • [ ] Each dependency has at least one failure mode
  • [ ] X-series IDs assigned consistently

# Supported AI Coding Agents

This skill is compatible with the SKILL.md standard and works with all major AI coding agents:

Learn more about the SKILL.md standard and how to use these skills with your preferred AI coding agent.