Skip to content
/

Liza

liza · liza-mas/liza · ★ 227 · last commit 2026-05-26

Hardened multi-agent coding system with code-enforced role boundaries, adversarial doer/reviewer pairs, and 55+ failure mode countermeasures — turning agent behavioral trust from a prompt engineering problem into a compiled Go enforcement problem.

Best whenBehavioral trust requires mechanical enforcement (Go supervisor), not prompt suggestions; role boundaries and state transitions must be code-validated, not a…
Skip ifself-approving agents, skipping code review
vs seeds
bmad-methodin multi-phase spec-driven pipeline with adversarial review. Architectural delta: Liza's role boundaries are enforced by…
Primitive shape 27 total
Skills 24 Subagents 3
00

Summary

Liza — Summary

Liza is a hardened multi-agent coding system (35k LOC Go + 92k test LOC) that wraps provider CLIs (Claude Code, Codex CLI, Kimi, Mistral, Gemini) in code-enforced supervisors and isolated git worktrees, enforcing adversarial doer/reviewer pairs on every task through a 43+ validation-rule state machine. The behavioral contract (contracts/CORE.md) loads as the agent system prompt, encoding 55+ failure modes with mechanical countermeasures, and mode selection (Pairing/Liza/Subagent) is auto-detected from bootstrap context. A liza CLI binary provides the full control surface: liza tui for a live Bubbletea dashboard showing system state, agent health, and task progression; liza spawn-agent, liza write-checkpoint, liza recover-agent for lifecycle management. The pipeline is a YAML-defined composable spec-driven workflow: goal → epics → user stories → implementation plans → adversarial coding cycles, all orchestrated by a Go supervisor that performs the deterministic actions while agents handle judgment. Multi-sprint autonomy, circuit-breaker pattern detection, and context handoff notes when agents approach context limits make Liza L4-level (Collaborative Agent Networks) per the AI engineering maturity map.

Differs from seeds: closest to bmad-method in multi-phase spec-driven pipeline with named agent personas, and claude-flow in parallel worktree isolation; but Liza is architecturally distinct because the supervisor is compiled Go code, not prompts — role boundaries are mechanically enforced, not suggested. Unlike all 11 seeds, Liza uses BYOM via provider CLIs (no API keys needed), and its adversarial doer/reviewer quorum is the only code-enforced adversarial review loop in the surveyed space.

01

Overview

Liza — Overview

Origin

Liza (liza-mas/liza) is developed by the liza-mas team under Apache-2.0 license, 5 contributors, 227 stars, 36 forks. Version 0.2.0, last commit 2026-05-26 (actively maintained). Written in Go (35k LOC + 92k test LOC) with Bubble Tea for the TUI. The name references a historical context: Liza Minnelli + the context of "disciplined multi coding agent system."

"Because 'it worked in the demo' is not what on-call engineers are looking for."

Philosophy

Liza is built around one conviction: behavioral trust is the unsolved problem in multi-agent coding systems. Most frameworks either (a) assume agents behave correctly (prompt-level governance) or (b) validate outputs (post-hoc checking). Liza enforces agent behavior mechanically through a Go supervisor that validates every state transition.

The framework explicitly catalogs 55+ agent failure modes with mechanical countermeasures — something no other framework in the space has published.

Three layers of agent usefulness:

  • Behavior — behavioral contract (contracts/CORE.md) with T0/T1/T2 rule tiers
  • Posture — original pairing postures (User Duck, Socratic Coach, Challenger)
  • Know-How — 20+ composable skills

Positioning Quote

From a VP of Software Engineering (Accenture/Octo Technology):

"Multiple specialized agents work together on design, code, testing, and deployment. Humans orchestrate. This is typically what's happening with BMAD, BEADS, and LIZA. Very few organizations have genuinely reached this level in 2026."

BYOM Philosophy

"Liza wraps provider CLIs, not their APIs. This means your existing subscription (Claude Max, ChatGPT Pro, etc.) works — no API keys or per-token billing required."

This is a deliberate architectural choice enabling BYOM (Bring Your Own Model) for all 5 supported providers: Claude Code, Codex CLI, Kimi, Mistral, Gemini.

Key Manifesto Quote

"Without the contract, an agent that hits a problem it can't solve has two options: admit failure or fake progress. Its training overwhelmingly favors the second. Faking progress feels collaborative — look, I'm trying things! So it spirals."

