Dependency Alignment

---
name: dependency-alignment
description: Align dependency choices by capability coverage for any engineering project. Use after crate or library reconnaissance when deciding direct reuse, backend crate use, semantic adapter, handwritten behavior, shared dependency ownership, source expansion, or dependency risk for rewrites, feature additions, or infrastructure work.
---

# Dependency Alignment

Use this skill after reconnaissance or user-supplied evidence exists. Alignment
chooses capability ownership; it is not package-name matching.

## Inputs

- project facts and accepted architecture boundary;
- unit outcome and verification from `work-unit-slicing`;
- crate/library reconnaissance, or a recorded manual/disabled mode;
- existing dependency policy, license/build/runtime constraints;
- shared dependency registry if the project has one;
- fixtures or acceptance checks that prove required behavior.

## Decision Paths

Prefer the smallest verified path that fits project policy:

1. `direct`: a dependency public API covers the capability and fixtures can prove
   the behavior.
2. `backend`: a lower crate/library behind an umbrella dependency owns the stable
   layer; the project calls it directly.
3. `adapter`: dependency owns a lower layer; project code covers semantic gaps.
4. `handwritten`: project implements the capability because dependency reuse is
   larger, riskier, unavailable, unmaintained, incompatible, or harder to verify.
5. `defer`: boundary, evidence, license, build, or runtime risk is unresolved.

Fewer dependencies is not a success metric. More dependencies is not a success
metric either.

## Shared Capability Rule

If multiple units need the same crate, fork, generated source, adapter, fixture
harness, or handwritten gap, create one canonical shared prerequisite. Do not let
agents create long-lived private copies.

## Source Expansion

Expand or snapshot dependency source only when behavior matters and the project
allows it. First-layer dependencies are often enough. Deeper dependencies need a
call-path reason; lockfile transitivity alone is not enough.

## Output

```yaml
unit_id: example
capability: example
decision: direct | backend | adapter | handwritten | defer
selected_dependencies: []
shared_prerequisites: []
semantic_gaps: []
fixtures_or_checks: []
source_references: []
risks: []
manifest_patch_needed: []
```

## Non-Negotiables

- Do not add dependencies during alignment unless the user explicitly asked for
  implementation in the same turn.
- Do not treat missing recon evidence as success.
- Do not hand-write a maintained lower-layer capability without a tradeoff.
- Do not select a crate whose license/build/runtime risk violates project
  policy.
- Do not consume durable artifacts from `/tmp` or agent-private paths.