Skip to content

A Horizon Foundry suite · Distill. Forge. Deliver.

Forge shippable software
from AI-built code.

Foundry is a suite of Claude Code skills that turns fast, messy, AI-built code into something you can ship. It distills the mess into clear direction, forges it with the discipline that keeps a cold start from going wrong, and delivers a pre-launch audit that ends in a verdict.

foundrysimulated run
verdict SAFE TO SHIP
0 risks 6 improvements
improvements don't block the release
Distill

Melt messy context down to what is clear and current.

Forge

Build with the discipline that survives a cold start.

Deliver

Ship on a verdict, not a hope.

Five promises, each kept by a skill

  1. 01Product intent is declared and audited/frame
  2. 02Execution context survives every session/phase-plan
  3. 03The intended outcome is instrumented/instrumentation
  4. 04The documentation matches reality/document
  5. 05Technical readiness is audited before real users/foundry + /production-audit

Install Foundry

One command adds the skills to Claude Code. No build step, no account required, and the skills contain no telemetry: they run entirely in your environment.

Star on GitHub
recommended
$ npx skills@latest add horizon-foundry/foundry

Runs the open-source skills CLI: it copies the skills you pick into your Claude Code setup and nothing more. Then run claude and /foundry check.

from source
$ git clone https://github.com/horizon-foundry/foundry
$ cd foundry
$ make install

Symlinks every skill so it tracks the repo. Update with git pull && make install, remove with make uninstall.

What happens when you invoke it

A skill is something Claude Code runs against your project. /production-audit reads your code (never writes), traces the flows that cross file boundaries, refutes its own findings, and returns a verdict:

verdict Ready to ship, risks noted
0 critical, 0 high, 4 medium, every finding cited to file and line
Requirements
For npx: Node and Claude Code. For the from-source path: git, make, and Claude Code. No account, no telemetry.
What it installs
The skills land in Claude Code's skills directory, invocable in any session as top-level commands (/foundry, /production-audit, and so on). npx lets you pick which skills; the from-source make install symlinks them all so they track the repo.
Upgrade and uninstall
npx: re-run the add command to update. From source: git pull && make install to update, make uninstall to remove the symlinks. Nothing else touches your system.

Production Audit

The deliver step of the suite: a whole-application pre-launch audit across the dimensions your product calls for, from a standing set of eleven, separating risks from improvements. It ends in a ship or no-ship verdict that names the evidence it stands on.

See our audit of this repo →
Safe to ship
Ready to ship, risks noted
Do not ship

Software built fast ships confident and unverified.

A security review looks at security. A diff review looks at a diff. A frontend audit looks at the frontend. None of them answer the question you actually ask the night before an invite wave: is this safe to put in front of real people.

That question covers the whole app, and it needs a verdict, not a list. Production Audit traces the flows that cross file boundaries, produces artifacts a reviewer can finish, and refuses to report anything it cannot back with evidence.

Eleven dimensions, resolved per project.

Security

An authorization matrix for every mutation, plus tenant isolation, injection surfaces, secret exposure, and how model output is handled.

Concurrency

Idempotency on every write, check-then-write races (TOCTOU), effect cleanup, and state that stays correct across multiple tabs.

Reliability

A failure-path table per dependency: timeout, retry, user-visible failure, partial success, rollback.

Accessibility

Primitives first: focus traps, labels, roles, and keyboard paths, checked against WCAG 2.2 AA as far as static review can reach.

UI consistency

Token conformance, component divergence, state coverage, and copy drift across the whole surface.

Infra

Deploy config, security headers, CSP, env handling, and a dependency audit triaged by real exposure.

These six usually apply. Five more resolve per project, operability, testing confidence, data and migration safety, release safety, and performance, and even these six drop out where there is no surface, accessibility or UI on a headless service. Anything left out is named with a reason, never quietly skipped.

The method

00

Context

Read the docs, map the stack, build the flow inventory and trust-boundary map. The audit works flow by flow, not file by file.

01

Sweep

Mechanical passes first: dependency audit, secret scan, typecheck, lint. That way the deeper review never spends time on something a tool could have caught.

02

Fan out

One reviewer per dimension, each producing its required artifact. Every finding cites a file and line, or it is not a finding.

03

Refute

Every critical, high, and verdict-driving finding goes to a fresh skeptic who tries to disprove it against the code. The ones that survive make the report.

What makes the findings trustworthy.

Flows, not files

A bug lives in the seam between two files more often than inside one. The unit of work is a flow traced end to end.

Artifacts, not vibes

An authorization matrix and a failure-path table can be finished, and a blank cell is a finding. 'Look harder' can't be finished, so it finds nothing.

Adversarial verification

The default failure of an AI audit is the confident, wrong finding. So every finding that drives the verdict has to survive someone trying to refute it.

Evidence classes

Runtime-reproduced means observed live. Code-traced means the full path was read. High-confidence names its one assumption. If a finding fits none of these, it isn't reported.

The kill list

The predictable false positives are named and forbidden. Before calling a control missing, check every layer it could live at.

The honest boundary

Anything that needs a running browser is labeled needs-verification or listed as not assessed. The verdict names the evidence it stands on: a static-only run is clear within the scope it checked, never a flat safe-to-ship.

You set the scope, not the bar. Which dimensions apply comes from what your product is, and which risks you accept is your call, on the record. The severity rubric and the meaning of the verdict are fixed on purpose. A bar you could lower until it turns green is the false comfort this exists to replace.

We audited Foundry with Foundry.

The same /production-auditthis suite ships, run against Foundry's own repository. Real code, real findings, nothing fictional. The core access controls, fail-closed auth, and security headers verified clean; the open risks are named and fixable. The repository is public, so you can read the report against its source and see exactly what the method checked and what it found.

Verdict: Safe to ship

Read the full report →Prefer a traditional SaaS shape? See the Perch example, a fictional booking app audited in full.
Report · Foundry · 2026-07-16Worked example

Release recommendation

Safe to ship

Static review · runtime not exercised

0
critical
0
high
2
medium
13
low
6
info

2 confirmed · 1 downgraded on verification · 1 refuted and dropped

Run it

/production-auditfull audit: core + applicable dimensions
/production-audit securityone dimension, scoped posture
/production-audit --quicksecurity + reliability triage
/production-audit --runtimeadd a live browser pass

The audit is read-only. It never changes your code. It produces a structured report and a verdict, and it tells you what it did not look at.