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-authgit 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-auth)<a href="https://agentmods.dev/skills/nonlinear-xyz/factory-kit/factory-auth"><img src="https://agentmods.dev/badge/skills/nonlinear-xyz/factory-kit/factory-auth/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-auth"><img src="https://agentmods.dev/badge/skills/nonlinear-xyz/factory-kit/factory-auth.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.00097 | $0.03209 |
| Opus 5.5 | $0.00039 | $0.01284 |
| Sonnet 5.5 | $0.00019 | $0.00642 |
| Haiku 4.5 | $0.00010 | $0.00321 |
Grade A, and why
factory-auth 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 — 259 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Factory auth
Each section leads with Principle (one sentence, stack-agnostic), then Why (constraint → option → tradeoff), then Recipe (the 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 any auth tutorial, sharpen the Why with a Factory-specific observation or drop the section to Recipe only.
Provider pick — match the authz model, not the familiarity
Principle. Pick the provider whose model matches your authz shape; don't fight the provider for features it isn't built for.
Why. Auth providers differ in what they make easy. Better Auth is org-shaped (teams, roles, invitations). Supabase Auth + RLS is row-shaped (per-row policy reasoning). Clerk is consumer-shaped (managed UI, social login). Picking the wrong shape means every authz feature is upstream — you're rebuilding the provider's missing model. The wrapper interface below makes provider a swap point, so the cost of getting this wrong is bounded — but you still pay the swap.
Recipe.
| Provider | Pick when |
|---|---|
| Better Auth + organization plugin | Default. B2B with team/org concept. Drizzle-based projects. Need 2FA + magic link + admin out of the box. |
| Supabase Auth + RLS | RLS is doing real work — multi-role partner/distributor model, deeply branched authz at row level. Project already commits to Supabase. |
| Clerk | Consumer / SSO-heavy. Managed auth UI components matter. Org features secondary. |
The wrapper interface — the single seam
Principle. The wrapper is the seam; the provider is swappable behind it.
Why. Every server action and API route calls auth. If they call the provider's SDK directly, swapping providers means touching every action. The wrapper concentrates the provider dependency in one file — requireAuth, requireRole, withOrgContext — and gives the call sites a stable interface that doesn't depend on which SDK is underneath. The cost is three small wrapper functions; the savings are linear in the number of mutations the project will ever have.
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 · 259 lines · 97 tokens per session scan A 7978a7191537
factory-auth is a skill published in the GitHub repository nonlinear-xyz/factory-kit (9 stars, last pushed 12d ago), licensed MIT. It adds 97 tokens to every session and 3,209 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.
social-login
An implementation guide for letting users sign in with accounts from Google, Apple, Kakao, or Naver. It explains the frontend and backend steps, including checking the sign-in token before creating a session for your app.
backend-api
Design and review REST/HTTP APIs, with bounded GraphQL and gRPC contract guidance: OpenAPI, auth, pagination, compatibility, and retries.
update-docs
Update README, changelogs, API docs, and runbooks after changes; find and fix documentation drift.
fullstack-coding-standards
A reference guide for full-stack development, covering frontend code, APIs, databases, and Java Spring Boot examples. It is intended for explicit use rather than automatic application to every implementation.
api-tester
A workflow for testing communication between a web frontend and backend service. It covers proxy settings, cross-origin access (CORS), login tokens, error responses, and file uploads.