SmolDLC — Pixelbadger Toolkit Delivery Lifecycle

What is SmolDLC?

SmolDLC is the informal name for the minimal software delivery lifecycle running in this repository. It is small by design: the entire loop is automated after a single human act — writing a GitHub issue.

The chain runs from a GitHub issue all the way to a published NuGet package that anyone can install with a single command. A GitHub Actions workflow detects the new ticket and invokes a Claude Code agent to plan and implement it. A second agent performs a thorough code review. Deterministic CI checks the hygiene. Project automation handles the bookkeeping. No human ever edits a file or sits at a terminal waiting for a build.

This page describes the as-built system as of June 2026. The workflows are in .github/workflows/; the autonomous agent instructions live in CLAUDE.md.

The environment

Every step of this lifecycle runs in the cloud. There is no local machine, no terminal, and no device involvement of any kind. GitHub Actions spins up ephemeral Ubuntu runners on demand, installs the .NET 9 toolchain and the gh CLI, and invokes Claude Code headlessly via the anthropics/claude-code-action GitHub Action.

The only local tooling involved is a web browser to write a GitHub issue. Everything else — code generation, build, test, review, merge, and NuGet publication — happens in cloud runners. That is the "smol" in SmolDLC: a lean process with zero local infrastructure.

The one human prompt

Everything else in this lifecycle is automated. This is the only moment a person needs to act.

Write a GitHub issue

Describe the feature or bug in plain language. Label it status: to-do. That's it — the pipeline takes over from here. A GitHub Actions workflow detects the label, fires a Claude Code agent to plan and implement the work, opens a PR, runs review and CI, and merges automatically when everything passes.

The full pipeline

Each stage below is labelled by who owns it.

Human

Write an issue

Create a GitHub issue describing the desired feature or bug fix. Apply the status: to-do label to mark it as ready.

GitHub Issues status: to-do

↓

GitHub Actions — agent build trigger

Label event fires agent build

Applying status: to-do to an issue triggers the agent-build.yml workflow. It spins up a runner, installs the toolchain, and invokes Claude Code as a headless agent. No terminal, no human waiting.

agent-build.yml on: issues labeled Claude Code CLI

↓

Claude (Sonnet) — autonomous agent

Plan (auto-accepted), then claim, branch, implement, and open a PR

Claude reads the issue and first enters a plan phase: it produces a structured implementation plan covering files to create or edit, test strategy, and version bump rationale. The plan is auto-accepted — no human approval gate — and Claude immediately executes it.

Claude relabels the issue status: in-progress, creates a feature/ branch, writes the code and tests, bumps the version, updates the README, and opens a PR with Closes #N in the body. All via the gh CLI and dotnet — no human file edits.

claude-sonnet-4-6 plan phase (auto-accepted) gh pr create dotnet build / test

↓ PR opened or pushed to GitHub

GitHub Actions — pr-checks.yml

PR checks — three sequential jobs

1 · mechanical-checks

Pure bash, zero API cost. Enforces three invariants: version bumped if production code changed, test file paired with every new component, benchmark updated for watched algorithms.

2 · build-and-test

Restore → build → test → pack. Verifies the branch version is strictly greater than the published NuGet version.

3 · claude-review — runs after jobs 1 & 2 pass

Checks CI status first — a failing check is an immediate blocker. Reads the diff, posts inline comments on specific lines, and submits a formal GitHub review. Behaviour differs by push number:

First push — primary review

Full diff. Evaluates correctness, test quality, architecture (component-per-command pattern), security (prompt injection, path traversal), and README consistency.

Subsequent pushes — follow-up review

Verifies each prior comment was addressed. Checks for new regressions introduced by the fixes. Does not re-review already-approved code.

pr-checks.yml claude-sonnet-4-6 gh pr review --approve / --request-changes

↓ claude-review submits decision

Claude (Sonnet) — autonomous iteration · only when changes requested

Fix & push

When claude-review requests changes, agent-build.yml re-fires automatically. Claude reads every review comment, addresses each one, and pushes a new commit — no human in the loop.

↺ The push re-triggers pr-checks.yml from the top. claude-review now runs in follow-up mode — it verifies prior feedback was addressed and checks for new regressions only. This cycle repeats until the review approves.

agent-build.yml on: pull_request_review (non-approval by Claude) claude-sonnet-4-6

↓ once claude-review approves and all checks are green

GitHub Actions — auto-merge

Squash merge to master

