Design partners · limited spots

AI-driven SDLC, under strict human governance

Hand it a ticket from whatever tracker you use — or a single line of plain English. It elaborates, asks the clarifying questions, then designs, implements, tests and deploys. From one change to an entire product, through a pipeline you shaped, with a human at every gate and a complete record of who decided what, when and why.

12phases, run the ones you need
5human gates you can't skip
7AI tools it plugs into
0dependencies to install
One unit of work, end to end

A ticket in. Shipped, audited software out.

You trigger one command. Zyroflo drives the whole lifecycle — and stops for a human at every gate. Here is one ticket, start to finish. The same loop delivers a fix, a feature, a release, or an entire product.

▶
Trigger

You hand it the work

A ticket ID from whatever tracker you run — Jira, Salesforce, StarTeam, Azure DevOps, ServiceNow — or one line of plain English. Zyroflo pulls the item and reads it.

/sdlc PROJ-482
P0
Intake

It elaborates the requirement

Turns a one-liner into a full statement of what is being asked.

00-intake.md
P1
Requirements

It asks the clarifying questions — and waits

Scope, data, errors, performance. Questions first, then testable acceptance criteria.

10-requirements.md
◆ G1 · scope
P3
Design

It designs the change

Options with trade-offs and a recommendation, against your standards.

30-design.md
◆ G2 · design
P4
Implementation

It writes the code

The agent's changes, scoped to the approved design.

40-impl/
◆ G3 · changes
P5
Test & review

It tests and reviews

Every acceptance criterion verified, the diff reviewed against the rubric.

50-tests.md
◆ G4 · merge — hard, always
P9
Deploy

It ships

Runs your deploy command, and closes out with the record intact.

90-deploy.md
◆ G5 · deploy
The same lifecycle ships a one-line fix or an entire product. Run it per change, per release, or point it at a greenfield build and drive the whole thing — the phases and the gates don't change, only how many times you go round.

PROJ-482 is an illustrative ticket reference. Every phase and artifact shown is exactly what Zyroflo produces.

One command. Any repo.

Drop it into the repository you already have

No packages, no network, no API keys. One command scaffolds the whole lifecycle and writes itself into the AI tool your team already uses.

install once
# scaffold the pipeline into any repo
python sdlc-init.py

# it writes a skill for whatever
# AI tool the repo already uses
✓ .sdlc/profile.yml
✓ .sdlc/policy.yml
✓ ledger check for CI
run per task
# a ticket from any tracker…
/sdlc PROJ-482

# …a plain-English requirement…
/sdlc "add SSO to the portal"

# …or an entire product build
/sdlc "build the billing service"

# resume anywhere, any tool
/sdlc resume
intakerequirements◆design◆implementation◆testreviewtriage◆releasedeploy◆verifycloseout

The 12-phase superset. The solo default lights 8; a regulated estate runs all twelve — including release, deploy and verify, which is what shipping a whole product takes. Connected to your tracker — Jira, Salesforce, StarTeam, Azure DevOps, GitHub, Linear — it pulls the item straight from there and posts the close-out back.

Enforced, not advisory

A gate you can skip is a suggestion

The gates are the whole point. AI proposes; a human disposes — and the pipeline can't route around it.

Five human gates

Scope, design, the agent's changes, the merge, and the deploy. At each one the AI stops and waits for a person to approve or reject.

The merge gate is hard, always

G4 cannot be softened in any configuration. Reject it and the pipeline loops back and tries again — it does not move until you say so.

Add a gate anywhere

Put a hard human stop after any step you like. Your organisation sets floors a project can only tighten, never loosen.

Core steps can't be deleted

Intake, implementation, review and closeout are locked. Try to drop one and the harness refuses it by name.

CI checks the ledger at merge

Continuous integration refuses a merge if a gate the run reached was never approved — or was approved over code that has since moved.

Tamper-evident by design

Every decision is a hash-chained line inside your own repository, using only the standard library — so tamper-evidence costs no dependencies.

Any model, any vendor

The pipeline is yours to shape

Which steps run, where the humans stop, and which model does which job — all in one file, or a wizard, or just in chat.

Customising the pipeline: adding a gate and removing a step SHIPS BY DEFAULT intake requirements design implement test deploy G2 G3 G4 AFTER YOUR EDITS intake requirements design implement test deploy + gate added step removed gemini-2.5 gpt-5 claude-opus-5 Same superset. Your steps, your gates, your model on each one.
.sdlc/profile.yml
# pick the model per step
models:
  requirements: openai/gpt-5
  design:       google/gemini-2.5
  review:       anthropic/claude-opus-5

