ralph

---
name: ralph
description: Queue processing with fresh context per phase. Processes N tasks from the queue, spawning isolated subagents to prevent context contamination. Supports serial, parallel, batch filter, and dry run modes. Triggers on "/ralph", "/ralph N", "process queue", "run pipeline tasks".
version: "1.0"
generated_from: "arscontexta-v1.6"
user-invocable: true
context: fork
allowed-tools: Read, Write, Edit, Grep, Glob, Bash, Task
argument-hint: "N [--parallel] [--batch id] [--type extract] [--dry-run] — N = number of tasks to process"
---

## EXECUTE NOW

**Target: $ARGUMENTS**

Parse arguments:
- N (required unless --dry-run): number of tasks to process
- --parallel: concurrent claim workers (max 5) + cross-connect validation
- --batch [id]: process only tasks from specific batch
- --type [type]: process only tasks at a specific phase (extract, create, reflect, reweave, verify, enrich)
- --dry-run: show what would execute without running
- --handoff: output structured RALPH HANDOFF block at end (for pipeline chaining)

### Step 0: Read Vocabulary

Read `ops/derivation-manifest.md` (or fall back to `ops/derivation.md`) for domain vocabulary mapping. All output must use domain-native terms. If neither file exists, use universal terms.

**START NOW.** Process queue tasks.

---

## MANDATORY CONSTRAINT: SUBAGENT SPAWNING IS NOT OPTIONAL

**You MUST use the Task tool to spawn a subagent for EVERY task. No exceptions.**

This is not a suggestion. This is not an optimization you can skip for "simple" tasks. The entire architecture depends on fresh context isolation per phase. Executing tasks inline in the lead session:
- Contaminates context (later tasks run on degraded attention)
- Skips the handoff protocol (learnings are not captured)
- Violates the ralph pattern (one phase per context window)

**If you catch yourself about to execute a task directly instead of spawning a subagent, STOP.** Call the Task tool. Every time. For every task. Including create tasks. Including "simple" tasks.

The lead session's ONLY job is: read queue, spawn subagent, evaluate return, update queue, repeat.

---

## Phase Configuration

Each phase maps to specific Task tool parameters. Use these EXACTLY when spawning subagents.

| Phase | Skill Invoked | Purpose |
|-------|---------------|---------|
| extract | /reduce | Extract claims from source material |
| create | (inline note creation) | Write the {DOMAIN:note} file |
| enrich | /enrich | Add content to existing {DOMAIN:note} |
| reflect | /reflect | Find connections, update {DOMAIN:topic map}s |
| reweave | /reweave | Update older {DOMAIN:note_plural} with new connections |
| verify | /verify | Description quality + schema + health checks |

**All phases use the same subagent configuration:**
- subagent_type: knowledge-worker (if available) or default
- mode: dontAsk

Subagents inherit the session model. Users running opus get opus quality on processing phases. Users running sonnet get sonnet everywhere. Fresh context per phase already ensures efficiency — every phase gets full capability in the smart zone.

---

## Step 1: Read Queue State

Read the queue file. Check these locations in order:
1. `ops/queue.yaml`
2. `ops/queue/queue.yaml`
3. `ops/queue/queue.json`

Parse the queue. Identify ALL pending tasks.

**Queue structure (v2 schema):**

The queue uses `current_phase` and `completed_phases` per task entry:

```yaml
phase_order:
  claim: [create, reflect, reweave, verify]
  enrichment: [enrich, reflect, reweave, verify]

tasks:
  - id: source-name
    type: extract
    status: pending
    source: ops/queue/archive/2026-01-30-source/source.md
    file: source-name.md
    created: "2026-01-30T10:00:00Z"

  - id: claim-010
    type: claim
    status: pending
    target: "claim title here"
    batch: source-name
    file: source-name-010.md
    current_phase: reflect
    completed_phases: [create]
```

If the queue file does not exist or is empty, report: "Queue is empty. Use /seed or /pipeline to add sources."

## Step 2: Filter Tasks

Build a list of **actionable tasks** — tasks where `status == "pending"`. Order by position in the tasks array (first = highest priority).