Once the PR has a formal GitHub approval and all checks are green, it is automatically squash-merged via gh pr merge --squash --delete-branch. The feature branch is deleted. No human action required.

auto-merge.yml on: pull_request_review; check_suite gh pr merge --squash

↓ ↓

Two post-merge workflows fire

GitHub Actions — project automation

Close issues & apply release label

Reads the version from the .csproj, creates a release/vX.Y.Z label if it does not exist, then parses the PR body for Closes #N references. Each linked issue gets:

Label status: done added
Label status: in-progress removed
Release label release/vX.Y.Z added
Issue closed with a comment

project-automation.yml on: pull_request closed

GitHub Actions — continuous delivery

Build, pack, publish & release

Triggered by the merge push to master (only when production files changed). Runs a clean Release build and test, then:

Packs the NuGet package
Pushes to nuget.org with --skip-duplicate
Tags the commit vX.Y.Z on GitHub
Creates a GitHub Release with auto-generated notes

publish-to-nuget.yml dotnet nuget push gh release create

↓

Anyone, anywhere

Install the tool

The package is live on NuGet within minutes of the merge. No action required from the repository owner.

$ dotnet tool install --global Pixelbadger.Toolkit

$ pbtk <topic> <action> [options]

Workflow reference

Workflow file	Trigger	Actor	What it does
`agent-build.yml`	Issue labeled `status: to-do`; or PR review submitted by Claude that is not an approval	Claude Sonnet	Invokes Claude Code headlessly. Claude enters a plan phase (auto-accepted), then claims the ticket, creates a branch, implements the feature, and opens (or updates) a PR. Re-runs on review feedback to iterate autonomously.
`pr-checks.yml` — `claude-review` job	PR opened or synchronised (runs after mechanical checks and build pass)	Claude Sonnet	Reviews the full diff on the first push; on subsequent pushes focuses on whether prior feedback was addressed and checks for new regressions. Posts inline comments, then submits a formal GitHub review — approve or request changes. Cancels in-progress runs when a new commit arrives.
`pr-checks.yml` — `mechanical-checks` job	PR opened or synchronised	GitHub Actions (bash)	Deterministic, zero-cost checks: version bump present, test file paired with every new component, benchmark updated for watched algorithms.
`pr-checks.yml` — `build-and-test` job	PR targeting master (production paths only)	GitHub Actions (.NET)	Restore → build → test → pack. Also verifies the branch version is strictly greater than the published NuGet version.
`auto-merge.yml`	PR review submitted (any); or check suite completed	GitHub Actions (bash)	Squash-merges the PR and deletes the feature branch automatically once the PR has a formal GitHub approval and all required checks are green.
`project-automation.yml`	PR merged to master	GitHub Actions (bash)	Parses `Closes #N` from the PR body. Closes linked issues, applies `status: done`, removes `status: in-progress`, and tags with the release version.
`publish-to-nuget.yml`	Push to master (production paths only)	NuGet CD	Clean Release build → `dotnet nuget push` → git tag → GitHub Release with auto-generated release notes.

Kanban labels

Issue state is tracked entirely through GitHub labels. No external project management tool is needed.

Label	Meaning	Applied by
`status: to-do`	Issue is ready to be picked up	Human (when writing the issue)
`status: in-progress`	Claude is actively working on this	Claude agent (on claim)
`status: done`	Issue resolved and merged	`project-automation.yml` (on merge)
`release/vX.Y.Z`	Identifies which package version shipped this work	`project-automation.yml` (on merge)

Cost model

The split between bash and AI is intentional. Mechanical invariants that can be expressed deterministically — version bump presence, test file pairing, benchmark coverage — are enforced in free bash. Both AI steps use Sonnet: the agent build (where implementation quality matters most) and the code review (where a cursory scan is not enough). Using the same capable model for both means the reviewer can evaluate the same kinds of nuance the author intended.

The pr-checks.yml workflow cancels an in-flight review job when a new commit arrives, so a fast iteration cycle does not stack up multiple simultaneous review runs. The agent build workflow uses a per-PR concurrency group on the review-iteration job, so only one agent is ever iterating on a branch at a time.

Install

Once any feature branch merges to master the new version is available on NuGet within a few minutes. Install or upgrade with:

First install

$ dotnet tool install --global Pixelbadger.Toolkit

Upgrade to latest

$ dotnet tool update --global Pixelbadger.Toolkit

Verify

$ pbtk --help

Requires the .NET 9 SDK or Runtime.