# delete a step, add a gate
phases: [intake, design, …]
extra_gates: [test]
providers.toml
# providers are data, not code —
# add one by adding a table
[openai]
protocol = "openai"
key_var  = "OPENAI_API_KEY"

[anthropic]
protocol = "anthropic-messages"
key_var  = "ANTHROPIC_API_KEY"
The harness itself never calls a model. Your keys, your providers, your spend. Zyroflo governs the work — it never does the spending, and it never phones home.
Proof, not promises

Every decision leaves a receipt

Who decided, when, and why — all answerable, as the work happens, in your own repository.

.sdlc/runs/<run-id>/events.jsonl
// each finished step — one append-only, hash-chained line
{ "step": "design", "actor": "model-endpoint",
  "provider": "google", "model": "gemini-2.5",
  "tokens": {"input": 8140, "output": 1920}, "cost": 0.031,
  "duration_ms": 42180, "outcome": "ok",
  "artifacts": ["30-design.md"], "prompt_sha256": "9f2c…" }

// each gate — who, when, and how long it waited on a human
{ "gate": "G2", "decision": "approved", "approver": "a.rahman",
  "waited_ms": 5400000, "ledger_hash": "c07b…" }
See the whole estate

From one repository to all of them

Those receipts become a dashboard — and roll up across every repo you run, without the harness ever holding a connection string.

One offline file

A single dashboard.html — no CDN, no third-party JavaScript. Tabs for runs, gates, models, rework. It opens on a locked-down laptop.

Query it, or read it in Grafana

Export to SQLite and Grafana reads it directly — a stable, documented column dictionary and a ready-to-import dashboard.

Roll up across the estate

Merge many repos into one store, de-duplicated on the event hash, grouped by the owner and criticality you set at install — identities pseudonymised if your policy says so.

The destination is a directory, never a service. Zyroflo writes files to a path; your own pipeline collects them. And a number nobody could measure is never drawn as zero — it shows its reason.
The four numbers that matter

Governance you can put on a board slide

Zyroflo measures the DORA four — lead time, deploy frequency, change failure rate, time to restore — plus the two most teams can't see at all: rework and how long work sat waiting on a human.

◆ Illustrative dashboard · sample data, not a performance claim
Lead time 6.2 days ↓ from 10.5
Change failure rate 4.1% ↓ from 11.0%
Rework per change 0.4× ↓ from 1.1×
Gate wait (human) 9.1 hrs ↓ from 31.6

Why it moves: the next phase starts the moment a gate clears — and the waiting itself is measured, so the bottleneck stops being invisible.

Why it moves: nothing merges without its gate approved over the current code. CI refuses the rest, so defects are caught at review, not in production.

Why it moves: the clarifying questions happen at requirements — before design, not after implementation, when the fix costs two orders of magnitude more.

Why it moves: machine time and human time are recorded separately, so you can finally tell a slow pipeline from a slow approver.

Read those figures honestly: they are sample data from a demonstration run, shown to illustrate what the dashboard reports. They are not an average, not a benchmark, and not a promise. Zyroflo's claim is narrower and firmer — it measures these numbers on every run, in your own repository, so you can hold us to yours.

What's real today

Built, tested, and looking for design partners

Zyroflo is the delivery discipline behind our own work, becoming a product. We're opening it to a small first cohort to shape it with us.

Resources

See it, then read the story

A short walkthrough of one ticket end to end, and the deck we take design partners through.

Design partners · limited spots

Shape it with us

We're opening Zyroflo to a small first cohort of design partners ahead of general availability. Come in now and you're not just a user — you're shaping how AI-driven delivery gets governed.

◆ Design-partner cohort

Build your governance model into the product

We're keeping the first cohort deliberately small so every partner gets real attention. In exchange for working with us to make Zyroflo better, design partners get:

  • Direct influence on the roadmapYour steps, your gates, your governance model shape what we build and prioritise next.
  • Hands-on onboardingA direct line to the founders and help wiring Zyroflo into your repos and your models.
  • First accessRun it on your real work before general availability, and help set the bar.
  • Founding-partner termsWe'll recognise the partners who came in early and shaped the product with us.