devex

z5labs developer-experience monorepo. It bundles two things:

• A collection of Dagger modules under daggerverse/ — reusable, composable building blocks for CI pipelines and local development.
• A Claude Code plugin marketplace that ships the same AI tooling we use in-repo, installable into anyone's Claude Code.

Install any module into your own Dagger project with:

dagger install github.com/z5labs/devex/daggerverse/<module>

See daggerverse/CLAUDE.md for module conventions (function caching, code generation, tests layout).

z5labs is the opinionated pipeline the rest of these modules are wired into. Everything hangs off one entry point:

# check a source tree — gofmt, go vet, golangci-lint, go test -race
dagger -m github.com/z5labs/devex/daggerverse/z5labs call go --source=. ci

# build a multi-arch app, then ship it
dagger -m github.com/z5labs/devex/daggerverse/z5labs call \
  go --source=. \
  app --version=v1.2.3 --platforms=linux/amd64,linux/arm64 \
  with-registry --address=ghcr.io --username="$GITHUB_ACTOR" --auth=env:GITHUB_TOKEN \
  with-oidc --request-url="$ACTIONS_ID_TOKEN_REQUEST_URL" --request-token=env:ACTIONS_ID_TOKEN_REQUEST_TOKEN \
  publish --repositories=z5labs/hello

publish returns one digest-pinned reference per published tag, and every published digest carries an SPDX and a CycloneDX document per platform plus a signed SLSA provenance statement — a publish that cannot produce provenance fails rather than shipping without it. app also exposes container and containers, which return the very images publish pushes, so a check can run against the artifact that ships rather than against a rebuild of it.

The version is yours and is validated as an image tag; the commit comes from HEAD and from nothing else, so two builds of one (commit, version) pair are byte-identical. Every image carries one standardized PATH with /usr/local/bin on it for an extension's executables — see the module's package doc, which records why both values are fixed.

This repo is also a Claude Code plugin marketplace named z5labs-devex. Add it to your Claude Code:

/plugin marketplace add z5labs/devex

Then install a plugin:

/plugin install daggerverse@z5labs-devex

See plugins/README.md for the plugin layout. To develop against an unmerged local checkout, run /plugin marketplace add . from the repo root instead.

Every module has a sibling tests/ module whose suite is a Dagger check. .github/workflows/ci.yml runs them through daggerverse/workspace-ci, which plans each change: it diffs the commit range, works out which modules the change could reach, and returns one leg per check to run — skipping those a previous run already proved good — each routed at the module that owns it. The ci/ module holds only the three checks that must run whatever changed.

The Actions half of that — engine image caching, the dagger/checks fan-out, recording a pass, and the single status check branch protection requires — is .github/workflows/change-aware-ci.yml, a workflow_call workflow anyone can use. ci.yml is a caller of it like any other repository would be, differing only in pointing at the in-tree planner so that a change to the planner is planned by the changed planner. Adopting it elsewhere is one uses::

jobs:
  ci:
    uses: z5labs/devex/.github/workflows/change-aware-ci.yml@main
    secrets: inherit

with ci / CI Gate as the required check. See daggerverse/workspace-ci/README.md for the inputs and the permissions a caller needs.

The manually-triggered update-dagger.yml workflow bumps the Dagger pin across every module and opens a PR. Its PR edits change-aware-ci.yml (a workflow file), which the default GITHUB_TOKEN may not push, so it authenticates with a dedicated update-dagger GitHub App via two repository secrets:

Install the App on this repo with Contents, Pull requests, and Workflows all set to Read and write (Workflows: write is what GITHUB_TOKEN can't have). The short-lived token is minted per run, so nothing needs rotating.

MIT © Z5labs and Contributors