Skip to content
sdlc-foundry

From a new repo to Kubernetes, declared once.

An agentic SDLC platform. Claude Code agents, slash commands and templates that scaffold your services, render every Kubernetes manifest from one file, and promote releases through reviewed pull requests, with secure defaults you do not have to remember.
Get startedWhy it existsView on GitHub

Watch a real run

Section titled “Watch a real run”

One system, recorded as it happened, in two parts. Part 1 goes from an empty folder to a new endpoint in dev: /system:new creates the repos, /component:spec asks its questions, and /component:ship plans, writes failing tests, builds, merges on green CI and deploys. Part 2 adds a Postgres database and a web UI with one system spec shipped across three repos. Click a chapter to jump.

  • ≈ 85 minof work for both parts, every wait cut
  • 8 + 10questions Claude asked before writing the two specs
  • 3 reposAPI, web UI and gitops, changed by one system spec
  • 1 resourcePostgres, declared once in system.yaml; tasks survive a restart
  • 13real pull requests in the public demo repos

Real runs on the public demo repos demo-taskboard-api, demo-taskboard-web and demo-taskboard-gitops, with every wait cut: about 85 minutes of work shown in 7 (where the time went). Walk through it step by step → what Claude asked, what it did and a link to every pull request.

Platform glue should not cost a small team months

Section titled “Platform glue should not cost a small team months”

The problem

Every service needs CI, a hardened Dockerfile, Kubernetes manifests, secrets, observability, policy and a promotion path. Small teams rebuild it per repo, and LLM agents that improvise it make it inconsistent faster. Read the problem statement.

The approach

Opinionated templates and a tested CLI do the deterministic work; Claude Code agents orchestrate it and ask before anything outward-facing. The GitOps repo owns every manifest, rendered from one declarative file. Read the vision.

The value

One slash command creates a repo that already builds, scans and publishes images. Adding Postgres, secrets or observability is one declaration. Promotion is a pull request you can review. See the client value.

What makes it different

Section titled “What makes it different”

A platform team for a small team: agents build the feature, the platform runs it, and you decide only what matters.

The tools we compared do one half. Spec-driven frameworks and coding agents stop at the code or the pull request; developer platforms and DevOps agents do not build features. sdlc-foundry is both, and that shows in ten things none of them does, ranked by value:

  1. An approved spec ends as a feature running in dev, unattended.Plan, failing tests, code, review, PR, merge on green CI, GitOps deploy and smoke tests; your one decision is the spec.
  2. Acceptance tests are written first and locked.Agents cannot weaken them to get a green build; only you can approve a change.
  3. Every criterion traces to production.From the issue through tests, review and PR to the version running in each environment.
  4. Every step that can be code is tested code.Gates, merges, pins and promotions are a CLI with more than 7,500 tests; agents only judge.
  5. Running systems file their own issues.Red smoke tests, firing alerts, platform failures and a weekly retro end as deduplicated issues.
  6. Prod runs the exact image staging tested.Promotion compares image digests and is a reviewed pull request with its evidence.
  7. One spec ships across several repos.A validated, dependency-ordered plan with the contract between them.
  8. Every generated repo stays current.One command updates every repo built from the templates, one reviewed PR each.
  9. Runs have a budget and stop on repeated failure.Time, agent calls, CI reruns and money per run, and the cost of every feature.
  10. Autonomy is declared per environment, in git.How far an engine may fix a running system, its limits, an undo and a pause; it never promotes forward.

How we compared, the sources, and where others are ahead

A model you can hold in your head

Section titled “A model you can hold in your head”

A system is made of components (services, websites, libraries), the APIs between them and the resources they use. Each part runs once per environment as an instance, and promoting moves a version one cell to the right. Every command is named after the noun it acts on: /system:new, /component:add, /resource:add, /instance:promote.

The todo system. On the left its parts: the todo-web website calls the todo-api service's API, and todo-api uses a postgres database. On the right three environments, dev, staging and prod, each promoting to the next. Every part runs as one instance per environment, showing its version and state; todo-web is not yet in prod. Below, a Spec is shipped by a Run, which lands in dev.
The domain model explains the nouns · open it full size