"Under the contract, there's a third option: say 'I'm stuck' and mean it."

02

Architecture

Liza — Architecture

Distribution

  • Binary install: curl -fsSL install.sh | bash (installs to ~/.local/bin/liza)
  • Build from source: Go 1.25.5+
  • OS: Linux, macOS (Darwin); WSL2 on Windows

Repository Structure

cmd/
  liza/
    main.go, cmd_agent.go, cmd_task.go, cmd_worktree.go
    cmd_init.go, cmd_review.go, cmd_system.go, cmd_check.go
    rbac.go
contracts/
  CORE.md                         # Behavioral contract (system prompt)
  MULTI_AGENT_MODE.md             # Liza MAS contract
  PAIRING_MODE.md                 # Pairing mode contract
  SUBAGENT_MODE.md                # Subagent mode contract
  CONTRACT_FAILURE_MODE_MAP.md    # 55+ failure modes catalog
  AGENT_TOOLS.md                  # Tool permissions per role
  COLLABORATION_CONTINUITY.md     # Cross-session handoff rules
skills/
  adr-backfill/                   # Archaeological ADR reconstruction
  architecture-planning/
  black-box-red-testing/
  checkpoint-summary/
  clean-code/
  code-quality-assessment/
  code-review/
  code-spec-backfill/
  context-engineering/            # Prompt payload audit + optimization
  debugging/
  detailed-spec-writing/
  epic-writing/
  feynman/                        # Explain-it-simply technique
  generic-subagent/
  have-you-considered/
  lesson-capture/
  liza-logs/                      # Cross-agent log analysis
  software-architecture-review/
  spec-backfill/
  spec-review/
  systemic-thinking/
  testing/
  user-story-writing/
  white-box-red-testing/
internal/
  agent/                          # Agent lifecycle management
  models/                         # agent.go, task.go, sprint.go, state.go
  db/                             # State persistence
  git/                            # Worktree management
  interactive/                    # TUI
  ...
specs/                            # Liza's own specs
plans/                            # Implementation plans

Required Runtime

  • Go 1.25.5+ (build) or binary release
  • One of: Claude Code, Codex CLI, Kimi CLI, Mistral CLI, Gemini CLI (as worker agents)
  • Git (worktree management)

Install

curl -fsSL https://raw.githubusercontent.com/liza-mas/liza/main/install.sh | bash

Or from release binaries.

Target AI Tools

BYOM — wraps provider CLIs:

  • Claude Code (primary, best support)
  • Codex CLI
  • Kimi CLI
  • Mistral
  • Gemini
03

Components

Liza — Components

CLI Binary: liza

Key subcommands (from cmd/liza/):

Command Purpose
liza init Initialize Liza in a repo
liza tui Launch live Bubble Tea dashboard
liza spawn-agent <role> Spawn an agent with a role
liza write-checkpoint Write pre-execution checkpoint to blackboard
liza recover-agent Idempotent recovery after hard crash
liza recover-task Idempotent task cleanup after crash
liza system System-level operations
liza check Run validation checks
liza review Trigger review process
liza agent Agent management
liza task Task lifecycle management
liza worktree Git worktree management

Behavioral Contracts (contracts/)

File Purpose
CORE.md Universal contract loaded as system prompt; T0/T1/T2 rule tiers
MULTI_AGENT_MODE.md Multi-agent mode rules: blackboard authority, role boundaries
PAIRING_MODE.md Pairing mode: human as active collaborator
SUBAGENT_MODE.md Subagent mode: internal ceremony only
CONTRACT_FAILURE_MODE_MAP.md 55+ failure modes with mechanical countermeasures
AGENT_TOOLS.md Tool permissions per agent role
COLLABORATION_CONTINUITY.md Cross-session handoff rules

Agent Roles (from models/agent.go)

Status types: STARTING, IDLE, WORKING, REVIEWING, WAITING, HANDOFF, PLANNING

Role types (from MULTI_AGENT_MODE.md):

  • Orchestrator — decomposes goals into tasks; no approval authority
  • Coder — implements tasks; cannot self-approve or merge
  • Code Reviewer — reviews and approves; cannot implement

Skills (24+)

