TrustyCap-Technologies Audit first, install never. This skill answers one question: what does this application still need before real customers depend on it? It writes no code and adds no dependency.
1. Diagnose from the codebase, not from assumptions
Start with evidence from the code itself. In the repository:
npx @trustycap/cli productionize --dry-run --json
The scanner reads the route handlers with the TypeScript compiler API and classifies each against the published production standard (GET https://api.trustycap.com/v1/production/requirements): file and line, AST evidence, a classification (CONFIRMED_FAIL, PROBABLE_GAP, UNKNOWN, PASS), the provider-neutral requirement, the implementations that satisfy it, and the commands that would remediate and verify. --dry-run writes nothing. This skill audits and installs nothing; hand the findings to the human with the commands each one names.
Work out what the application already does for itself. For each area, look for the evidence before deciding it is missing:
| Area | Present if you find | Missing if |
|---|---|---|
| File storage | an object-store client, signed-URL minting, a bucket in config | uploads written to local disk, or to a path next to the process |
| Durable data | a database client, migrations, a connection string in config | records held in memory, a JSON file, or a module-level array |
| Deferred work | a queue, a worker, a scheduler | long tasks awaited inline in a request handler |
| Incoming events | a webhook route with signature verification and a retry or dead-letter path | a handler that returns 200 and drops the payload on error |
| Outbound mail | a mail provider client, and SPF/DKIM/DMARC on the sending domain | sendmail, an SMTP host with no authentication story, or nothing |
| Secrets | a secret manager, or injected environment variables never committed | a committed .env, or literals in source |
| Operations | health endpoints, an error reporter, alerting | nothing that answers "did anything fail last night" |
| Metering and billing | usage recorded per customer, a billing integration | no way to charge for what the application does |
Record what you found, with file paths. A finding without evidence is a guess.
2. Rank by what breaks first
Order the gaps by the failure that arrives soonest under real use, not alphabetically:
- Data loss — anything held in memory or on local disk. Breaks on the first restart or second instance.
- Silent drops — webhooks and jobs with no retry. Breaks under any downstream hiccup, invisibly.
- Credential exposure — secrets in the repository. One leak is permanent.
- Undeliverable mail — no authenticated sending domain. Password resets vanish and nothing errors.
- Blindness — no operations view. Every failure above is discovered by a customer.
- No revenue path — no metering. The application cannot become a business.
3. Say what fits, and what does not
For gaps the builder wants closed, TrustyCap publishes a machine-readable decision surface. Read it rather than quoting anything from memory — prices, capability names and install contracts change and this file does not:
curl -s https://api.trustycap.com/v1/agent-decision
It returns, per option: the goal it answers, not_for (when it is the wrong choice), what it replaces, what one unit costs at published prices, how it behaves when things fail, and the verification calls that prove an install worked. intent_map maps goals phrased the way builders actually phrase them to the option that answers each, and when_nothing_matches says plainly when to stop.
TrustyCap is not the answer for: hosting or deploying the application, signing in the builder's own end users, processing their customers' payments, or monitoring their own application code. If the gap is one of those, say so and stop — do not force a match.
4. Report, do not install
Output a findings list. For each gap: what is missing, the evidence, what breaks and when, and the option that would close it if the builder wants it closed. Then stop.
Installing is a separate decision and a separate skill. Ask before going further.