isa:planning isa:implementing isa:validating isa:trigger isa:success

Your GitHub issues,
resolved by AI.

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.

See how it works
isa-service

Six steps from issue to pull request

Label an issue with isa:trigger and ISA handles the rest.

01

Trigger

Add the isa:trigger label to any GitHub issue. ISA picks it up on the next polling cycle.

02

Discover

Discovery agent analyzes the issue and identifies which repositories across your organization are needed — building the right workspace automatically.

03

Plan

Planner agent explores the codebase with full cross-repo context, produces a detailed implementation plan. Can request more repos mid-planning.

04

Implement

Implementation agent follows the plan precisely — edits files across multiple repos, runs commands, commits changes to working branches.

05

Validate

Pluggable validator checks the result — run your CI, tests, linters, or any custom validation logic.

06

Ship

PRs created to your target branches across all modified repos, issues closed, success hooks fire. Done.

A state machine that handles the unexpected

Nine states, human-in-the-loop control, automatic retries, crash recovery, and issue decomposition — all driven by GitHub labels.

PLANNING
ready
IMPLEMENTING
pushed
VALIDATING
success
SUCCESS

Needs Clarification

PLANNING needs_info → NEEDS_INFO
User replies → PLANNING resumes with full history

Plan Approval

PLANNING ready_approval → AWAITING_APPROVAL
/approve → IMPLEMENTING  ·  /replan → PLANNING

Validation Failed

VALIDATING failure → AWAITING_DECISION
/retry → re-plan  ·  /revert → undo commits  ·  /abort → FAILED

Workspace Expansion

PLANNING needs_repos → PLANNING (self-loop)
Discovery or Planner requests more repos → workspace expands → planning resumes

Decomposition

Large issue → DECOMPOSED into sub-issues
Each child runs its own full pipeline sequentially

Four specialized roles, any model

Each role has a specific job, its own tools, and its own model configuration. Mix Claude and Gemini freely across roles.

Discovery workspace builder

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.

cross-repo intelligence dynamic workspace

Planner exploration

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.

Read Glob Grep

Implementation execution

Follows the plan precisely — edits files across multiple repos, writes new code, runs shell commands. Changes are committed and pushed to feature branches automatically.

Edit Write Read Glob Grep Bash

Plan Review validation

Reviews validation output (CI results, test reports) against the original plan and decides whether the implementation is acceptable or needs changes.

text-only review

Multi-Provider, Multi-Model

Claude

  • opus — highest capability
  • sonnet — balanced
  • haiku — fast & efficient

Gemini

  • gemini-2.5-pro
  • gemini-2.5-flash
  • gemini-3-pro-preview
  • gemini-3-flash-preview
  • gemini-3.1-pro-preview
Mix providers freely. Use Claude opus for planning, Gemini flash for implementation, sonnet for review. Tool names are abstract — the runner maps them automatically per provider.

Three YAML files. That's it.

Define what repos to watch, how to process issues, and which AI models to use. No code changes needed for most customizations.

Maps GitHub repositories to workflows. Add per-repo overrides for branches, retries, approval requirements, and validator config.
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
Defines processing behavior: branch patterns, agents, validators, hooks, completion actions, decomposition rules, and more.
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}" }
Defines AI agent profiles: model, tools, timeout, reasoning budget, and domain-specific system prompts. Output formats are handled automatically by the framework.
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.

A Python class and a dotted path

No SDKs, no frameworks, no plugin registries. Write a class, reference it in YAML, and ISA loads it at runtime.

Context Resolvers

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.

SingleRepoResolver resolve() → WorkspaceLayout expand() → add repos mid-plan extra_context → agent prompts
context_resolver: myapp.resolvers.MultiRepoResolver # Discovery agent feeds repos → resolve() clones them # Planner can request more → expand() adds mid-plan # extra_context keys auto-surface in agent prompts

Validators

Run after implementation to check results. Integrate your CI pipeline, test suites, linters, or any custom validation. Three result statuses drive the next step.

NoopValidator success needs_review failure
validator: type: myapp.validators.CIValidator config: timeout: 300

Hooks

Actions that fire at pipeline transitions. Merge branches, push code, call webhooks, run scripts, or write your own handler — all configurable per workflow.

