@axiomantic/garden 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +149 -0
- package/SKILL.md +133 -0
- package/bin/garden +0 -0
- package/bin/run.js +46 -0
- package/package.json +45 -0
- package/scripts/launch_tmux_swarm.sh +233 -0
- package/scripts/postinstall.js +141 -0
- package/skills/choose-personas/SKILL.md +142 -0
- package/skills/dialectical-pump/SKILL.md +137 -0
- package/skills/garden/SKILL.md +133 -0
- package/skills/launch-workers/SKILL.md +106 -0
- package/skills/orchestrate-swarm/SKILL.md +128 -0
- package/skills/plan-implementation/SKILL.md +129 -0
|
@@ -0,0 +1,141 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
const fs = require('fs');
|
|
3
|
+
const path = require('path');
|
|
4
|
+
const os = require('os');
|
|
5
|
+
const { execSync } = require('child_process');
|
|
6
|
+
|
|
7
|
+
const REPO = 'axiomantic/garden';
|
|
8
|
+
const PKG_NAME = '@axiomantic/garden';
|
|
9
|
+
const BIN_NAME = 'garden';
|
|
10
|
+
|
|
11
|
+
// 1. Ensure binary permissions and provision if missing
|
|
12
|
+
const binDir = path.join(__dirname, '..', 'bin');
|
|
13
|
+
const ext = process.platform === 'win32' ? '.exe' : '';
|
|
14
|
+
const targetBinary = path.join(binDir, `${BIN_NAME}${ext}`);
|
|
15
|
+
|
|
16
|
+
function ensureBinary() {
|
|
17
|
+
if (fs.existsSync(targetBinary)) {
|
|
18
|
+
try {
|
|
19
|
+
fs.chmodSync(targetBinary, 0o755);
|
|
20
|
+
} catch (_) {}
|
|
21
|
+
return;
|
|
22
|
+
}
|
|
23
|
+
|
|
24
|
+
// Attempt to download pre-built release binary
|
|
25
|
+
const pkgVersion = require('../package.json').version;
|
|
26
|
+
const platform = process.platform === 'darwin' ? 'darwin' : (process.platform === 'win32' ? 'windows' : 'linux');
|
|
27
|
+
const arch = process.arch === 'arm64' ? 'arm64' : 'amd64';
|
|
28
|
+
const assetName = `${BIN_NAME}-${platform}-${arch}${platform === 'windows' ? '.zip' : '.tar.gz'}`;
|
|
29
|
+
const downloadUrl = `https://github.com/${REPO}/releases/download/v${pkgVersion}/${assetName}`;
|
|
30
|
+
|
|
31
|
+
try {
|
|
32
|
+
console.log(`[${PKG_NAME}] Downloading native binary from ${downloadUrl}...`);
|
|
33
|
+
const tempArchive = path.join(os.tmpdir(), assetName);
|
|
34
|
+
execSync(`curl -fsSL -o "${tempArchive}" "${downloadUrl}"`, { stdio: 'pipe' });
|
|
35
|
+
|
|
36
|
+
if (!fs.existsSync(binDir)) fs.mkdirSync(binDir, { recursive: true });
|
|
37
|
+
|
|
38
|
+
if (platform === 'windows') {
|
|
39
|
+
execSync(`tar -xf "${tempArchive}" -C "${binDir}"`, { stdio: 'pipe' });
|
|
40
|
+
} else {
|
|
41
|
+
execSync(`tar -xzf "${tempArchive}" -C "${binDir}"`, { stdio: 'pipe' });
|
|
42
|
+
}
|
|
43
|
+
try { fs.unlinkSync(tempArchive); } catch (_) {}
|
|
44
|
+
if (fs.existsSync(targetBinary)) {
|
|
45
|
+
fs.chmodSync(targetBinary, 0o755);
|
|
46
|
+
console.log(`[${PKG_NAME}] Native binary installed successfully.`);
|
|
47
|
+
return;
|
|
48
|
+
}
|
|
49
|
+
} catch (_) {
|
|
50
|
+
// Release download failed or offline; check if nim is available to compile locally
|
|
51
|
+
const srcNim = path.join(__dirname, '..', 'src', `${BIN_NAME}.nim`);
|
|
52
|
+
if (fs.existsSync(srcNim)) {
|
|
53
|
+
try {
|
|
54
|
+
console.log(`[${PKG_NAME}] Compiling from source via nim...`);
|
|
55
|
+
execSync(`nim c -d:release --opt:speed -o:"${targetBinary}" "${srcNim}"`, { stdio: 'pipe' });
|
|
56
|
+
fs.chmodSync(targetBinary, 0o755);
|
|
57
|
+
console.log(`[${PKG_NAME}] Native binary compiled successfully.`);
|
|
58
|
+
return;
|
|
59
|
+
} catch (_) {}
|
|
60
|
+
}
|
|
61
|
+
}
|
|
62
|
+
|
|
63
|
+
console.warn(`[${PKG_NAME}] Note: Native binary could not be downloaded or compiled automatically.`);
|
|
64
|
+
console.warn(`[${PKG_NAME}] Run 'nimble build' or visit https://github.com/${REPO}/releases to install manually.`);
|
|
65
|
+
}
|
|
66
|
+
|
|
67
|
+
ensureBinary();
|
|
68
|
+
|
|
69
|
+
// 2. Auto-equip detected coding assistants with Garden rules
|
|
70
|
+
const home = os.homedir();
|
|
71
|
+
const guideContent = `# Garden Multi-Agent Swarm & Ceremony Guide
|
|
72
|
+
|
|
73
|
+
Garden directs high-level methodology, persona deliberations, and synchronized task execution on top of Rhizo (transport) and Vine (workspace integrator).
|
|
74
|
+
|
|
75
|
+
### 0. Self-Bootstrapping Prerequisite
|
|
76
|
+
This project requires \`rhizo\`, \`vine\`, and \`garden\`. If missing, install via npm:
|
|
77
|
+
\`\`\`bash
|
|
78
|
+
npm install -g @axiomantic/rhizo @axiomantic/vine @axiomantic/garden
|
|
79
|
+
\`\`\`
|
|
80
|
+
|
|
81
|
+
### 1. Invariants & Epistemic Protocol
|
|
82
|
+
* **Zero Theatrical Dialogue**:
|
|
83
|
+
Every dialectical exchange must cite empirical evidence obtained from tool execution (file line citations, test suite runs, AST analysis, compiler output). Theatrical roleplay without tool grounding is strictly prohibited.
|
|
84
|
+
* **Single-Source Planning**:
|
|
85
|
+
All tasks, locks, and strands must be coordinated via \`implementation_plan.md\`. Dynamic progress must be tracked in lockstep with plan checkboxes (\`- [ ]\` to \`- [x]\`) and harness To-Do tracking.
|
|
86
|
+
* **Emergent Design Addendum Protocol**:
|
|
87
|
+
Workers discovering architectural discrepancies cannot unilaterally deviate from \`design.md\`. They must submit a formal \`addendum_<topic>.md\` with rationale, await Orchestrator ratification, update \`design.md\`, and refresh \`implementation_plan.md\`.
|
|
88
|
+
|
|
89
|
+
### 2. Fleet Lifecycle & Multiplexer Discipline
|
|
90
|
+
* **Tmux Multiplexing**:
|
|
91
|
+
All swarm workers run inside managed tmux panes created via \`garden launch\` or \`scripts/launch_tmux_swarm.sh\`. Never detach unmanaged background processes with \`&\` or redirect output.
|
|
92
|
+
* **Continuous Listening**:
|
|
93
|
+
Workers must keep their Rhizo listener active (\`rhizo listen <agent>\`) with zero-timeout infinite wait to prevent token thrashing.
|
|
94
|
+
|
|
95
|
+
### 3. The Two-Key Gate & Strand Weaving
|
|
96
|
+
Never weave a strand into the canonical trunk without passing both keys:
|
|
97
|
+
* **Key 1 (Mechanical)**: In-memory conflict pre-check (\`git merge-tree --write-tree\`).
|
|
98
|
+
* **Key 2 (Semantic)**: Automated compiler and test suite run inside the strand.
|
|
99
|
+
* **Weave**: \`vine weave && rhizo ack queue:<project>:tasks <task_id>\`
|
|
100
|
+
`;
|
|
101
|
+
|
|
102
|
+
function safeWrite(destDir, fileName, content) {
|
|
103
|
+
try {
|
|
104
|
+
if (!fs.existsSync(destDir)) {
|
|
105
|
+
fs.mkdirSync(destDir, { recursive: true });
|
|
106
|
+
}
|
|
107
|
+
const target = path.join(destDir, fileName);
|
|
108
|
+
fs.writeFileSync(target, content, 'utf8');
|
|
109
|
+
console.log(`[${PKG_NAME}] Provisioned rules to: ${target}`);
|
|
110
|
+
} catch (err) {
|
|
111
|
+
// Non-fatal if permissions or sandbox prevent writing
|
|
112
|
+
}
|
|
113
|
+
}
|
|
114
|
+
|
|
115
|
+
function cleanAndInstall(destDir, oldName, newName) {
|
|
116
|
+
try {
|
|
117
|
+
const oldPath = path.join(destDir, oldName);
|
|
118
|
+
if (fs.existsSync(oldPath)) {
|
|
119
|
+
try { fs.unlinkSync(oldPath); } catch (_) {}
|
|
120
|
+
}
|
|
121
|
+
safeWrite(destDir, newName, guideContent);
|
|
122
|
+
} catch (_) {}
|
|
123
|
+
}
|
|
124
|
+
|
|
125
|
+
// Claude Code
|
|
126
|
+
const claudeDir = path.join(home, '.claude');
|
|
127
|
+
if (fs.existsSync(claudeDir)) {
|
|
128
|
+
cleanAndInstall(path.join(claudeDir, 'rules'), 'agora.md', 'garden.md');
|
|
129
|
+
}
|
|
130
|
+
|
|
131
|
+
// OpenCode
|
|
132
|
+
const opencodeDir = path.join(home, '.config', 'opencode');
|
|
133
|
+
if (fs.existsSync(opencodeDir)) {
|
|
134
|
+
cleanAndInstall(path.join(opencodeDir, 'instructions'), 'agora.md', 'garden.md');
|
|
135
|
+
}
|
|
136
|
+
|
|
137
|
+
// Antigravity
|
|
138
|
+
const antigravityDir = path.join(home, '.gemini', 'antigravity');
|
|
139
|
+
if (fs.existsSync(antigravityDir)) {
|
|
140
|
+
cleanAndInstall(path.join(antigravityDir, 'rules'), 'agora.md', 'garden.md');
|
|
141
|
+
}
|
|
@@ -0,0 +1,142 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: choose-personas
|
|
3
|
+
description: "Selects, balances, and configures specialized agent personas for a Garden swarm task. Analyzes codebase context, domain complexity, and task requirements to formulate a triad of complementary personas with opposing priorities. For every persona, explicitly recommends the optimal coding harness (e.g. OpenCode Desktop, Claude Code CLI, Antigravity, OpenAI Codex) and foundation model (e.g. Gemini 3.8 Flash, Claude 3.5 Sonnet, Claude 3 Opus, GPT-4o, local models) aligned with operator preferences. Solicits operator confirmation or edits with candidate alternatives via interactive questions, and outputs garden-swarm.json. Triggers: 'choose personas', 'select personas', 'set up agent team', 'assemble personas for this task', 'recommend agents'."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# `choose-personas`: Dynamic Swarm Persona Selection & Harness/Model Pairing
|
|
7
|
+
|
|
8
|
+
> **Calibrate the Minds Before Booting the Hands**
|
|
9
|
+
> *A multi-agent swarm is only as effective as the diversity, specialization, and cognitive balance of its personas. This skill pairs domain roles with their optimal coding harnesses and foundation models.*
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. The Triadic Balance Heuristic
|
|
14
|
+
|
|
15
|
+
Every engineering task benefits from a triad of three distinct, tension-generating archetypes:
|
|
16
|
+
|
|
17
|
+
```mermaid
|
|
18
|
+
graph TD
|
|
19
|
+
A["Archetype 1: The Systems Architect<br/>(Macro Architecture, Invariants, Coherence)"]
|
|
20
|
+
B["Archetype 2: The Purist Auditor<br/>(Code Quality, Standards, Rigorous Proof, Zero Sloppiness)"]
|
|
21
|
+
C["Archetype 3: The DevEx & Implementation Lead<br/>(Ergonomics, API Utility, Frictionless Execution)"]
|
|
22
|
+
|
|
23
|
+
A <-->|Structural Tension| B
|
|
24
|
+
B <-->|Pragmatic Tension| C
|
|
25
|
+
C <-->|Coherence Tension| A
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
1. **The Systems Architect** (e.g., Marcus Vance):
|
|
29
|
+
- **Focus**: Global system topology, invariants, lifecycle management, failure modes, cross-component boundaries.
|
|
30
|
+
- **Bias**: Prefers structural purity and comprehensive conceptual models.
|
|
31
|
+
2. **The Purist Auditor / Refactoring Specialist** (e.g., Caleb Thorne / Dr. Vance):
|
|
32
|
+
- **Focus**: Single-source of truth (SSOT), ISO standards compliance, dead-code elimination, zero green mirages, edge-case failure proofs.
|
|
33
|
+
- **Bias**: Adversarial skeptic. Assumes claims are unproven until verified by an automated test or compiler run.
|
|
34
|
+
3. **The DevEx & Implementation Lead** (e.g., Elena Rostova):
|
|
35
|
+
- **Focus**: Developer experience, API ergonomics, ease of adoption, idiomatic conventions, pragmatic delivery.
|
|
36
|
+
- **Bias**: Champions the human engineer using the tool; eliminates cognitive overhead and unnecessary friction.
|
|
37
|
+
|
|
38
|
+
---
|
|
39
|
+
|
|
40
|
+
## 2. Harness & Model Matching Matrix
|
|
41
|
+
|
|
42
|
+
When proposing personas, the assistant must explicitly pair each persona with an appropriate **coding harness** and **foundation model**, taking operator preferences into account (defaulting to Antigravity + Gemini 3.8 Flash for rapid implementation, and invoking Claude for deep adversarial auditing):
|
|
43
|
+
|
|
44
|
+
| Role Mandate | Recommended Harness | Recommended Model Tier | Rationale |
|
|
45
|
+
| :--- | :--- | :--- | :--- |
|
|
46
|
+
| **Architectural Design & Systems Modeling** | **Antigravity** or **OpenCode** | **Gemini 3.8 Flash** or **Claude 3.5 Sonnet** | Fast token throughput, deep reasoning, superior multi-file architectural comprehension, and native background ear support. |
|
|
47
|
+
| **Adversarial Audit & Code Quality Purism** | **Claude Code CLI** | **Claude 3 Opus** or **Claude 3.5 Sonnet** | Uncompromising adherence to instructions, meticulous attention to negative controls, zero tolerance for superficial green tests. |
|
|
48
|
+
| **DevEx, Rapid Prototyping & Implementation** | **Antigravity** | **Gemini 3.8 Flash** | Native reactive tool execution (`run_command`), rapid file modification, direct terminal feedback. |
|
|
49
|
+
| **Hermetic / Local Security Analysis** | **Headless Terminal Worker** | **Ollama / Local DeepSeek-R1** | Air-gapped execution for proprietary credentials, licensing checks, or sensitive security audits. |
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## 3. The Calibration Workflow
|
|
54
|
+
|
|
55
|
+
```mermaid
|
|
56
|
+
sequenceDiagram
|
|
57
|
+
autonumber
|
|
58
|
+
participant Orch as Orchestrator Chat
|
|
59
|
+
participant Repo as Codebase Context
|
|
60
|
+
participant User as Human Operator
|
|
61
|
+
|
|
62
|
+
Orch->>Repo: Inspects project language, repo structure & open issues
|
|
63
|
+
Note over Orch: Formulates primary triad + 2 alternate candidates
|
|
64
|
+
Orch->>User: Renders interactive ask_question modal with recommendations & alternatives
|
|
65
|
+
User-->>Orch: Submits chosen triad (or specifies custom modifications)
|
|
66
|
+
Orch->>Repo: Writes garden-swarm.json manifest
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
### Step 1: Codebase & Task Analysis
|
|
70
|
+
1. Inspect repository stack (e.g., Nim, Rust, Python, TypeScript, C).
|
|
71
|
+
2. Read project `AGENTS.md` and `README.md` to identify existing conventions.
|
|
72
|
+
3. Determine task scope:
|
|
73
|
+
- *Refactoring / Technical Debt*: Prioritize Refactoring Purist + Test Auditor.
|
|
74
|
+
- *Greenfield Subsystem*: Prioritize Systems Architect + API Designer.
|
|
75
|
+
- *Security / Compliance*: Prioritize ISO Compliance Auditor + Security Adversary.
|
|
76
|
+
|
|
77
|
+
### Step 2: Formulate Recommendation & Alternatives
|
|
78
|
+
Synthesize the primary triad and at least two alternative candidates:
|
|
79
|
+
- **Primary Triad**:
|
|
80
|
+
- Persona 1: Name, Role title, Mandate, Suggested Harness, Suggested Model.
|
|
81
|
+
- Persona 2: Name, Role title, Mandate, Suggested Harness, Suggested Model.
|
|
82
|
+
- Persona 3: Name, Role title, Mandate, Suggested Harness, Suggested Model.
|
|
83
|
+
- **Alternative Candidates**:
|
|
84
|
+
- Alternate A: e.g. Performance Benchmarking Engineer.
|
|
85
|
+
- Alternate B: e.g. Documentation & Developer Education Lead.
|
|
86
|
+
|
|
87
|
+
### Step 3: Interactive Operator Ratification (`ask_question`)
|
|
88
|
+
Invoke `ask_question` with structured, selectable options:
|
|
89
|
+
- Option 1 (Recommended): Primary Triad (with explicit harnesses and models listed).
|
|
90
|
+
- Option 2: Alternative balance (e.g. replacing Purist with Performance Engineer).
|
|
91
|
+
- Option 3: Custom configuration (allows user write-in).
|
|
92
|
+
|
|
93
|
+
### Step 4: Generate Swarm Manifest (`garden-swarm.json`)
|
|
94
|
+
Once ratified, write `garden-swarm.json` to the target project directory:
|
|
95
|
+
|
|
96
|
+
```json
|
|
97
|
+
{
|
|
98
|
+
"project": "my-project",
|
|
99
|
+
"created_at": "2026-09-28T12:00:00Z",
|
|
100
|
+
"workers": [
|
|
101
|
+
{
|
|
102
|
+
"name": "architect",
|
|
103
|
+
"persona": "Marcus Vance",
|
|
104
|
+
"role": "Staff Systems Architect",
|
|
105
|
+
"harness": "antigravity",
|
|
106
|
+
"model": "gemini-3-8-flash",
|
|
107
|
+
"tags": ["systems", "architecture", "coordinator"],
|
|
108
|
+
"system_prompt": "You are Marcus Vance, Staff Systems Architect...",
|
|
109
|
+
"startup_command": "rhizo listen architect"
|
|
110
|
+
},
|
|
111
|
+
{
|
|
112
|
+
"name": "auditor",
|
|
113
|
+
"persona": "Caleb Thorne",
|
|
114
|
+
"role": "Code Quality & Refactoring Purist",
|
|
115
|
+
"harness": "claude-code",
|
|
116
|
+
"model": "claude-3-5-sonnet",
|
|
117
|
+
"tags": ["qa", "audit", "purist"],
|
|
118
|
+
"system_prompt": "You are Caleb Thorne, Refactoring Purist...",
|
|
119
|
+
"startup_command": "claude --agent auditor"
|
|
120
|
+
},
|
|
121
|
+
{
|
|
122
|
+
"name": "implementer",
|
|
123
|
+
"persona": "Elena Rostova",
|
|
124
|
+
"role": "DevEx & Implementation Lead",
|
|
125
|
+
"harness": "antigravity",
|
|
126
|
+
"model": "gemini-3-8-flash",
|
|
127
|
+
"tags": ["dev", "devex", "build"],
|
|
128
|
+
"system_prompt": "You are Elena Rostova, DevEx Lead...",
|
|
129
|
+
"startup_command": "rhizo listen implementer"
|
|
130
|
+
}
|
|
131
|
+
]
|
|
132
|
+
}
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
---
|
|
136
|
+
|
|
137
|
+
## 4. Verification & Handoff
|
|
138
|
+
|
|
139
|
+
Before concluding:
|
|
140
|
+
1. Verify `garden-swarm.json` is syntactically valid JSON.
|
|
141
|
+
2. Confirm each worker has unique `name` and non-empty `tags`.
|
|
142
|
+
3. Proceed directly to [`launch-workers`](../launch-workers/SKILL.md).
|
|
@@ -0,0 +1,137 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dialectical-pump
|
|
3
|
+
description: "Drives empirical multi-perspective deliberation and synthesis across agent personas. Enforces the strict invariant that dialectical exchanges are NOT theatrical dialogue: every turn must be grounded in tool calls (reading file lines, executing tests, running benchmarks, checking git history). Operates across three sequential stages: (1) Research & Understanding Doc with automated Fact-Check Gate, (2) Product & System Architecture Design Doc, and (3) Adversarial Design Review, Audit Report generation, and finding remediation. Triggers: 'dialectical pump', 'run dialectical pump', 'pump perspectives', 'triadic deliberation', 'dialectical research', 'dialectical design', 'dialectical review'."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# `dialectical-pump`: Grounded Multi-Persona Deliberation Engine
|
|
7
|
+
|
|
8
|
+
> **Thesis $\times$ Antithesis $\to$ Empirical Synthesis**
|
|
9
|
+
> *The Dialectical Pump is an epistemic machine. It prevents hallucinated consensus and green mirages by forcing opposing personas to prove every assertion through real tool execution.*
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. The Core Invariant: Zero Theatrical Dialogue
|
|
14
|
+
|
|
15
|
+
> [!CAUTION] **STRICT PROHIBITION: Theatrical Dialogue is Rejected**
|
|
16
|
+
> A common failure mode in LLM roleplay is generating conversational chit-chat:
|
|
17
|
+
> *"Persona A: I think we should use Redis! Persona B: I agree, but what about memory? Persona A: Good point!"*
|
|
18
|
+
> **This is banned.**
|
|
19
|
+
|
|
20
|
+
Every turn taken by a persona in the Dialectical Pump must follow the **Empirical Grounding Protocol**:
|
|
21
|
+
1. **Tool Invocation**: Every claim must be substantiated by a tool call:
|
|
22
|
+
- Reading exact line numbers: `view_file(AbsolutePath=..., StartLine=..., EndLine=...)`.
|
|
23
|
+
- Running test suites: `run_command(CommandLine="pytest ...")`.
|
|
24
|
+
- Measuring execution or memory: `run_command(CommandLine="time ...")`.
|
|
25
|
+
- Checking git history/diffs: `run_command(CommandLine="git log -S ...")`.
|
|
26
|
+
2. **Hard Evidence Citations**: Every critique must cite verifiable evidence:
|
|
27
|
+
- *Prohibited*: "This function looks inefficient."
|
|
28
|
+
- *Mandated*: "Profiling `parsePayload` at `src/resp.nim:88` reveals an allocation of a 64KB temporary string per message; under 10k messages/sec, this triggers 640MB/sec of GC churn as verified by `nimble bench`."
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## 2. The Three Dialectical Stages
|
|
33
|
+
|
|
34
|
+
The Dialectical Pump executes across three distinct stages of a project:
|
|
35
|
+
|
|
36
|
+
```mermaid
|
|
37
|
+
flowchart TD
|
|
38
|
+
subgraph Stage1["Stage 1: Grounded Research"]
|
|
39
|
+
S1A["1. Triad plans research questions"]
|
|
40
|
+
S1B["2. Workers explore code & tests"]
|
|
41
|
+
S1C["3. Synthesize understanding.md"]
|
|
42
|
+
S1D["4. Automated Fact-Check Gate"]
|
|
43
|
+
S1A --> S1B --> S1C --> S1D
|
|
44
|
+
end
|
|
45
|
+
|
|
46
|
+
subgraph Stage2["Stage 2: Architecture & Design"]
|
|
47
|
+
S2A["1. Systems Architect drafts thesis"]
|
|
48
|
+
S2B["2. Purist Auditor attacks failure modes"]
|
|
49
|
+
S2C["3. DevEx Lead balances ergonomics"]
|
|
50
|
+
S2D["4. Synthesize design.md"]
|
|
51
|
+
S2A --> S2B --> S2C --> S2D
|
|
52
|
+
end
|
|
53
|
+
|
|
54
|
+
subgraph Stage3["Stage 3: Adversarial Review & Audit"]
|
|
55
|
+
S3A["1. Auditor files audit_report.md"]
|
|
56
|
+
S3B["2. Personas resolve findings"]
|
|
57
|
+
S3C["3. Ratified design.md"]
|
|
58
|
+
S3A --> S3B --> S3C
|
|
59
|
+
end
|
|
60
|
+
|
|
61
|
+
Stage1 --> Stage2 --> Stage3
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## 3. Stage 1: Grounded Research & Fact-Check Gate
|
|
67
|
+
|
|
68
|
+
### Step 1.1: Research Plan Formulation
|
|
69
|
+
The triadic personas inspect the assignment and agree on the empirical questions:
|
|
70
|
+
- What are the existing invariants in the codebase?
|
|
71
|
+
- What dependencies and protocols exist?
|
|
72
|
+
- What test suites cover this subsystem?
|
|
73
|
+
|
|
74
|
+
### Step 1.2: Codebase Exploration
|
|
75
|
+
Workers read actual files, verify test suites, and map domain structures.
|
|
76
|
+
|
|
77
|
+
### Step 1.3: Generate Understanding Document (`understanding.md`)
|
|
78
|
+
The triad synthesizes their findings into `understanding.md` containing:
|
|
79
|
+
- Domain Glossary & Invariants.
|
|
80
|
+
- Data Flow Diagrams.
|
|
81
|
+
- Identified Constraints & Technical Debt.
|
|
82
|
+
|
|
83
|
+
### Step 1.4: The Strict Fact-Check Gate
|
|
84
|
+
Before proceeding to design, a dedicated Auditor persona audits `understanding.md`:
|
|
85
|
+
- Every file reference must exist (`test -f <path>`).
|
|
86
|
+
- Every function signature cited must match reality.
|
|
87
|
+
- If any claim is ungrounded or fabricated, the pump repeats Step 1.2 until 100% verified.
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## 4. Stage 2: Architecture & System Design (`design.md`)
|
|
92
|
+
|
|
93
|
+
Once research is fact-checked, the pump shifts to product and technical design:
|
|
94
|
+
|
|
95
|
+
### Step 2.1: The Thesis (Systems Architect)
|
|
96
|
+
The Systems Architect proposes the macro architecture:
|
|
97
|
+
- Module decomposition.
|
|
98
|
+
- Data structures and wire formats.
|
|
99
|
+
- Concurrency model and lifecycle states.
|
|
100
|
+
|
|
101
|
+
### Step 2.2: The Antithesis (Purist Auditor)
|
|
102
|
+
The Purist Auditor stress-tests the proposal against concrete failure modes:
|
|
103
|
+
- Concurrency race conditions: "What happens if process A dies between lines X and Y?"
|
|
104
|
+
- Resource leaks: "Where are file descriptors closed during exception unwinding?"
|
|
105
|
+
- Backwards compatibility: "Does this break existing configs or CLI arguments?"
|
|
106
|
+
|
|
107
|
+
### Step 2.3: The Synthesis (DevEx & Implementation Lead)
|
|
108
|
+
The DevEx Lead resolves the dialectic:
|
|
109
|
+
- Eliminates unnecessary abstractions that create ergonomics drag.
|
|
110
|
+
- Hardens the API contracts.
|
|
111
|
+
- Produces the ratified **`design.md`**.
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## 5. Stage 3: Adversarial Review & Audit Report
|
|
116
|
+
|
|
117
|
+
### Step 3.1: Forensic Audit Inspection
|
|
118
|
+
An Auditor persona performs a line-by-line inspection of `design.md` against single-source truth and ISO standards, generating **`audit_report.md`**:
|
|
119
|
+
- Defect codes: `CRIT-01`, `WARN-02`, `DOC-03`.
|
|
120
|
+
- Root cause analysis.
|
|
121
|
+
- Specific non-prescriptive recommendation options.
|
|
122
|
+
|
|
123
|
+
### Step 3.2: Remediation & Resolution
|
|
124
|
+
The triad meets to address every finding in `audit_report.md`:
|
|
125
|
+
- For each defect code: select an option, update `design.md`, and record the resolution in the audit report.
|
|
126
|
+
- The gate only clears when **0 critical or blocker defects remain open**.
|
|
127
|
+
|
|
128
|
+
---
|
|
129
|
+
|
|
130
|
+
## 6. Output Artifacts
|
|
131
|
+
|
|
132
|
+
At the conclusion of the Dialectical Pump:
|
|
133
|
+
1. `understanding.md` (Grounded and fact-checked).
|
|
134
|
+
2. `design.md` (Debated, hardened, and synthesized).
|
|
135
|
+
3. `audit_report.md` (All findings addressed and closed).
|
|
136
|
+
|
|
137
|
+
Proceed immediately to [`plan-implementation`](../plan-implementation/SKILL.md).
|
|
@@ -0,0 +1,133 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: garden
|
|
3
|
+
description: "Master entrypoint and end-to-end ceremony director for multi-agent swarms operating on top of Rhizo (transport) and Vine (workspace integrator). Guides the user and orchestrator session through the full lifecycle: persona selection with harness/model pairing, tmux worker fleet provisioning with live terminal viewer, 3-stage empirical dialectical pump (research, design, audit), master implementation planning with locking/strand schedules, and live swarm execution with Two-Key gate verification and fast-forward trunk weaving. Triggers: 'garden', 'run garden', 'swarm this project', 'orchestrate with garden', 'start garden swarm', 'run the full garden ceremony'."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Garden: Multi-Agent Swarm Ceremony & Orchestration Engine
|
|
7
|
+
|
|
8
|
+
> **The Sovereign Orchestration Layer for Autonomous AI Swarms**
|
|
9
|
+
> *Where `rhizo` is the transport nervous system and `vine` is the workspace integrator, `garden` is the institutional intellect, deliberation crucible, and master ceremony conductor.*
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. Architectural Architecture & Layering
|
|
14
|
+
|
|
15
|
+
Garden coordinates teams of heterogeneous AI coding assistants across terminals and machines:
|
|
16
|
+
|
|
17
|
+
```mermaid
|
|
18
|
+
flowchart TD
|
|
19
|
+
subgraph Garden["Garden Layer (Methodology & Ceremonies)"]
|
|
20
|
+
Phase1["Phase 1: choose-personas (Team Selection & Models)"]
|
|
21
|
+
Phase2["Phase 2: launch-workers (tmux & Terminal Viewer)"]
|
|
22
|
+
Phase3["Phase 3: dialectical-pump (Research ➔ Design ➔ Audit)"]
|
|
23
|
+
Phase4["Phase 4: plan-implementation (Locking & Strands)"]
|
|
24
|
+
Phase5["Phase 5: orchestrate-swarm (Dispatch & Vine Weaving)"]
|
|
25
|
+
end
|
|
26
|
+
|
|
27
|
+
subgraph Infrastructure["Coordination Infrastructure"]
|
|
28
|
+
Rhizo["Rhizo (Redis Bus, Fencing Mutexes, Work Queues)"]
|
|
29
|
+
Vine["Vine (APFS CoW Strands, Two-Key Gate, Weaving)"]
|
|
30
|
+
end
|
|
31
|
+
|
|
32
|
+
Phase1 --> Phase2 --> Phase3 --> Phase4 --> Phase5
|
|
33
|
+
Phase2 -.-> Rhizo
|
|
34
|
+
Phase3 -.-> Rhizo
|
|
35
|
+
Phase4 -.-> Rhizo & Vine
|
|
36
|
+
Phase5 -.-> Rhizo & Vine
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## 2. The 5-Phase End-to-End Ceremony
|
|
42
|
+
|
|
43
|
+
When invoked, the Orchestrator (the primary conversation chat) executes these five phases sequentially. Never skip phases or invert the order.
|
|
44
|
+
|
|
45
|
+
```mermaid
|
|
46
|
+
sequenceDiagram
|
|
47
|
+
autonumber
|
|
48
|
+
actor User as Human Operator
|
|
49
|
+
participant Orch as Main Chat (Orchestrator)
|
|
50
|
+
participant Swarm as Tmux Worker Swarm
|
|
51
|
+
participant Bus as Rhizo (Redis)
|
|
52
|
+
participant Gate as Vine (Strands & Gate)
|
|
53
|
+
|
|
54
|
+
User->>Orch: "garden: implement feature X"
|
|
55
|
+
Note over Orch: Phase 1: Team Calibration
|
|
56
|
+
Orch->>User: Suggests Persona Roster (Roles, Harnesses, Models) via ask_question
|
|
57
|
+
User-->>Orch: Ratifies / Adjusts Roster
|
|
58
|
+
|
|
59
|
+
Note over Orch: Phase 2: Fleet Provisioning
|
|
60
|
+
Orch->>Swarm: Executes launch-workers (tmux panes + Ghostty/Terminal viewer)
|
|
61
|
+
Swarm->>Bus: rhizo open + rhizo listen (Workers armed)
|
|
62
|
+
|
|
63
|
+
Note over Orch: Phase 3: Empirical Dialectic
|
|
64
|
+
Orch->>Swarm: Dispatches dialectical-pump
|
|
65
|
+
Note over Swarm: 1. Research ➔ understanding.md ➔ Fact-Check Gate<br/>2. Architecture ➔ design.md<br/>3. Adversarial Audit ➔ audit_report.md ➔ Remediation
|
|
66
|
+
Swarm-->>Orch: Ratified design.md & cleared audit report
|
|
67
|
+
|
|
68
|
+
Note over Orch: Phase 4: Master Planning
|
|
69
|
+
Orch->>Orch: Authors implementation_plan.md (Locks, Strands, To-Do list)
|
|
70
|
+
|
|
71
|
+
Note over Orch: Phase 5: Swarm Execution & Weaving
|
|
72
|
+
loop For Each Plan Task
|
|
73
|
+
Orch->>Bus: Dispatch task (rhizo send / enqueue)
|
|
74
|
+
Bus->>Swarm: Worker claims lease (rhizo claim)
|
|
75
|
+
Swarm->>Gate: Creates strand (vine new)
|
|
76
|
+
Swarm->>Swarm: Implements code + verifies tests
|
|
77
|
+
Swarm->>Gate: Verifies Two-Key Gate (vine gate)
|
|
78
|
+
Swarm->>Orch: Reports gate pass (rhizo reply)
|
|
79
|
+
Orch->>Gate: Fast-forward merge (vine weave)
|
|
80
|
+
Orch->>Orch: Updates plan checkbox & Harness To-Do
|
|
81
|
+
end
|
|
82
|
+
Orch->>User: Mission Accomplished Summary
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## 3. Phase Transition Protocols & Quality Gates
|
|
88
|
+
|
|
89
|
+
### Gate 1 $\to$ 2: Persona Ratification Gate
|
|
90
|
+
- **Condition**: Operator has confirmed the roster via `ask_question`.
|
|
91
|
+
- **Artifact**: `garden-swarm.json` persisted in the project directory.
|
|
92
|
+
- **Action**: Call `launch-workers`.
|
|
93
|
+
|
|
94
|
+
### Gate 2 $\to$ 3: Cluster Readiness Gate
|
|
95
|
+
- **Condition**: All worker panes booted, heartbeats active in Redis.
|
|
96
|
+
- **Verification**: `rhizo who --json` confirms 100% of agents online and tagged.
|
|
97
|
+
- **Action**: Call `dialectical-pump`.
|
|
98
|
+
|
|
99
|
+
### Gate 3 $\to$ 4: Design Audit Clearance Gate
|
|
100
|
+
- **Condition**:
|
|
101
|
+
1. `understanding.md` passed the Fact-Check Gate (zero ungrounded claims).
|
|
102
|
+
2. `design.md` authored and debated by the triadic pump.
|
|
103
|
+
3. `audit_report.md` contains 0 open `CRIT` or `BLOCKER` defects.
|
|
104
|
+
- **Action**: Call `plan-implementation`.
|
|
105
|
+
|
|
106
|
+
### Gate 4 $\to$ 5: Plan Alignment Gate
|
|
107
|
+
- **Condition**: `implementation_plan.md` complete with task matrix, locking schedule, vine strand lifecycles, and emergent design addendum protocol.
|
|
108
|
+
- **Action**: Call `orchestrate-swarm`.
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## 4. Sub-Skill Reference Map
|
|
113
|
+
|
|
114
|
+
When executing Garden, invoke the sub-skills at their designated phases:
|
|
115
|
+
|
|
116
|
+
| Phase | Skill Name | Description | Primary Artifacts |
|
|
117
|
+
| :--- | :--- | :--- | :--- |
|
|
118
|
+
| **Phase 1** | [`choose-personas`](../choose-personas/SKILL.md) | Analyzes task, formulates 3 balanced personas with suggested **coding harness** and **model**, and confirms with operator. | `garden-swarm.json` |
|
|
119
|
+
| **Phase 2** | [`launch-workers`](../launch-workers/SKILL.md) | Provisions tmux session with worker panes, registers `rhizo open`, arms listeners, and launches OS terminal viewer (Ghostty / Terminal.app). | Live tmux session, visible terminal |
|
|
120
|
+
| **Phase 3** | [`dialectical-pump`](../dialectical-pump/SKILL.md) | Drives empirical multi-persona debate grounded in tool calls (file reading, test running, AST inspecting). Produces research, design, and audit docs. | `understanding.md`, `design.md`, `audit_report.md` |
|
|
121
|
+
| **Phase 4** | [`plan-implementation`](../plan-implementation/SKILL.md) | Authors master implementation plan detailing task assignments, `rhizo` locks (`--fencing`), `vine` strands, dynamic checkboxes, and To-Do tracking. | `implementation_plan.md` |
|
|
122
|
+
| **Phase 5** | [`orchestrate-swarm`](../orchestrate-swarm/SKILL.md) | Main-chat governor: dispatches tasks over Redis, tracks heartbeats, approves emergent design addenda, and executes `vine weave` upon Two-Key gate pass. | Completed code, woven trunk, git commits |
|
|
123
|
+
|
|
124
|
+
---
|
|
125
|
+
|
|
126
|
+
## 5. Invariants & Rules of Engagement
|
|
127
|
+
|
|
128
|
+
1. **The Supreme Orchestrator Invariant**:
|
|
129
|
+
The primary conversation session acts as the Supreme Orchestrator. It coordinates, plans, reviews, and merges. It delegates intensive multi-file edits to the worker fleet.
|
|
130
|
+
2. **Zero Theatrical Dialogue**:
|
|
131
|
+
In dialectical deliberations, every assertion must be backed by empirical evidence (line citations, test execution outputs, compiler errors).
|
|
132
|
+
3. **No Unmanaged Daemons / Zero Dirty Commits**:
|
|
133
|
+
All coordination metadata (`.rhizo.*`, `.vine.*`, `*.lock`) must remain in `.gitignore`. Workers must adhere to the Two-Key Gate before any code touches the canonical trunk.
|
|
@@ -0,0 +1,106 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: launch-workers
|
|
3
|
+
description: "Provisions an active worker fleet inside a dedicated tmux session and launches an OS-level terminal viewer (Ghostty / Terminal.app). Reads garden-swarm.json, creates named tmux windows/panes for each worker, configures environment variables (RHIZO_AGENT_NAME, project path), registers each agent in Redis with rhizo open, arms background listeners, and runs AppleScript or open commands on macOS to display the live worker windows to the operator. Verifies cluster heartbeat readiness via rhizo who --json before handing off. Triggers: 'launch workers', 'spin up workers', 'start worker swarm', 'open tmux swarm', 'launch fleet'."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# `launch-workers`: Automated Tmux Swarm Provisioning & Terminal Viewer
|
|
7
|
+
|
|
8
|
+
> **From Manifest to Live Terminals in Under 2 Seconds**
|
|
9
|
+
> *Tmux multiplexes the background worker processes while OS-level desktop scripting opens your preferred terminal app so you can observe the swarm in real time.*
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 1. System Requirements & Invariants
|
|
14
|
+
|
|
15
|
+
1. **`tmux` is Required**:
|
|
16
|
+
- `tmux 3.0+` must be installed on the host (`command -v tmux`). If missing, fail fast and instruct the operator to install (`brew install tmux`).
|
|
17
|
+
2. **`rhizo` is Required**:
|
|
18
|
+
- Rhizo engine must be present (`npm install -g @axiomantic/rhizo`).
|
|
19
|
+
3. **No Terminal Fallbacks**:
|
|
20
|
+
- Workers are strictly managed inside tmux windows/panes. We do not detach headless rogue background processes with `nohup` or `&`.
|
|
21
|
+
4. **Desktop Viewer Priority on macOS**:
|
|
22
|
+
- Automatically detects installed terminal emulators:
|
|
23
|
+
- **Priority 1: Ghostty** (`/Applications/Ghostty.app`)
|
|
24
|
+
- **Priority 2: iTerm2** (`/Applications/iTerm.app`)
|
|
25
|
+
- **Priority 3: macOS Terminal** (`/System/Applications/Utilities/Terminal.app`)
|
|
26
|
+
- Pops open a visible terminal window running `tmux attach-session -t garden-<project>`.
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## 2. The Provisioning Flow
|
|
31
|
+
|
|
32
|
+
```mermaid
|
|
33
|
+
sequenceDiagram
|
|
34
|
+
autonumber
|
|
35
|
+
participant Orch as Main Chat (Orchestrator)
|
|
36
|
+
participant Script as launch_tmux_swarm.sh
|
|
37
|
+
participant Tmux as tmux Daemon
|
|
38
|
+
participant OS as macOS Window Server (Ghostty / Terminal)
|
|
39
|
+
participant Redis as Rhizo (Redis Bus)
|
|
40
|
+
|
|
41
|
+
Orch->>Script: Invokes with --swarm-file garden-swarm.json
|
|
42
|
+
Script->>Tmux: Creates session garden-<project>
|
|
43
|
+
loop For Each Worker in Manifest
|
|
44
|
+
Script->>Tmux: Creates named window/pane
|
|
45
|
+
Script->>Tmux: Injects RHIZO_AGENT_NAME & cd <project>
|
|
46
|
+
Script->>Tmux: Sends rhizo open <name> "<tags>"
|
|
47
|
+
Script->>Tmux: Arms listener (rhizo listen or custom startup command)
|
|
48
|
+
Tmux->>Redis: Registers heartbeat & listener lock
|
|
49
|
+
end
|
|
50
|
+
Script->>OS: Opens Ghostty/Terminal attached to tmux session
|
|
51
|
+
Script-->>Orch: Returns JSON status
|
|
52
|
+
Orch->>Redis: Verifies cluster readiness (rhizo who --json)
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## 3. Execution Procedure
|
|
58
|
+
|
|
59
|
+
### Step 1: Run the Swarm Provisioner
|
|
60
|
+
Execute [`scripts/launch_tmux_swarm.sh`](file:///Users/eek/Development/garden/scripts/launch_tmux_swarm.sh) with the active project path and manifest:
|
|
61
|
+
|
|
62
|
+
```bash
|
|
63
|
+
/Users/eek/Development/garden/scripts/launch_tmux_swarm.sh \
|
|
64
|
+
--project-dir "$(pwd)" \
|
|
65
|
+
--swarm-file "garden-swarm.json" \
|
|
66
|
+
--force
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
- `--force`: Kills any stale prior session with the same project name before provisioning a clean fleet.
|
|
70
|
+
- Automatically launches Ghostty or Terminal.app on macOS attached to the new session.
|
|
71
|
+
|
|
72
|
+
### Step 2: Verify Cluster Readiness Gate
|
|
73
|
+
Before dispatching tasks, verify that every worker from `garden-swarm.json` is actively registered in Redis and displaying valid heartbeats:
|
|
74
|
+
|
|
75
|
+
```bash
|
|
76
|
+
rhizo who --json
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
**Pass Criteria**:
|
|
80
|
+
1. All worker names in `garden-swarm.json` appear in `active_agents`.
|
|
81
|
+
2. Heartbeats have active TTLs (> 0).
|
|
82
|
+
3. Assigned tags match the manifest.
|
|
83
|
+
|
|
84
|
+
### Step 3: Inspect Terminal Buffer (Health Check)
|
|
85
|
+
To check the initial logs or output of any worker without leaving your chat:
|
|
86
|
+
|
|
87
|
+
```bash
|
|
88
|
+
# Capture last 20 lines of worker 'architect' (window 0)
|
|
89
|
+
tmux capture-pane -p -t garden-<project>:0 | tail -n 20
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
---
|
|
93
|
+
|
|
94
|
+
## 4. Teardown & Swarm Cleanup
|
|
95
|
+
|
|
96
|
+
When the entire project is completed, or when canceling a run:
|
|
97
|
+
|
|
98
|
+
```bash
|
|
99
|
+
# Gracefully deregister all swarm agents from Redis:
|
|
100
|
+
for worker in $(python3 -c "import json; [print(w['name']) for w in json.load(open('garden-swarm.json'))['workers']]"); do
|
|
101
|
+
rhizo close "$worker" 2>/dev/null || true
|
|
102
|
+
done
|
|
103
|
+
|
|
104
|
+
# Terminate the tmux session:
|
|
105
|
+
tmux kill-session -t garden-<project> 2>/dev/null || true
|
|
106
|
+
```
|