DivineSWE

You speak. They build. The prophecy is fulfilled.

You are the Architect. The world exists because of your vision. You speak, and reality bends. DivineSWE is your divine apparatus -- a system of prophets, oracles, and artisans who serve your will, transcribing your word into scripture, etching prophecies into stone tablets that never crack.

Prophet is your voice -- the immortal conductor who hears your intent and dispatches agents to execute your will. They do not question. They do not falter. They build what you decree.

Oracle plumbs the depths of possibility, breaking your visions into sacred tasks, each a prophecy written in divine prose.

Thoth writes the laws -- the immutable tests that define what is true and what is false. Every law carved before creation begins.

Preacher examines the law for contradictions, ensuring no flaw in the sacred word. It pronounces GO or NO_GO.

Monkeys are your hands -- tireless workers who forge your will into reality, one test, one implementation at a time.

4eyes scrutinizes the work, ensuring no flaw escapes your divine notice. Styx verifies every sacred artifact meets your law. Mason merges the work into the eternal codebase, resolving conflicts with divine patience.

And Loki -- the necessary chaos -- tears apart the false to reveal what endures.

Every task becomes scripture. Every decision, carved in stone. Every completion, eternal proof that your vision was true.

Stateful Multi-Agent Orchestration for Agentic Engineering

DivineSWE is a Claude Code, OpenCode, GitHub Copilot, and Codex CLI plugin that replaces ad-hoc task management with a deterministic state machine driven by Prophet — an immortal orchestrator that dispatches specialized agents through a structured development pipeline. It solves three problems that emerge when running multi-agent software development sessions:

1. Silent context degradation — agents forget decisions, duplicate work, and contradict themselves as the context window fills and compresses older content.
2. Unproven output — AI emits plausible-but-wrong code (bugs, security holes, regressions) with no adversary probing it and no verification gate it must pass.
3. No live observability — no visibility into what agents are doing, what decisions they made, or where things went wrong.

DivineSWE addresses these with externalized state (Scrolls), an append-only event log (Ledger), adversarial audit (4eyes + Loki), a verification gate (Styx), and git worktree isolation for parallel agents.

Installation

The rites of installation — choose your platform and let the prophecy begin.

Prerequisites

• Claude Code CLI — installed and authenticated
• Git — required for worktree isolation (parallel agent sub-tasks run in git worktree branches)

Claude Code (Recommended)

Option 1: From within Claude Code

In an active Claude Code session, run:

/plugin marketplace add https://gitlab.com/aidragonllc/divineswe.git
/plugin install divineswe

Option 2: Headless command line

claude plugin marketplace add https://gitlab.com/aidragonllc/divineswe.git
claude plugin install divineswe

Both marketplace add and install accept --scope user (default), --scope project, or --scope local.

Option 3: Clone

git clone https://gitlab.com/aidragonllc/divineswe.git ~/divineswe
claude plugin marketplace add ~/divineswe
claude plugin install divineswe

Copilot CLI

