A shared software factory core powered by OpenHands, with configurable deployment policies and isolated worker execution. Discuss and approve a specification in Agent Canvas, then let agents implement, test, and independently review it in disposable Docker workers. Passing changes become draft pull requests.
IntentMade runs locally on Linux. Workers use Codex through OpenHands ACP with your subscription login, or native OpenHands with a saved API-backed LLM profile. Canvas provides chat, schedules, run history, and logs.
- Specify — discuss a feature and approve its scope and acceptance criteria.
- Build — implement it in a dedicated branch and disposable workspace.
- Validate — run project tests, optional browser QA, and independent review; repair within the configured attempt limit.
- Publish — open a draft PR with validation results. Merge and deploy manually.
Scheduled workflows can also pick up approved GitHub issues, maintain the factory's PRs, and respond to review requests. Each task has its own Docker daemon for integration tests. IntentBond optionally connects requirements, code, and verification throughout the workflow.
You need Linux, Docker Engine with Compose, Git, Python 3, GitHub CLI (gh)
access to your repositories, and a Codex login or a native OpenHands LLM profile.
The quick start below uses Codex; see native worker setup
for the alternative.
git clone https://github.com/kbak/intentmade.git
cd intentmade
mkdir -p ../my-factory
cp -R examples/. ../my-factory/
cp .env.example .envSet the paths in .env, replace the example registrations under
../my-factory/config/, and configure your test commands. Examples have
scheduling disabled. Authenticate gh, then run:
./scripts/factoryctl init
./scripts/factoryctl up
./scripts/factoryctl codex-login
./scripts/factoryctl configure
./scripts/factoryctl openIn Canvas, select the model under Settings → Agent → factory-codex and set your Git name and email in Application settings. The setup guide covers authentication and configuration.
Discuss the change in Canvas and explicitly approve implementation, or submit an approved specification from the command line:
./scripts/factoryctl submit example-app ./approved-spec.md --runOmit --run to inspect the prepared job first. Add --no-publish to keep results
local, or --task TASK_ID to continue an existing task. Review an existing PR with:
./scripts/factoryctl review example-app 123See workflows for scheduling, replies, and PR maintenance.
The same factory core supports personal workflows and maintainer-operated OSS work. Runtime isolation, credential handling and issue approval are deployment choices; implementation, repair, review, evidence and publication checks stay shared. See deployment choices.
The current controller assumes one trusted operator. Canvas listens on localhost by default; access to it grants factory control. DockerWorkspace workers receive the selected model credential; Docker Sandboxes Codex workers use host-managed proxy credentials. GitHub publication credentials stay in the parent workflow. The default containers share the host kernel, including privileged Docker test daemons. Docker Sandboxes places each worker and its test daemon in a separate VM.
Issue intake defaults to manual submission; no GitHub label is required. Scheduling starts disabled. Trusted repositories can opt into automatic issue intake. Review the target repository's CI permissions before enabling publication. Read the security model and resource limits before unattended use.
The shared core can underpin future enterprise integrations, but the repository does not provide enterprise identity, organization-level authorization or a multi-tenant controller boundary.
- Intent and specification: outcomes, requirements and supporting code/tests.
- Configuration: repositories, test profiles, browser QA, and groups.
- Reviews: review policy, evidence, and GitHub verdicts.
- Agents: models, roles, and skills.
- Operations: updates, backups, and recovery.
- Traceability: optional IntentBond integration.
- All documentation: guides and technical references.
See CONTRIBUTING.md for development and testing, and SECURITY.md for vulnerability reports.
MIT. Bundled third-party files retain their own licenses; see third-party notices.