Skip to main content

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_KEY environment variable (or a .env file in your project root)
  • A GitHub repository with a GH_TOKEN environment 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:

  1. A new issue arrives labelled needs-triage.
  2. 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 it ready-for-agent.
  3. 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


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

pycastle-0.1.2.1.tar.gz (115.6 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

pycastle-0.1.2.1-py3-none-any.whl (53.9 kB view details)

Uploaded Python 3

File details

Details for the file pycastle-0.1.2.1.tar.gz.

File metadata

  • Download URL: pycastle-0.1.2.1.tar.gz
  • Upload date:
  • Size: 115.6 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for pycastle-0.1.2.1.tar.gz
Algorithm Hash digest
SHA256 e5d41f5d631f104f995990f51c7cc0b5faf0247274b880e6fbc65037ce756167
MD5 9942de53f59e72c5b1ac3b19c73cfc95
BLAKE2b-256 e48a90b8f2cbc7830a1f9d452ac4f69ee48ce27eaaf561c98798420935102425

See more details on using hashes here.

Provenance

The following attestation bundles were made for pycastle-0.1.2.1.tar.gz:

Publisher: publish.yml on Johannes-Kutsch/pycastle

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file pycastle-0.1.2.1-py3-none-any.whl.

File metadata

  • Download URL: pycastle-0.1.2.1-py3-none-any.whl
  • Upload date:
  • Size: 53.9 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/6.1.0 CPython/3.13.12

File hashes

Hashes for pycastle-0.1.2.1-py3-none-any.whl
Algorithm Hash digest
SHA256 0ce2d71dbdeeec30dc27c0d7570188433cdc15488174265bf43807ca61bb3ad8
MD5 29e8d5857982220898a7c39c77da84ff
BLAKE2b-256 7bb6747055e3f8e5868042874b5cc8fee58419550fdca43228147253b0a6940b

See more details on using hashes here.

Provenance

The following attestation bundles were made for pycastle-0.1.2.1-py3-none-any.whl:

Publisher: publish.yml on Johannes-Kutsch/pycastle

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page