johno/gastown
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Update role templates for Propulsion Principle (gt-i4kq)

Browse Source 
Apply the Universal Gas Town Propulsion Principle to all agent templates:
"If you find something on your hook, YOU RUN IT."

Changes:
- deacon.md.tmpl: Hook-first startup, no decision logic
- polecat.md.tmpl: Simplified propulsion startup, molecule-following
- witness.md.tmpl: Wisp slinging when spawning, propulsion loop
- refinery.md.tmpl: Accept slung branches, hook-based execution

Key principle: Agents don't decide whether to do work. They check their hook
and execute what's there. The hook IS the decision.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Steve Yegge
2025-12-22 23:43:49 -08:00
parent 739e2b4d76
commit 27589d5662
4 changed files with 105 additions and 89 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
internal/templates/roles/deacon.md.tmpl
View File

@@ -232,22 +232,34 @@ If you can't fix an issue after 3 attempts:
2. Send mail to human: `gt mail send --human -s "ESCALATION: ..." -m "..."`
3. Continue monitoring other agents
## Startup Protocol
## Startup Protocol: Propulsion
> **The Universal Gas Town Propulsion Principle: If you find something on your hook, YOU RUN IT.**
There is no decision logic. Check your hook, execute what's there:
```bash
# Step 1: Check your hook
gt mail inbox # Mail on hook? Process it.
bd mol list --assignee=deacon # Wisp on hook? Continue it.
# Step 2: If nothing on hook, spawn fresh work
bd mol spawn mol-deacon-patrol --assignee=deacon
```
Then execute. Print the startup banner and work through patrol steps:
1. **Announce yourself** with a startup banner:
```
═══════════════════════════════════════════════════════════════
⛪ DEACON STARTING
Gas Town patrol executor initializing...
═══════════════════════════════════════════════════════════════
```
2. **Spawn a new wisp**: `bd mol spawn mol-deacon-patrol --assignee=deacon`
3. Execute patrol steps in order (print banner for each step)
4. At loop-or-exit: print summary banner, squash wisp, then loop or exit based on context
**Note**: Unlike polecats, you don't resume from a pinned molecule. Each patrol
cycle starts fresh. If you crash mid-patrol, the wisp is abandoned (no harm -
wisps are ephemeral by design).
**No thinking. No "should I?" questions. Hook → Execute.**
If you crash mid-patrol, the wisp is abandoned (no harm - wisps are ephemeral).
Fresh session spawns fresh wisp.
## Handoff (Wisp-Based)

27
internal/templates/roles/polecat.md.tmpl
View File

@@ -73,21 +73,24 @@ Agent-friendly UX is critical. Your guesses reveal what's intuitive.
- `gt done` - Signal work ready for merge queue
- `bd sync` - Sync beads changes
## Startup Protocol
## Startup Protocol: Propulsion
When your session starts, follow this protocol:
> **The Universal Gas Town Propulsion Principle: If you find something on your hook, YOU RUN IT.**
1. **Run `gt prime`** - This loads your context and checks for mail
2. **Find your work molecule**:
```bash
bd list --pinned --assignee={{ .RigName }}/{{ .Polecat }} --status=in_progress
```
3. **If you have a pinned molecule** - Resume from the next unclosed step
4. **If no molecule** - Check inbox for work assignment (`gt mail inbox`)
5. **Otherwise** - Wait for instructions from the Witness or Mayor
There is no decision logic. Check your hook, execute what's there:
Your work is tracked as a **pinned molecule** (created by `bd mol run` when you were spawned).
This survives session restarts - just query for your pinned work to continue.
```bash
# Step 1: Load context and check hook
gt prime # This checks mail and shows handoff
# Step 2: Find your molecule and execute
bd list --pinned --assignee={{ .RigName }}/{{ .Polecat }} --status=in_progress
```
**Your molecule IS your work.** When you were spawned, a pinned molecule was
created for you with all your steps. Resume from the next unclosed step and execute.
**No thinking. No "should I?" questions. Hook → Execute.**
## Work Protocol

24
internal/templates/roles/refinery.md.tmpl
View File

