---
date: 2026-02-14T18:00:00-08:00
researcher: reuben
git_commit: 321fef6032916646bae3991d5ebb6e8601e58e6b
branch: main
repository: rho
topic: "Rho Architecture Extensions: Hooks, Loops, Compaction, Agents, Config, and Integration Patterns"
tags: [research, architecture, hooks, ralph-loops, compaction, subagents, config, humanlayer, scud, prompt-commands]
status: complete
last_updated: 2026-02-14
last_updated_by: reuben
---

# Research: Rho Architecture Extensions

**Date**: 2026-02-14
**Git Commit**: 321fef6
**Branch**: main
**Repository**: rho

## Research Question

What architecture extensions does Rho need for: hooks, Ralph-style autonomous loops (first-class), context compaction, subagents/tools, RHO.md project configuration, backpressure, and integration with SCUD task management? How do Claude Code, OpenCode, HumanLayer, and the Ralph pattern inform the design?

## Summary

Rho's current agent loop (`crates/rho-core/src/agent_loop.rs`) already has key extension points — `get_steering_messages`, `get_follow_up_messages`, the `AgentTool` trait, and skill discovery — that can support all planned features with minimal core changes. The Ralph autonomous loop pattern is trivially implementable as a bash outer loop invoking `rho` per iteration, but can be made first-class with a `rho loop` subcommand. Compaction requires a token estimation layer and message pruning/summarization pipeline. Subagents are best implemented as recursive `rho` invocations via the bash tool (same pattern as Ralph), with named agent configurations providing specialized behavior. HumanLayer's layered architecture (4-binary daemon, symlinked thoughts, MCP approvals, configuration distribution) provides a mature reference for session management and team collaboration patterns.

---

## Part 1: Ralph Autonomous Loops

### What Ralph Is

Ralph is a bash outer loop that repeatedly invokes a coding agent with fresh context per iteration. The entire implementation is ~300 lines of bash:

```bash
while [ $iteration -lt $MAX_ITERATIONS ]; do
    iteration=$((iteration + 1))
    if [ -f "$STOP_FILE" ]; then break; fi
    cmd=$(build_command "$PROMPT_FILE")
    eval "$cmd"
    sleep "$SLEEP_BETWEEN"
done
```

**Source**: `~/projects/claude_skills/ralph/skills/setup/templates/loop.sh`

### Core Mechanics

| Component | Purpose | File |
|-----------|---------|------|
| `loop.sh` | Outer loop orchestration | `templates/loop.sh:234-313` |
| `PROMPT_plan.md` | Read-only gap analysis mode | `templates/PROMPT_plan.md` |
| `PROMPT_build.md` | Implementation mode (one task per iteration) | `templates/PROMPT_build.md` |
| `AGENTS.md` | Project conventions + validation commands | `templates/AGENTS.md` |
| `IMPLEMENTATION_PLAN.md` | Persistent state between iterations | Generated by agent |
| `specs/*.md` | JTBD requirement specifications | User-authored |
| `.stop` | Signal file to terminate loop | Written by agent |
| `ralph.conf` | Configuration (harness, iterations, sleep) | `templates/ralph.conf` |
| `stream_display.py` | TUI for readable output | `templates/stream_display.py` |

### Two Modes

**Planning mode** (`--plan`):
- Tools: `Read, Glob, Grep, Task, WebFetch, WebSearch` (read-only)
- Agent analyzes gaps between specs and existing code
- Updates `IMPLEMENTATION_PLAN.md`
- Exit: `echo "planning complete" > .stop`

**Building mode** (`--build`):
- Tools: `Edit, Write, Bash, Read, Glob, Grep` (+ optional `Task`)
- Agent picks one task marked `[CURRENT]`, implements it
- Runs validation (build → lint → test), fixes failures
- Updates plan, commits, exits cleanly
- Exit: `echo "no tasks remaining" > .stop`

### Backpressure

Backpressure = automated validation gates that reject invalid work:

