# Task for crew-planner

Create a task breakdown for implementing this PRD.

## PRD: PRD.md

# PRD.md - Wire All Touchpoints to Symbol Registry (SSoT)

## PROSTAT

**Look for opportunity. Look for opportunity where something is not doing. Look for opportunity while any of the touchpoints or boundaries that are or any internal logics are not wired to the symbol registry or central, single source of truth for parameter values. If they do, we have to identify them. And then propose ways that we can resolve them and remark them so that we have everything ready for later implementation with these guides.**

---

## Background

This project (`opendeviationbar-py`) has a **Symbol Registry** at `symbols.toml` — the Single Source of Truth (SSoT) for all symbol metadata including:
- `min_threshold` — minimum threshold in decimal basis points (dbps)
- `thresholds` — list of valid thresholds per symbol
- `listing_date` — when symbol started trading
- `effective_start` — first date with clean/usable data
- `asset_class`, `exchange`, `market` — symbol classification
- `enabled` — whether symbol is active

**The Problem**: Many parts of the codebase have hardcoded threshold values (250, 500, 750, 1000 dbps), listing dates, or other symbol-specific parameters instead of querying the symbol registry. This creates:
1. **Data drift** — changes to symbols.toml don't propagate
2. **Inconsistency** — different parts use different defaults
3. **Maintenance burden** — updates must be made in multiple places
4. **Bugs** — invalid symbol/threshold combinations may be processed

---

## Objectives

1. Audit each code touchpoint for hardcoded symbol parameters
2. Identify boundaries where symbol registry should be queried but isn't
3. Propose resolution strategies (wire to registry, remove hardcoding, add validation)
4. Document findings for later implementation

---

## 9 Investigative Perspectives (Tasks)

### Task 1: Python Constants Module Audit
**Perspective**: Audit `python/opendeviationbar/constants.py` for hardcoded threshold values.

**Investigation angles:**
- Check `DEFAULT_THRESHOLD` and `THRESHOLD_PRESETS` against symbols.toml defaults
- Verify `OPENDEVIATIONBAR_CRYPTO_MIN_THRESHOLD` matches registry defaults
- Identify any hardcoded symbol names (e.g., "BTCUSDT")
- Compare TIER1_SYMBOLS constants to enabled symbols in registry

**Use Dynamic Task Creation**: After initial audit, if you find specific hardcoded values that should come from registry, create sub-tasks to: (1) identify the fix approach, (2) document the current vs expected behavior.

**After completing your investigation, broadcast your key findings to all peers.**

---

### Task 2: CLI/Tool Entry Points Audit
**Perspective**: Audit Rust tools and Python CLI entry points for hardcoded thresholds.

**Investigation angles:**
- Check `tools/chart/src/main.rs` default threshold (line 59: `default_value_t = 250`)
- Audit any other CLI tools in `tools/` for hardcoded thresholds
- Verify Python CLI entry points in `python/opendeviationbar/` use registry
- Check `.mise.toml` commands for hardcoded threshold values

**Use Dynamic Task Creation**: After finding hardcoded defaults, create sub-tasks to: (1) document each tool's threshold source, (2) propose how to wire to registry.

**After completing your investigation, broadcast your key findings to all peers.**

---

### Task 3: ClickHouse Cache Layer Audit
**Perspective**: Audit ClickHouse cache queries for hardcoded thresholds and symbols.

**Investigation angles:**
- Check `python/opendeviationbar/clickhouse/cache.py` for hardcoded "BTCUSDT" and threshold values
- Review `bulk_operations.py` for hardcoded symbol/threshold combinations
- Audit `maintenance.py` for hardcoded values in deduplication queries
- Verify schema uses registry for threshold validation

**Use Dynamic Task Creation**: Create sub-tasks to document each hardcoded query and propose parameterized alternatives.

**After completing your investigation, broadcast your key findings to all peers.**

---

### Task 4: Configuration Modules Audit
**Perspective**: Audit config modules for hardcoded defaults that should come from registry.

**Investigation angles:**
- Check `config/algorithm.py` for `OPENDEVIATIONBAR_ALGORITHM_DEFAULT_THRESHOLD_DECIMAL_BPS`
- Audit `config/sidecar.py` for threshold handling vs registry
- Review `config/population.py` for `OPENDEVIATIONBAR_CRYPTO_MIN_THRESHOLD` usage
- Check `config/backfill.py` for hardcoded failure thresholds (unrelated but document)