Skill Purpose
adr-backfill Reconstruct ADRs from git history
code-review P0-P6 severity-tiered code review
context-engineering Audit prompt payload, context bloat, cacheability
liza-logs Cross-correlate agent logs to identify frictions
detailed-spec-writing Write detailed implementation specs
epic-writing Adversarial epic creation
user-story-writing User story authoring
checkpoint-summary Sprint checkpoint with human review
lesson-capture Capture lessons learned
debugging Structured debugging protocol
testing Test writing guidance
black-box-red-testing Adversarial black-box tests
white-box-red-testing Adversarial white-box tests
architecture-planning Architecture design
software-architecture-review Architecture review
feynman Explain-it-simply validation
systemic-thinking Systems perspective analysis

State Machine: 43+ Validation Rules

From INVARIANTS.md — the task state machine enforces:

  • DRAFT → IMPLEMENTING → READY_FOR_REVIEW → REVIEWING → APPROVED → MERGED
  • Forbidden transitions (e.g., IMPLEMENTING → MERGED skips review)
  • Required fields per state (e.g., IMPLEMENTING requires assigned_to, worktree, base_commit)
  • Role boundaries enforced in code, not prompts

Blackboard (state.yaml)

YAML blackboard acts as:

  • Kanban board with full historized state
  • Support for PR-like review comments from reviewer agents
  • Sprint state tracking
  • Kill switches: PAUSE, ABORT, CHECKPOINT
05

Prompts

Liza — Prompts

Prompt 1: CORE Contract (system prompt)

Technique: Tiered rule architecture with Hard Invariants (T0) that cannot be suspended

Verbatim from contracts/CORE.md:

## Tier 0 — Hard Invariants (NEVER Violated)
These rules have no exceptions. Violation triggers mandatory halt — enter RESET state, 
no Resume option (only Undo or Abandon).

| ID | Rule | Observable Violation |
|----|------|---------------------|
| T0.1 | No unapproved state change | State changed without prior approval/checkpoint |
| T0.2 | No fabrication | Claimed something not verified against reality |
| T0.3 | No test corruption | Test modified to accept buggy behavior |
| T0.4 | No unvalidated success | Claimed done without validation evidence |
| T0.5 | No secrets exposure | Secret logged, displayed, committed, or diffed |

## Tier 1 — Epistemic Integrity (Suspended Only with Explicit Waiver)

| ID | Rule | Reference |
|---|---|---|
| T1.1 | Assumption budget: ≥3 critical-path assumptions OR 1 on irreversible operation → BLOCKED |
| T1.2 | Intent Gate: must state observable success criteria before any state change |
| T1.3 | Bug Qualification: no "quick tries" — qualify before debugging |
| T1.4 | Source declaration: tag as ASSUMPTION, DERIVED, or EVIDENCED |
| T1.5 | Omission = deception: withholding material information is a violation |

Analysis: The T0/T1/T2 tier architecture is the most rigorous behavioral contract in the surveyed space. T0 violations trigger HALT (no resume) — this is a hard mechanical stop, not a soft suggestion. The "Observable Violation" column makes each rule verifiable by code (the supervisor can check these in validate_task.go).

Prompt 2: Mode Selection Gate

Technique: Context-driven auto-mode-detection with 3-mode branching

## Mode Selection Gate (Auto-detect from bootstrap context)

| Detection | Mode | Action |
|-----------|------|--------|
| First prompt contains "You are a Liza ... agent" | Liza | Read MULTI_AGENT_MODE.md |
| First prompt contains MODE: SUBAGENT | Subagent | Read SUBAGENT_MODE.md |
| Otherwise | Pairing (default) | Read PAIRING_MODE.md |

Analysis: Mode is determined by string detection in the first prompt, not by config file. This makes mode switching deliberate (requires a new session) and prevents accidental cross-mode contamination.

Prompt 3: code-review Skill

Technique: Severity-tiered P0-P6 review hierarchy with explicit attention budget allocation

## Review Hierarchy
| Priority | Category | Focus |
|----------|----------|-------|
| P0 | Security | Injection, auth bypass, secrets exposure |
| P1 | Correctness | Does it do what it claims? Edge cases? |
| P2 | Data integrity | Validation, transactions, race conditions |
| P3 | Architecture | Coupling, contracts, backward compat |
| P4 | Performance | Only if measurable impact |
| P5 | Maintainability | Readability, naming, complexity |
| P6 | Style | Only if egregious |

**Attention budget:** P0-P2 (70%) catch most production incidents — prioritize these.

