Let anyone build production-grade software with AI agents — from an idea to operating software.

In 60 seconds

Opinionated about how you build. Neutral about what you build with.

It is opinionated about how to build well with agents, and deliberately neutral on three axes — any stack, any harness, any model. Your stack, environment, deploy target, coding agent, and even which AI model powers each role are chosen as you engage the kit, never picked for you.

It is not a platform you buy, not a runtime you depend on, and not a service that holds your code or credentials. You copy it into your own repository, choose your stack, and its checks run on every push in your own CI. There is no lock-in — it sits alongside the tools you already use.

Who it’s for. Any team — humans, agents, or both — that wants production-grade discipline without inventing a process from scratch, whether they’re starting a new project or bringing the kit to an existing codebase. Adopt it as-is, or hand it to a team and tailor it.

Why now

Agents amplify whatever discipline they’re dropped into.

AI is already in nearly every workflow — 90% of the ~5,000 software professionals surveyed for Google’s 2025 DORA study reported using it at work. The question is no longer whether AI touches your codebase, but whether it does so safely. Recent research on ungoverned AI is the warning. Every figure below carries its source: the research is industry findings about the problem, not Sparkwright’s results.

Google’s DORA 2025 report (Sept 2025) is the sharpest version of the story: AI finally lifted delivery throughput — yet delivery instability kept rising, and the report concludes that without “intentional changes to workflows, roles, governance, and cultural expectations,” AI tools are “likely to remain isolated boosts in an otherwise unchanged system.” That is the whole case for Sparkwright: agents move fast inside enforced boundaries, so the speed is real and the instability isn’t. Human attention and integration risk are the scarce resources; the kit spends the cheap one freely and protects the expensive ones.

Sources: DORA, State of AI-assisted Software Development 2025 (Google, Sept 2025, ~5,000 respondents) · Veracode 2025 GenAI Code Security Report (Jul 2025, 100+ models) · CodeScene, “Code for Machines, Not Just Humans” (peer-reviewed, 2026).

What you actually do with it

From an empty repo to a green pipeline, then into the loop.

Sparkwright is the execution engine that takes you from a Ready backlog to operating, monitored software, with the guardrails built in.

1. 01

   Create your project from the kit

   Clone a throwaway copy and run one script that produces a clean, CI-ready project of your own — pruned of the kit’s internal scaffolding, but keeping every stack profile so your stack stays a decision, not a default.

2. 02

   Let it guide you through Inception (Phase 0)

   Open the project in your AI coding tool and say “Walk me through START-HERE.” You write a charter, choose your stack and record it as ADR-000 — the one step that decides what you build it with — stand up CI, and get a green pipeline on the empty project before any feature work. You build on working software, not an empty repo.

3. 03

   Enter the loop

   Each backlog item flows through the delivery cycle. You, the human, sit on the gates — approve the design, make the go/no-go at release, accept the increment. The agents do the building between the gates, at machine speed.

create-your-project.sh
# Clone a throwaway copy — used only to create your project
git clone --depth 1 https://github.com/SeaBrad72/sparkwright /tmp/sparkwright

# Create your new project from it — name it whatever you like
sh /tmp/sparkwright/scripts/adopter-export.sh ./my-app
cd my-app

# then open it in your AI coding tool and say:
#   "Walk me through START-HERE."

The shape, in one line: a project is born through Inception and evolves through a closed loop, with humans as a thin layer of judgment at the gates and agents doing the volume between them. In a typical feature — say, “add CSV export” — humans touch it at exactly three points (spec, merge, acceptance); agents run continuously in between.

First principles & foundations

Rituals that clarify intent get stronger. Rituals that just manage effort die.

From these follow the core ideas: flow, not sprints (WIP-limited kanban, humans as the pacing metronome); a closed loop (a retro that changes nothing is theatre); agent governance by autonomy tiers keyed on risk × reversibility (irreversible actions are human-gated, autonomy is earned by metrics); and universal-plus-profile (standards stay stack-neutral, the one stack-specific layer is a swappable profile).

