Ed_
f15d1bc866
- CLAUDE.md: full project guidance (architecture, MMA workflow, beads task lifecycle, code conventions, policy rules, commit guidelines) - .mcp.json: manual-slop-tools MCP server registration (26+ dev tools) - .claude/settings.json: Claude Code project settings - .claude/settings.local.json: MCP server permissions - .claude/commands/: 9 conductor slash commands (conductor-setup, conductor-status, conductor-implement, conductor-new-track, conductor-verify, mma-tier1 through tier4)
68 lines
2.3 KiB
Markdown
68 lines
2.3 KiB
Markdown
---
|
|
description: Plan new work — audit codebase, create beads tasks with proper dependencies
|
|
---
|
|
|
|
# /conductor-new-track
|
|
|
|
Plan and create new beads tasks. This is a Tier 1 (Orchestrator) operation.
|
|
The quality of the task descriptions directly determines whether Tier 3 workers
|
|
can execute without confusion. Vague tasks produce vague implementations.
|
|
|
|
## Prerequisites
|
|
- Read `CLAUDE.md` for product alignment, policy rules, and architecture
|
|
|
|
## Steps
|
|
|
|
### 1. Gather Information
|
|
Ask the user for:
|
|
- **Goal**: what capability to add or fix
|
|
- **Scope**: which modules are involved
|
|
|
|
### 2. MANDATORY: Deep Codebase Audit
|
|
|
|
Before writing a single task, audit the actual codebase:
|
|
|
|
1. `get_tree` — map the current `src/rook/` structure
|
|
2. `py_get_code_outline` on every file the new work will touch
|
|
3. `py_get_definition` on relevant existing functions
|
|
4. `Grep` to find existing partial implementations
|
|
5. `get_git_diff` to understand recent changes
|
|
|
|
**Output**: A "Current State Audit" listing:
|
|
- What already exists (file:line references)
|
|
- What's missing (the actual gaps)
|
|
- What's partially implemented
|
|
|
|
### 3. Create Beads Tasks
|
|
|
|
Each task must be specific enough for a Tier 3 Worker to execute without
|
|
understanding the full architecture:
|
|
|
|
```powershell
|
|
cd C:\projects\rook
|
|
bd create --title "Verb: specific thing in specific file" --description "WHERE: file:lines. WHAT: change. HOW: API/pattern. SAFETY: thread constraints if any."
|
|
```
|
|
|
|
**Rules for task descriptions:**
|
|
1. Reference exact locations: "In `policy.py:confirm_spawn` (lines X-Y)"
|
|
2. Specify the API: "Use `subprocess.Popen` with `stdin=PIPE, stdout=PIPE`"
|
|
3. Name the data structures: "Append to `APPROVED_DIRS: list[str]`"
|
|
4. Describe the change shape: "Add a new function, do not modify existing ones"
|
|
5. State thread safety: "Must be called from asyncio loop only"
|
|
6. For bugs: list specific root cause candidates with code-level reasoning
|
|
|
|
### 4. Wire Dependencies
|
|
|
|
```powershell
|
|
bd dep add <new-id> <blocking-id> # new task depends on blocking-id
|
|
```
|
|
|
|
### 5. Confirm
|
|
Show the user the new tasks and dependency graph before finishing.
|
|
|
|
## Anti-Patterns
|
|
- Task that says "implement X" without WHERE or HOW → worker guesses wrong
|
|
- No line references → worker wastes tokens searching
|
|
- Tasks scoped too broadly → worker fails
|
|
- Not checking if something already exists → duplicate work
|