Apply filters:
- If `--batch` specified: keep only tasks where `batch` matches
- If `--type` specified: keep only tasks where `current_phase` matches (e.g., `--type reflect` finds tasks whose `current_phase` is "reflect")

The `phase_order` header defines the phase sequence:
- `claim`: create -> reflect -> reweave -> verify
- `enrichment`: enrich -> reflect -> reweave -> verify

## Step 3: If --dry-run, Report and Stop

Show this and STOP (do not process):

```
--=={ ralph dry-run }==--

Queue: X total tasks (Y pending, Z done)

Phase distribution:
  Claims:       {create: N, reflect: N, reweave: N, verify: N}
  Enrichments:  {enrich: N, reflect: N, reweave: N, verify: N}

Next tasks to process:
1. {id} — phase: {current_phase} — {target}
2. {id} — phase: {current_phase} — {target}
...

Estimated: ~{N} subagent spawns
```

---

## Step 4: Process Loop (SERIAL MODE)

**If `--parallel` is set, skip to Step 6 instead.**

Process up to N tasks (default 1). For each iteration:

### 4a. Select Next Task

Pick the first pending task from the filtered list. Read its metadata: `id`, `type`, `file`, `target`, `batch`, `current_phase`, `completed_phases`.

The `current_phase` determines which skill to invoke.

Report:
```
=== Processing task {i}/{N}: {id} — phase: {current_phase} ===
Target: {target}
File: {file}
```

### 4b. Build Subagent Prompt