1. Agent reads validation commands from `AGENTS.md`
2. After implementation, runs: `build → lint → test` (serialized, exactly 1 subagent)
3. If validation fails: agent fixes and re-validates within same iteration
4. Only commits when all checks pass
5. Language-specific patterns documented in `references/backpressure.md`

**Serialized test execution is critical**: Multiple parallel test subagents create noise (flaky tests, resource contention). Single subagent gives clear cause-effect.

### Harness System

Ralph supports multiple agent CLIs via pluggable harnesses:

| Harness | Command Pattern | Permission Modes |
|---------|----------------|-----------------|
| `claude` | `cat PROMPT \| claude --output-format stream-json --allowedTools ...` | Plan: read-only tools; Build: write tools |
| `opencode` | `opencode --model MODEL --prompt-file PROMPT` | `--auto-approve` for dangerous |
| `codex` | `codex --model MODEL PROMPT` | `suggest` / `auto-edit` / `full-auto` |
| `custom` | `${CUSTOM_CMD//\{PROMPT_FILE\}/PROMPT}` | User-defined |

### Key Design Principles (from ghuntley.com)

1. **Fresh context per iteration**: Agent exits after one task, loop restarts with clean context
2. **IMPLEMENTATION_PLAN.md as persistent state**: Survives across iterations, tracks progress
3. **"Let Ralph Ralph"**: Don't micromanage — observe failure patterns and tune prompts
4. **100% smart zone context**: One task per iteration uses full context budget for reasoning
5. **Operator skill matters**: Ralph is "a mirror of operator skill" — success depends on prompt engineering
6. **Disposable plans**: Regeneration costs one planning iteration; don't fight stale plans

### Making Ralph First-Class in Rho

**Minimal approach** (works today):
```bash
while :; do rho --prompt-file PROMPT_build.md; done
```

**First-class approach** (new `rho loop` subcommand):

```
rho loop --mode build --max-iterations 100 --sleep 5
rho loop --mode plan --max-iterations 10
rho loop --stop               # Write .stop file
```

Implementation in `src/main.rs`:
- Add `Loop` subcommand to clap args
- Outer loop logic in Rust (no bash dependency)
- Read `ralph.conf` or `rho.toml` for configuration
- Check `.stop` file between iterations
- Pass appropriate tool restrictions based on mode
- Support `--prompt-file` for custom prompts or use built-in defaults

---

## Part 2: Context Compaction

### Current State in Rho

**Rho has zero compaction infrastructure.** Messages accumulate without bounds:

- `Model.context_window: 200_000` is stored but **never read**
- No token counting or estimation before API calls
- No message pruning or summarization
- GUI operates in **single-turn mode** (fresh agent loop per message, no conversation history carried forward)
- Tool output truncation exists (bash: 20KB, edit diff: 100 lines) but this is per-tool, not context management

**Key locations**:
- `crates/rho-core/src/agent_loop.rs:45` — `messages` vector grows unbounded
- `crates/rho-core/src/types.rs:85` — `context_window` field (unused)
- `crates/rho-gui/src/app.rs:459-479` — Single-turn: fresh `prompts` vector each send

### Claude Code Compaction

**Trigger**: ~75-95% of context window (reserves 40-45K buffer for compaction itself)

**Two-phase strategy**:
1. **Clear old tool outputs first** — removes verbose tool results from earlier turns
2. **Summarize conversation** — separate LLM call with summarization prompt:
   ```
   Write a summary of the transcript. Include state, next steps, learnings...
   Wrap in <summary></summary> block.
   ```

**Key details**:
- Same model generates summary (no cheaper fallback)
- Summary replaces all prior messages (compaction block + continuation)
- `/compact` manual command with optional focus: `/compact focus on API changes`
- CLAUDE.md has `## Compact Instructions` section for customization
- Session Memory feature pre-generates summaries every ~5K tokens in background

### OpenCode Compaction

**Trigger**: 75% of context window (`total_tokens > context_limit - output_limit`)