From an issue to production

Section titled “From an issue to production”

You decide at three points: route an issue, approve its spec, promote to prod. /component:ship runs everything in the green band, and every run, failure and alert comes back as an issue for the next round.

Swimlane map of the delivery flow and its feedback loops: you route an issue and approve the spec, which merges its draft pull request; agents write spec, plan, red tests, code and verification; the `cplat` CLI runs the gates, opens the PR, merges on green, runs the smoke tests in dev and promotes to staging; escalations reach you in the console Inbox; prod promotion stays yours. Run records, the weekly retro, platform failures, red smoke tests and firing alerts come back as deduplicated issues that you route in triage; an optional autonomy engine can open fix pull requests.
How it works explains the map and lists the feedback loops · open it full size

Optional: see it all in one place

Section titled “Optional: see it all in one place”

Everything runs from Claude Code. If you want an overview, /platform:ui opens a local console in your browser. The Inbox shows the few decisions that need you, the Board every change by stage, and System where each part runs at which version. Each decision shows what it changes, the exact command, and the way back; the console stores nothing and every change ends in a pull request. Help, the process and every command are built in: press ? or g.

The console's Board: one column per stage from Issue to Prod; a stopped run says why in one line; decision columns explain what you decide.
The local console · get started

One declaration, a running stack

Section titled “One declaration, a running stack”
applications/shop/system.yaml
# abbreviated: /component:add fills in port, probes, user and resources from the component type's defaults
system: shop
owner: team-shop
components:
  shop-api:
    type: service
    lang: java
    repo: acme/shop-api
    uses: [postgres]
    secrets:
      - name: shop-api-auth
        generate: [JWT_KEY]
    instances: {dev: {}, staging: {}}
  shop-web:
    type: website
    lang: typescript
    repo: acme/shop-web
    env: { API_URL: "http://shop-api" }
    expose: true
resources:
  postgres: {type: database}

From that file the platform renders, per environment: Deployments with numeric non-root users and read-only filesystems, Services, Gateway API routes, an ExternalSecret that creates the JWT key in the cluster, a CloudNativePG database whose connection string reaches shop-api as DATABASE_URL, an OpenTelemetry collector, and Kyverno policies that check all of it. ArgoCD syncs the result. Nothing is applied by hand, and no secret value touches git.

How it works · Configuration reference

What you get

Section titled “What you get”

Scaffold any shape

/component:new creates Python, Java, Go and Next.js services, libraries and the GitOps repo from tested templates, with CI, Dockerfile, devbox recipes and agent instructions. Shapes

Agent pipeline

/component:spec, /component:plan and /component:build go from an approved spec to failing acceptance tests, code that passes them, a check against every criterion and a pull request, with the right agents for each shape. Agents model

GitOps that is generated

/component:add edits one system.yaml; render.py writes every manifest. /instance:promote pins verified image tags per environment. Concepts

Secrets without git

External Secrets Operator creates and reads secrets in the cluster; generated passwords never leave it. Secrets

Resources and observability

Postgres via CloudNativePG; OpenTelemetry collector with optional Grafana dev stack. Resources

Guard rails

Kyverno policies for the platform’s own conventions, checked before merge; pinned Actions, scanned images and SBOMs. Guard rails

Measured, not promised

Section titled “Measured, not promised”
  • 12defects found by running the real chain end to end, each now a regression test or contract check
  • 9 → 3 minmulti-arch Next.js image build (native runners instead of QEMU)
  • −28 %always-on prompt tokens after tightening agent descriptions
  • ≈ 1m40sfrom no cluster at all to a local one with ArgoCD and every app healthy

The numbers come from the platform’s own test application and are listed with their method on the baselines page. Limits are stated plainly on the client value page.

Pick a scenario

Section titled “Pick a scenario”
Ship a system from zeroGitOps repo, services, first environment.
Promote to production safelyVerified tags, one pull request per move.
Add Postgres, secrets, observabilityThree declarations instead of three projects.
Adopt an existing repoBring what you have onto the platform.
Build a feature with agentsFrom a request to a tested pull request.
Harden for an auditShow how supply chain and runtime are controlled.