assess-dependencylisted

# Assess a dependency Decide whether a **structural dependency** belongs in this project — a decision grounded in *this* codebase, not a survey of the dependency's features and not an implementation plan. Mental model: **run the gates in order and stop at the first that yields a terminal decision**, rather than running every check to look thorough. The decision, not a survey, is the goal. Governing intuition: **decline is a valid, common result** — most adoption questions should narrow or stop before any proposal work begins. **Input**: the structural dependency under consideration (a library, framework, runtime, or abstraction layer) and the target repo — if the candidate's role is unclear, run the Scope gate first to confirm this skill applies. **Boundary**: reads and decides only — does not edit files, add the dependency, or run builds; writes only the optional worksheet when asked, and stops at the decision (implementation is downstream). ## Scope gate (Step 0 — do this first) This skill is for **structural** dependencies: abstraction layers, frameworks, runtimes, capability/effect systems, DI/contract layers, broker/storage substrates, serialization frameworks — anything that shapes how code is *written* or *composed*. It is **not** for leaf utility libraries (a date parser, a hashing library, a CLI arg parser). If the candidate is a leaf utility with a local, reversible blast radius and no architectural mechanism, **stop**: tell the user ordinary judgment applies