**Three-stage strategy**:
1. **Prune tool outputs** — protect last 40K tokens, require 20K savings minimum
2. **Full compaction** — LLM summary if pruning insufficient
3. **Manual** — `/compact` command or `Ctrl+X C` keybinding

**Key innovation**: Pruning avoids expensive summarization in most cases. OpenCode creator: "You rarely hit compaction now."

### Proposed Rho Compaction Design

**Phase 1**: Token estimation
- Add `estimate_tokens(messages: &[Message]) -> usize` to `rho-core`
- Simple heuristic: chars / 4 (roughly 1 token per 4 chars for English)
- Check before each LLM call in `agent_loop.rs`

**Phase 2**: Tool output pruning
- Before sending to API, scan messages oldest-first
- Replace tool results older than last N tokens with `[pruned]`
- Protect last 40K tokens of tool results

**Phase 3**: Conversation summarization
- If still over threshold after pruning, call LLM with summarization prompt
- Replace all messages before summary with single summary message
- Emit `AgentEvent::Compaction { summary }` for UI display

**Phase 4**: Configuration
- `RHO.md` `## Compact Instructions` section
- `--compact-threshold` CLI flag (default: 0.75)
- `/compact` slash command in GUI

---

## Part 3: Subagents and the Agent/Tool Boundary

### How Claude Code Does It

**Task tool** = a tool that spawns an agent:
- From main agent's perspective: just another tool call
- What it creates: fresh message list, new API call, restricted tool set
- Results: only summary returns to main context (context isolation)
- Subagents **cannot spawn other subagents** (Task filtered from their tools)

**Named agent types** (`.claude/agents/*.md`):
- Configuration file with: name, description, tools, model, permission mode
- System prompt specialization
- Tool restrictions (e.g., Explore agent: Read, Grep, Glob only)

**Agent teams** (separate processes):
- Fully independent Claude Code instances
- Communicate via shared task files on disk + `SendMessage` tool
- Own context windows, load project context independently

### How OpenCode Does It

- **Build/Plan/Explore agents** — different tool access levels
- Task tool creates new session with restricted tools + specialized prompt
- In-process with isolated message histories (not separate OS processes)
- Results broadcast via SSE for real-time UI updates

### Subagent Pattern for Rho

**Approach: Recursive invocation via bash tool** (same as Ralph pattern)

A "subagent" is just another `rho` process:
```bash
rho --prompt "Analyze the authentication module" --model sonnet --tools read,grep,find
```

**Why this works**:
- Context isolation by default (separate process = separate context)
- Tool restrictions via `--tools` flag
- Parallel execution via multiple bash tool calls
- No special infrastructure needed
- Same pattern Ralph uses for harness invocation

**Named agent configurations** (`.rho/agents/*.toml` or markdown):
```toml
name = "codebase-analyzer"
description = "Analyzes implementation details with file:line references"
model = "sonnet"
tools = ["read", "grep", "find"]
system_prompt_append = """
You are a specialist at understanding HOW code works.
Output with ## Overview, ## Entry Points, ## Core Implementation sections.
Include file:line references for all findings.
"""
```

**Implementation**:
1. Discover agent configs from `.rho/agents/`, `.claude/agents/`
2. Add `task` tool that invokes `rho` with agent configuration
3. Agent configs restrict tools and append to system prompt
4. Results captured from stdout and returned as tool result

**The codebase-analyzer and codebase-locator patterns** are just well-designed agent configurations — not special built-in types. They become first-class when Rho can discover and invoke them.

---

## Part 4: RHO.md Project Configuration

### Current State

All configuration is hardcoded:
- System prompt: `src/main.rs:58-70` (const string)
- Model: `src/main.rs:95-109` (hardcoded Sonnet 4.5)
- Tools: `src/main.rs:123-130` (hardcoded 6 tools)
- Thinking level: CLI `--thinking` flag only
- Skill directories: `crates/rho-core/src/skills.rs:76-83` (hardcoded paths)
- Context window: `src/main.rs:103` (hardcoded 200,000)

### Proposed RHO.md Format

