Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add nonlinear-xyz/factory-kit --skill factory-apigit clone --depth 1 https://github.com/nonlinear-xyz/factory-kitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/nonlinear-xyz/factory-kit/factory-api)<a href="https://agentmods.dev/skills/nonlinear-xyz/factory-kit/factory-api"><img src="https://agentmods.dev/badge/skills/nonlinear-xyz/factory-kit/factory-api/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/nonlinear-xyz/factory-kit/factory-api"><img src="https://agentmods.dev/badge/skills/nonlinear-xyz/factory-kit/factory-api.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00095 | $0.03955 |
| Opus 5.5 | $0.00038 | $0.01582 |
| Sonnet 5.5 | $0.00019 | $0.00791 |
| Haiku 4.5 | $0.00010 | $0.00396 |
Grade A, and why
factory-api scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 403 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Factory api
Each section leads with Principle (one sentence, stack-agnostic), then Why (constraint → option → tradeoff), then Recipe (the Next.js / Drizzle / tRPC shape we use), and Failure mode when there's one to name. Sections that are pure style with no deeper truth are marked Recipe only. Editors: if the Principle could appear unchanged in Clean Code, sharpen the Why with a Factory-specific observation or drop the section to Recipe only — honesty over inflation.
API style — pick one
Principle. Pick one transport style per project; don't mix server actions and tRPC.
Why. Two transport styles in one codebase means two error-handling conventions, two cache-invalidation patterns, two surfaces to audit. The cost compounds linearly with every new endpoint; the cleanup is almost never worth the disruption. The decision is cheap at project start and expensive six months in.
Recipe.
| Style | Pick when |
|---|---|
| Server actions | Default. Feature-folder colocation matters. One frontend consumer. App-internal API only. Pairs with TanStack Query useMutation. |
| tRPC | ≥3 entities with cross-feature queries. Multiple frontend consumers. Need typed RPC across a real network boundary. |
| REST / OpenAPI | Only when an external system needs to call you. Don't use for internal app traffic. |
Failure mode. Encode imported tRPC at project start and built the rest in server actions; the unused tRPC surface created confusion at every call site for months before being deleted.
Server actions — canonical shape
Principle. Every mutation: parse input first, then wrap with org context, then fire-and-forget the audit log.
Why. Three contracts in tension. Validation is the boundary guarantee — past safeParse, downstream code assumes the shape. Org context is the tenant guarantee — without it, a cross-tenant write is one missing filter away. Audit is the reconstructability guarantee — but it's after-the-fact, so it never blocks the response. The order matters: validation can refuse; org context can refuse; audit can fail silently.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 403 lines · 95 tokens per session scan A 9822a0fe7381
factory-api is a skill published in the GitHub repository nonlinear-xyz/factory-kit (9 stars, last pushed 12d ago), licensed MIT. It adds 95 tokens to every session and 3,955 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
databases
Design schemas, tune queries, migrate, and administer PostgreSQL, MySQL/MariaDB, MongoDB, MSSQL, Redis, and Valkey.
supabase-node
Express/Hono with Supabase and Drizzle ORM.
nodejs-backend
Node.js backend patterns with Express/Fastify, repositories.
phoenix-contexts
Phoenix context design — creating/splitting contexts, Scope (1.8+), Ecto.Multi, PubSub, routers, plugs, controllers. Use when editing contexts, routers, or designing boundaries.
firebase
Use when building on Firebase — Firestore data modeling, Security Rules, Auth and custom claims, Cloud Functions, Storage, modular Web/Admin SDK imports — including symptoms like a database open to the internet, a query rejected by rules, or a doc stuck at 1 write/sec. NOT managed-Postgres BaaS with SQL and RLS (that…
notion-connector
Use when wiring server code or a cron job to Notion as an ops backend over its HTTP API: pushing or mirroring database rows, two-way sync without duplicates, page blocks, or an integration broken by the 2025-09-03 data-source split. NOT generic REST wiring (that is api-connector-builder), NOT inbound Notion webhook…