Construct a prompt based on `current_phase`. Every prompt MUST include:
- Reference to the task file path (from queue's `file` field)
- The task identity (id, current_phase, target)
- The skill to invoke with `--handoff`
- `ONE PHASE ONLY` constraint
- Instruction to output RALPH HANDOFF block

**Phase-specific prompts:**

For **extract** phase (type=extract tasks only):
```
Read the task file at ops/queue/{FILE} for context.

You are processing task {ID} from the work queue.
Phase: extract | Target: {TARGET}

Run /reduce --handoff on the source file referenced in the task file.
After extraction: create per-claim task files, update the queue with new entries
(1 entry per claim with current_phase/completed_phases), output RALPH HANDOFF.
ONE PHASE ONLY. Do NOT run reflect or other phases.
```

For **create** phase:
```
Read the task file at ops/queue/{FILE} for context.

You are processing task {ID} from the work queue.
Phase: create | Target claim: {TARGET}

Create a {DOMAIN:note} for this claim in {DOMAIN:notes}/[claim as sentence].md
Follow note design patterns:
- YAML frontmatter with description (adds info beyond title), topics
- Body: 150-400 words showing reasoning with connective words
- Footer: Source (wiki link), Relevant Notes (with context), Topics
Update the task file's ## Create section.
ONE PHASE ONLY. Do NOT run reflect.
```

For **enrich** phase:
```
Read the task file at ops/queue/{FILE} for context.

You are processing task {ID} from the work queue.
Phase: enrich | Target: {TARGET}

Run /enrich --handoff using the task file for context.
The task file specifies which existing {DOMAIN:note} to enrich and what to add.
ONE PHASE ONLY. Do NOT run reflect.
```

For **reflect** phase:

**Build sibling list:** Query the queue for other claims in the same batch where `completed_phases` includes "create" (note already exists). Format as wiki links.

```
Read the task file at ops/queue/{FILE} for context.

You are processing task {ID} from the work queue.
Phase: reflect | Target: {TARGET}

OTHER CLAIMS FROM THIS BATCH (check connections to these alongside regular discovery):
{for each sibling in batch where completed_phases includes "create":}
- [[{SIBLING_TARGET}]]
{end for, or "None yet" if this is the first claim}

Run /reflect --handoff on: {TARGET}
Use dual discovery: {DOMAIN:topic map} exploration AND semantic search.
Add inline links where genuine connections exist — including sibling claims listed above.
Update relevant {DOMAIN:topic map} with this {DOMAIN:note}.
ONE PHASE ONLY. Do NOT run reweave.
```

For **reweave** phase:

**Same sibling list** as reflect (re-query queue for freshest state):

```
Read the task file at ops/queue/{FILE} for context.

You are processing task {ID} from the work queue.
Phase: reweave | Target: {TARGET}

OTHER CLAIMS FROM THIS BATCH:
{for each sibling in batch where completed_phases includes "create":}
- [[{SIBLING_TARGET}]]
{end for}

Run /reweave --handoff for: {TARGET}
This is the BACKWARD pass. Find OLDER {DOMAIN:note_plural} AND sibling claims
that should reference this {DOMAIN:note} but don't.
Add inline links FROM older {DOMAIN:note_plural} TO this {DOMAIN:note}.
ONE PHASE ONLY. Do NOT run verify.
```

For **verify** phase:
```
Read the task file at ops/queue/{FILE} for context.

You are processing task {ID} from the work queue.
Phase: verify | Target: {TARGET}

Run /verify --handoff on: {TARGET}
Combined verification: recite (cold-read prediction test), validate (schema check),
review (per-note health).
IMPORTANT: Recite runs FIRST — read only title+description, predict content,
THEN read full {DOMAIN:note}.
Final phase for this claim. ONE PHASE ONLY.
```

### 4c. Spawn Subagent (MANDATORY — NEVER SKIP)

Call the Task tool with the constructed prompt:

```
Task(
  prompt = {the constructed prompt from 4b},
  description = "{current_phase}: {short target}" (5 words max)
)
```

**REPEAT: You MUST call the Task tool here.** Do NOT execute the prompt yourself. Do NOT "optimize" by running the task inline. The Task tool call is the ONLY acceptable action at this step.

Wait for the subagent to complete and capture its return value.

### 4d. Evaluate Return

When the subagent returns:

1. **Look for RALPH HANDOFF block** — search for `=== RALPH HANDOFF` and `=== END HANDOFF ===` markers
2. **If handoff found:** Parse the Work Done, Learnings, and Queue Updates sections
3. **If handoff missing:** Log a warning but continue — the work was still completed
4. **Capture learnings:** If Learnings section has non-NONE entries, note them for the final report

### 4e. Update Queue (Phase Progression)

After evaluating the return, advance the task to the next phase.

**Phase progression logic:**

Look up `phase_order` from the queue header to determine the next phase. Find `current_phase` in the array. If there is a next phase, advance. If it is the last phase, mark done.

**If NOT the last phase** — advance to next:
- Set `current_phase` to the next phase in the sequence
- Append the completed phase to `completed_phases`

**If the last phase** (verify) — mark task done:
- Set `status: done`
- Set `completed` to current UTC timestamp
- Set `current_phase` to null
- Append the completed phase to `completed_phases`

**For extract tasks ONLY:** Re-read the queue after marking done. The reduce skill writes new task entries (1 entry per claim/enrichment with `current_phase`/`completed_phases`) to the queue during execution. The lead must pick these up for subsequent iterations.

### 4f. Report Progress

```
=== Task {id} complete ({i}/{N}) ===
Phase: {current_phase} -> {next_phase or "done"}
```

If learnings were captured, show a brief summary.
If more unblocked tasks exist, show the next one.

### 4g. Re-filter Tasks

Before the next iteration, re-read the queue and re-filter tasks. Phase advancement may have changed eligibility (e.g., after completing a `create` phase, the task is now at `reflect` — if filtering by `--type reflect`, it becomes eligible).

---

## Step 5: Post-Batch Cross-Connect (Serial Mode)

After advancing a task to "done" (Step 4e), check if ALL tasks in that batch now have `status: "done"`. If yes and the batch has 2 or more completed claims:

1. **Collect all note paths** from completed batch tasks. For each claim task with `status: "done"`, read the task file's `## Create` section to find the created note path.

2. **Spawn ONE subagent** for cross-connect validation:
```
Task(
  prompt = "You are running post-batch cross-connect validation for batch '{BATCH}'.

Notes created in this batch:
{list of ALL note titles + paths from completed batch tasks}

Verify sibling connections exist between batch notes. Add any that were missed
because sibling notes did not exist yet when the earlier claim's reflect ran.
Check backward link gaps. Output RALPH HANDOFF block when done.",
  description = "cross-connect: batch {BATCH}"
)
```

3. **Parse handoff block**, capture learnings. Include cross-connect results in the final report.

**Skip if:** batch has only 1 claim (no siblings) or tasks from the batch are still pending.

---

## Step 6: Parallel Mode (--parallel)

**When `--parallel` flag is present, SKIP Step 4 entirely and use this section instead.**

**Incompatible flags:** `--parallel` cannot be combined with `--type`. Parallel mode processes claims end-to-end (all phases). If `--type` is also set, report an error:
```
ERROR: --parallel and --type are incompatible. Parallel processes full claim pipelines, not individual phases.
Use serial mode for per-phase filtering: /ralph N --type reflect
```

### Parallel Architecture

**Two-phase design:** Workers receive sibling claim info upfront so they can link proactively. Phase B validates and catches any gaps.

```
Ralph Lead (you) — orchestration only
|
+-- PHASE A: PARALLEL CLAIM PROCESSING (concurrent)
|   +-- worker-001: all 4 phases for claim 001 (with sibling awareness)
|   +-- worker-002: all 4 phases for claim 002 (with sibling awareness)
|   +-- worker-003: all 4 phases for claim 003 (with sibling awareness)
|   +-- ...up to 5 concurrent workers
|
+-- [semantic search index sync]
|
+-- PHASE B: CROSS-CONNECT VALIDATION (one subagent, one pass)
|   +-- validates sibling links, adds any that workers missed
|
+-- CLEANUP + FINAL REPORT
```

**Why two phases?** Workers have sibling awareness (claim titles in spawn prompt) and link proactively during reflect/reweave. But timing means some sibling notes may not exist yet during a worker's reflect phase. Phase B runs a single cross-connect pass after all notes exist.

### 6a. Identify Parallelizable Claims

From the filtered queue, find pending claims. A claim is parallelizable when its `status == "pending"`. Cap at 5 concurrent workers (or N, whichever is smaller).

Report:
```
=== Parallel Mode ===
Parallelizable claims: {count}
Max concurrent workers: {min(count, N, 5)}
```

### 6b. Spawn Claim Workers

For each parallelizable claim (up to N requested, max 5 concurrent):

Build the worker prompt with sibling awareness:

```
You are a claim worker processing claim "{TARGET}" from batch "{BATCH}".

Claim ID: {CLAIM_ID}
Task file: ops/queue/{FILE}
Current phase: {CURRENT_PHASE}
Completed phases: {COMPLETED_PHASES}

SIBLING CLAIMS IN THIS BATCH (link to these where genuine connections exist):
{for each other claim in the batch:}
- "{SIBLING_TARGET}" (task file: ops/queue/{SIBLING_FILE})
{end for}

During REFLECT and REWEAVE, check if your claim genuinely connects to any sibling.
If a sibling {DOMAIN:note} exists in {DOMAIN:notes}/, link to it inline where the
connection is real. If it does not exist yet (still being created), skip —
cross-connect will catch it after.

Read the task file for full context. Execute phases from current_phase onwards.
If completed_phases is not empty, skip those phases (resumption mode).

When complete, update the queue entry to status "done" and report the created
{DOMAIN:note} title, path, and claim ID. The lead needs this for cross-connect.
```

Spawn via Task tool:
```
Task(
  prompt = {the constructed prompt},
  description = "claim: {short target}" (5 words max)
)
```

**Spawn workers in PARALLEL** — launch all Task tool calls in a single message, not sequentially.

### 6c. Monitor Workers (Phase A)

Wait for worker completions. As workers complete:

1. **Parse completion message** — extract the created note title and path (needed for Phase B)
2. **Log any learnings** from the worker's report
3. **Check for issues** — failures, skipped phases, resource conflicts

**Collect all created notes** — maintain a list of `{note_title, note_path}` from worker completion messages. You need this for the cross-connect validation phase.

**Completion gate:** Phase B CANNOT start until ALL spawned workers have reported back (either success or error). Track completions:

```
Workers spawned: {total_spawned}
Workers completed: {completion_count}
Workers with errors: {error_count}

Phase B ready: {completion_count + error_count == total_spawned}
```

Do NOT proceed to Phase B while any worker is still running.

### 6d. Cross-Connect Validation (Phase B)

**Light validation pass.** Workers had sibling awareness during Phase A and linked proactively. This phase validates their work and catches gaps.

**Skip if only 1 claim was processed** (no siblings to cross-connect).

Spawn ONE subagent for cross-connect validation:

```
Task(
  prompt = "You are running post-batch cross-connect validation for batch '{BATCH}'.

Notes created in this batch:
{list of ALL newly created note titles with paths from Phase A}

Verify sibling connections exist between these notes. Add any connections that
workers missed because sibling notes did not exist yet when a worker's reflect ran.
Check backward link gaps. Output RALPH HANDOFF block when done.",
  description = "cross-connect: batch {BATCH}"
)
```

Parse the handoff block, capture learnings.

Report after Phase B:
```
=== Cross-Connect Validation Complete ===
Sibling connections validated: {count}
Missing connections added: {count}
```

### 6e. Cleanup

After Phase B completes (or after Phase A if cross-connect was skipped):

1. Clean any lock files if created
2. Skip to Step 7 for the final report, noting parallel mode in the output

---

## Step 7: Final Report

After all iterations (or when no unblocked tasks remain):

```
--=={ ralph }==--

Processed: {count} tasks
  {breakdown by phase type}

Subagents spawned: {count} (MUST equal tasks processed)

Learnings captured:
  {list any friction, surprises, methodology insights, or "None"}

Queue state:
  Pending: {count}
  Done: {count}
  Phase distribution: {create: N, reflect: N, reweave: N, verify: N}

Next steps:
  {if more pending tasks}: Run /ralph {remaining} to continue
  {if batch complete}: Run /archive-batch {batch-id}
  {if queue empty}: All tasks processed
```

**Verification:** The "Subagents spawned" count MUST equal "Tasks processed." If it does not, the lead executed tasks inline — this is a process violation. Report it as an error.

If `--handoff` flag was set, also output:

```
=== RALPH HANDOFF: orchestration ===
Target: queue processing

Work Done:
- Processed {count} tasks: {list of task IDs}
- Types: {breakdown by type}

Learnings:
- [Friction]: {description} | NONE
- [Surprise]: {description} | NONE
- [Methodology]: {description} | NONE
- [Process gap]: {description} | NONE

Queue Updates:
- Marked done: {list of completed task IDs}
=== END HANDOFF ===
```

---

## Error Recovery

**Subagent crash mid-phase:** The queue still shows `current_phase` at the failed phase. The task file confirms the corresponding section is empty. Re-running `/ralph` picks it up automatically — the task is still pending at that phase.

**Queue corruption:** If the queue file is malformed, report the error and stop. Do NOT attempt to fix it automatically.

**All tasks blocked:** Report which tasks are blocked and why. Suggest remediation.

**Empty queue:** Report "Queue is empty. Use /seed or /pipeline to add sources."

---

## Quality Gates

### Gate 1: Subagent Spawned
Every task MUST be processed via Task tool. If the lead detects it executed a task inline, log this as an error and flag it in the final report.

### Gate 2: Handoff Present
Every subagent SHOULD return a RALPH HANDOFF block. If missing: log warning, mark task done, continue.

### Gate 3: Extract Yield
For extract tasks: if zero claims extracted, log as an observation. Do NOT retry automatically.

### Gate 4: Task File Updated
After each phase, the task file's corresponding section (Create, Reflect, Reweave, Verify) should be filled. If empty after subagent completes, log warning.

---

## Critical Constraints

**Never:**
- Execute tasks inline in the lead session (USE THE TASK TOOL)
- Process more than one phase per subagent (context contamination)
- Retry failed tasks automatically without human input
- Skip queue phase advancement (breaks pipeline state)
- Process tasks that are not in pending status
- Run if queue file does not exist or is malformed
- In parallel mode: combine with --type (incompatible)

**Always:**
- Spawn a subagent via Task tool for EVERY task (the lead ONLY orchestrates)
- Include sibling claim titles in reflect and reweave prompts
- Re-read queue after extract tasks (subagent adds new entries)
- Re-filter tasks between iterations (phase advancement creates new eligibility)
- Log learnings from handoff blocks
- Report failures clearly for human review
- Verify subagent count equals task count in final report