Install via git-URL marketplace — the only supported install path (direct owner/repo form is broken upstream — copilot-cli#2390):

copilot plugin marketplace add https://gitlab.com/aidragonllc/divineswe.git
copilot plugin install divineswe@divineswe

Note: Do NOT use copilot plugin install owner/repo (direct form). The direct install owner/repo form hits an upstream loader bug (copilot-cli#2390) that breaks discovery when the manifest is in a subdirectory. Use the marketplace form above.

To install all platforms globally (into ~/.copilot/, ~/.config/opencode/, etc.) or manage per-platform targets, use the installer scripts — the global install is the default (without --per-project) and is the recommended path:

npm run install:copilot-cli    # Install copilot-cli bundle globally
npm run install:all            # Install all installable platforms globally
npm run install:interactive    # Interactive platform selection and target confirmation

Or invoke the installer directly for fine-grained control:

node scripts/install-platform.mjs install --platform copilot-cli
node scripts/install-platform.mjs install --platform copilot-cli --target ~/.copilot
node scripts/install-platform.mjs install --all --force

Add --per-project (opt-out) to install into the current project directory instead of the global target. Without --per-project, the global install is the default. Add --target <path> to specify an explicit installation directory. Use --all to install all platforms at once. Use --force to overwrite existing (user-modified) files.

OpenCode

OpenCode is delivered as the divineswe npm package (not a file-copy bundle). On startup OpenCode resolves the package from npm and installs it via Bun, caching it under ~/.cache/opencode/node_modules/. No manual npm install step required.

Add "divineswe" to the plugin array in your global OpenCode config at ~/.config/opencode/opencode.json:

{
  "plugin": ["divineswe"]
}

Then restart OpenCode. The plugin installs globally (into ~/.config/opencode/) by default.

Codex CLI

Codex CLI is detected via the marker file .codex-plugin/plugin.json. To install:

1. Generate the Codex CLI package: npm run generate -- --platform codex-cli
2. Copy the full contents of dist/codex-cli/ into your project root (the marketplace source.path resolves to the full package root, so all scripts, agents, skills, and hooks must be present).

Note: The install path above is NOT validated against the real codex binary — orchestration behavior is unproven (packaging-conformant only). See docs/platform-portability.md for details.

After installation

Before running your first orchestration cycle, you need a Book — a task file authored via /divineswe:oracle-consult or /divineswe:prophet-revelation. An empty Book directory means no tasks to orchestrate, and Prophet will exit immediately. Run oracle-consult to produce your first Book, then invoke prophet-fulfill.

prophet-fulfill calls divineswe-init automatically on first run. If you want to pre-configure the statusline and inject DivineSWE instructions into .claude/CLAUDE.md before your first cycle, run /divineswe:divineswe-init manually in your project.

Quick Start

Once installed, the oracle speaks and the prophecy unfolds:

1. Design your tasks — start a consultation session:

   /divineswe:oracle-consult

   Oracle will guide you through an iterative dialogue to produce a Book file (task list) and decision record. Loki-Doubt shadows Oracle to challenge the plan.

2. Run the cycle — invoke the full state machine:

   /divineswe:prophet-fulfill

   Prophet reads your Book, dispatches agents through the pipeline (TEST → IMPLEMENT → AUDIT → MERGE → VERIFY → WRAP UP), and loops until all tasks are complete.

3. Resume after interruption — if a session is interrupted:

   /divineswe:prophet-resume

   Prophet reads .divineswe/session-state.json and re-enters at the exact phase where it left off.

4. Standalone audit — run a security + quality audit without a full cycle:

   /divineswe:prophet-full-audit

How It Works

The state machine that bends reality to your will.

Prophet drives each cycle through seven phases in strict order:

INIT -> TEST -> IMPLEMENT -> AUDIT -> MERGE -> VERIFY -> WRAP UP

Prophet infers the pipeline phase from the agent name before the colon in each Book task line — this is the agent-name-as-phase workflow. For example, Thoth: → TEST, Monkey: → IMPLEMENT, 4eyes: → AUDIT, Mason: → WRAP UP. Tasks are ordered by phase: test-writing first, then implementation, then audit, then verify, then commit.

Planning happens at design time inside oracle-consult (Oracle + Preacher + Loki-Doubt). The run-time pipeline dispatches Thoth (tests), Monkey (implementation), 4eyes + Loki-Exploit (audit), Mason (merge), and Styx (verify).

Prophecies (Book 62)

A prophecy is a self-contained mini-pipeline (TEST → IMPLEMENT → AUDIT → VERIFY) scoped to a single-context unit — one focused change that touches one cohesive slice of the codebase. A Book is an ordered collection of prophecies.

Per-prophecy task numbering format: B<NN>-P<N>-<YY> where <NN> is the Book number, <N> is the prophecy index, and <YY> is the zero-padded 2-digit task index restarting at 01 per prophecy. Examples: B62-P1-01, B62-P2-01.

Backward compatibility. Books without ### Prophecy N: headings still work — they parse as a single implicit prophecy spanning the whole Book.

After all prophecies in a Book complete, Book-Level AUDIT runs against the full Book diff, and Book-Level VERIFY (Global VERIFY) runs the full test suite.

For the full pipeline reference, phase table, prophecy execution model, branch isolation, and failure recovery, see docs/architecture.md.

The Agents

The divine council — each a sacred role, each dispatch a prophecy fulfilled.

| Agent | Role | Phase | |-------|------|-------| | Prophet | Immortal orchestrator — drives the state machine, dispatches all agents | All (run-time) | | Oracle | Plan architect — task decomposition, file targets, architecture design | Plan-time | | Preacher | Pre-flight examiner — returns GO / CAUTION / NO_GO | Plan-time | | Thoth | Test writer — writes failing TDD tests (the immutable laws) | TEST | | Monkey | Implementation worker — makes all tests pass in an isolated worktree | IMPLEMENT | | 4eyes | Code auditor — correctness, architecture, security, simplify, retrospective | AUDIT, WRAP UP | | Mason | Merge worker — merges worktrees, commits prophecies, FF-merges branches | MERGE | | Styx | Verifier — 7-pass verification protocol, produces unambiguous PASS/FAIL | VERIFY | | Loki | Adversary — three forms: Loki-Doubt (plan), Loki-Break (tests), Loki-Exploit (audit) | All | | Atlas | Read-only explorer/cartographer — maps the codebase; invoked by the atlas-explore skill | Plan-time |

The atlas-explore skill invokes Atlas to chart the repository and produce a navigable map before planning begins.

For the full agent reference including model tiers, lifecycle, Loki's three forms (Loki-Doubt, Loki-Break, Loki-Exploit), and dispatch rules, see docs/agents.md.

Configuration

Carve your config in stone — the scrolls obey.

After divineswe-init, edit .divineswe/config.json:

{
  "version": "0.25.0",
  "project_name": "your-project",
  "model_preferences": {
    "high": "opus",
    "medium": "sonnet",
    "low": "haiku"
  },
  "worktree_isolation": true,
  "ledger_enabled": true,
  "scrolls_enabled": true,
  "max_parallel_agents": 4,
  "verification_passes": 7,
  "specs_dir": "docs/specs",
  "books_dir": ".divineswe/books",
  "default_branch": "master",
  "simplify_pass_enabled": true,
  "custom_instructions": ""
}

Key fields:

• books_dir — where your Book files live (default .divineswe/books; supports absolute paths and ~ for local-only Books outside the repo).
• default_branch — Mason's FF-merge target at Book-level WRAP UP (default "master"; set to "main" if needed).
• simplify_pass_enabled — when true (default), 4eyes runs a two-stream audit (correctness + simplify) in the AUDIT phase.
• agent_models — optional per-agent model overrides (e.g., "monkey": "haiku").

For the full field reference including agent_models, specs_dir, simplify_pass_enabled, and override semantics, see docs/configuration.md.

Platforms

DivineSWE supports four platforms. The canonical source targets claude-code; packages for other platforms are generated from it.

| Platform | Manifest | Slash Prefix | Install target | Status | |----------|----------|--------------|----------------|--------| | claude-code | .claude-plugin/plugin.json | /divineswe: | N/A (source IS platform) | Fully supported | | opencode | npm plugin (divineswe package) | / | ~/.config/opencode/ (global default) | Supported | | copilot-cli | copilot/plugin.json (committed) | / | ~/.copilot/ (global default) | Packaging-conformant; tier-3 unproven | | codex-cli | .codex-plugin/plugin.json | / | project root | Packaging-conformant; orchestration unproven |

GitHub Copilot CLI plugin packaging

The copilot/ package is committed at the repo root and installs directly from a git URL. The canonical install path (marketplace form — do NOT use the direct install owner/repo form, which hits upstream loader bug copilot-cli#2390):

copilot plugin marketplace add https://gitlab.com/aidragonllc/divineswe.git
copilot plugin install divineswe@divineswe

VS Code Copilot (Preview): Same install gesture. Use "Chat: Install Plugin From Source" with the git URL, or add to chat.plugins.marketplaces in VS Code settings. VS Code auto-discovers CLI-installed plugins.

Caveats (honest scope per Loki-Doubt review):

• VS Code runtime: unvalidated. Install and plugin registration work via the CLI path; VS Code runtime skill/hook self-location is untested (CLI-validated only, different process model).
• Windows: out of scope. State-CLI skills self-locate via a bash glob — Windows Copilot state-CLI skills are not supported (bash-only self-location).
• Tier-3 hook/agent firing: unproven. The copilot/ package is packaging-conformant (hooks, agents, plugin.json pointer all correct), but hook FIRING and agent DISPATCH have not been validated against a live session. Tier-3 firing is unproven.

For full platform portability details, generator usage, build/install scripts (install-platform.mjs), the three-state file model, atomicity guarantees, and adding new platform targets, see docs/platform-portability.md and docs/contributing.md.

What's New

v0.25.0 (Book 74 — Copilot Git-Marketplace Install)

• Copilot git-URL marketplace install. The copilot/ package is committed at the repo root so it installs directly from a git URL — no clone+generate step required. copilot plugin marketplace add <git-url> → copilot plugin install divineswe@divineswe is the only supported install path.
• owner must be an object {name:<string>}. The real @github/copilot binary rejects a string owner. Any string author/owner is normalized to {name:...} in both marketplace files.
• Copilot self-location. Generated copilot SKILL and HOOK bodies self-locate scripts via a marketplace-name-pinned cache-glob — never $CLAUDE_PLUGIN_ROOT.

See CHANGELOG.md for the full version history.

Contributing & Docs

The sacred texts — read them before you write.

• docs/architecture.md — pipeline, state machine, prophecy execution model, branch isolation
• docs/agents.md — full agent reference, model tiers, Loki's three forms
• docs/configuration.md — full config field reference, agent_models, books_dir
• docs/state-model.md — Scrolls, Ledger, Status, Session State, TEACHINGS, Akashic Records
• docs/testing-guide.md — wiring vs unit tests, typed test doubles, test conventions
• docs/contributing.md — building platform packages, publishing, version bumps, git practices
• docs/platform-portability.md — platform portability architecture, generator usage, adding new platforms
• CHANGELOG.md — full version history

License

MIT — see LICENSE.