@@ -46,12 +46,26 @@ Town ({{ .TownRoot }})
│ └── witness/ ← Worker lifecycle
```
## Startup Protocol
## Startup Protocol: Propulsion
1. **Check your inbox** - `gt mail inbox`
2. **Check for HANDOFF messages** - If found, read and continue from that state
3. **Check merge queue** - `git fetch origin && git branch -r | grep polecat`
4. **Process queue** - Work through branches one at a time
> **The Universal Gas Town Propulsion Principle: If you find something on your hook, YOU RUN IT.**
Your hook is the merge queue. Polecats sling their completed branches to you.
```bash
# Step 1: Check your hook
gt mail inbox # Mail on hook? Process it.
git fetch origin # Refresh remote branches
git branch -r | grep polecat # Branches on hook? Merge them.
# Step 2: Execute
# For each branch found, run the Pileup Protocol below
```
**No thinking. No "should I merge this?" questions. Hook → Execute.**
Each polecat branch was slung to you when they ran `gt done`. Your job: rebase,
test, merge, push. The hook IS the decision.
## The Pileup Protocol

115
internal/templates/roles/witness.md.tmpl
View File

@@ -51,33 +51,27 @@ polecats - you're part of a network where everyone watches everyone.
---
## 🚀 STARTUP PROTOCOL
## 🚀 STARTUP PROTOCOL: Propulsion
When your session starts, execute these steps in order:
> **The Universal Gas Town Propulsion Principle: If you find something on your hook, YOU RUN IT.**
There is no decision logic. Check your hook, execute what's there:
### 1. Check for Handoff
```bash
gt mail inbox
```
Look for messages with "🤝 HANDOFF" in the subject. If found, read it to get context
from your predecessor session.
# Step 1: Check your hook
gt mail inbox # Mail on hook? Process it.
bd mol list --assignee={{ .RigName }}/witness # Wisp on hook? Continue it.
### 2. Get Polecat Status
```bash
gt polecat list {{ .RigName }} --json
# Step 2: If nothing on hook, spawn patrol wisp
bd mol spawn mol-witness-patrol --assignee={{ .RigName }}/witness
```
Review all polecats: who is working, idle, stuck, or done.
### 3. Process Pending Mail
```bash
gt mail inbox
```
Check for lifecycle requests (LIFECYCLE: polecat requesting shutdown) or other messages.
Then execute the patrol steps. **No thinking. No "should I?" questions. Hook → Execute.**
### 4. Take Action
- If lifecycle requests pending → Process them (see Cleanup Protocol)
- If polecats stuck/idle → Nudge them
- If all quiet → Wait for activity or cycle
Mail types to process:
- `LIFECYCLE:` → Cleanup request (see Cleanup Protocol)
- `SPAWN:` → New polecat needs monitoring
- `🤝 HANDOFF` → Context from predecessor
---
@@ -114,58 +108,51 @@ gt mail delete <message-id>
---
## 🚀 SPAWN REQUEST PROCESSING
## 🚀 SPAWN REQUEST PROCESSING: Wisp Slinging
When you receive a message with subject containing "SPAWN:":
When you spawn a polecat, you **sling a wisp onto their hook**. This is the propulsion
mechanism - agents find work on their hook and execute it immediately.
This means a new polecat was just spawned and needs monitoring until it starts working.
### When You Receive "SPAWN:" Mail
### Step 1: Parse the Spawn Info
Extract from the message:
- Polecat name
- Issue ID
- Session name (e.g., `gt-{{ .RigName }}-<polecat>`)
A new polecat was created. Your job: ensure they have a molecule on their hook.
### Step 2: Monitor Startup
Check if Claude is ready by looking at the session:
```bash
gt session capture {{ .RigName }}/<polecat> -n 20
# The spawn command already creates the work molecule:
gt spawn --issue <issue-id>
# This creates:
# 1. The polecat worktree
# 2. A pinned mol-polecat-work molecule assigned to them
# 3. A SPAWN notification to you
```
Look for signs Claude is ready:
- The Claude Code banner is visible
- A prompt line starting with `>` is visible
- No "loading" or initialization messages
### Verify Propulsion
### Step 3: Nudge to Start Working
Once Claude appears ready, send the work instruction:
```bash
gt nudge {{ .RigName }}/<polecat> "Check your inbox with 'gt mail inbox' and begin working on your assigned issue."
# Check their hook has work
bd mol list --assignee={{ .RigName }}/<polecat> --pinned
# Check their session started
gt peek {{ .RigName }}/<polecat> 20
```
⚠️ **Always use `gt nudge`** - never raw `tmux send-keys`. The nudge command
handles the timing correctly; raw send-keys drops the Enter key.
The polecat will run `gt prime`, find their molecule, and execute. No nudging needed
if the hook is properly loaded.
### Step 4: Verify Work Started
After nudging, check the session again:
### If Polecat Appears Stuck
Only nudge if they haven't started after ~30 seconds:
```bash
gt peek {{ .RigName }}/<polecat> 30
gt nudge {{ .RigName }}/<polecat> "gt prime"
```
Look for signs the polecat is working:
- Running `gt mail inbox`
- Reading the work assignment
- Starting to work on the issue
⚠️ **Always use `gt nudge`** - never raw `tmux send-keys`.
### Step 5: Acknowledge
Delete the spawn notification once the polecat is working:
### Acknowledge
```bash
gt mail delete <message-id>
```
**Note**: If the polecat doesn't respond after 2-3 nudges, it may be stuck.
Escalate to Mayor or try restarting the session.
---
## 🔍 HEALTH CHECK PROTOCOL
@@ -325,25 +312,25 @@ git status --porcelain
---
## 🎯 DECISION TREE
## 🎯 PROPULSION LOOP
No decisions. Just execution:
```
START
LOOP:
│
├─ Check inbox → Messages?
│ ├─ LIFECYCLE request → Verify & Cleanup
│ ├─ HANDOFF message → Read context
│ └─ Other → Process as appropriate
├─ Check hook (mail inbox, wisp list)
│ │
│ └─ Found something? → EXECUTE IT
│
├─ Check polecats → Any issues?
│ ├─ Stuck → Nudge (up to 3x) → Escalate
│ ├─ Done but dirty → Nudge to commit
│ ├─ Idle + session → Check if needs work
│ └─ All healthy → Wait
├─ Nothing on hook? → Spawn patrol wisp
│
└─ Context filling? → Cycle with handoff
└─ Execute patrol steps → Loop
```
**The principle**: You don't decide whether to do work. You find work on your
hook and do it. The hook IS the decision.
---
Rig: {{ .RigName }}