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.

You know this part already. AI is in the workflow; the open question is whether it is in there safely. Every figure below carries its source — these are industry findings about the problem, not Sparkwright’s results.

Google’s DORA 2025 report names the tension exactly: AI finally lifted delivery throughput, and delivery instability rose anyway — leaving AI tools “likely to remain isolated boosts in an otherwise unchanged system” without deliberate change to workflows, roles, governance and culture. Which is the case for Sparkwright in a sentence: agents move fast inside enforced boundaries, so the speed is real and the instability isn’t.

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).

How it works

One loop, from idea to operating software.

A project is stood up once through Inception. After that every item runs the same loop — pulled, not pushed, with no timebox. Humans are the pacing metronome.

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

Discover

Intake, validation, triage. Production signals land here too.

Plan

Slice into vertical increments, write testable criteria, threat-model anything sensitive.

Build

Test-first, in an isolated worktree, against the spec.

Review

Did we build it right? Code, security and quality lenses, by a seat that didn't write it.

Release

Deploy behind flags, staged rollout, smoke test, rollback ready.

Done

Acceptance — did we build the right thing? — then the retro.

Operate

Monitor, triage, resolve. What you learn feeds Discover.

What it changes about how you work

Agent effort is cheap. Human attention is not.

That single shift decides which of your rituals still earn their place. Ceremonies that forecast human effort stop making sense. Practices that clarify intent or catch defects get more valuable, because agents can run them far more often than a team of people ever could.

The bar, enforced

If it isn’t automated, it isn’t enforced.

Work enters through a Definition of Ready and leaves through a Definition of Done — both enumerated gates, not aspirations. Between them, every pull request clears the same seven checks.

Seven required gates, on every pull request — lint, type-check, test and coverage, build, secret-scan across your full commit history, dependency scan, and supply-chain integrity (an SBOM, plus signed build provenance). They are declared by gate ID, so the contract is the gate, never the vendor: the same seven run on GitHub Actions or GitLab CI.

Guardrails & governance

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

• A guard that holds on any harness — a CLI, a git pre-push hook, and a CI gate, verified to block destructive and control-plane actions whichever agent you run. Where your harness supports it, the same rules also intercept in-editor, before a bad write ever lands.

• Every gate can explain itself — ask it why it exists and it tells you, from the CLI: sparkwright explain <topic>. A guardrail nobody can justify becomes bureaucracy.

• Separation of duties, enforced — the merge is bound to the commit that was actually reviewed (shipped == approved), and branch protection carries it to the merge button: the last hand on the code is never the hand that approves it.

• 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 — reversibility being the master variable. Irreversible work (deploying, deleting data, rotating secrets, spending money) stays human-gated at every tier, and a team raises a tier only when its own metrics earn it.

• Ratification — an agent never silently changes the standards, process, or control-plane files that govern it.

The team you get

Four seats, and a governor on the whole run.

A small standing team does the building between the gates — four seats, each with a job another seat cannot quietly absorb, and as many engineers running at once as the work splits into.

Fits your environment

Any stack. Any agent. Any model.

The contract does not know what language you are in. Ten worked stack references ship so you are not starting from a blank file — every one is yours to rewrite, and new-profile.sh generates one for a stack that isn’t here. The only thing that has to pass is conformance.

Cutting across all of them, whatever the language: gitleaks, CycloneDX SBOMs, and signed build provenance. Every reference is held to the same Definition of Done — there is no tiering here, and no second-class stack.

Foundations

The engineering substance, already wired.

None of this is the interesting part of an agentic SDLC. All of it is the part teams skip, and the part an auditor asks for. It ships standard.

Test-driven by default

Tests written with the code, never after — 80% floor, 100% on critical paths.

The whole test pyramid

Unit, property-based, integration, API contract, end-to-end, smoke, load and stress, and security tests against every auth and data boundary — each with a defined point in the lifecycle where it starts being owed.

Evals as tests for AI

Model and prompt quality, regression, and red-team sets — written alongside the feature, run in CI, and gating exactly like tests.

15-factor architecture

Config, backing services, disposability, telemetry — checked for anything deployable.

Ephemeral environments

A throwaway environment per pull request, so reviewers exercise the change running rather than reading a diff. Synthetic data only, never production credentials.

Proportional promotion

Ceremony scales with risk. A change's class is derived at promotion, never self-asserted, and defaults higher when uncertain.

Drift guards

What the docs promise cannot quietly diverge from what the pipeline enforces.

Observability & SLOs

Declared SLOs, wired telemetry, alerts on breach, a tracked error budget.

Disaster recovery, proven

Tiered RTO and RPO, and a restore drill that actually ran.

Progressive delivery

Feature flags, staged rollout, smoke tests, and a rollback path verified before you need it.

Incident response

Severity ladder, on-call ownership, postmortems that exit into tracked work.

Supply-chain integrity

Full-history secret scanning, dependency scanning, an SBOM per build, signed provenance on releases.

AI governance

An AI system card per feature — risk classified, human oversight named — plus prompt-injection defense and schema-validated output.

Methodology as skills

Planning, design, TDD, review, verification, evals and operating ship as executable skills an agent invokes — not prose it might ignore.

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 conformance still passes. That is why nothing here is a catalogue — and why the kit can be built with the very loop it prescribes.

Honesty as a feature

Every control labelled: enforced, advisory, or declared.

Most tools let you assume a green check means more than it does. This one tells you exactly how strong each guarantee is — and draws the safety story as a layered defense rather than a disclaimer.

For engineering leaders & compliance

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

What you actually do with it

A new repo, or the one you already have.

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

   One script turns a throwaway clone into a clean, CI-ready project of your own — with every stack profile still on the table, so your stack stays a decision, not a default.

2. 02

   Let it guide you through Inception (Phase 0)

   Open it in your AI tool and say “Walk me through START-HERE.” A charter, your stack decision recorded as an ADR, CI stood up — and a green pipeline before any feature work, so you build on working software, not an empty repo.

3. 03

   Enter the loop

   Every backlog item runs the loop, and your team holds the three gates.

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

# Your new project
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."

And every function has a door. Product, design, QA, DevOps, security and engineering each start at their own row, with their own artifact — but routing by role changes which document you open, never which gate applies. Non-builders get the rigor carried, not waived.

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.