How the kit is built

Contract → Reference → Conformance.

Every capability ships as a three-part vertical — the architectural idea that makes Sparkwright opinionated and neutral at once.

The kit dictates the contract and offers the implementation: rewrite the reference however you like, as long as the conformance check still passes. The checks run, on the kit’s own tree, on every push — and the kit is built with the very loop it prescribes, holding itself to the same Definition of Done it gives you.

What it covers

One guided spine, from idea to operating software.

A project is stood up once through Inception, then every item runs the recurring loop. Humans gate at spec, merge, and acceptance; agents run between.

1. Inception · once→
2. Discover→
3. Plan→
4. Build→
5. Review→
6. Release→
7. Done→
8. Operate

Guardrails & governance

Built in, not bolted on — the reason to adopt the kit.

• The guard — a PreToolUse deny-matrix that intercepts destructive actions, and changes to the rules governing the agents themselves, before they land: a fast first layer in front of the real boundary, the git + CI chokepoints below.

• Every gate can explain itself — each one records the risk it answers and why paying its cost beats the alternative, queryable from the CLI with sparkwright explain <topic>. A guardrail nobody can justify becomes bureaucracy; this is how the kit keeps them accountable to a reason.

• Eight required CI quality gates on every push — nothing merges without them. Lint, type-check, test + coverage, build, secret-scan, dependency-scan, SBOM, and SAST — plus build-provenance (SLSA), license-policy, and AI-eval gates that activate by context.

• Separation of duties, enforced — builder ≠ reviewer ≠ ratifier, the last being whoever signs off that a governing change may ship. Those changes need an independent ratifier, and the merge is a recorded go/no-go bound to the reviewed commit (shipped == approved, verified by tree equality). Branch protection carries the rule down to the merge button itself: the last hand on the code is never the hand that approves it. The agent actuates the mechanics; the judgment is the control, not the keystroke.

• Model tiering — each agent seat runs at an abstract tier: judgment and review seats pinned to the top model, builders free to run cheaper where the task allows, high-stakes work floored to the top. You declare the tier→model map for your provider — opinionated about structure, neutral about which model.

• Autonomy tiers (L1/L2/L3) — how much an agent may do without sign-off, from suggest-only to act-then-report, keyed on risk × reversibility. Autonomy is earned by metrics.

• Ratification — agents propose, humans approve. An agent never silently changes the standards, process, or control-plane files that govern it.

• Proportional promotion — rigor scales with how risky a change is and how far it is being promoted. Safe changes move fast; dangerous ones get slowed down. A change’s class is derived at promotion, defaulting higher when uncertain, so it can’t be understated.

Honesty as a feature

Every control labelled: enforced, advisory, or declared.

The rarest thing the kit does is tell you exactly how strong each guarantee is — a live gate that blocks, a nudge that doesn’t, or an attestation it can’t observe at runtime. That candor is the differentiator, and the safety story is drawn as a layered defense, not a disclaimer.

For engineering leaders & compliance

A portable, executable assurance layer you own and run in your own CI.

Maturity

Built and hardened with its own loop.

Maturity is tracked as a stage, separate from the version. Sparkwright is at release-candidate — hardened, red-teamed, and dogfooded, and ready to adopt.

1. pre-adoption→
2. release-candidate · now→
3. adopted

The discipline is proven, not asserted: the kit is built with its own loop, holding itself to the same Definition of Done and mutation-tested gates it gives you — on every change, run end-to-end to build and deploy real software. Where it cannot hold itself to a standard, it says so. On its own repository agent ≠ ratifier is enforced. Two-person human review is not — the kit is maintained solo, and that gap is declared rather than hidden.

The next stage — adopted — is earned when an external team ships real software through the loop; the kit is being put in front of its first teams now.