Python orchestrator for autonomous Claude Code agents in Docker
Project description
pycastle
pycastle is a Python orchestrator for autonomous Claude Code agents running inside Docker containers. It is inspired by sandcastle — Matt Pocock's original project — and brings the same multi-agent, worktree-based workflow to a pip-installable Python package with configurable prompts, Dockerfile, and environment.
Installation
pip install pycastle
Prerequisites
- Python 3.11.3 or later
- Docker (daemon must be running)
- A valid
ANTHROPIC_API_KEYenvironment variable (or a.envfile in your project root) - A GitHub repository with a
GH_TOKENenvironment variable that has issue read/write access
CLI Commands
pycastle init
Copies the default pycastle/ configuration directory into your project root. This directory contains the Dockerfile, config.py, and prompt templates (plan-prompt.md, implement-prompt.md, review-prompt.md, merge-prompt.md, CODING_STANDARDS.md) that drive the agents. Run this once per repository, then customise the files to suit your project.
pycastle init
pycastle build
Builds the Docker image defined in pycastle/Dockerfile. Pass --no-cache to force a clean build. You must rebuild whenever you change the Dockerfile or install new dependencies.
pycastle build [--no-cache]
pycastle labels
Creates the standard label set on your GitHub repository. These labels drive the triage workflow that feeds issues into the agent pipeline (see The ready-for-agent label below).
pycastle labels
pycastle run
Runs the full agent pipeline. The pipeline iterates up to max_iterations times, each time picking up whatever ready-for-agent issues remain open. Progress is streamed to your terminal in real time.
pycastle run
How the pipeline works
Each iteration of pycastle run moves through five phases in order.
1. Pre-flight
Before any agent work starts, pycastle runs the configured preflight checks inside Docker (default: ruff check ., mypy ., pytest). If all checks pass the pipeline continues normally.
If a check fails, a preflight-issue agent is spawned. It analyses the failure and creates a GitHub issue describing what needs to be fixed. The issue is labelled either ready-for-agent (the fix can be automated) or ready-for-human (a human must intervene). If the issue is ready-for-human, pycastle exits immediately so you can investigate. If it is ready-for-agent, the issue is queued as the sole work item for this iteration and the pipeline continues.
You can skip preflight entirely by setting skip_preflight = True in pycastle/config.py — useful while the codebase is still being bootstrapped.
2. Planner
The planner agent reads all open GitHub issues labelled ready-for-agent. It evaluates dependencies (issues can declare blocked by #N in their body), filters out issues that are still blocked, and emits a <plan> JSON block listing the unblocked issues to tackle this iteration. Only the issues selected by the planner proceed to the next phase.
3. Implementer(s)
For each planned issue, pycastle spawns an implementer agent in a dedicated git worktree on a branch named pycastle/issue-<N>. The agent reads the issue, writes the code, and continuously runs the implement checks (ruff check --fix, ruff format --check, mypy ., pytest by default) until they pass. When the agent is satisfied it emits <promise>COMPLETE</promise>; if it cannot complete the issue it exits without that tag and the issue is skipped this iteration.
Multiple implementer agents can run in parallel (controlled by max_parallel in config.py).
4. Reviewer
Immediately after each implementer signals completion, a reviewer agent inspects the same branch. The reviewer re-runs the checks, reads the diff, and pushes any corrections directly onto the branch before handing off to the merge phase.
5. Merging
Once all implementer/reviewer pairs have finished, pycastle attempts to fast-forward merge each completed branch into the default branch:
- No conflict — the branch is merged automatically and the worktree is cleaned up.
- Conflict — the conflicting branches are handed to a merger agent, which resolves the conflicts manually, re-runs the preflight checks, and commits the result.
After merging, the corresponding GitHub issue is closed. If an issue is a child of a parent/epic issue and all sibling issues are now closed, the parent issue is closed too. Merged branches are deleted.
If the working tree has uncommitted changes when the merge phase begins, pycastle waits (polling every 10 seconds) until the tree is clean before proceeding.
The ready-for-agent label
ready-for-agent is the entry point into the automated pipeline. The planner only considers issues that carry this label. The intended workflow is:
- A new issue arrives labelled
needs-triage. - A maintainer (or a separate triage agent) evaluates it and either closes it, marks it
need-info,wontfix, or — once it is fully specified with a clear acceptance criterion — relabels itready-for-agent. - On the next
pycastle run, the planner picks it up and the automated pipeline takes over.
Marking an issue ready-for-agent is a deliberate gate: it signals that the issue has enough detail for an agent to implement it without further clarification.
The companion label ready-for-human is used for issues that are too ambiguous, require access to external systems, or have failed preflight in a way that needs manual diagnosis. These issues are never picked up by the planner.
Configuration
All runtime configuration lives in pycastle/config.py. Key settings:
| Setting | Default | Description |
|---|---|---|
max_iterations |
10 |
How many plan→implement→merge loops to run |
max_parallel |
1 |
Maximum concurrent implementer agents |
issue_label |
ready-for-agent |
Label the planner filters on |
hitl_label |
ready-for-human |
Label that triggers a human-intervention exit |
preflight_checks |
ruff, mypy, pytest | Commands run before planning |
implement_checks |
ruff fix, mypy, pytest | Commands the implementer must pass |
skip_preflight |
False |
Set to True to bypass preflight entirely |
plan_override / implement_override / review_override / merge_override |
— | Per-stage model and effort overrides |
Edit pycastle/config.py (created by pycastle init) to tailor these to your project.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file pycastle-0.1.3.8.dev0.tar.gz.
File metadata
- Download URL: pycastle-0.1.3.8.dev0.tar.gz
- Upload date:
- Size: 532.8 kB
- Tags: Source
- Uploaded using Trusted Publishing? Yes
- Uploaded via: twine/6.1.0 CPython/3.13.12
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
78cf38b539a60d47174fa4a65b072cce14276588fbf4c022121f6f0282ebddd5
|
|
| MD5 |
d9e7e197dba1d668680f27b6693119a6
|
|
| BLAKE2b-256 |
61c6aee45a6b2dafd2166cfdcdb771a878194fe23787c6bef88d0d614006462b
|
Provenance
The following attestation bundles were made for pycastle-0.1.3.8.dev0.tar.gz:
Publisher:
publish.yml on Johannes-Kutsch/pycastle
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
pycastle-0.1.3.8.dev0.tar.gz -
Subject digest:
78cf38b539a60d47174fa4a65b072cce14276588fbf4c022121f6f0282ebddd5 - Sigstore transparency entry: 1429262507
- Sigstore integration time:
-
Permalink:
Johannes-Kutsch/pycastle@e5eec88b970139e7fe45b726aea57b7ed8d104f6 -
Branch / Tag:
refs/tags/v0.1.3.7 - Owner: https://github.com/Johannes-Kutsch
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
publish.yml@e5eec88b970139e7fe45b726aea57b7ed8d104f6 -
Trigger Event:
push
-
Statement type:
File details
Details for the file pycastle-0.1.3.8.dev0-py3-none-any.whl.
File metadata
- Download URL: pycastle-0.1.3.8.dev0-py3-none-any.whl
- Upload date:
- Size: 159.2 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? Yes
- Uploaded via: twine/6.1.0 CPython/3.13.12
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
3d091c888e10ee18f8c8bfc5744777774f28e0a9218619452076dad7ad516ae0
|
|
| MD5 |
af529a8fc278e4a1167b60c1b30578bf
|
|
| BLAKE2b-256 |
fec06f4c807be3f51f07f7fe8501e4ed0785d406b5fd07861901897626a05386
|
Provenance
The following attestation bundles were made for pycastle-0.1.3.8.dev0-py3-none-any.whl:
Publisher:
publish.yml on Johannes-Kutsch/pycastle
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
pycastle-0.1.3.8.dev0-py3-none-any.whl -
Subject digest:
3d091c888e10ee18f8c8bfc5744777774f28e0a9218619452076dad7ad516ae0 - Sigstore transparency entry: 1429262513
- Sigstore integration time:
-
Permalink:
Johannes-Kutsch/pycastle@e5eec88b970139e7fe45b726aea57b7ed8d104f6 -
Branch / Tag:
refs/tags/v0.1.3.7 - Owner: https://github.com/Johannes-Kutsch
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
publish.yml@e5eec88b970139e7fe45b726aea57b7ed8d104f6 -
Trigger Event:
push
-
Statement type: