From a new repo to Kubernetes via GitOps

A real run on public demo repos (demo-taskboard-api, demo-taskboard-gitops), with every wait cut: about 30 minutes of work shown in 4. The ship run stops once to ask about a formatter change to the acceptance tests; that is part of the run, not edited out.

Formerly claude-platform. Renamed in v3.0.0 to stay clear of a third-party trademark; GitHub redirects the old repository URL. Installed plugins must be reinstalled from the new marketplace: see the changelog and run /platform:doctor.

You describe what you want in Claude Code; the platform scaffolds the repos (Python, Java, Go and Next.js services, plus a GitOps repo), builds and publishes multi-arch images, and renders every Kubernetes manifest from one declarative file in the GitOps repo. Secrets, a Postgres resource, OpenTelemetry observability and Kyverno guard rails are one declaration each; promotion between environments is a reviewed pull request. Everything that can be code is a tested script (cplat), and agents only orchestrate it.

• Documentation site: https://ika100.github.io/sdlc-foundry/ has the vision, the problem statement, client value, usage scenarios and the full user documentation with search.

• Console: /platform:ui opens a local console that shows the system, its process and what needs you (docs/console.md).

• Start here: docs/USER-JOURNEY.md (end-to-end walk-through) and docs/HOW-IT-WORKS.md (diagrams).

• Needs: Claude Code, git, gh, uv, devbox and Docker for local clusters; run /platform:doctor to check.

• Status: used end to end on a real test application; see the changelog and ADRs.

Quickstart

From an empty folder to a feature running in a local cluster. Every step is a slash command in Claude Code except the cluster, which is one devbox recipe.

1. Install and check (once per machine):

   /plugin marketplace add ika100/sdlc-foundry
   /plugin install shared@sdlc-foundry
   /platform:doctor
   

2. Describe the system in taskboard.yaml:

   system: taskboard
   owner: <your-github-user>
   components:
     - {name: taskboard-api, description: Task API, type: service, lang: python}
     - {name: taskboard-web, description: Frontend, type: website, lang: typescript}
   

3. Create it: /system:new taskboard.yaml creates the GitOps repo taskboard and one private repo per component, and opens a pull request that adds the components to system.yaml. Merge it.

4. Run it locally: in taskboard, devbox run cluster-up starts a k3d cluster with ArgoCD and prints the URLs (needs Docker; devbox run cluster-down removes it).

5. Ship a feature: in taskboard-api, run /component:spec "list tasks with due dates", answer its questions, /component:spec approve 001, then /component:ship 001. It plans, writes failing acceptance tests, builds until they pass, opens the pull request, merges it on green CI and waits until dev runs the new image.

The user journey walks through every step in detail, including staging, prod and system-wide specs.

What's here

.
├── .claude-plugin/marketplace.json    Claude Code marketplace catalog
├── plugins/
│   ├── component/                     Component commands (/component:*): new, spec, plan, build, ship, release, add, set, remove ...
│   ├── svc/                           PM, architect, reviewer + Python agents, spec skills
│   ├── web/                           Next.js agents (coder, tester, deployment, observability, release)
│   ├── svc-java/                      Spring Boot agents
│   ├── svc-go/                        Go agents
│   ├── system/                        System specs across repos (/system:new, spec, plan, ship, status)
│   ├── api/ resource/ instance/       /api:list, /resource:add|remove, /instance:promote|secret|verify
│   ├── issue/ platform/               /issue:triage|report, /platform:doctor|update|fleet|runs|retro|ui|release
│   └── shared/                        cplat on the PATH, hooks, quality and security agents
├── shapes.yml                         Shape registry (single source of truth)
├── templates/
│   ├── service-python/                Python service
│   ├── library-python/                Python library (no Docker)
│   ├── web-nextjs/                    Next.js App Router web app
│   ├── gitops-app/                    System-scoped GitOps repo: owns all manifests (ADR-017)
│   ├── service-java/                  Spring Boot 3 / JDK 21 service
│   └── service-go/                    Go (chi) service
├── scripts/                           detect-shape.sh, shapes.py, tests
└── docs/
    ├── USER-JOURNEY.md                End-to-end walk-through (start here to explain the setup)
    ├── AGENTS.md                      Orchestration model
    ├── ADOPTING.md                    How to bring an existing repo onto the platform
    ├── ARCHITECTURE.md                Why the platform looks the way it does
    ├── templates.md                   How to add a new shape
    ├── requirements/                  Platform vision PRD
    └── adr/                           Architecture decision records

Install in a new repo

/component:new payments-api Stripe webhooks to Postgres                        # service in python (default)
/component:new my-saas-web  Marketing site and app --type website              # website in typescript (web-nextjs)
/component:new billing      Billing service --type service --lang java        # or --lang go; --type library
/system:new my-saas.yaml                                                       # a system: its gitops repo plus every component repo

/component:new resolves the shape from shapes.yml (type and language) and:

1. Runs copier copy from templates/<shape>
2. git init + commit
3. gh repo create --private under your GitHub account
4. gh repo edit --add-topic deployable-service (deployable shapes only) so ArgoCD discovers it

See docs/requirements/platform-vision.md §7 for the end-to-end system flow (/system:new → components → /component:add → /instance:promote).