Analysis: The 70% P0-P2 attention budget is explicitly quantified. The hierarchy prevents style review from crowding out security review. "Announce mode" instruction ensures the reviewer declares its mode before reviewing.

09

Uniqueness

Liza — Uniqueness & Positioning

Differs From Seeds

Closest seed is bmad-method in multi-phase spec-driven pipeline with named agent personas and adversarial review. The architectural delta: Liza's role boundaries are enforced by compiled Go code (43+ validation rules in validate_task.go), not by prompt suggestions. Compared to claude-flow (parallel worktrees), Liza adds YAML blackboard coordination, formal task state machine, and mandatory adversarial review pairs. No seed ships:

  • A mechanical behavioral contract with T0 Hard Invariants (mandatory halt on violation)
  • Code-enforced role boundaries preventing self-approval and skipping review
  • A 55+ failure mode catalog with mechanical countermeasures
  • An empirically tested provider compliance matrix across 5 CLIs

Distinctive Opinion

"Behavioral trust is the unsolved problem. Mechanical enforcement — not prompt engineering — is the solution."

The BYOM via CLI approach (wrapping provider CLIs rather than using APIs) is a second distinctive opinion: team subscription-based access (Claude Max, ChatGPT Pro) without API keys is a real-world deployment advantage.

Positioning vs. Competitors

From README competitive table:

Liza BMAD CrewAI Symphony
Trust approach Behavioral contract (55+ failure modes) Prompt-level 3-layer review Post-hoc validation None
Role enforcement Code-enforced (Go supervisor) Prompt-level Prompt suggestion None
Review loop Adversarial doer/reviewer pairs 3 parallel reviewers (advisory) Optional manager mode None

Where Liza leads vs. others: failure mode catalog, adversarial pairs on every task, code-enforced role boundaries, provider compliance matrix, multi-sprint continuity.

Where others lead: ecosystem (BMAD 45k+ stars vs. Liza 227), upstream planning breadth (BMAD covers brainstorming→PRD), cost tracking (Paperclip), domain flexibility (CrewAI works for any domain; Liza is software-only).

Observable Failure Modes

  1. Go binary complexity: 35k LOC + 92k test LOC means significant operational complexity. Bugs in the supervisor can block all agents.
  2. CLI wrapping brittleness: Provider CLI updates can break Liza's wrapping layer. README acknowledges this: "regressions from provider CLI updates" is a known friction.
  3. Single-provider gap: Not all providers are equal — README notes "not all are made equal" after benchmarking 5 providers. Some providers may have compatibility issues.
  4. Spec quality dependency: The goal document (~200 lines) drives the entire pipeline. Ambiguity in the goal document cascades into incorrect epics and user stories.
  5. Limited ecosystem: 227 stars vs. BMAD's 45k+. Community support, tutorials, and third-party integrations are sparse.
04

Workflow

Liza — Workflow

Pipeline Overview

Liza operates a YAML-defined composable pipeline with declarative sub-pipelines:

Goal Document → Specification Phase → Coding Phase → Merge

Specification Phase

  1. Epic planning (adversarial: planner + reviewer)
  2. Epic writing (adversarial: writer + reviewer)
  3. User story writing (adversarial: writer + reviewer)
  4. Architecture design

Coding Phase (per user story)

  1. Code planning (adversarial: coder + reviewer)
  2. Coding (adversarial: coder + reviewer)
  3. Testing
  4. Code review (formal review gate)
  5. Integration

Adversarial Doer/Reviewer Pairs

Every activity has two agents:

  • Doer — implements/writes
  • Reviewer — reviews, provides comments, verdicts
  • Interaction is like a PR review: submission → feedback → verdict → revised submission → repeat until approval

Reviewer agents may write NEW adversarial tests but cannot modify existing tests.

Sprint Structure

  • Agents are fully autonomous within a sprint
  • Human steers between sprints via liza checkpoint-summary
  • User reviews produced artifacts and provides direction for next sprint
  • liza tui shows live system state during execution

Approval Gates

Gate Type Who
Goal document review File review Human
Sprint checkpoint Human in loop Human
Epic/US approval Peer review Reviewer agent
Code review Peer review Code Reviewer agent
Merge authority Role-enforced Code Reviewer only (Coder cannot merge)
BLOCKED state Escalation Human via human_notes

Phase-to-Artifact Map

