Governed Agent SDLC
Ship with agents. Keep humans in control.
Project website · Architecture · Workflow · CLI reference · Adoption guide
Governed Agent SDLC is a cross-platform toolkit for AI coding agents. It separates a tool-neutral workflow kernel from project profiles and vendor adapters, so the same approval, security, artifact, review, and QA rules can be applied to different technology stacks.
The project is intentionally human-in-the-loop. It helps agents work predictably; it does not grant an AI permission to approve, merge, release, or retrieve credentials.
Alpha status: the core workflow, the Claude Code, Codex, OpenCode and Antigravity adapters, deterministic safety hooks, cross-platform validation, and PyPI Trusted Publishing are available. Interfaces may still evolve before 1.0.
What is included
- Six tool-neutral roles: architect, planner, developer, reviewer, QA, and publisher.
- A structured artifact lifecycle with explicit approval evidence and supersession.
- A TOML project manifest for repository layout, profiles, commands, and protected areas.
- A dependency-free Python CLI:
init,generate,update-hooks,validate,doctor, and artifact commands. - Claude Code agent generation and safety hooks.
- Native Codex project configuration and governed role generation.
- OpenCode subagents with a guard plugin, and Antigravity agents with a guard hook (OpenCode adapter, Antigravity adapter).
- Stack profiles for generic repositories, Python, .NET, Nuxt, Node.js and TypeScript, Java (Spring Boot on Maven), Flutter, Go, Rust, Kotlin (Gradle), and PHP (Composer).
- Cross-platform tests and reusable GitHub Actions.
Quick start
Requires Python 3.11 or newer. Install the published package:
python -m pip install governed-agent-sdlc
agentkit --version
agentkit doctor
Upgrade an existing installation to this release:
python -m pip install --upgrade governed-agent-sdlc==0.8.0
agentkit --version
agentkit update-hooks
agentkit generate claude-code --force
agentkit doctor
Version 0.8.0 adds stack profiles for Go, Rust, Kotlin, and PHP for agentkit init --profile, and
GitHub-verified artifact approvals: with [review].approval_mode = "github" (or artifact transition ... approved --approval-mode github) the evidence must be a review or comment on GitHub
by a human owner, member or collaborator, checked through gh. Approvals made in the default local
mode are now marked verification = "unverified"; approvals recorded earlier stay valid. Upgrading
the Python package does not overwrite project configuration, and that includes the guards under
hooks/, so run update-hooks to get the guards this version ships, and only then regenerate the
adapter (generate codex --force for Codex): regenerated settings can name a guard an older
project does not have, and a missing guard file fails every tool call it guards closed. See
release notes for the full changes.
For local development:
python -m pip install -e .
agentkit doctor
agentkit validate
python -m unittest discover -s tests -v
Initialize another project:
agentkit init ../my-project --name my-project --adapter claude-code
cd ../my-project
agentkit doctor
Use --format json with validate, doctor, generation, migration, and artifact inspection
commands for automation. Preview additive initialization or adapter generation with --dry-run.
Initialization is additive: existing AGENTS.md, manifest, core policy, hook, and adapter files are
not overwritten. A fresh project receives the stack profiles and a minimal AGENTS.md so
generated roles always have the instructions they reference.
Name the stack when you initialize, and the manifest starts with its profile and its commands instead of the generic one:
agentkit init my-service --profile java
agentkit init my-app --profile flutter --profile node # several: the first to name a command wins
The profiles are generic, python, dotnet, nuxt, node, java, flutter, go, rust,
kotlin and php. The commands a profile gives are a starting point written into [commands] of
the manifest: a Gradle project replaces the Maven ones of java, and flutter names no build
because which artefact to build is the project's to say. kotlin runs ./gradlew check, which
runs ktlint or detekt only when the build applies them, and php names composer validate and
PHPUnit; a project using PHPStan or PHP CS Fixer adds those commands. The go format check is a
POSIX shell line, because gofmt -l lists files without failing.
Create and move a governed artifact:
agentkit artifact new spec add-search
agentkit artifact transition docs/agent/specs/<file>.md awaiting_approval
agentkit artifact transition docs/agent/specs/<file>.md approved \
--approved-by "github:maintainer" \
--evidence "https://github.com/org/repo/issues/123#issuecomment-..."
An agent must never supply approval metadata for itself. The human supplies the actor and durable
evidence, and CI validates that the fields exist. By default ([review].approval_mode = "local",
as for review approve) the approval is recorded as given and marked
verification = "unverified". With approval_mode = "github", or --approval-mode github on the
command, the CLI checks through gh that the review or comment URL is in this repository and was
written by a human collaborator, and records that login (github:LOGIN) as the approver; see
artifact approval verification.
Project manifest
agentkit.toml or .agent/project.toml is the source of truth:
version = 1
protected_areas = ["authentication", "database-schema", "billing"]
[project]
name = "commerce"
topology = "monorepo"
[[repositories]]
id = "backend"
path = "services/api"
profiles = ["dotnet"]
[[repositories]]
id = "frontend"
path = "apps/web"
profiles = ["nuxt"]
[workflow]
require_spec = true
require_plan = true
require_review = true
require_qa = true
Repository paths are resolved from the manifest and must remain inside the project root. No machine or user-specific absolute path belongs in committed configuration.
Validation is strict and dependency-free. It rejects unsupported manifest versions and topology,
missing workflow flags, invalid field types, duplicate repository identities or paths, escaping
repository paths, and profile capabilities that are not provided by profiles/, adapters/, or
the repository's GitHub integration.
Artifact validation also checks kind-specific parent gates, approval history for approved/active/
completed/superseded states, repository and protected-area references, timestamps, supersession,
and metadata types. Artifact creation refuses filename collisions. Transitions made through the CLI
are restricted to Markdown files below the active project's docs/agent/ directory.
Design boundaries
core/is vendor-neutral and is the only source of workflow meaning.profiles/contain stack-specific commands and exclusions.adapters/and generated tool files translate the core; they do not redefine it.hooks/enforce deterministic safety rules. Prompts explain behavior but are not security controls.- Hook input is fail-closed: malformed input is denied, as are credential paths/environment dumps, force pushes, and direct protected-branch refspecs.
- Hooks also hold the workflow: a role is spawned only from artifacts that passed their gate, and a role that does not own a task file may change only its completion evidence.
docs/agent/holds project artifacts, not hidden agent memory.
See Architecture, Workflow, and Adopting Governed Agent SDLC.
Maturity
The project is an alpha. Claude Code, Codex, OpenCode and Antigravity consume the same core contracts rather than introducing parallel policy files. The credential and git guards hold on all four; the role write scope and the role gate are enforced on Claude Code only, because only its hook input says which role is acting.
See CHANGELOG.md for release history and upgrade notes.
License
MIT. See LICENSE.
Metadata
Release files for governed-agent-sdlc 0.8.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| governed_agent_sdlc-0.8.0.tar.gz | 204.5 kB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| governed_agent_sdlc-0.8.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 304.4 kB
Release files / governed_agent_sdlc-0.8.0.tar.gz
| Download URL | governed_agent_sdlc-0.8.0.tar.gz |
|---|---|
| Size | 204.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
b8d5ad084421c12b2e262441e93a780291adbe329c5ffe88a060c182b6edd456
|
|
BLAKE2b-256 checksum How to use checksums |
51ee89f8a46d1a4360da28922264c3f9a12a5185e3d00622232ccdfe0896890e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 20, 2026.
Transparency logRelease files / governed_agent_sdlc-0.8.0-py3-none-any.whl
| Download URL | governed_agent_sdlc-0.8.0-py3-none-any.whl |
|---|---|
| Size | 99.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
edc3f2b0b02b96833b45060e207ba5e1af791724000247e2d4019d120b3347fb
|
|
BLAKE2b-256 checksum How to use checksums |
99688d75b651fd50f96759ea7ee14d0ef94c4b5362c6241f562e8a51dcc01401
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 20, 2026.
Transparency logSecurity for governed-agent-sdlc 0.8.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for governed_agent_sdlc-0.8.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 20, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.