Autonomous Dev Team

A fully automated development pipeline that turns issues into merged pull requests — no human intervention required. It scans for issues labeled autonomous, dispatches a Dev Agent to implement the feature with tests in an isolated worktree, and hands off to a Review Agent for code review with optional E2E verification. The entire cycle runs unattended on a cron schedule.

• Code hosts: GitHub and GitLab (gitlab.com or any standard self-managed instance) via pluggable provider seams — see GitLab support.
• Agent CLIs: Claude Code, Codex CLI, Kiro CLI, opencode, Cursor Agent, Antigravity CLI (agy), and most CLIs with a -p <prompt> non-interactive flag — see docs/agent-clis.md.

Dev and review sessions can retain verified lessons across retries. After a confirmed merge, useful updates go to the nearest AGENTS.md, docs/troubleshooting/, or docs/lessons-learned/ in a separate documentation commit and PR. Existing facts are revised rather than duplicated. No new or corrected information means no documentation change, empty commit or extra model call. Machine details and credential references stay in ignored, mode-600 AGENTS.local.md; credential values remain in their existing private sources.

The Stop hook checks an assessment, which may explicitly report no update. Read the recording and retry reference for interactive use. After upgrading skills, re-run the project bootstrap and your agent's hook installer to register the new Stop hook.

npx skills add zxkane/autonomous-dev-team

Works with Claude Code, Cursor, Windsurf, Antigravity, Kiro CLI, and 40+ agents. After installing, follow docs/installation.md for the post-install wiring (symlinks, plugins, autonomous.conf, labels) — it includes a copy-paste prompt that lets your AI agent drive the whole setup.

1. Clone and configure:

   gh repo create my-project --template zxkane/autonomous-dev-team
   cd my-project
   cp scripts/autonomous.conf.example scripts/autonomous.conf
   # Edit autonomous.conf — see docs/installation.md Step 4 for every key.

2. Create the pipeline labels:

   ( source scripts/autonomous.conf && bash scripts/setup-labels.sh "$REPO" )

3. Schedule the dispatcher tick. Anything that can run a shell command on a cadence works:

   Host	When to use	Tick command
   OpenClaw (recommended)	Purpose-built skill runtime	openclaw run skills/autonomous-dispatcher/SKILL.md
   Plain cron	Zero extra infra	bash skills/autonomous-dispatcher/scripts/dispatcher-tick.sh
   GitHub Actions schedule / any scheduled runtime	Managed infra	same tick script (or dispatcher-multi-tick.sh for multi-project)

   */5 * * * * cd /path/to/project && bash skills/autonomous-dispatcher/scripts/dispatcher-tick.sh

   The tick script is host-agnostic — it needs only jq, a code-host credential, and a reachable autonomous.conf. The agent CLI is invoked by the wrapper the tick spawns, not by the tick itself.

4. Create an issue with the autonomous label and watch the pipeline work — the dispatcher spawns agents, tracks progress via labels, and merges the PR when review passes.

Issue (autonomous label)
   │
   ▼
Dispatcher (cron tick) ──▶ Dev Agent ──────────▶ Review Agent
   scan + dispatch          worktree + TDD         find PR + review
   concurrency + retry      implement + test       optional E2E verify
                            open PR                approve + merge

Issues progress through labels managed automatically by the agents:

autonomous → in-progress → pending-review → reviewing → approved (merged)
                                                 │
                                                 └─→ pending-dev (loop back if review fails)

With the no-auto-close label, the PR is approved but not auto-merged — the repo owner is notified instead.

Every issue/code-host operation routes through pluggable provider seams (ISSUE_PROVIDER / CODE_HOST): abstract verbs with per-provider leaves, proven by a provider-parameterized conformance suite. The normative contract lives in docs/pipeline/provider-spec.md.

Multi-agent review (AGENT_REVIEW_AGENTS), external review bots (REVIEW_BOTS), and per-CLI configuration are covered in docs/agent-clis.md.

Set the shared dev/review policy in the project's scripts/autonomous.conf:

REVIEW_BLOCKING_SEVERITY="P1"

Lower-severity findings remain visible as advisories. Dev fixes blockers and records advisory dispositions; advisory notes alone do not restart the review loop. Unknown finding severity blocks until classified. Invalid configuration warns and uses P3. Required acceptance criteria, security checks, CI/E2E, and merge gates remain mandatory. Structured artifacts are filtered per finding before determining whether remaining blockers need dev or a maintainer.

Dev runs feasible local tests and relevant lint/typecheck/build before pushing, records commands and results in the PR, and documents checks that require CI. Independent simplification and correctness review may share one pass on the same tree before push. Fixes are batched, affected checks rerun, and subsequent reviews focus on changes and affected contracts. Final E2E runs once in the review wrapper when configured; reviewers reuse evidence only for the same HEAD, environment, and scenario coverage. Required verification is never marked complete based on a skipped or unavailable check.

For this repository, run bash tests/run-unit-tests.sh locally and in CI. Its bounded parallel pool preserves the full unit suite and reports failing logs. Set UNIT_TEST_JOBS to tune concurrency for the host. This removes the former serial CI loop without changing test coverage or runner selection.

Both provider seams accept gitlab: issues and merge requests on gitlab.com or any self-managed CE/EE instance whose API speaks standard PAT auth against /api/v4.

# scripts/autonomous.conf
ISSUE_PROVIDER="gitlab"
CODE_HOST="gitlab"
GITLAB_HOST="gitlab.example.com"          # default gitlab.com
GITLAB_TOKEN="glpat-…"                    # PAT / project / group token, scope `api`
GITLAB_PROJECT="group%2Fsubgroup%2Fproject"   # URL-encoded namespace/name

• Setup guide: docs/gitlab-setup.md — token creation, self-hosted host config, the auth model, and verification steps.
• Custom auth gateways (SSO-cookie instances, mTLS, forked transports): supported out-of-tree via GITLAB_TRANSPORT_HOOK — an operator-owned file that replaces the single HTTP primitive while the library keeps pagination, backoff, and fail-closed semantics. Contract in docs/pipeline/provider-spec.md §transport.
• Capability differences vs GitHub (declared in providers/chp-gitlab.caps, callers branch automatically): no external review bots (review_bots=0), no REST "request changes" object (findings post as comments + labels), auto-close fires only on merge to the default branch, and agent tokens are convention-contained (GitLab has no GitHub-App equivalent — see docs/security.md).

GitHub remains the default: an existing conf with no provider keys set behaves byte-identically.

Designed for private repositories and trusted environments. The pipeline executes issue content as agent instructions — in a public repo that is a prompt-injection surface. Read docs/security.md for the risk model, per-environment recommendations, the mitigation checklist, and the token posture per code host. Minimum for public repos: restrict who can apply the autonomous label, and use no-auto-close so merges stay manual.

Beyond autonomous mode, the same hooks enforce a TDD workflow for interactive coding-agent sessions:

Design Canvas → Worktree → Test Cases → Implement → Unit Tests
   → code-simplifier → commit → pr-review → push → CI → E2E

• Step-by-step workflow: CLAUDE.md
• Hook reference + state manager: skills/autonomous-common/hooks/README.md
• Cross-agent hook support (Kiro, Cursor, …): docs/cross-agent-hooks.md

This template is based on the Claude Code memory and hook system implementation from Openhands Infra.

MIT License