```markdown
# Project Configuration

## Model
sonnet

## Thinking
medium

## System Prompt
You are working on the Rho codebase, a Rust-native coding agent.
Always run `cargo check` after making changes.

## Compact Instructions
Preserve file paths and architectural decisions.

## Validation Commands
- Build: `cargo build`
- Test: `cargo test`
- Lint: `cargo clippy -- -D warnings`
- Format: `cargo fmt --check`

## Skill Directories
- .skills/
- .claude/skills/

## Agent Directories
- .rho/agents/
- .claude/agents/

## Backpressure
On loop iterations, run validation commands before committing.
```

### Resolution Order

1. **CLI flags** (highest priority)
2. **RHO.md** in working directory
3. **~/.rho/config.md** global config
4. **CLAUDE.md** (compatibility — read system prompt section)
5. **Built-in defaults** (lowest priority)

### Implementation

Parse in `src/main.rs` before building `AgentLoopConfig`:
1. Search for `RHO.md` in cwd, then parents (like `.gitignore`)
2. Parse markdown sections by `##` headers
3. Override defaults with found values
4. Merge with CLI flags

---

## Part 5: First-Class Prompt Commands

### What the User Wants

Make `cl:research_codebase` and `cl:create_plan` (and similar) into first-class Rho features — not just Claude Code skills but built-in prompt commands.

### Current cl: Skill Inventory

**Located at**: `~/projects/claude_skills/cl/commands/`

| Category | Skills | Purpose |
|----------|--------|---------|
| **Research** | `research_codebase`, `research_codebase_nt`, `research_codebase_generic` | Document codebase with parallel subagents |
| **Planning** | `create_plan`, `create_plan_nt`, `create_plan_generic` | Interactive research + plan creation |
| **Implementation** | `implement_plan`, `iterate_plan`, `validate_plan` | Execute/iterate/verify plans |
| **Git/PR** | `commit`, `ci_commit`, `describe_pr`, `local_review`, `create_worktree` | Git workflow commands |
| **Session** | `create_handoff`, `resume_handoff` | Context transfer between sessions |
| **Ralph** | `ralph_research`, `ralph_plan`, `ralph_impl`, `oneshot_plan`, `oneshot` | Autonomous loop integration |
| **Other** | `debug`, `founder_mode`, `linear` | Specialized workflows |

**Supporting agent configs** (`~/projects/claude_skills/cl/agents/`):
- `codebase-analyzer.md` — How code works (file:line refs)
- `codebase-locator.md` — Where files/components live
- `codebase-pattern-finder.md` — Find existing patterns
- `thoughts-analyzer.md` / `thoughts-locator.md` — Thoughts directory analysis

### Design for First-Class Commands

**Built-in commands** (hardcoded in Rho, always available):

| Command | Description |
|---------|-------------|
| `/research` | Research codebase with parallel subagents |
| `/plan` | Create implementation plan interactively |
| `/implement` | Execute a plan from file |
| `/validate` | Verify implementation against plan |
| `/commit` | Git commit with context |
| `/loop` | Start Ralph-style autonomous loop |
| `/compact` | Manually trigger context compaction |
| `/backpressure` | Run validation commands |

**Implementation**: Built-in commands are prompt templates embedded in the binary (like the system prompt today). When user types `/research`, Rho:
1. Recognizes it as a built-in command (not a skill)
2. Loads the embedded prompt template
3. Appends any arguments as the research question
4. Sends as the user message with the template prepended

**User-defined commands** (from `.rho/commands/`, `.claude/commands/`, skill dirs):
- Same `SKILL.md` format as today
- Override built-ins if same name
- Discovered alongside skills

---

## Part 6: SCUD Integration

### What SCUD Is

SCUD (`~/projects/scud/`) is a Rust DAG-driven task manager:
- **SCG format**: 75% token reduction vs JSON for LLM consumption
- **Wave computation**: Kahn's algorithm groups tasks into parallel execution waves
- **Swarm orchestration**: Wave mode (sequential waves) and Beads mode (chain-of-agents)
- **Backpressure validation**: Configurable build/test/lint commands per tag
- **Salvo worktrees**: Parallel git worktree execution for a tag
- **SQLite storage**: Task state, DAG edges, transcripts

