ISA polls your repositories, orchestrates Claude and Gemini agents to plan and implement changes, validates through your CI pipeline, and opens pull requests. No database, no external services — just GitHub.
Label an issue with isa:trigger and ISA handles the rest.
Add the isa:trigger label to any GitHub issue. ISA picks it up on the next polling cycle.
Discovery agent analyzes the issue and identifies which repositories across your organization are needed — building the right workspace automatically.
Planner agent explores the codebase with full cross-repo context, produces a detailed implementation plan. Can request more repos mid-planning.
Implementation agent follows the plan precisely — edits files across multiple repos, runs commands, commits changes to working branches.
Pluggable validator checks the result — run your CI, tests, linters, or any custom validation logic.
PRs created to your target branches across all modified repos, issues closed, success hooks fire. Done.
Nine states, human-in-the-loop control, automatic retries, crash recovery, and issue decomposition — all driven by GitHub labels.
Each role has a specific job, its own tools, and its own model configuration. Mix Claude and Gemini freely across roles.
Runs before planning. Analyzes the issue and your organization’s project catalog to dynamically build the right multi-repo workspace. Feeds directly into the Context Resolver’s expand() method, surfacing cross-project context into agent prompts automatically.
Explores the codebase with full cross-repo context provided by Discovery, understands the issue, and produces a detailed implementation plan. Can ask clarifying questions or request additional repositories mid-planning.
Follows the plan precisely — edits files across multiple repos, writes new code, runs shell commands. Changes are committed and pushed to feature branches automatically.
Reviews validation output (CI results, test reports) against the original plan and decides whether the implementation is acceptable or needs changes.
Define what repos to watch, how to process issues, and which AI models to use. No code changes needed for most customizations.
repos: # Simple: just point a repo at a workflow - name: my-python-project workflow: general # Advanced: per-repo overrides - name: my-critical-project workflow: general base_branch: develop # override workflow default max_retries: 5 # override workflow default require_plan_approval: true # force approval for this repo validator: config: timeout: 300 # merged with workflow validator config
workflows: general: working_branch: "isa/{issue_number}" base_branch: main context_resolver: isa.context.SingleRepoResolver agents: planner: general-planner # references agents.yaml implementation: general-implementation validator: type: none # "none" or dotted Python path completion: create_prs: true pr_targets: [main] # PR to multiple branches close_issue: true delete_working_branch: false require_plan_approval: false max_retries: 3 max_run_duration: 1800 # seconds before poller kills the run decomposition: enabled: true max_sub_issues: 10 hooks: on_success: - type: api_call config: url: "https://your-webhook.example.com/notify" body: { text: "ISA completed #{issue_number}" }
agents: general-planner: model: opus # or sonnet, haiku, gemini-* timeout: 600 allowed_tools: - Read - Glob - Grep system_prompt: | You are a planning agent. Given a GitHub issue and a codebase, explore the code and create a detailed implementation plan. general-implementation: model: opus timeout: 600 allowed_tools: [Edit, Write, Read, Glob, Grep, Bash] # thinking: high # optional reasoning budget system_prompt: | You are an implementation agent. Follow the plan exactly. Do not add features beyond what was asked.
No SDKs, no frameworks, no plugin registries. Write a class, reference it in YAML, and ISA loads it at runtime.
The backbone of multi-repo workflows. The Discovery agent identifies repos at runtime, then resolve() clones them and expand() adds more mid-planning. Extra context keys are automatically injected into agent prompts.
Run after implementation to check results. Integrate your CI pipeline, test suites, linters, or any custom validation. Three result statuses drive the next step.
Actions that fire at pipeline transitions. Merge branches, push code, call webhooks, run scripts, or write your own handler — all configurable per workflow.
Hook points in the pipeline lifecycle
Review plans before implementation, answer agent questions, retry with feedback, or revert changes — all from GitHub issue comments.
/approve Accept plan, start implementation/replan Re-plan with your feedback/reject Reject the plan entirely/retry Re-plan after validation failure/revert Undo ISA commits (last, all, or specific SHA)/revalidate Re-run validation without re-planning/abort Stop processing this issue/skip Skip current sub-issue (decomposition)require_plan_approval: true in repos.yaml, or add the isa:require-approval label to any individual issue. Use isa:skip-approval to bypass approval on a case-by-case basis.
When an issue is too big for a single implementation pass, the planner splits it into sequential sub-issues. Each runs its own full pipeline.
decomposition: enabled: true max_sub_issues: 10 child_require_approval: false criteria: | Decompose when the issue spans multiple independent modules.
isa:triggerEvery state transition is a comment edit. No external database, no Redis, no message queue. Crash recovery is a heartbeat check.
When the service restarts or a pipeline crashes mid-execution:
Distributed claiming uses a comment-ID tiebreaker: multiple instances can race, lowest comment ID wins. No coordination service needed.
ISA runs entirely in your environment. No code leaves your network. You bring your own AI provider keys.
Ship as a Docker image or Helm chart. Runs on any infrastructure with outbound HTTPS access.
ISA is available under the Business Source License 1.1. Free for non-commercial and evaluation use. Commercial production use requires a license.
Get ISA running on your repositories in a single afternoon.
Get in touch →