**Use Dynamic Task Creation**: Create sub-tasks to compare config defaults vs registry and propose wiring strategy.

**After completing your investigation, broadcast your key findings to all peers.**

---

### Task 5: Scripts Directory Audit
**Perspective**: Audit `scripts/` for hardcoded symbols and thresholds.

**Investigation angles:**
- Search all .py scripts for hardcoded threshold values (250, 500, 750, 1000)
- Check for hardcoded "BTCUSDT" or other symbol names in scripts
- Audit `populate_full_cache.py`, `backfill_watcher.py`, `kintsugi.py`
- Review validation scripts (`validate_*.py`) for hardcoded test values

**Use Dynamic Task Creation**: Create sub-tasks for each script category (data loading, validation, analysis) to document hardcoded values.

**After completing your investigation, broadcast your key findings to all peers.**

---

### Task 6: Backfill & Population Pipeline Audit
**Perspective**: Audit data pipeline code for hardcoded thresholds and symbol lists.

**Investigation angles:**
- Check `python/opendeviationbar/backfill/` for hardcoded thresholds
- Audit population logic in `python/opendeviationbar/population.py` if exists
- Review checkpoint logic (`checkpoint.py`) for threshold handling
- Check sidecar streaming (`sidecar.py`) for threshold validation vs registry

**Use Dynamic Task Creation**: Create sub-tasks to document pipeline touchpoints that need registry integration.

**After completing your investigation, broadcast your key findings to all peers.**

---

### Task 7: Rust Crates Audit
**Perspective**: Audit Rust crates for hardcoded threshold values.

**Investigation angles:**
- Check `crates/opendeviationbar-core/` for hardcoded threshold values in tests
- Review `processor.rs` for default threshold handling
- Audit any Rust CLI tools for hardcoded defaults
- Check PyO3 bindings for threshold parameter passing

**Use Dynamic Task Creation**: Create sub-tasks to document Rust-side hardcoding and propose solutions (pass from Python, use env var, etc.).

**After completing your investigation, broadcast your key findings to all peers.**

---

### Task 8: Symbol Registry Integration Points Audit
**Perspective**: Audit existing symbol registry usage patterns.

**Investigation angles:**
- Review `symbol_registry.py` for what fields are currently exposed
- Check which parts of codebase already use the registry correctly
- Identify missing registry fields that would help eliminate hardcoding
- Audit `compat/availability.py` for registry integration

**Use Dynamic Task Creation**: Create sub-tasks to propose registry enhancements needed to support all touchpoints.

**After completing your investigation, broadcast your key findings to all peers.**

---

### Task 9: Cross-Cutting Synthesis & Resolution Strategy
**Perspective**: Synthesize all findings and propose resolution strategy.

**Investigation angles:**
- Aggregate all hardcoded values found across tasks 1-8
- Categorize by type: threshold defaults, symbol lists, listing dates, etc.
- Identify dependencies: what can be wired immediately, what needs registry enhancement
- Propose implementation phases: quick wins vs architectural changes
- Document migration strategy for each category

**Use Dynamic Task Creation**: Create sub-tasks for: (1) create comprehensive findings matrix, (2) draft implementation plan, (3) identify quick-win fixes.

**After completing your investigation, broadcast your key findings to all peers.**

---

## Task Dependencies

### Sequential Dependencies (required)
- **Task 9** depends on Tasks 1-8 (needs all audit findings to synthesize)
- Tasks 1-8 can run in parallel — each investigates a different code area

### Parallel (independent - can run simultaneously)
- **Tasks 1-8** are independent — each focuses on a different code module/section

---

## Execution Instructions

### For Planner
1. Create exactly 9 tasks with the titles above
2. Assign Tasks 1-8 to run in parallel (independent perspectives)
3. Set Task 9 dependsOn: [1,2,3,4,5,6,7,8]
4. Include Dynamic Task Creation instructions in each task spec
5. Workers should create scaffolding directories under `/tmp/crew-<perspective>/`

### For Workers (Each Task)
1. Join mesh first: `pi_messenger({ action: "join" })`
2. Start your assigned task
3. Create scaffolding directory: `mkdir -p /tmp/crew-<perspective>/`
4. Investigate your assigned code area systematically using bash + grep/ripgrep
5. Use `uvx` or `uv run` for empirical validation when needed
6. Use `pi_messenger({ action: "task.create", ... })` to spawn follow-up sub-tasks for specific findings
7. Use `pi_messenger({ action: "send", ... })` to share cross-cutting discoveries
8. Complete your investigation task with clear findings

