---
name: protocol-first-dependency-audit
description: Use this skill when the user wants to decide whether to keep, replace, or drop a specific dependency (an SDK, ORM, wrapper library, or framework) using Bare Metal Software's protocol-first and build/depend/generate decision method. Triggers on requests like "should we keep this SDK," "run a protocol-first review on our ORM," "is this library worth keeping," "audit this dependency against Bare Metal Software's method," or "what protocol is this wrapping and could we talk to it directly."
---

# Protocol-First Dependency Audit
This skill is Labor as Code™ for several chapters of *Bare Metal
Software*: "Use the Protocol Directly Before You Add a Library," "Dependencies and
Abstractions Must Earn Their Place," and "When to Keep the Library."
Read those for the reasoning; this skill only executes the audit
method and produces a recommendation. It does not replace anything on
its own authority — the final build/depend/generate call is always
the user's, made with the evidence this skill assembles, never guessed
by this skill on the user's behalf.

## Before running

Confirm before starting:

1. **Which exact dependency or boundary** is under review — name it
   precisely (a specific SDK, a specific ORM, a specific framework),
   not "our dependencies" in general. This method is applied one
   boundary at a time.
2. **What production features of it are actually used.** Ask the user
   to list these; do not infer them from the library's full
   documentation. The whole method depends on comparing the complexity
   you actually need against the complexity the library or the
   protocol brings — not the library's full feature list and not the
   full protocol specification.
3. **Does this boundary touch cryptography, password hashing, TLS or
   certificate validation, sandboxing, secure update signing, or a
   certified/regulated component?** If yes, stop the replacement
   question here. The book draws one hard wall: never generate your
   own cryptography or authentication, and never replace a certified
   component in regulated work with in-house confidence. This skill
   may still help narrow how much of that library's surface the
   project actually touches, but it must not produce a "replace it
   with a direct protocol implementation" recommendation for anything
   in this category. Say so plainly and move to the narrowing question
   instead of the replacement question.

## Step 1: Run the protocol complexity test

For the real, stated features from "Before running this," fill in
this comparison — the book's own table, applied to this one
dependency:

| Question | Direct protocol points toward | Library points toward | Your answer for THIS boundary |
| --- | --- | --- | --- |
| Surface used | Small, stable subset | Large or rapidly changing surface | |
| Security behavior | Ordinary transport and validation | Complex signing, key management, adversarial parsing | |
| Interop edge cases | Few and testable | Many vendor quirks or certification cases | |
| Failure behavior | Explicit and easy to model | Library contains mature retry/recovery logic | |
| Change rate | Protocol stable | Protocol/vendor behavior changes frequently | |
| Testing | Contract tests are straightforward | Proving compatibility would be expensive | |

Fill in the fourth column honestly against the *actual* used surface,
not the theoretical one. If most rows point toward "library," stop
here and recommend keeping it — do not continue the audit looking for
a way to justify replacement anyway.

## Step 2: Classify the layer

Platform layers (an operating system, a container runtime, a database engine, a TLS
implementation) are usually kept. Problem layers (something that
encodes a real domain need) are owned when strategically useful.
Convenience layers (an ORM, a wrapper SDK, a state library) mostly save
developer effort and should re-justify themselves:

| Layer | This dependency is | Default posture |
| --- | --- | --- |
| Platform | | Usually keep |
| Problem | | Own when strategically useful |
| Convenience | | Re-justify; often generate directly |

## Step 3: Build the dependency ledger entry

One row, the book's own fields:

| Field | Question | Your answer |
| --- | --- | --- |
| Capability | What do we actually use? | |
| Protocol beneath it | What standard or platform capability is being wrapped? | |
| Surface | What code, services, and data enter our trust boundary because of it? | |
| Replacement | Could AI (a harness) maintain the narrow capability directly? | |
| Failure | What breaks if it disappears? | |
| Exit | How do we remove it without data or behavior loss? | |

## Step 4: Make the build/depend/generate call

Given Steps 1–3, which of the three does this boundary warrant?

- **Build** — the capability is strategic and deserves deliberate,
  in-house subsystem design.
- **Depend** — another party solves a genuinely difficult problem
  better, and the dependency risk (Step 3's Surface/Failure/Exit) is
  acceptable.
- **Generate** — the capability is narrow, well specified by the
  protocol, and a harness can own the narrow implementation more
  cheaply than the project can own the dependency's lifecycle.

State which one, and state the reversal trigger — the measurable
condition that would flip this recommendation later. A recommendation
with no reversal trigger is incomplete; write one even if it currently
seems unlikely.

## Step 5: Argue the other side before finalizing

Before presenting the recommendation, make the strongest case for the
*opposite* choice: protocol complexity, security, interoperability,
certification, performance, the value of the library's community and
integrations, and genuine uncertainty in your own Step 1 answers. This
is the book's own check — if direct protocol use only wins after
dismissing edge cases the library already handles, the recommendation
is wrong. Revise Step 4 if this step changes your answer; do not
present a recommendation you haven't stress-tested this way.

## Step 6: Present the two-page-review-style output

Summarize for the user, short enough to fit the book's own "output
should fit on two pages" rule — the decision surface, not the full
analysis:

- The boundary and the features actually used.
- The protocol complexity verdict (Step 1).
- The layer classification (Step 2).
- The ledger (Step 3).
- The recommendation and reversal trigger (Step 4).
- The counter-argument considered (Step 5).

**Stop here.** This skill's job ends at the recommendation. Whether to
actually act on it — replace the dependency, keep it, or build the
capability in-house — is the user's decision, not this skill's.

## The check that catches this chapter's own failure mode

Before finalizing, reread the recommendation against two traps the
book names explicitly:

- If the recommendation is "generate a direct implementation" for
  anything touching cryptography, authentication, TLS/certificate
  validation, or a certified component, that is wrong regardless of
  what Steps 1–5 showed — go back and flag it as a hard-wall case
  instead.
- If the recommendation is "replace with a direct protocol
  implementation" anywhere, confirm Step 5 actually happened and
  actually considered the edge cases the library handles today — not
  just a token restatement of Step 1's already-favorable answer. A
  library should be treated as innocent until the direct
  implementation's full lifetime obligation, tested and edge cases
  included, is shown to be smaller — not just shorter on day one.