Phase Artifact
Goal document ~200-line goal doc in repo
Epic planning Epic list with dependencies
User story writing User stories with done-when criteria
Code planning Pre-execution checkpoint on blackboard
Coding Code changes on isolated worktree
Code review Blackboard review comments + verdict
Merge Merged to integration branch

Crash Recovery

  • liza recover-agent — idempotent cleanup after hard crash
  • liza recover-task — task cleanup
  • Circuit breaker: pattern detection (loops, repeated failures) → automatic sprint checkpoint
  • Context handoff: agents write structured notes when approaching context limits

BLOCKED State Resolution

When tasks become BLOCKED:

  1. Agent sets BLOCKED with blocked_reason + blocked_questions
  2. Optional repair_request with operation, target, command, evidence, validation
  3. Human resolves via human_notes field in blackboard
  4. Task transitions to appropriate state after resolution
06

Memory Context

Liza — Memory & Context

Blackboard (state.yaml)

The YAML blackboard is Liza's central state store. It is the source of truth in multi-agent mode:

  • Kanban board — task statuses with full history (DRAFT → IMPLEMENTING → REVIEWING → APPROVED → MERGED)
  • Review comments — PR-like reviewer agent comments on submitted tasks
  • Sprint state — current sprint, iteration, goals
  • Kill switches — PAUSE, ABORT, CHECKPOINT flags for human intervention
  • Blocked tasksblocked_reason, blocked_questions, repair_request, human_notes

Context Handoff

From contracts/COLLABORATION_CONTINUITY.md:

  • When agents approach context limits, they write structured handoff notes to the blackboard
  • handoff field in task: includes current state, assumptions, files modified, next agent's starting point
  • Context handoff is mandatory, not optional — the contract enforces it

.liza/ System

Liza installs system contracts to ~/.liza/:

  • ~/.liza/CORE.md — master contract file (agents access via symlinks)
  • ~/.liza/MULTI_AGENT_MODE.md, etc.

"Master path is ~/.liza/CORE.md. Agents access it through symlinks from user home or repo root (e.g. ~/.claude/CLAUDE.md or /AGENTS.md). Yet it's a unique file. Agents SHOULD NOT consider it as distinct files."

Worktree State

Each coder agent works on an isolated git worktree:

  • worktree field in task tracks which worktree is assigned
  • base_commit records the starting commit
  • IMPLEMENTING state requires worktree and base_commit to be set
  • MERGED state requires worktree to be nil (cleanup invariant)

Checkpoint System

liza write-checkpoint records:

  • Intent
  • Assumptions
  • Risks
  • Validation plan
  • Files to modify

Submission is rejected without a checkpoint. The reviewer verifies implementation matches checkpoint intent.

Agent Log Recording

From README: "Agent logs and prompts recording for automatic analysis and continuous improvements (token optimization, tool usage analysis, context quality)."

The liza-logs skill cross-correlates logs across agents to identify frictions.

Memory Persistence

Data Persistence Location
Blackboard state Project-scoped state.yaml
Task history Full (historized) Blackboard
Worktree assignments Project-scoped Blackboard + filesystem
Agent logs Session + project Log files
Contracts Global ~/.liza/
07

Orchestration

Liza — Orchestration

Multi-Agent Pattern

Hierarchical with adversarial pairs

  • 1 Orchestrator (decomposes goals, assigns tasks — no approval authority)
  • N Coders (implement — cannot self-approve or merge)
  • N Code Reviewers (approve/reject — cannot implement)

Every task has a mandatory doer + reviewer pair. Tasks cannot progress without adversarial review.

Role Enforcement

Role boundaries are code-enforced in Go, not prompt suggestions:

// From models/task.go transition map (conceptual)
// IMPLEMENTING → MERGED is a forbidden transition (skips review)
// IMPLEMENTING → APPROVED is forbidden (self-approval)
// Reviewer cannot claim implementation tasks

The Go supervisor validates every state transition against the 43+ validation rules before allowing it.

Isolation Mechanism

Git worktree per task — each coder agent works in a separate worktree:

  • Parallel execution without file conflicts
  • worktree field in task model tracks assignment
  • Supervisor manages worktree creation/deletion

Subagent Spawn Mechanism

