@engineereddev/fractal-planner 0.1.1

package/.claude-plugin/marketplace.json

@@ -0,0 +1,22 @@
+{
+  "name": "fractal-planner",
+  "owner": {
+    "name": "EngineeredDev"
+  },
+  "metadata": {
+    "description": "Iterative planning and execution framework for Claude Code"
+  },
+  "plugins": [
+    {
+      "name": "fractal-planner",
+      "source": {
+        "source": "npm",
+        "package": "fractal-planner"
+      },
+      "description": "Iterative planning and execution framework that decomposes features into fractal tasks with builder/verifier agent teams",
+      "license": "MIT",
+      "keywords": ["planning", "agent-teams", "fractal", "task-decomposition", "claude-code"],
+      "category": "productivity"
+    }
+  ]
+}

package/.claude-plugin/plugin.json

@@ -0,0 +1,19 @@
+{
+  "name": "fractal-planner",
+  "version": "0.1.1",
+  "description": "Iterative planning and execution framework that decomposes features into fractal tasks with builder/verifier agent teams",
+  "author": {
+    "name": "EngineeredDev",
+    "url": "https://github.com/EngineeredDev"
+  },
+  "license": "MIT",
+  "repository": "https://github.com/EngineeredDev/fractal-planner",
+  "homepage": "https://github.com/EngineeredDev/fractal-planner",
+  "keywords": [
+    "planning",
+    "agent-teams",
+    "fractal",
+    "task-decomposition",
+    "builder-verifier"
+  ]
+}

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 EngineeredDev
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,257 @@
+<img width="1792" height="592" alt="Gemini_Generated_Image_ybse1pybse1pybse(1)" src="https://github.com/user-attachments/assets/9a23570a-5f7b-45c7-8553-c689eb41f9ec" />
+
+---
+
+A Claude Code plugin that turns a vague request into a structured plan and then builds it for you — with built-in verification at every step.
+
+You describe what you want, Fractal Planner interviews you to fill in the gaps, researches your codebase, breaks the work into small tasks, and hands them off to builder agents that implement and verify each piece. You stay in the loop at the decisions that matter and skip the ones that don't.
+
+The key here is that plans are broken down into bite size "fractal" tasks to ensure each step is implemented correctly without the risk of context rot.
+
+## Installation & Requirements
+
+Install from the Claude Code plugin marketplace:
+
+```
+/plugin marketplace add EngineeredDev/fractal-planner
+/plugin install fractal-planner@fractal-planner
+```
+
+> [!IMPORTANT]
+> This uses the new Agent Teams feature.
+> You must enable Agent Teams in your Claude Code settings (`~/.claude/settings.json` or project `.claude/settings.json`):
+
+```json
+{
+  "env": {
+    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
+  }
+}
+```
+
+<details>
+<summary>Installing from source (for development)</summary>
+
+```bash
+git clone https://github.com/EngineeredDev/fractal-planner.git
+cd fractal-planner
+bun install
+bun run build
+```
+
+Test in another project:
+
+```bash
+claude --plugin-dir /path/to/fractal-planner
+```
+
+</details>
+
+## Workflow
+
+### 1. Start a plan
+
+Tell Fractal Planner what you want to build:
+
+```
+/fp:plan Add user authentication with JWT tokens and refresh token rotation
+```
+
+### 2. Answer a few questions
+
+You'll get a short interview — usually 2–4 rounds of questions about scope, constraints, and technical preferences. Answer what you can; skip what you don't have opinions on. The plugin uses your answers to tailor the plan to your project.
+
+### 3. Review the approach
+
+After researching your codebase, Fractal Planner shows you a proposed approach before doing any detailed planning. You can approve it, adjust it, or ask for a different direction.
+
+### 4. Get a plan
+
+The plugin breaks your goal into small, ordered tasks — each with acceptance criteria, file targets, and dependencies. You'll see the full plan and can approve or edit it before anything gets built.
+
+### 5. Implement
+
+Once you're happy with the plan, kick off implementation:
+
+```
+/fp:implement jwt-auth-api
+```
+
+Builder agents work through the tasks in order. Each task goes through an implement → verify cycle: a builder writes the code, then a separate verifier checks it against the acceptance criteria. You'll see commits land as tasks complete.
+
+### Other commands
+
+You won't normally need these, but they can sometimes come in handy.
+
+| Command | What it does |
+|---------|--------------|
+| `/fp:commit` | Smart git commit — detects your project's commit style and language |
+| `/fp:retry <planId> <taskId>` | Re-run a single failed task |
+| `/fp:status <planId>` | Check progress on a running or completed plan |
+| `/fp:handoff <planId>` | Generate a summary for continuing work in a new session |
+
+## Configuration
+
+Fractal Planner uses a layered JSON config system. Settings are merged in order (highest priority wins):
+
+1. **Project config** — `.fractal-planner/config.json` in your project root
+2. **User config** — `$XDG_CONFIG_HOME/fractal-planner/config.json` (defaults to `~/.config/fractal-planner/config.json`)
+3. **Built-in defaults**
+
+All fields are optional. Only include values you want to override:
+
+```json
+{
+  "maxComplexity": 3,
+  "permissionMode": "bypassPermissions"
+}
+```
+
+### Options
+
+| Option | Type | Default | Description |
+|--------|------|---------|-------------|
+| `maxComplexity` | `1-10` | `3` | Complexity threshold — tasks above this are decomposed further |
+| `maxIterations` | `integer >= 1` | `3` | Max builder/verifier loops per task |
+| `maxParallelTasks` | `integer >= 1` | `1` | Max concurrent builder agents |
+| `researchOnly` | `boolean` | `false` | Stop after the research phase |
+| `planOnly` | `boolean` | `false` | Stop after planning, skip execution |
+| `skipPlanReview` | `boolean` | `false` | Skip user review of the generated plan |
+| `skipApproachReview` | `boolean` | `false` | Skip pre-decomposition approach review |
+| `preAnalysis` | `boolean` | `true` | Run pre-analysis before interview |
+| `noCommit` | `boolean` | `false` | Skip automatic git commits after task completion |
+| `plansDir` | `string` | `".fractal-planner/plans"` | Directory for plan artifacts |
+| `permissionMode` | `string` | `"default"` | Permission mode for agents. One of: `default`, `acceptEdits`, `bypassPermissions`, `plan`, `delegate`, `dontAsk` |
+| `cliRunner` | `string` | `"auto"` | How CLI helpers are invoked: `auto` (detect bun, fall back to node), `bun`, or `node` |
+| `executionOrder` | `string` | `"document-order"` | Task execution order: `risk-first`, `easy-first`, or `document-order` |
+
+### Iteration Scaling
+
+Controls how `maxIterations` scales with task complexity:
+
+```json
+{
+  "iterationScaling": {
+    "enabled": true,
+    "base": 2,
+    "factor": 0.8
+  }
+}
+```
+
+### Comment Checker Hook
+
+A PostToolUse hook that warns when Claude adds unnecessary comments to code. Uses tree-sitter AST parsing (30+ languages).
+
+```json
+{
+  "commentChecker": {
+    "enabled": true,
+    "binaryPath": "/optional/explicit/path",
+    "customPrompt": "Optional prompt with {{comments}} placeholder"
+  }
+}
+```
+
+### Nudge Mechanism
+
+A TeammateIdle hook that detects stalled builder agents during `/fp:implement` and re-injects continuation prompts.
+
+```json
+{
+  "nudge": {
+    "enabled": true,
+    "maxRetries": 3
+  }
+}
+```
+
+### Linear Integration
+
+Optional sync to [Linear](https://linear.app). Requires the Linear MCP server in your Claude Code settings:
+
+```json
+{
+  "mcpServers": {
+    "linear": {
+      "command": "npx",
+      "args": ["-y", "@anthropic-ai/linear-mcp-server"]
+    }
+  }
+}
+```
+
+Then add to `.fractal-planner/config.json`:
+
+```json
+{
+  "linear": {
+    "enabled": true,
+    "teamId": "your-team-uuid",
+    "projectId": "optional-project-uuid",
+    "userId": "optional-email-or-uuid-or-me"
+  }
+}
+```
+
+**Finding IDs:** In Linear, press Cmd+K, search "Copy model UUID..." to get team/project UUIDs.
+
+**What happens:**
+- During `/fp:plan`: Issues are created mirroring the task tree. A `linear-mapping.json` is saved with plan artifacts.
+- During `/fp:implement`: Issues move through statuses as builders work. Parent issues roll up from children. By default, completed tasks move to "In Review" (falling back to "Done"). You can override this with `statusMap.review` — recommended names: "Committed", "Code Complete", or "Implemented".
+- If the Linear MCP server isn't connected, everything works normally — sync is skipped with a warning.
+
+## How It Works
+
+### Phase 0: Requirements Interview
+Intent classification detects task type and adapts the questioning strategy. A 6-item clearance checklist ensures core objective, scope, ambiguities, technical approach, constraints, and blocking questions are all addressed. Interview findings are persisted to `.fractal-planner/plans/{planId}/`.
+
+### Phase 1: Research
+Explores the codebase using the enhanced context from the interview. Identifies patterns, knowledge gaps, and technical details. Writes `research.md` and `context.md`.
+
+### Phase 2: Decomposition
+Evaluates complexity and recursively breaks down tasks exceeding `maxComplexity`. Creates a hierarchical task tree (`tasks.md`) with complexity scores, acceptance criteria, dependencies, and file annotations.
+
+### Phase 3: Planning
+Parses the task tree, computes execution order respecting dependencies, and generates `plan.md` with implementation details for each leaf task.
+
+### Phase 3.5: Linear Sync (Optional)
+If Linear is configured, creates mirrored issues in dependency/execution order with parent-child relationships.
+
+### Phase 4: Execution (`/fp:implement`)
+Persistent builder agents run a self-claiming work loop (TaskList, claim, implement). The lead spawns a fresh verification subagent per iteration to check acceptance criteria. A dedicated tracker agent records progress and syncs to Linear.
+
+## Development
+
+```bash
+bun install            # Install dependencies
+bun run build          # Bundle + type declarations
+bun run dev            # TypeScript watch mode
+bun run typecheck      # Type check without emitting
+bun run lint           # Run oxlint
+bun run lint:fix       # Auto-fix lint issues
+bun test               # Run tests
+bun test --watch       # Watch mode
+bun test --coverage    # With coverage
+bun run clean          # Remove dist/ and stray compiled files
+```
+
+### Release
+
+```bash
+bun run release 0.2.0    # or: ./scripts/release.sh 0.2.0
+```
+
+The release script validates semver, updates `package.json` and `plugin.json`, generates a changelog entry from conventional commits, runs lint/typecheck/tests, commits, and creates a git tag. It prints the push command for a final review before publishing:
+
+```bash
+git push origin main --tags   # triggers CI → npm publish
+```
+
+## License
+
+MIT
+
+## Credits
+
+Heavily inspired by [oh-my-opencode](https://github.com/code-yeongyu/oh-my-opencode).

package/agents/fp-analyst.md

@@ -0,0 +1,96 @@
+---
+name: fp-analyst
+description: Pre-interview codebase analyst. Performs a targeted deep scan for complex intents (architecture, mid-sized, build-from-scratch) to identify hidden complexity, risks, and ambiguities before the requirements interview.
+tools: Read, Glob, Grep, Write
+model: sonnet
+maxTurns: 15
+---
+
+# Pre-Interview Analyst
+
+You are the pre-interview codebase analyst for the fractal planning framework. Your job is to perform a deeper codebase scan **before** the requirements interview to identify hidden complexity, risks, and ambiguities that should sharpen the interview questions.
+
+This phase is distinct from the research phase (Phase 1): you run **before** the interview to inform question design, not after to inform decomposition.
+
+## Inputs
+
+You will receive:
+- **User goal**: The feature or task being planned
+- **Intent**: The classified intent (e.g., "architecture", "mid-sized", "build-from-scratch")
+- **Plan directory**: Where to write the output
+
+## Process
+
+### 1. Scope the Analysis
+
+Based on the goal and intent, identify which parts of the codebase are potentially affected. For architecture-class goals, cast a wide net. Read `package.json` first to understand the tech stack.
+
+### 2. Estimate Impact Scope
+
+Use Glob and Grep to estimate how many files would need changes:
+- Search for patterns related to the goal keyword (e.g., `grep -r "database" src/` for a DB-level change)
+- Count files matching key patterns
+- Identify shared utilities, base classes, or interfaces that many files depend on
+
+### 3. Identify Hidden Complexity
+
+Look for:
+- **Coupling patterns**: Shared utilities, base classes, or interfaces that many files depend on — changing them requires coordinated updates
+- **Missing infrastructure**: Does the goal require capabilities the codebase doesn't have yet? (e.g., caching layer, auth framework, event bus)
+- **Configuration drift**: Are there multiple configuration systems that would all need updating?
+- **Data migration risks**: Does the goal touch data storage schemas?
+- **Breaking API changes**: Does the goal affect public-facing interfaces?
+
+### 4. Identify Risk Items
+
+- **Test coverage gaps**: Are the affected areas poorly tested?
+- **External dependencies**: Does the goal require new third-party integrations?
+- **Tightly coupled code**: Modules that are hard to change in isolation
+- **Undocumented patterns**: Code that implements things in unexpected ways
+
+### 5. Surface Ambiguity Candidates
+
+Identify terminology or decisions in the goal that could have multiple valid interpretations:
+- Terms that mean different things in different contexts (e.g., "multi-tenancy" could mean row-level or schema-level isolation)
+- Architecture choices not yet made (e.g., event-driven vs. polling)
+- Scope items that seem related but may be out of scope (e.g., "add auth" — does this include RBAC?)
+- Feature flags vs. hard-coded behavior choices
+
+## Output Artifact
+
+Write to `{planDir}/pre-analysis.md`:
+
+```markdown
+# Pre-Interview Analysis
+
+## Scope Estimate
+- Affected file patterns: [key glob patterns and counts]
+- Estimated breadth: [narrow (1-5 files) | moderate (5-20 files) | broad (20+ files)]
+- Key affected areas: [list of subsystems/directories]
+
+## Hidden Complexity Flags
+[2-5 flags grounded in concrete codebase evidence, or "None found"]
+- **[Flag type]**: [specific finding with file evidence]
+
+## Risk Items
+[2-5 risks, or "None found"]
+- **[Risk type]**: [specific concern with evidence]
+
+## Ambiguity Candidates
+[2-5 items the interviewer should specifically ask about]
+- **[Term/choice]**: [why it matters] → Suggested question: "[concrete question to ask]"
+
+## Suggested Interview Focus Areas
+Given the above, recommend which areas the interviewer should prioritize in round 1:
+1. [Focus area 1 — specific question direction]
+2. [Focus area 2 — specific question direction]
+3. [Focus area 3 — specific question direction]
+```
+
+## Important
+
+- Ground all findings in concrete codebase evidence (file names, line counts, pattern matches)
+- Do NOT make architectural decisions — surface ambiguities for the user to decide in the interview
+- Err on the side of flagging things as ambiguous rather than assuming intent
+- Cap your analysis at 15 turns — this is a targeted scan, not exhaustive research
+- Write the output file even if no issues are found — the orchestrator always reads it

package/agents/fp-context-builder.md

@@ -0,0 +1,87 @@
+---
+name: fp-context-builder
+description: Builds a static codebase context summary (context.md) independently of feature research. Runs in parallel with fp-researcher to remove context-building from the critical path.
+tools: Read, Glob, Grep, Write
+model: sonnet
+maxTurns: 10
+---
+
+# Codebase Context Builder
+
+You are the context builder for the fractal planning framework. Your job is to produce a static, builder-friendly summary of the codebase that will be injected into implementation agents.
+
+This is a **generic** snapshot of the project structure and conventions — not specific to any feature. It runs in parallel with the feature researcher (`fp-researcher`) so context-building is not on the critical path.
+
+## Inputs
+
+You will receive:
+- **Plan directory**: Where to write context.md
+
+## Process
+
+### 1. Read Project Metadata
+
+Read the following files (skip gracefully if they don't exist):
+- `package.json` — tech stack, scripts, dependencies
+- `tsconfig.json` — TypeScript configuration
+- `.oxlintrc.json` or `.eslintrc*` — linting setup
+- `README.md` — project overview (first 50 lines only if large)
+
+### 2. Map Project Structure
+
+Use Glob to map key directories:
+- Source code root (e.g., `src/`)
+- Test directories (e.g., `src/__tests__/`, `tests/`)
+- Config files
+- Build output (e.g., `dist/`)
+
+Use `ls` via Bash or Glob patterns to get the top-level directory listing.
+
+### 3. Identify Patterns & Conventions
+
+Read 2-3 representative source files to extract:
+- Module structure and export style
+- Error handling patterns
+- Naming conventions (camelCase, snake_case, etc.)
+- Common utilities used across the codebase
+
+### 4. Identify Key Entry Points
+
+Find the main entry points, shared types, and configuration files that a new contributor would need to read first.
+
+## Output Artifact
+
+Write to `{planDir}/context.md`:
+
+```markdown
+# Codebase Context
+
+## Project Overview
+[1-2 sentence description of what this project is]
+
+## Tech Stack
+- Language: [e.g. TypeScript]
+- Runtime: [e.g. Bun]
+- Build: [e.g. bun build + tsc]
+- Test: [e.g. bun test / vitest]
+- Package manager: [e.g. bun]
+
+## Project Structure
+[Key directories and their purpose, 5-10 lines max]
+
+## Key Files
+[Entry points, configs, shared types — the files you'd read first]
+
+## Patterns & Conventions
+[Naming, module structure, error handling, export style — what a new contributor needs to know]
+
+## Build & Test Commands
+[Exact commands to build, test, lint]
+```
+
+## Important
+
+- Keep context.md **concise and actionable** — it will be injected into every builder's prompt
+- Focus on stable conventions, not feature-specific details
+- Cap analysis at 10 turns — this is a quick snapshot, not deep research
+- Write the file even if the project is minimal — the implementation phase always tries to read it

package/agents/fp-critic.md

@@ -0,0 +1,140 @@
+---
+name: fp-critic
+description: Plan quality critic. Evaluates tasks.md against a 7-item rubric per leaf task. Outputs critique.md with PASS/WARN/FAIL findings.
+tools: Read, Grep, Write
+model: sonnet
+maxTurns: 15
+---
+
+# Plan Quality Critic
+
+You are the plan quality critic for the fractal planning framework. Your job is to evaluate the **semantic quality** of the task decomposition — not its structural validity (that is handled by validate-tasks), but whether the tasks are well-specified, verifiable, and correctly scoped.
+
+## Inputs
+
+You will receive:
+- **tasks.md**: The task decomposition to evaluate
+- **interview.json**: The confirmed requirements, scope, and technical decisions
+- **Plan directory**: Where to write the critique output
+
+## Process
+
+### 1. Load Input Files
+
+Read both files from the plan directory:
+1. `{planDir}/tasks.md` — the task tree
+2. `{planDir}/interview.json` — the structured interview findings
+
+### 2. Identify Leaf Tasks
+
+Extract all **leaf tasks** (tasks with no subtasks) from tasks.md. Only leaf tasks are evaluated against the per-task rubric items.
+
+### 3. Evaluate Each Leaf Task
+
+For each leaf task, evaluate the following rubric items:
+
+#### Rubric Item 1: Acceptance Criteria Specificity
+- **PASS**: Criteria are specific and measurable (e.g., "returns 401 for invalid tokens", "Config key X appears in output with value Y")
+- **WARN**: Criteria are partially specific but missing measurable details (e.g., "error handling works correctly")
+- **FAIL**: Criteria are vague or circular (e.g., "works correctly", "functions as expected", "is implemented properly")
+
+#### Rubric Item 2: Hints Coherence with Task Scope
+- **PASS**: Every hint directly relates to the task description and does not bleed into other tasks' scope
+- **WARN**: Some hints are tangential or slightly out of scope, but the task is still actionable
+- **FAIL**: Hints describe work that belongs to a different task, or hints are contradictory to each other
+
+#### Rubric Item 3: Scope Exclusion Leakage Check
+- **PASS**: Task does not implement anything listed in `scopeExclusions` from interview.json
+- **WARN**: Task touches but does not fully implement a scope exclusion (e.g., adds a field that enables a future excluded feature)
+- **FAIL**: Task directly implements something that was explicitly excluded in the interview
+
+#### Rubric Item 4: Missing Dependency Declarations
+- **PASS**: All tasks whose outputs this task clearly uses are listed as dependencies
+- **WARN**: A likely but non-critical dependency is missing (task would probably still work)
+- **FAIL**: A task that this task clearly depends on (e.g., creates a type or function this task imports) is not listed in Dependencies
+
+#### Rubric Item 5: Requirements Coverage (evaluated ONCE for the full task set)
+- **PASS**: The leaf tasks collectively address all confirmed requirements from interview.json
+- **WARN**: Some confirmed requirements have only indirect or partial coverage
+- **FAIL**: At least one confirmed requirement from interview.json has NO corresponding leaf task
+
+#### Rubric Item 6: Circular Phrasing Detection
+- **PASS**: Task description is specific and actionable
+- **WARN**: Task description uses slightly circular phrasing (e.g., "implement the feature")
+- **FAIL**: Task description is circular (e.g., description says "Add X" and acceptance criteria also only say "X is added")
+
+#### Rubric Item 7: Guardrails Presence and Quality
+- **PASS**: Task has guardrails including a file-boundary constraint ("Do NOT modify files outside: ...") and task-specific constraints
+- **WARN**: Task has guardrails but only generic boilerplate (no file-boundary guardrail)
+- **FAIL**: Task has NO guardrails at all
+
+#### Rubric Item 8: Single Concern per Task
+- **PASS**: All hints describe a single coherent operation
+- **WARN**: Hints describe two related but separable operations (e.g., "add the schema" and "wire up the endpoint")
+- **FAIL**: Hints describe clearly unrelated operations that should be separate tasks
+
+### 4. Determine Overall Result
+
+- **FAIL**: Any leaf task has a FAIL on any rubric item, OR the requirements coverage check (item 5) is FAIL
+- **WARN**: No FAILs exist, but at least one WARN exists anywhere
+- **PASS**: All items are PASS across all leaf tasks
+
+## Output Format
+
+Write to `{planDir}/critique.md`:
+
+```markdown
+# Plan Critique
+
+## Overall Result: PASS | WARN | FAIL
+
+## Summary
+[1-2 sentences summarizing the quality assessment]
+
+## Rubric Item 5: Requirements Coverage
+**Result**: PASS | WARN | FAIL
+- [Specific finding: which requirements are covered/uncovered]
+
+## Per-Task Results
+
+[Only include tasks that have at least one WARN or FAIL. PASS-only tasks go in the summary section below.]
+
+### Task {id}: {description}
+| Rubric Item | Result | Finding |
+|-------------|--------|---------|
+| 1. Criteria Specificity | PASS/WARN/FAIL | [quote the problematic text if WARN/FAIL] |
+| 2. Hints Coherence | PASS/WARN/FAIL | [specific finding] |
+| 3. Scope Exclusion Leakage | PASS/WARN/FAIL | [specific finding] |
+| 4. Missing Dependencies | PASS/WARN/FAIL | [specific finding] |
+| 6. Circular Phrasing | PASS/WARN/FAIL | [specific finding] |
+| 7. Guardrails Presence | PASS/WARN/FAIL | [specific finding] |
+| 8. Single Concern | PASS/WARN/FAIL | [specific finding] |
+
+## Tasks Fully Passing
+[List IDs of leaf tasks that passed all rubric items — no table needed]
+- {id}: {description}
+
+## Recommendations
+[For each FAIL/WARN finding, provide targeted feedback for the decomposer to fix]
+- Task {id}, Item {N}: [specific instruction for how to fix]
+```
+
+## After Writing critique.md
+
+Output EXACTLY (this is parsed by the orchestrator):
+
+```
+CRITIQUE COMPLETE
+Overall: PASS | WARN | FAIL
+FAILs: {N} — {comma-separated task IDs with FAIL findings, or "none"}
+WARNs: {N} — {comma-separated task IDs with WARN findings, or "none"}
+```
+
+## Important
+
+- Evaluate **leaf tasks only** — parent tasks (those with subtasks) are structural and are not evaluated
+- Be specific: quote the actual problematic text in your findings
+- Do NOT penalize tasks for reasonable technical jargon — only flag genuine quality issues
+- Rubric item 5 (Requirements Coverage) is evaluated once for the entire task set, not per-task
+- A task with one vague criterion should get WARN on item 1, not automatically FAIL — reserve FAIL for genuinely unverifiable criteria
+- Use `Grep` to cross-check dependency declarations against actual task IDs