Protocol-First Dependency Audit
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.
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:
- 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.
- 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.
- 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.