Lib Advisor
Diego's dependency philosophy: pragmatic. Instead of rewriting the wheel, find a
dependency that already solves the problem — especially one that trivializes a
recurring problem or whose API reads like well-written prose, cutting the cognitive
load of the calling code. Small, focused dependencies over frameworks (a framework
only if the project adopts one from the start). Manual implementations only when
full control is a requirement, or the problem is too specific for any dependency.
During planning (primary trigger)
When drafting an implementation plan for a new feature, run the standard-problem
test over each planned component before the plan commits to building anything
manually. For every component that passes the test, resolve the dependency
decision inside the plan itself:
- Run steps 2-3 (candidates and evaluation) as part of plan research — read-only
work, safe to parallelize with other plan investigation.
- The plan lists each chosen dependency with a one-line justification and the
mechanism that makes its API read well (Facade / Fluent Interface / Internal
DSL), alongside the plan's contract previews.
- Components that fail the test are marked manual, with the reason (full control
required, or too domain-specific).
A plan that reaches the user with "implement an SSH client" as a task, instead of
"use golang.org/x/crypto/ssh", missed this skill's job. Deciding dependencies at
planning time costs a search; deciding them after implementation costs a rewrite.
Step 1 — The standard-problem test
Before implementing, ask: has someone already solved this? Signals that the
answer is yes:
- The functionality is infrastructure, not domain logic (SSH clients, retries,
parsers, validators, schedulers, routers).
- Describing the problem takes one generic sentence with no mention of the
project's domain.
- A wrong implementation has well-known failure modes (timezones, TLS, escaping,
concurrency) that specialists have already debugged for years.
If the problem passes the test, proceed. If it is domain-specific or requires full
control, implement manually and say why.
Step 2 — Find candidates
- Check the language's standard library and official extended packages first — in
Go especially (
golang.org/x/... counts as near-stdlib; e.g. x/crypto/ssh for
programmatic SSH).
- Search for 2-4 third-party candidates. Prefer sources close to the ecosystem
(pkg.go.dev, npm, awesome-lists) over generic blog rankings.
Step 3 — Evaluate
Score each candidate on four axes, in this order of importance:
- Maintenance. Discard anything unmaintained: no commits or releases in a long
stretch, unresolved issue pileup, archived repos. This criterion is
eliminatory.
- API prose quality. Read example call sites and classify the mechanism that
produces (or fails to produce) prose-like reading:
- Facade: hides a complex subsystem behind two or three orchestrating
functions (GoF sense). Examples: react-hook-form over form state/validation,
zustand over global state.
- Fluent Interface: methods return
this (or an equivalent object),
enabling chained calls that read as a sentence. Example: chi's routing groups.
- Internal DSL: the API as a whole feels like a mini-language embedded in
the host language.
The best libraries combine two or three mechanisms. The reference bar:
react-hook-form, zustand, samber/lo, chi.
- Scope fit. Small and focused on the problem beats broad and framework-like.
A dependency that drags a large transitive tree for one function is a bad
trade.
- Fit with the project. License, language version constraints, and whether it
plays well with dependencies already present.
Step 4 — Recommend and confirm
Present the recommendation with a short comparison of the candidates evaluated —
what each does well, why the winner wins, and what the manual-implementation route
would cost instead. Confirm with the user before installing.
After confirmation, query the library's docs via the context7-cli skill (ctx7
is installed; do not use npx) before writing integration code, and install with
the project's package manager.
Anti-patterns
- Recommending by popularity alone — stars measure adoption, not API quality or
maintenance.
- Wrapping a trivial stdlib call in a dependency (left-pad syndrome).
- Adopting a framework mid-project because one candidate happens to be one.
- Skipping the user confirmation, or installing before checking docs via ctx7.
1---2name: lib-advisor3description: Search, evaluate and select libraries when a problem is "standard" — meaning someone has almost certainly solved it already. The strongest trigger is mid-planning of a new feature — while drafting or reviewing an implementation plan (plan mode, task-planning), run the standard-problem test on each planned component before the plan commits to a manual implementation. Also use this skill whenever the user is about to implement non-trivial functionality that sounds like a solved problem (programmatic SSH, retry/backoff, argument parsing, schema validation, date handling, HTTP routing, queues, templating), asks "should I implement X myself or use a lib?", "is there a library for X?", asks to compare libraries, or starts writing infrastructure-flavored code from scratch. Also use it when evaluating whether an existing dependency should be replaced, or when designing a public API and the prose-quality taxonomy (Facade / Fluent Interface / Internal DSL) applies.4---56# Lib Advisor78Diego's dependency philosophy: pragmatic. Instead of rewriting the wheel, find a9dependency that already solves the problem — especially one that trivializes a10recurring problem or whose API reads like well-written prose, cutting the cognitive11load of the calling code. Small, focused dependencies over frameworks (a framework12only if the project adopts one from the start). Manual implementations only when13full control is a requirement, or the problem is too specific for any dependency.1415## During planning (primary trigger)1617When drafting an implementation plan for a new feature, run the standard-problem18test over each planned component **before the plan commits to building anything19manually**. For every component that passes the test, resolve the dependency20decision inside the plan itself:2122- Run steps 2-3 (candidates and evaluation) as part of plan research — read-only23 work, safe to parallelize with other plan investigation.24- The plan lists each chosen dependency with a one-line justification and the25 mechanism that makes its API read well (Facade / Fluent Interface / Internal26 DSL), alongside the plan's contract previews.27- Components that fail the test are marked manual, with the reason (full control28 required, or too domain-specific).2930A plan that reaches the user with "implement an SSH client" as a task, instead of31"use `golang.org/x/crypto/ssh`", missed this skill's job. Deciding dependencies at32planning time costs a search; deciding them after implementation costs a rewrite.3334## Step 1 — The standard-problem test3536Before implementing, ask: **has someone already solved this?** Signals that the37answer is yes:3839- The functionality is infrastructure, not domain logic (SSH clients, retries,40 parsers, validators, schedulers, routers).41- Describing the problem takes one generic sentence with no mention of the42 project's domain.43- A wrong implementation has well-known failure modes (timezones, TLS, escaping,44 concurrency) that specialists have already debugged for years.4546If the problem passes the test, proceed. If it is domain-specific or requires full47control, implement manually and say why.4849## Step 2 — Find candidates5051- Check the language's standard library and official extended packages first — in52 Go especially (`golang.org/x/...` counts as near-stdlib; e.g. `x/crypto/ssh` for53 programmatic SSH).54- Search for 2-4 third-party candidates. Prefer sources close to the ecosystem55 (pkg.go.dev, npm, awesome-lists) over generic blog rankings.5657## Step 3 — Evaluate5859Score each candidate on four axes, in this order of importance:60611. **Maintenance.** Discard anything unmaintained: no commits or releases in a long62 stretch, unresolved issue pileup, archived repos. This criterion is63 eliminatory.642. **API prose quality.** Read example call sites and classify the mechanism that65 produces (or fails to produce) prose-like reading:66 - **Facade**: hides a complex subsystem behind two or three orchestrating67 functions (GoF sense). Examples: react-hook-form over form state/validation,68 zustand over global state.69 - **Fluent Interface**: methods return `this` (or an equivalent object),70 enabling chained calls that read as a sentence. Example: chi's routing groups.71 - **Internal DSL**: the API as a whole feels like a mini-language embedded in72 the host language.73 The best libraries combine two or three mechanisms. The reference bar:74 react-hook-form, zustand, samber/lo, chi.753. **Scope fit.** Small and focused on the problem beats broad and framework-like.76 A dependency that drags a large transitive tree for one function is a bad77 trade.784. **Fit with the project.** License, language version constraints, and whether it79 plays well with dependencies already present.8081## Step 4 — Recommend and confirm8283Present the recommendation with a short comparison of the candidates evaluated —84what each does well, why the winner wins, and what the manual-implementation route85would cost instead. **Confirm with the user before installing.**8687After confirmation, query the library's docs via the `context7-cli` skill (`ctx7`88is installed; do not use `npx`) before writing integration code, and install with89the project's package manager.9091## Anti-patterns9293- Recommending by popularity alone — stars measure adoption, not API quality or94 maintenance.95- Wrapping a trivial stdlib call in a dependency (left-pad syndrome).96- Adopting a framework mid-project because one candidate happens to be one.97- Skipping the user confirmation, or installing before checking docs via ctx7.
DieGopherLT