---

## Success Criteria

- [ ] All 9 tasks complete their investigation
- [ ] Each task spawns sub-tasks for specific hardcoded values found (DCTG pattern)
- [ ] Cross-task findings shared via messaging
- [ ] Final synthesis (Task 9) documents all hardcoded values by category
- [ ] Resolution strategy proposed with implementation phases
- [ ] Clear roadmap for wiring all touchpoints to symbol registry

---

## Key Search Patterns

Workers should search for these patterns to identify hardcoded values:

```bash
# Threshold values
grep -rn "250\|500\|750\|1000" --include="*.py" | grep -i threshold
grep -rn "default_threshold\|DEFAULT_THRESHOLD" --include="*.py"

# Symbol hardcoding
grep -rn "BTCUSDT\|ETHUSDT" --include="*.py" | grep -v "symbols.toml\|#"

# Listing dates
grep -rn "listing_date\|effective_start" --include="*.py" | grep -v "symbol_registry"

# Config defaults
grep -rn "_DEFAULT\|DEFAULT_" --include="*.py" python/opendeviationbar/config/
```


## Previous Planning Context
# Planning Progress

## Notes
<!-- User notes here are read by the planner on every run.
     Add steering like "ignore auth" or "prioritize performance". -->


---
## Run: 2026-03-02T20:42:17.262Z — /Users/terryli/eon/opendeviationbar-py/PRD.md

### Pass 1 (20:43)
Now I have a comprehensive understanding of the project. Let me produce the task breakdown.

## 1. PRD Understanding Summary

The PRD requires auditing and aligning 7 CLAUDE.md files (1 root + 6 nested) to reflect the current code state in a Rust/Python hybrid project (`opendeviationbar-py`) that generates open deviation bars — a novel financial data type.

**Key Requirements:**
- Audit each CLAUDE.md for accuracy against current code
- Fix discrepancies between documentation and implementation
- Ensure cross-reference consistency between CLAUDE.md files
- Verify public API documentation matches actual exports
- Validate code examples in docs are runnable

**Project Structure Verified:**
- 9 Rust crates in workspace (opendeviationbar, opendeviationbar-core, opendeviationbar-providers, opendeviationbar-config, opendeviationbar-io, opendeviationbar-streaming, opendeviationbar-batch, opendeviationbar-cli, opendeviationbar-hurst)
- Python module at `python/opendeviationbar/` with submodules (clickhouse, config, plugins)
- Scripts directory with 150+ Python and shell scripts

## 2. Relevant Code/Docs/Resources Reviewed

- **PRD.md**: Full specification with 9 investigative perspectives
- **Cargo.toml**: Workspace configuration with 9 crates
- **CLAUDE.md files**: All 7 files identified and located
- **Directory structures**: Verified crates/, python/, scripts/ contents
- **Python __init__.py**: Confirmed API exports via `__all__`

## 3. Sequential Implementation Steps

1. **Tasks 1-7 (Parallel)**: Each worker investigates their assigned CLAUDE.md file
   - Create scaffolding directory `/tmp/crew-<perspective>/`
   - Audit documentation against actual code
   - Use bash/uvx for empirical validation
   - Broadcast findings to peers

2. **Task 8**: Cross-Reference Consistency Audit (after Tasks 1-7)
   - Verify links between CLAUDE.md files
   - Fix broken references

3. **Task 9**: Public API vs Documentation Parity (after Task 8)
   - Final comprehensive check
   - Run documented code examples

## 4. Parallelized Task Graph

---

## Tasks

### Task 1: Root CLAUDE.md Alignment

Investigate and verify that the root `/CLAUDE.md` (21KB) accurately reflects the project structure, architecture, and entry points. Create scaffolding directory at `/tmp/crew-root/`. Check: crate list in "Architecture" section matches actual `crates/` directory (9 crates verified: opendeviationbar, opendeviationbar-core, opendeviationbar-providers, opendeviationbar-config, opendeviationbar-io, opendeviationbar-streaming, opendeviationbar-batch, opendeviationbar-cli, opendeviationbar-hurst); PyO3 bindings in `src/` match documented exports; API entry points in "Python API" section exist in actual code; mise commands in "Development Commands" are valid. Use Dynamic Task Creation: after finding specific mismatches, create sub-tasks to fix each category of issues. Broadcast key findings to all peers via pi_messenger.

Dependencies: none