Install in an existing repo

/plugin marketplace add ika100/sdlc-foundry
/plugin install component@sdlc-foundry        # + web / svc-java / svc-go / system as your shapes need
/plugin install svc@sdlc-foundry
/plugin install shared@sdlc-foundry

…or pre-wire it by adding to .claude/settings.json:

{
  "extraKnownMarketplaces": {
    "sdlc-foundry": {
      "source": { "source": "github", "repo": "ika100/sdlc-foundry", "ref": "main" }
    }
  },
  "enabledPlugins": {
    "component@sdlc-foundry": true,
    "svc@sdlc-foundry": true,
    "shared@sdlc-foundry": true
  }
}

See docs/ADOPTING.md for the full migration guide.

Slash commands

Command	Plugin	Purpose
/component:spec <desc>	component	Feature spec with acceptance criteria AC-<NNN>.<n>; asks you its open questions; approve <id>, --amend <id>, --from-plan for multi-repo plans; index lists specs with the next step, migrate converts legacy stories
/component:plan <id>	component	Architect: design.md + plan.md for an approved spec, checked by cplat spec
/component:build <id>	component	Failing acceptance tests → parallel coders → quality ‖ tests ‖ security → reviewer verifies the spec → image → PR (shape-aware, resumable)
/component:ship <id> [--no-merge]	component	Unattended: plan → build → PR → merge after green CI → wait until dev runs it; resumable, kept going by the Stop hook (ADR-028)
/component:verify [<id>]	component	Check code against a spec
/component:fix <desc>	component	Lightweight and bug fixes: coder → quality → tester → PR
/component:release	component	Quality gate → test gate → security gate → version bump → tag → close issues
/component:check	component	Read-only quality + security audit
/component:new <name> <desc> [--type T --lang L]	component	Bootstrap a new component repo (shapes.yml resolves type and language to a template; default service in python), with main protected by its CI checks
/component:add|set|remove <component...>	component	In a system's gitops repo: declare components in system.yaml; set changes env, exposure, resources or replicas of one already declared
/system:new <manifest>	system	A whole system: its gitops repo plus every component repo

Every generated repo also checks its specs in CI (warn-only specs workflow, devbox run spec-check): all specs valid, and every criterion of a spec being built named by a test. Unattended runs (claude -p, /loop, /schedule): see ADOPTING.md → Unattended runs.

Updates

• Agent / command changes: bump the version in plugins/<name>/.claude-plugin/plugin.json + .claude-plugin/marketplace.json, tag, and push. Consumers run /plugin marketplace update.
• Template changes: edit templates/<shape>/, commit, tag. Consumers run /platform:update (optionally --ref <tag>) in their repo: it re-applies the template on a review branch and leaves project-owned files alone.

These two channels are independent — you can ship new agents without forcing all repos to run /platform:update, and vice versa.

Using it for your own organisation

The marketplace is published as ika100/sdlc-foundry and installs as sdlc-foundry. Generated repositories use the github_org you are asked for (it defaults to the account gh is logged in as), so nothing in the output is tied to this repository's owner. To run your own variant, fork the repository, change the owner in .claude-plugin/marketplace.json, and add your fork with /plugin marketplace add <you>/sdlc-foundry. Code generated from the templates is yours; this repository's license does not apply to it.

Disclaimer, privacy, AI-assisted development

• Not affiliated. sdlc-foundry is an independent open-source project, not affiliated with, sponsored by or endorsed by Anthropic or the owners of the other names it mentions (see THIRD_PARTY_NOTICES.md). Claude and Claude Code are trademarks of Anthropic, PBC.
• Non-commercial. sdlc-foundry is a private, non-commercial hobby project: no paid services, sponsorship, advertising or business stands behind it or its name.
• No warranty. The software is provided "as is" under the Apache License 2.0 (sections 7 and 8). Review what it generates (manifests, workflows, policies) before it touches a production cluster; the platform never runs kubectl apply on its own, and humans bootstrap real clusters.
• No telemetry. The plugins and the cplat CLI send nothing anywhere on their own. Network access is what you would expect: git/gh against GitHub, package registries, GHCR. Generated applications export telemetry only to the endpoint you configure. /issue:report shows you the full text first and files it only after your OK; issues on this repository are public, and the draft already has tokens, e-mail addresses and home-directory names removed.
• AI-assisted. Much of this repository was written with Claude Code and reviewed, tested and committed by the maintainer (commits carry a Co-Authored-By trailer). Licensing is the maintainer's: AI-generated parts may be subject to limited copyright protection depending on jurisdiction.

Contributing, security, support

• CONTRIBUTING.md: how to set up, which checks to run, PR rules. Code of Conduct.
• SECURITY.md: report vulnerabilities privately. SUPPORT.md: where to ask questions.

Reporting problems

If something in a template, script, command or agent misbehaves, run /issue:report in Claude Code. It drafts a GitHub issue with your platform and plugin versions, OS, tool availability and the error output, removes tokens, e-mail addresses and home-directory names, shows you the draft and files it only after your OK (without gh it prints a prefilled link). The agents suggest it themselves when a step fails for a platform reason. You can also open an issue by hand: new issue.

License

Apache License 2.0. Copyright 2026 Eike Hensler.