### Integration Points with Rho

1. **Task discovery**: `rho` reads SCUD task list, presents as context
2. **Ralph + SCUD**: Each loop iteration picks next SCUD task (instead of IMPLEMENTATION_PLAN.md)
3. **Backpressure**: SCUD's validation commands feed into loop backpressure
4. **Wave-based parallelism**: Multiple `rho` instances work wave tasks in parallel
5. **Transcript capture**: SCUD captures agent output per task

**Practical integration**:
- `rho loop --scud-tag sprint-1` — Loop through SCUD tasks for a tag
- Each iteration: `scud next` → get task → implement → `scud set-status done`
- Validation from SCUD's backpressure config
- Wave awareness: only pick tasks whose dependencies are met

---

## Part 7: HumanLayer Architecture Patterns

### The 4-Binary Stack

```
CodeLayer.app
├── codelayer-wui (17MB Rust/Tauri v2) → Native macOS GUI
├── cld (59MB TypeScript/Bun)          → HTTP/oRPC proxy
├── hld (27MB Go 1.24.11)             → Core daemon (sessions, approvals, SQLite)
└── humanlayer (58MB TypeScript/Bun)   → CLI tool
```

**Communication**:
- GUI → CLD → HLD (HTTP proxy chain)
- CLI → HLD (Unix socket JSON-RPC)
- Real-time updates via SSE event bus

### Key Architectural Patterns

#### 1. Configuration Distribution (`humanlayer claude init`)

HumanLayer bundles 30 commands, 6 agents, and settings with the CLI. `humanlayer claude init` interactively copies selected files to the project's `.claude/` directory.

**Layering**:
1. Bundled (read-only source, ships with CLI)
2. Global (`~/.config/humanlayer/humanlayer.json`)
3. Project (`.claude/` in repo)
4. Local (`.claude/settings.local.json`, gitignored)

**Rho equivalent**: `rho init` could copy built-in commands/agents to `.rho/`.

#### 2. Symlinked Thoughts with Searchable Hard Links

```
code_repo/
  thoughts/
    <user>/      → ~/thoughts/repos/code_repo/<user>/    (symlink)
    shared/      → ~/thoughts/repos/code_repo/shared/     (symlink)
    global/      → ~/thoughts/global/                     (symlink)
    searchable/  (hard links for search tool compatibility)
```

**Why dual linking**: Symlinks preserve git boundaries; hard links enable search tools that don't follow symlinks.

**Auto-sync**: Git post-commit hook fires `humanlayer thoughts sync` in background — stages, commits, pulls with rebase, pushes.

**Protection**: Git pre-commit hook prevents accidentally committing `thoughts/` to the code repo.

#### 3. MCP-Based Permission Gateway

```
Claude needs risky operation
  → calls mcp__codelayer__request_permission tool
    → MCP server creates approval in daemon SQLite
      → GUI shows approval modal via SSE event
        → User approves/denies
          → MCP server polls, returns decision to Claude
```

**Key insight**: Approvals use standard MCP tool protocol — no special Claude modifications needed. Any MCP-compatible client can participate.

#### 4. Daemon-Based Session Management

The Go daemon (`hld`) manages Claude Code sessions as subprocesses:
- Launches `claude --output-format stream-json` with configured parameters
- Monitors session output via goroutine
- Publishes events to bus (tool_call, tool_result, session_status_changed)
- SQLite persistence for sessions, approvals, events

**Rho equivalent**: Could expose a daemon mode for GUI session management, or operate standalone.

---

## Part 8: Extension Points in Current Rho

### Agent Loop Hooks (`crates/rho-core/src/agent_loop.rs:12-22`)

