Let people ship. Keep the bar high.
Skills, subagents, and slash commands that encode how you build — then drive every agent, manage your context, and enforce the standard at every PR.
One command. 14 skills, 10 subagents, 6 commands.
Symlinks into ~/.claude/ — restart your agent and everything auto-loads, in every repo.
npx @nonlinear-labs/factory-kit Author once. Every agent reads it before it writes.
A loop that calls a library of sharp, tested, named skills is a system that compounds.
- 01
Author the standard
Write how you build once. Every skill is Principle → Why → Recipe — plain markdown you own and version.
factory-data-layer.md - 02
Install it everywhere
One npx per machine. The kit symlinks into the agent's config and rides along to every repo — no per-project setup.
$ npx @nonlinear-labs/factory-kit - 03
Every agent builds to spec
Skills auto-load before the agent writes; the checker and CI gate keep the output honest.
✓ to spec
Everything the kit lets you do.
The richness is in the depth. Every skill, subagent, and command is a concrete unlock — here's what you get on day one.
Drive your agents
One command symlinks your standard into ~/.claude/, so Claude Code reads it before it writes. “Call my feature-architect. Pull up my db-schema-architect.”
Manage your context
Linear slash commands — /standup, /entry, /close — load tickets into your session and move them through review without leaving the terminal.
Set the standard
Specialist skills for design tokens, animation budgets, schema migrations, auth wiring. Each is Principle → Why → Recipe → Failure mode.
Enforce it
factory-kit-check reads and judges every build against the standard. Read-only — it never writes to your code. CLI headless, or a GitHub CI gate at PR.
Twelve specialists, routed by one architect.
Every non-trivial feature starts with the feature-architect: it scopes the ask, names the decisions, and hands the work to the right specialist — each one carrying your conventions, not generic boilerplate.
> use feature-architect — scope the intake feature, route the build
✓ spec drafted · 3 decisions needed · 2 specialists routed
↳ db-schema-architect — org-keyed tables, cascade delete
↳ forms-builder — multi-step intake, field registry
Your tickets, in your terminal, in context.
/standup shows the board. /entry loads a ticket into the session and plans the work. /submit moves it to review, /close ships it — small, modular changes, each one traced to a ticket, without leaving the terminal.
> /standup
Dev standup · NON
In progress NON-64 — homepage rebuild
In review NON-66 — what-you-unlock section
Top priority NON-67 — integrations matrix
↳ pick up NON-67 next — highest priority, no blockers.
Standards agents can actually read.
21 skills covering design tokens, animation budgets, schema migrations, auth wiring, and more. Each leads with the stack-agnostic principle, argues the why, then locks the recipe — so the reasoning ports even where the stack doesn't.
## ORM pick — match the data shape, not the comfort
Principle. Use the ORM whose abstractions match your schema's shape; don't escape to raw SQL by default.
Why. An ORM with $inferSelect-style derivation means the schema is the type — one source of truth, one place to refactor. The cost is one query DSL; the cost of raw SQL is every hand-written mapper and every silent type drift.
Recipe. Drizzle by default — Postgres + TypeScript, pairs with Better Auth's drizzleAdapter. Supabase auto-types when RLS does real work.
Failure mode. Raw pg with hand-mapped rows: every new query meant another mapper, and the types drifted from the schema on every migration.
Deterministic checks. Verdicts that cite the spec.
factory-kit-check is read-only — it reads and judges, it never writes to your code. Every finding cites the skill line it violates. At the PR, the gate is delta-gated: new criticals block, old debt never does.
$ factory-kit-check
factory-kit-check · read-only — we read and judge, we never write
FAIL — critical findings present
src/server/db/ops.ts:42 update/delete with no .where() — this mutates every row
→ factory-data-layer.md §ORM pick [update-delete-no-where]
1 critical · 0 high — 6 rules run · 214 files scanned
$ git commit -am "fix: scope the delete with .where(eq(orgId))"
$ factory-kit-check
PASS — no critical or high findings
✓ 6 rules run · 214 files scanned · 0 findings
npx @nonlinear-labs/factory-kit add-ci Rides on the tools you already use.
The kit is markdown plus a read-only CLI — no vendor lock. It fits in the space between the platforms you've already chosen.
Author your standard once — it holds wherever you work.
Start with the kit. Build the factory.
Start with the free, self-hosted kit your team authors. Orchestrate it across a whole portfolio — that's the hosted level-up.
Self-hosted
start here- Pre-built skills, subagents & slash commands
- Run locally via the CLI + CI drift check
Hosted · Team
- Hosted Org Kit + GitHub App CI gate
- Reads builds across the team, calls out drift
- Drift dashboard
Hosted · Enterprise
- SSO, audit log, policy controls
- Self-hosted control plane
- Write-back authoring engine
Frequently asked questions.
How is this different from one big CLAUDE.md?
A monolithic CLAUDE.md is always in context and always stale. The kit splits the standard into named skills that load on demand, specialist subagents that carry only the context their job needs, and a checker that enforces the subset that can be enforced deterministically. Structure is what makes the standard testable.
Does it only work with Claude Code?
The standard itself is plain markdown and the checker is a read-only CLI — both vendor-neutral. Claude Code is the first-class integration (skills, subagents, and slash commands auto-load); Codex and Cursor surfaces are being built.
What does factory-kit-check actually enforce?
Six deterministic rules today, severity-banded (pass / warn / fail), each finding citing the exact skill line it violates. The uncovered backlog — 45 pitfalls without a machine rule yet — is listed in the scorecard, never hidden. No LLM, no black box: every rule is greppable code.
Will the CI gate block my legacy debt?
No. The GitHub Action is delta-gated: it fails only on newly-introduced critical findings. Pre-existing debt is reported, never punished, so you can adopt the gate on a ten-year-old repo without a cleanup sprint first.
Do I need the hosted product?
No. The self-hosted kit is complete and free — skills, subagents, commands, checker, CI gate. Hosted adds cross-repo measurement (one dashboard watching drift across your whole portfolio) and is opening in beta via the waitlist.
What's the license? Can I fork it?
MIT. Fork it, rewrite the skills to match how your team builds, and keep the structure — that's the intended use, not a workaround.
The spec your coding agent reads before it writes.
Run locally, fork freely. The full kit is yours to own and extend.
Hosted measurement reads builds across your team and calls out drift. Opening in beta.