### Task 2: Rust Crates CLAUDE.md Alignment

Investigate and verify that `/crates/CLAUDE.md` (15KB) accurately documents the Rust crate structure, types, and algorithms. Create scaffolding directory at `/tmp/crew-rust/`. Verify 9-crate workspace matches actual `Cargo.toml` and directory structure; check microstructure feature formulas match implementation in `processor.rs`; validate inter-bar feature list in `interbar.rs`; confirm key types (`OpenDeviationBarProcessor`, `FixedPoint`, etc.) exist in actual code. Use Dynamic Task Creation: after finding specific mismatches, spawn sub-tasks to update formulas, add missing features, or correct type references. Broadcast key findings to all peers.

Dependencies: none

### Task 3: Python Core API CLAUDE.md Alignment

Investigate and verify that `/python/opendeviationbar/CLAUDE.md` (18KB) matches Python API exports. Create scaffolding directory at `/tmp/crew-python/`. Check all functions in "Key Files > __init__.py" exist in actual `__init__.py` (verify `__all__` exports); validate `TIER1_SYMBOLS`, `THRESHOLD_PRESETS` constants match code; verify validation modules exist (`validation/tier1.py`, `tier2.py`); confirm storage classes (`TickStorage`) exist. Use Dynamic Task Creation: for each missing function or incorrect reference, create a sub-task to either add to code or update docs. Broadcast key findings to all peers.

Dependencies: none

### Task 4: ClickHouse CLAUDE.md Alignment

Investigate and verify that `/python/opendeviationbar/clickhouse/CLAUDE.md` (14KB) matches actual cache implementation. Create scaffolding directory at `/tmp/crew-clickhouse/`. Check `schema.sql` matches documented columns; verify `populate_cache_resumable()` signature and behavior; validate ClickHouse connection code matches documented approach; confirm dedup hardening procedures are documented. Use Dynamic Task Creation: if schema or API mismatches found, create sub-task to reconcile. Broadcast key findings to all peers.

Dependencies: none

### Task 5: Configuration CLAUDE.md Alignment

Investigate and verify that `/python/opendeviationbar/config/CLAUDE.md` (2.6KB) matches actual config modules. Create scaffolding directory at `/tmp/crew-config/`. List all files in `config/` directory and compare to "File Map" table (verified: `__init__.py`, `algorithm.py`, `cli_models.py`, `clickhouse.py`, `monitoring.py`, `population.py`, `settings.py`, `sidecar.py`, `streaming.py`); verify Settings singleton pattern works as documented; check environment variable prefixes match; validate pydantic models exist with documented fields. Use Dynamic Task Creation: for missing config files or wrong env var names, create sub-tasks. Broadcast key findings to all peers.

Dependencies: none

### Task 6: Plugin System CLAUDE.md Alignment

Investigate and verify that `/python/opendeviationbar/plugins/CLAUDE.md` (4.4KB) matches actual plugin implementation. Create scaffolding directory at `/tmp/crew-plugins/`. Check `protocol.py` defines `FeatureProvider` Protocol as documented; verify entry-point discovery works in `loader.py`; validate plugin example code is runnable; confirm migration helpers exist. Use Dynamic Task Creation: if protocol or loader mismatches, create sub-tasks to fix. Broadcast key findings to all peers.

Dependencies: none

### Task 7: Scripts CLAUDE.md Alignment

Investigate and verify that `/scripts/CLAUDE.md` (15KB) matches actual scripts in `scripts/` directory. Create scaffolding directory at `/tmp/crew-scripts/`. List all `.py` and `.sh` scripts and compare to documented ones (verified 150+ scripts exist); verify mise commands exist in `.mise.toml`; check pueue orchestration scripts are documented; validate cache population scripts exist. Use Dynamic Task Creation: for missing scripts or wrong commands, create sub-tasks. Broadcast key findings to all peers.

Dependencies: none

### Task 8: Cross-Reference Consistency Audit

Investigate and verify consistency of cross-references between all CLAUDE.md files. Create scaffolding directory at `/tmp/crew-crossref/`. Check links from root CLAUDE.md to nested files are valid; verify parent/child relationships documented correctly; validate "Related" sections reference existing files; confirm hub-and-spoke CLAUDE.md network is accurate. This task depends on all individual file tasks (1-7) being complete. Use Dynamic Task Creation: create sub-tasks to fix broken links or inconsistent references. Broadcast key findings to all peers.