merge_to_branch push_branch run_script api_call
hooks: on_success: - type: myapp.hooks.SlackNotifier config: { channel: "#deploys" }

Hook points in the pipeline lifecycle

after_plan
after_implementation
after_validation
on_success
on_failure

AI proposes, you decide

Review plans before implementation, answer agent questions, retry with feedback, or revert changes — all from GitHub issue comments.

ISA
Plan ready for review
Refactor the authentication module to use JWT tokens. Changes span 3 files: auth.py, middleware.py, config.py.

Reply /approve to proceed or /replan with feedback.
You
/replan Please also update the unit tests in tests/test_auth.py
ISA
Updated plan
Now includes test updates. 4 files: auth.py, middleware.py, config.py, tests/test_auth.py.
You
/approve
ISA
Implementation complete
4 files changed, pushed to isa/42. PR #43 created → main.

Available Commands

/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)
Per-repo and per-issue control: Set 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.

Large issues, handled automatically

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.

Refactor auth system

#42
isa:decomposed
[#42/1] Extract JWT token handler
#43 · PR merged
[#42/2] Update middleware chain
#44 · implementing...
·
[#42/3] Migrate session storage
#45 · pending

Configuration

decomposition:
  enabled: true
  max_sub_issues: 10
  child_require_approval: false
  criteria: |
    Decompose when the issue spans
    multiple independent modules.

Lifecycle

  • 1. Planner identifies scope → proposes decomposition
  • 2. User reviews and approves the split
  • 3. Sub-issues created on GitHub with markers
  • 4. Each child activated sequentially via isa:trigger
  • 5. Parent tracks progress with checklist updates

GitHub is the database

Every state transition is a comment edit. No external database, no Redis, no message queue. Crash recovery is a heartbeat check.

State Persistence

Storage GitHub issue comments
Heartbeat interval 60 seconds
Stale threshold 300 seconds
Claim mechanism Comment ID tiebreaker
External dependencies None
<!-- isa-bot --> <!-- isa-state {"attempt":1,"max_retries":3,...} --> Status: Implementing (1/3) · 5m elapsed

Crash Recovery

When the service restarts or a pipeline crashes mid-execution:

1. Poller detects stale heartbeat (>300s old)
2. Issue transitioned to AWAITING_DECISION
3. User notified with available commands
4. On restart: reclaim via edited state comment
5. Large fields reloaded from marker comments

Distributed claiming uses a comment-ID tiebreaker: multiple instances can race, lowest comment ID wins. No coordination service needed.

Your code, your keys, your infrastructure

ISA runs entirely in your environment. No code leaves your network. You bring your own AI provider keys.

Self-Hosted Deployment

Ship as a Docker image or Helm chart. Runs on any infrastructure with outbound HTTPS access.

  • Docker / docker-compose for simple setups
  • Kubernetes with Helm chart for orchestration
  • Your own AI API keys (Anthropic, Google)
  • GitHub App or PAT authentication
  • No inbound ports needed (polling mode)
┌────────────────────────────────────────┐ │ Your Infrastructure │ │ │ │ ┌──────────────────────────────────┐ │ │ │ ISA Container │ │ │ │ ┌────────────────────────────┐ │ │ │ │ │ Pipeline Engine + Poller │ │ │ │ │ └────────────────────────────┘ │ │ │ │ ┌────────────┐ ┌─────────────┐ │ │ │ │ │ Claude CLI │ │ Gemini CLI │ │ │ │ │ └────────────┘ └─────────────┘ │ │ │ └──────────────────────────────────┘ │ │ │ │ │ │ ┌────┬────┐ ┌─────┬─────┐ │ │ │ GitHub │ │ AI APIs │ │ │ └─────────┘ └───────────┘ │ └────────────────────────────────────────┘

Licensing

ISA is available under the Business Source License 1.1. Free for non-commercial and evaluation use. Commercial production use requires a license.

  • Non-commercial use: always free
  • Internal evaluation: always free
  • Commercial production: licensed
  • Converts to Apache 2.0 after 4 years
Enterprise packages include implementation contracts, custom validator and hook development, agent prompt engineering, deployment assistance, and ongoing support with SLA.
ISA

Ready to automate your issues?

Get ISA running on your repositories in a single afternoon.

Get in touch →