# How to ask your agent about this library `AGENT-CATALOG.md` is written for a coding agent, not for you. This page gives you the prompts to run it with. The quality of the answer depends almost entirely on the prompt. A vague ask ("is this library any good?") produces a vague answer. The prompts below are specific about what to inspect, how to classify a match, and what to report when something does **not** fit. **Before you start:** your agent needs two things open at once — your own repository, and `AGENT-CATALOG.md`. If your agent cannot read your repo, it can only summarize the catalog back to you, which tells you nothing. --- ## 1. Before you buy — "does this fit us?" Use this with the public catalog. It is written to let your agent tell you **no**. > You have two inputs: (1) this repository, and (2) the attached > `AGENT-CATALOG.md` describing a commercial component library I am considering > buying. > > Do not summarize the catalog. Evaluate it against this codebase specifically. > > **Step 1 — Inventory us.** Enumerate what this repo already has in these areas: > resilience and retry, caching, state machines, validation, auth and permission > gates, telemetry, provenance and audit trails, rate limiting, codegen, and any > hand-rolled utilities. For each, record the file path, the exported surface, > and roughly how many lines it is. > > **Step 2 — Match by capability, not by name.** For each catalog component, > decide whether it does the same *job* as something we already have, or fills a > gap we have been living with. Identifier similarity is not a match. > > **Step 3 — Classify every match** as exactly one of: > - `REPLACE` — covers our unit's job and more. > - `HARDEN` — our unit works, but this adds correctness or failure handling we > lack (determinism, tamper evidence, backpressure, circuit breaking). > - `SKIP` — our version is more specific, or it needs ports we cannot satisfy. > > **Step 4 — Read the constraints before recommending anything.** For each > component you recommend, report its stated verification status verbatim, and > report whether it requires a governed runtime or unimplemented adapter ports. > A component whose verification says "Not claimed" for behavior must be > reported that way. Do not soften it. > > **Step 5 — Report what does NOT fit.** I need the honest ceiling, not a sales > pitch. Tell me which parts of this library are irrelevant to us and why. > > **Bottom line.** Answer three questions directly: > 1. How many components would we actually adopt in the next 90 days? > 2. Which three would change the most, and what specifically would improve? > 3. Given what you found, is this worth buying for us — and at which tier? > If the answer is no, say no and explain what would have to be true for it > to be yes. > > Constraints: never invent a component that is not in the catalog. If you are > unsure whether something exists, say so rather than guessing. --- ## 2. Narrow version — "we have this specific problem" Faster and often more useful if you already know your pain. Replace the bracket. > Read the attached `AGENT-CATALOG.md` and this repository. > > We have a specific problem: **[e.g. our webhook delivery double-sends under > retry / we have no audit trail we can prove wasn't tampered with / our AI > provider costs are unpredictable and we're locked to one vendor]**. > > Which components in this catalog address that problem, and what would the > integration actually involve in *our* codebase — which files change, which > adapter ports we would have to implement, and what we would still have to > build ourselves? > > If nothing in the catalog addresses it well, say so plainly. --- ## 3. After you buy — "what do I install first?" Run this with the full delivery unzipped, not just the catalog. > You have this repository and an unzipped component library at `[path]`. > > Read `manifest.json` as the source of truth — never infer a component from a > directory listing. `AGENT-CATALOG.md` is the index; `artifacts//artifact-manifest.json` > has the per-component detail. > > Produce an adoption plan: > > 1. **Order.** Which components should land first, given our dependencies? > Anything with `runtimeRequirements.requiresGovernedRuntime: true` must ship > with its `sliceIds` — never alone. > 2. **Ports.** List every `adapterPorts[]` entry across the components you > recommend. The portable defaults in `adapters/` compile but do nothing, so > each one is real work I have to schedule. Estimate it. > 3. **Peers.** List the host packages `install.mjs` will ask for. > 4. **Blast radius.** For each component, which of our files would change. > 5. **Verification gaps.** For each component, restate its verification status > and tell me what I would need to test myself before trusting it in > production. > > Start with one component end to end before recommending a batch. Show me the > install command and the wiring for that one. --- ## What a good answer looks like If your agent's output has these properties, it did the job: - It names **your** file paths, not just catalog component names. - It has a `SKIP` list. An evaluation with no skips did not evaluate anything. - It repeats verification status, including the "Not claimed" entries. - It names the adapter ports as work you have to do, not as free. - It gives a number for question 1 that is smaller than the catalog size. If your agent returns an enthusiastic list of every component with no constraints, no skips, and no ports — re-run it with prompt 1 verbatim. It summarized instead of evaluating. --- ## What this library will not tell you The catalog reports what each component is verified for and, just as importantly, what it is not. Components carry this ceiling: > Extracted from systems the author has run in production since August 2025. > Operationally exercised, not independently security-audited. That is a real claim and a bounded one. If your agent tells you a component is "secure" or "production-proven for your use case," it went beyond the evidence. Ask it to cite the verification field it based that on.