Dependencies: Task 1, Task 2, Task 3, Task 4, Task 5, Task 6, Task 7

### Task 9: Public API vs Documentation Parity

Perform final comprehensive check comparing documented API to actual code exports. Create scaffolding directory at `/tmp/crew-api/`. Compare Python `__all__` exports to documented functions; check Rust types exported via PyO3 match CLAUDE.md listings; verify CLI commands in docs match actual entry points; run documented code examples to confirm they work. This is the final audit task - depends on Tasks 1-8. Use Dynamic Task Creation: for each parity gap, create sub-task to update code or docs. Broadcast final comprehensive findings to all peers.

Dependencies: Task 1, Task 2, Task 3, Task 4, Task 5, Task 6, Task 7, Task 8

---

```tasks-json
[
  {
    "title": "Task 1: Root CLAUDE.md Alignment",
    "description": "Investigate and verify that the root `/CLAUDE.md` (21KB) accurately reflects the project structure, architecture, and entry points. Create scaffolding directory at `/tmp/crew-root/`. Check: crate list in \"Architecture\" section matches actual `crates/` directory (9 crates verified: opendeviationbar, opendeviationbar-core, opendeviationbar-providers, opendeviationbar-config, opendeviationbar-io, opendeviationbar-streaming, opendeviationbar-batch, opendeviationbar-cli, opendeviationbar-hurst); PyO3 bindings in `src/` match documented exports; API entry points in \"Python API\" section exist in actual code; mise commands in \"Development Commands\" are valid. Use Dynamic Task Creation: after finding specific mismatches, create sub-tasks to fix each category of issues. Broadcast key findings to all peers via pi_messenger.",
    "dependsOn": []
  },
  {
    "title": "Task 2: Rust Crates CLAUDE.md Alignment",
    "description": "Investigate and verify that `/crates/CLAUDE.md` (15KB) accurately documents the Rust crate structure, types, and algorithms. Create scaffolding directory at `/tmp/crew-rust/`. Verify 9-crate workspace matches actual `Cargo.toml` and directory structure; check microstructure feature formulas match implementation in `processor.rs`; validate inter-bar feature list in `interbar.rs`; confirm key types (`OpenDeviationBarProcessor`, `FixedPoint`, etc.) exist in actual code. Use Dynamic Task Creation: after finding specific mismatches, spawn sub-tasks to update formulas, add missing features, or correct type references. Broadcast key findings to all peers.",
    "dependsOn": []
  },
  {
    "title": "Task 3: Python Core API CLAUDE.md Alignment",
    "description": "Investigate and verify that `/python/opendeviationbar/CLAUDE.md` (18KB) matches Python API exports. Create scaffolding directory at `/tmp/crew-python/`. Check all functions in \"Key Files > __init__.py\" exist in actual `__init__.py` (verify `__all__` exports); validate `TIER1_SYMBOLS`, `THRESHOLD_PRESETS` constants match code; verify validation modules exist (`validation/tier1.py`, `tier2.py`); confirm storage classes (`TickStorage`) exist. Use Dynamic Task Creation: for each missing function or incorrect reference, create a sub-task to either add to code or update docs. Broadcast key findings to all peers.",
    "dependsOn": []
  },
  {
    "title": "Task 4: ClickHouse CLAUDE.md Alignment",
    "description": "Investigate and verify that `/python/opendeviationbar/clickhouse/CLAUDE.md` (14KB) matches actual cache implementation. Create scaffolding directory at `/tmp/crew-clickhouse/`. Check `schema.sql` matches documented columns; verify `populate_cache_resumable()` signature and behavior; validate ClickHouse connection code matches documented approach; confirm dedup hardening procedures are documented. Use Dynamic Task Creation: if schema or API mismatches found, create sub-task to reconcile. Broadcast key findings to all peers.",
    "dependsOn": []
  },
  {
    "title": "Task 5: Configuration CLAUDE.md Alignment",
    "description": "Investigate and verify that `/python/opendeviationbar/config/CLAUDE.md` (2.6KB) matches actual config modules. Create scaffolding directory at `/tmp/crew-config/`. List all files in `config/` directory and compare to \"File Map\" table (verified: `__init__.py`, `algorithm.py`, `cli_models.py`, `clickhouse.py`, `monitoring.py`, `population.py`, `settings.py`, `sidecar.py`, `streaming.py`); verify Settings singleton pattern works as documented; check environment variable prefixes match; validate pydantic models exist with documented fields. Use Dynamic Task Creation: for missing config files or wrong env var names, create sub-tasks. Broadcast key findings to all peers.",
    "dependsOn": []
  },
  {
    "title": "Task 6: Plugin System CLAUDE.md Alignment",
    "description": "Investigate and verify that `/python/opendeviationbar/plugins/CLAUDE.md` (4.4KB) matches actual plugin implementation. Create scaffolding directory at `/tmp/crew-plugins/`. Check `protocol.py` defines `FeatureProvider` Protocol as documented; verify entry-point discovery works in `loader.py`; validate plugin example code is runnable; confirm migration helpers exist. Use Dynamic Task Creation: if protocol or loader mismatches, create sub-tasks to fix. Broadcast key findings to all peers.",
    "dependsOn": []
  },
  {
    "title": "Task 7: Scripts CLAUDE.md Alignment",
    "description": "Investigate and verify that `/scripts/CLAUDE.md` (15KB) matches actual scripts in `scripts/` directory. Create scaffolding directory at `/tmp/crew-scripts/`. List all `.py` and `.sh` scripts and compare to documented ones (verified 150+ scripts exist); verify mise commands exist in `.mise.toml`; check pueue orchestration scripts are documented; validate cache population scripts exist. Use Dynamic Task Creation: for missing scripts or wrong commands, create sub-tasks. Broadcast key findings to all peers.",
    "dependsOn": []
  },
  {
    "title": "Task 8: Cross-Reference Consistency Audit",
    "description": "Investigate and verify consistency of cross-references between all CLAUDE.md files. Create scaffolding directory at `/tmp/crew-crossref/`. Check links from root CLAUDE.md to nested files are valid; verify parent/child relationships documented correctly; validate \"Related\" sections reference existing files; confirm hub-and-spoke CLAUDE.md network is accurate. This task depends on all individual file tasks (1-7) being complete. Use Dynamic Task Creation: create sub-tasks to fix broken links or inconsistent references. Broadcast key findings to all peers.",
    "dependsOn": ["Task 1: Root CLAUDE.md Alignment", "Task 2: Rust Crates CLAUDE.md Alignment", "Task 3: Python Core API CLAUDE.md Alignment", "Task 4: ClickHouse CLAUDE.md Alignment", "Task 5: Configuration CLAUDE.md Alignment", "Task 6: Plugin System CLAUDE.md Alignment", "Task 7: Scripts CLAUDE.md Alignment"]
  },
  {
    "title": "Task 9: Public API vs Documentation Parity",
    "description": "Perform final comprehensive check comparing documented API to actual code exports. Create scaffolding directory at `/tmp/crew-api/`. Compare Python `__all__` exports to documented functions; check Rust types exported via PyO3 match CLAUDE.md listings; verify CLI commands in docs match actual entry points; run documented code examples to confirm they work. This is the final audit task - depends on Tasks 1-8. Use Dynamic Task Creation: for each parity gap, create sub-task to update code or docs. Broadcast final comprehensive findings to all peers.",
    "dependsOn": ["Task 1: Root CLAUDE.md Alignment", "Task 2: Rust Crates CLAUDE.md Alignment", "Task 3: Python Core API CLAUDE.md Alignment", "Task 4: ClickHouse CLAUDE.md Alignment", "Task 5: Configuration CLAUDE.md Alignment", "Task 6: Plugin System CLAUDE.md Alignment", "Task 7: Scripts CLAUDE.md Alignment", "Task 8: Cross-Reference Consistency Audit"]
  }
]
```


## Available Skills

Workers can load these skills on demand during task execution. When creating tasks, you may include a `skills` array with relevant skill names to help workers prioritize which to read.

  ralph-loop — Use ralph_loop tool to run agent tasks in a persistent loop until a goal or condition is met. Load this skill whenever the user mentions "ralph loop", "keep trying", "retry until", "loop until", "run until done", or wants something to keep going across sessions.


You must follow this sequence strictly:
1) Understand the PRD
2) Review relevant code/docs/reference resources
3) Produce sequential implementation steps
4) Produce a parallel task graph

Return output in this exact section order and headings:
## 1. PRD Understanding Summary
## 2. Relevant Code/Docs/Resources Reviewed
## 3. Sequential Implementation Steps
## 4. Parallelized Task Graph

In section 4, include both:
- markdown task breakdown
- a `tasks-json` fenced block with task objects containing title, description, dependsOn, and optionally skills (array of skill names from the Available Skills list that are relevant to the task).