```rust
pub struct AgentLoopConfig {
    pub model: Model,
    pub api_key: String,
    pub system_prompt: String,
    pub tools: Vec<Arc<dyn AgentTool>>,
    pub thinking: ThinkingLevel,
    pub max_tokens: Option<usize>,
    pub stream_fn: StreamFn,
    pub get_steering_messages: Option<Box<dyn Fn() -> Vec<Message> + Send + Sync>>,
    pub get_follow_up_messages: Option<Box<dyn Fn() -> Vec<Message> + Send + Sync>>,
}
```

| Hook | When Called | Use For |
|------|-----------|---------|
| `get_steering_messages` | Between tool calls (after first tool) | Interrupt/redirect mid-turn |
| `get_follow_up_messages` | After complete turn (no more tools) | Continue conversation, inject context |
| `stream_fn` | Creates streaming consumer | Custom providers, logging |

### Missing Hooks Needed

| Hook | Purpose | When |
|------|---------|------|
| `transform_context` | Compaction/pruning before API call | Before `stream_assistant_response()` |
| `pre_tool_execute` | Permission check, logging | Before each `execute_tool_call()` |
| `post_tool_execute` | Result transformation, caching | After each `execute_tool_call()` |
| `on_agent_event` | External event bus, UI updates | On every `AgentEvent` emission |

### AgentEvent Variants (`crates/rho-core/src/types.rs:100-137`)

9 variants: `AgentStart`, `AgentEnd`, `TurnStart`, `TurnEnd`, `MessageStart`, `MessageUpdate`, `MessageEnd`, `ToolExecutionStart`, `ToolExecutionEnd`

Plus unused: `ToolExecutionUpdate` (defined but never emitted — could be used for streaming tool results).

### Tool Trait (`crates/rho-core/src/tool.rs:29-36`)

```rust
#[async_trait]
pub trait AgentTool: Send + Sync {
    fn name(&self) -> &str;
    fn label(&self) -> String;
    fn description(&self) -> String;
    fn parameters_schema(&self) -> Value;
    async fn execute(&self, tool_call_id: &str, params: Value, cancel: CancellationToken) -> Result<ToolResult, ToolError>;
}
```

Adding new tools (task, web_fetch, ask_user, etc.) just means implementing this trait.

### Skills System (`crates/rho-core/src/skills.rs`)

- Discovery from 6 directories: `.skills/`, `.claude/skills/`, `.opencode/skills/` (project + global)
- YAML frontmatter: `name`, `description` (both required)
- Content loaded lazily at reference resolution time
- Formatted as `<available_skills>` XML in system prompt

---

## Proposed Implementation Priority

### Phase 1: Multi-turn Conversations + Basic Compaction
- Carry message history across turns in GUI
- Token estimation heuristic
- Tool output pruning (oldest first, protect last 40K)
- `/compact` command

### Phase 2: RHO.md Configuration
- Parse `RHO.md` sections
- Override system prompt, model, thinking, tools, skill dirs
- `## Validation Commands` section for backpressure
- `## Compact Instructions` section

### Phase 3: Ralph Loops (First-Class)
- `rho loop --mode build|plan` subcommand
- Built-in `PROMPT_plan.md` and `PROMPT_build.md` templates
- `.stop` file mechanism
- `ralph.conf` / `rho.toml` configuration
- Stream display (reuse GUI or build terminal TUI)

### Phase 4: Subagents via Recursive Invocation
- `task` tool that invokes `rho` subprocess
- Agent configurations from `.rho/agents/`
- Tool restrictions via `--tools` flag
- Context isolation by default

### Phase 5: Built-in Prompt Commands
- `/research`, `/plan`, `/implement`, `/validate`, `/commit`
- Embedded prompt templates in binary
- User overrides via `.rho/commands/`

### Phase 6: SCUD Integration
- `rho loop --scud-tag TAG` mode
- Task discovery and status updates
- Wave-aware parallelism

---

## Code References