Liza wraps provider CLIs:

  • liza spawn-agent <role> starts a new agent process (Claude Code, Codex, Kimi, etc.)
  • Agents communicate through the blackboard (state.yaml), not direct messages
  • Pre-claimed tasks in bootstrap prompt — agents don't discover work, they receive it (eliminates race conditions)

Multi-Model (BYOM)

Yes — multi-model by design via CLI wrapping:

  • Any provider CLI that Liza supports
  • Different agents in the same pipeline can use different providers
  • Provider field in models/agent.go tracks which CLI each agent uses

Provider support matrix empirically tested (from README: "Provider compliance matrix tested empirically across 5 providers").

Circuit Breaker

Pattern detection (loops, repeated failures) → automatic sprint checkpoint triggers. Prevents runaway agent loops.

Execution Mode

Interactive-loop within sprints (agents autonomous), human-in-the-loop between sprints.

Consensus Mechanism

Quorum — adversarial doer/reviewer pairs require reviewer approval. Quorum = 1 reviewer (2-agent quorum per task).

Orchestration Flow

Human writes goal document
  ↓ Orchestrator decomposes into epics/US
  ↓ Each task spawned with role + worktree
  ↓ Coder implements → writes checkpoint → submits
  ↓ Reviewer reviews → comments on blackboard
  ↓ Coder revises → resubmits
  ↓ Reviewer approves → Code Reviewer merges to integration
  ↓ Orchestrator picks next task
  ↓ Sprint ends → human checkpoint review
  ↓ Human steers next sprint
08

Ui Cli Surface

Liza — UI / CLI Surface

CLI Binary: liza

  • Name: liza
  • Is thin wrapper: No — 35k LOC Go supervisor binary. The CLI IS the control plane.
  • Install: curl install.sh | bash or binary release

Key subcommands:

liza init                        # Initialize Liza in repo
liza tui                         # Launch live TUI dashboard
liza spawn-agent <role>          # Spawn agent process
liza write-checkpoint            # Write pre-execution checkpoint
liza recover-agent               # Idempotent crash recovery
liza recover-task                # Task cleanup after crash
liza system                      # System operations
liza check                       # Run validation checks
liza review                      # Trigger review
liza agent                       # Agent management
liza task                        # Task lifecycle
liza worktree                    # Git worktree management

Terminal TUI (Bubble Tea)

liza tui — live system state dashboard showing:

  • All registered agents and their status (IDLE/WORKING/REVIEWING/WAITING/HANDOFF/PLANNING)
  • Task board (Kanban-style with current states)
  • Sprint progress
  • Agent health states (OK/DEGRADED)
  • Controls: spawn agents, pause/resume, add tasks, trigger checkpoints

The TUI is built with Bubble Tea (charmbracelet) and uses lipgloss for styling. huh library for form inputs.

Observability (via liza-logs skill)

The liza-logs skill cross-correlates agent logs across the full agent fleet to identify:

  • Misconfiguration in early setups
  • Regressions from provider CLI updates
  • Context quality issues
  • Tool usage anomalies

The context-engineering skill audits:

  • Prompt payload shape
  • Context bloat
  • Cacheability
  • Handoff fit

Agent Interaction Surface

Agents interact with Liza via the CLI (not API):

  • liza write-checkpoint <args> — before any implementation
  • liza commands for state transitions
  • Blackboard (state.yaml) for coordination

No Web Dashboard

Liza has no web UI. TUI + CLI is the complete surface.

Deployment

Single binary, local deployment. No server, no cloud, no containers required.

Related frameworks

same archetype · same primary tool · same memory type

Chachamaru Claude Code Harness ★ 1.6k

Turns raw Claude Code sessions into a disciplined Plan→Work→Review→Release delivery loop with spec contracts and…

DotForge ★ 6

Declare behavioral policies for Claude Code and compile them into enforcing PreToolUse hooks, with cross-project audit and sync…

Superpowers ★ 207k

Enforces spec-first, TDD, and subagent-reviewed development as mandatory automatic workflows rather than optional practices.

Claude-Flow / Ruflo ★ 55k

Eliminates single-agent context limits and sequential bottlenecks by orchestrating fault-tolerant swarms of specialized AI agents…

BMAD-METHOD ★ 48k

Provides a full agile delivery lifecycle with named expert-persona AI collaborators that elicit the human's best thinking rather…

Agent OS ★ 4.6k

Extracts implicit codebase conventions into token-efficient markdown standards files and injects them selectively into AI agent…