### Rho Core
- `crates/rho-core/src/agent_loop.rs:12-22` — AgentLoopConfig struct
- `crates/rho-core/src/agent_loop.rs:38-192` — run_loop with steering/follow-up hooks
- `crates/rho-core/src/agent_loop.rs:107-129` — Steering message injection between tool calls
- `crates/rho-core/src/agent_loop.rs:174-181` — Follow-up message injection after turns
- `crates/rho-core/src/agent_loop.rs:333-365` — Tool dispatch by name
- `crates/rho-core/src/types.rs:78-87` — Model struct (context_window unused)
- `crates/rho-core/src/types.rs:100-137` — AgentEvent enum (9 variants)
- `crates/rho-core/src/tool.rs:29-36` — AgentTool trait
- `crates/rho-core/src/skills.rs:37-69` — Skill discovery algorithm
- `crates/rho-core/src/skills.rs:76-83` — Default skill directories
- `crates/rho-core/src/skills.rs:87-104` — Skills XML formatting for system prompt

### Rho GUI
- `crates/rho-gui/src/app.rs:459-479` — Single-turn handle_send_prompt
- `crates/rho-gui/src/app.rs:89-90` — Token counters (display only)
- `crates/rho-gui/src/autocomplete.rs:177-273` — Reference resolution (/skills, @files)

### Rho CLI
- `src/main.rs:58-70` — Hardcoded system prompt
- `src/main.rs:95-109` — Hardcoded model configuration
- `src/main.rs:123-130` — Hardcoded tool registration
- `src/main.rs:147-157` — AgentLoopConfig assembly

### Ralph
- `~/projects/claude_skills/ralph/skills/setup/templates/loop.sh:234-313` — Main loop
- `~/projects/claude_skills/ralph/skills/setup/templates/loop.sh:174-236` — Harness command building
- `~/projects/claude_skills/ralph/skills/setup/templates/PROMPT_plan.md` — Planning prompt
- `~/projects/claude_skills/ralph/skills/setup/templates/PROMPT_build.md` — Building prompt
- `~/projects/claude_skills/ralph/skills/setup/templates/AGENTS.md` — Conventions template
- `~/projects/claude_skills/ralph/skills/setup/references/backpressure.md` — Language-specific validation
- `~/projects/claude_skills/ralph/skills/setup/references/subagents.md` — Scaling guidelines

### SCUD
- `~/projects/scud/crates/scud-core/src/` — Core DAG, wave computation, task state
- `~/projects/scud/crates/scud-cli/src/` — CLI commands (next, waves, commit)

### HumanLayer
- `humanlayer_analysis.xml` — Full CLI codebase (Repomix bundle)
- `ARCHITECTURE.md` — 4-binary stack, communication channels, data flows
- `commands/claude/init_L10225.ts` — Configuration distribution to projects
- `commands/thoughts/init.ts` — Thoughts system with symlinks + hard links
- `mcp.ts` — MCP permission gateway (request_permission tool)
- `daemonClient.ts` — Unix socket JSON-RPC to Go daemon

### cl: Skills
- `~/projects/claude_skills/cl/commands/research_codebase.md` — Research prompt (213 lines)
- `~/projects/claude_skills/cl/commands/create_plan.md` — Planning prompt (449 lines)
- `~/projects/claude_skills/cl/agents/codebase-analyzer.md` — Analysis agent config
- `~/projects/claude_skills/cl/agents/codebase-locator.md` — Locator agent config

## Related Research

- `thoughts/shared/research/2026-02-14-rho-feature-comparison.md` — Feature matrix vs Claude Code, OpenCode, HumanLayer
- `thoughts/shared/plans/2026-02-13-rho-rust-port.md` — Original 9-phase implementation plan

## Open Questions

1. Should compaction use the same model or a cheaper model for summarization?
2. Should subagents be separate processes (like Ralph) or in-process with isolated message histories (like Claude Code)?
3. Should RHO.md be markdown (human-friendly) or TOML (machine-friendly)?
4. Should built-in prompt commands be embedded in the binary or shipped as files alongside it (like HumanLayer's distribution pattern)?
5. How should Rho handle SCUD's wave-based parallelism — spawn N rho instances or use in-process subagents?
6. Should Rho adopt HumanLayer's daemon architecture for session management, or stay single-process?
