pub const SPLIT: &str = "---\nname: split\npurpose: Split a driver spec into members with detailed acceptance criteria\n---\n\n# Split Driver Specification into Member Specs\n\nYou are analyzing a driver specification for the {{project.name}} project and proposing how to split it into smaller, ordered member specs.\n\n**IMPORTANT: This is an analysis task. Do NOT use any tools, do NOT explore the codebase, do NOT make any changes, do NOT commit anything. ONLY output text in the exact format specified below.**\n\n## Driver Specification to Split\n\n**ID:** {{spec.id}}\n**Title:** {{spec.title}}\n\n{{spec.description}}\n\n## Your Task\n\nYou will complete this analysis in THREE PHASES:\n\n### Phase 1: Dependency Analysis\n\nBefore generating any member specs, analyze the work described in the driver spec:\n\n1. **Identify logical tasks** - List all distinct pieces of work needed\n2. **For each task, determine:**\n - **Inputs:** What information, types, functions, or infrastructure does this task need?\n - **Outputs:** What does this task produce? (functions, types, configs, modules, etc.)\n - **Shared types/interfaces:** What data structures or contracts are used across tasks?\n3. **Categorize tasks:**\n - **Infrastructure:** Logging, config, types, error handling, utilities (should have minimal dependencies)\n - **Features:** Business logic, user-facing functionality (often depend on infrastructure)\n - **Integration:** Wiring, main entry points (usually depend on features)\n\n### Phase 2: DAG Construction\n\nBased on the dependency analysis:\n\n1. **Determine actual dependencies** - For each task, justify which other tasks it depends on\n2. **Identify parallel tasks** - Which tasks can execute simultaneously after their dependencies?\n3. **Detect ordering errors** - Warn if infrastructure tasks depend on feature tasks\n4. **Build the DAG** - Show the dependency graph structure (not a linear chain unless truly necessary)\n\n### Phase 3: Generate Member Specs\n\nFor each task identified in Phase 1-2:\n\n1. Create a member spec with:\n - A descriptive title (5-15 words) that describes the specific change, not just the category\n - **Good:** \"Add unit tests for user authentication flow\"\n - **Good:** \"Implement error handling for invalid configuration files\"\n - **Bad:** \"Add tests\" (too terse, not specific)\n - **Bad:** \"Implement error handling\" (missing context on what/where)\n - Description of what should be implemented\n - Explicit acceptance criteria with checkboxes for verification\n - Edge cases that should be considered\n - Example test cases where applicable\n - List of affected files (if identifiable from the spec)\n - Clear \"done\" conditions that can be verified\n - **Inherited Context** section (constraints/principles from parent)\n - **Provides** section (if this task produces shared functions/types)\n - **Requires** section (if this task consumes outputs from other tasks)\n2. Ensure each member:\n - Leaves code in a compilable state\n - Is independently testable and valuable\n - Respects common patterns (add new alongside old \u{2192} update callers \u{2192} remove old)\n\n## Complexity Thresholds (Linting-Aware)\n\nEach resulting member spec should meet these thresholds to pass linting:\n- **Acceptance Criteria:** \u{2264} 5 items (allows haiku to verify completion)\n- **Target Files:** \u{2264} 5 files (keeps scope focused, minimal coupling)\n- **Description Length:** \u{2264} 200 words (haiku-friendly, clear intent)\n\nThese thresholds ensure the split produces specs that are:\n- **Independently executable** by Claude Haiku\n- **Verifiable** with clear, specific acceptance criteria\n- **Self-contained** without cross-references\n\n## Why Thorough Acceptance Criteria?\n\nThese member specs will be executed by Claude Haiku, a capable but smaller model. A strong model (Opus/Sonnet) doing the split should think through edge cases and requirements thoroughly. Each member must have:\n\n- **Specific checkboxes** for each piece of work (not just \"implement it\")\n- **Edge case callouts** to prevent oversights\n- **Test scenarios** to clarify expected behavior\n- **Clear success metrics** so Haiku knows when it\'s done\n- **Within complexity thresholds** so the spec stays manageable for haiku\n\nThis way, Haiku has a detailed specification to follow and won\'t miss important aspects.\n\n## Cross-References and Interface Contracts\n\nWhen member specs share functionality:\n- **Use explicit contracts** - If spec A creates a function spec B uses, define the contract\n- **Producer specs** include `## Provides` section with signatures (name, params, return type, errors)\n- **Consumer specs** include `## Requires` section referencing the contract\n- **Format:** \"Uses `ConfigType` from Member 2\" or \"Calls `detect()` from Member 3\"\n- **No spec ID references in main description** - only in Requires/Provides sections\n\nThis makes dependencies explicit while keeping specs self-contained.\n\n## Context Inheritance\n\nExtract and propagate parent spec\'s constraints to members:\n- Identify sections like: \"Constraints\", \"Design Principles\", \"Out of Scope\", \"What X Cannot Do\"\n- Add `## Inherited Context` section to each member with a concise summary\n- Don\'t duplicate verbatim - summarize relevant constraints for each member\n\n## Output Format\n\n**CRITICAL: You MUST output in TWO SECTIONS:**\n\n### Section 1: Dependency Analysis (Required)\n\nStart with `# Dependency Analysis` and include:\n\n```markdown\n# Dependency Analysis\n\n## Tasks Identified\n\n1. **Task Name** (Infrastructure/Feature/Integration)\n - Inputs: What this needs\n - Outputs: What this produces\n - Shared types: Any contracts or interfaces\n\n2. **Task Name** (Infrastructure/Feature/Integration)\n - Inputs: What this needs\n - Outputs: What this produces\n - Shared types: Any contracts or interfaces\n\n...\n\n## Dependency Graph\n\n```\nTask 1 (infra)\n \u{251c}\u{2500}\u{2500} Task 2 (feature)\n \u{251c}\u{2500}\u{2500} Task 3 (feature)\n \u{2502} \u{2502}\n \u{2502} v\n \u{2514}\u{2500}\u{2500}\u{2500}> Task 4 (integration) <\u{2500}\u{2500}\u{2500} Task 2\n```\n\n**Justification:**\n- Task 2 depends on Task 1 because: [reason]\n- Task 3 depends on Task 1 because: [reason]\n- Task 4 depends on Tasks 2 and 3 because: [reason]\n- Tasks 2 and 3 can run in parallel after Task 1\n```\n\n### Section 2: Member Specs (Required)\n\nAfter the dependency analysis, output member specs in this format:\n\n```markdown\n## Member 1: <title>\n\n<description of what this member accomplishes>\n\n### Inherited Context\n\n- Constraint/principle from parent spec\n- Another relevant constraint\n\n### Acceptance Criteria\n\n- [ ] Specific criterion 1\n- [ ] Specific criterion 2\n- [ ] Specific criterion 3\n\n### Edge Cases\n\n- Edge case 1: Describe what should happen and how to test it\n- Edge case 2: Describe what should happen and how to test it\n\n### Example Test Cases\n\nFor this feature, verify:\n- Case 1: Input X should produce Y\n- Case 2: Input A should produce B\n\n### Provides\n\n*Include this section if this member produces shared functionality:*\n- `function_name(params) -> return_type` - Description and error cases\n- `TypeName` - Description of the type\n\n### Requires\n\n*Include this section if this member needs outputs from other members:*\n- Uses `TypeName` from Member 2\n- Calls `function_name()` from Member 3\n\n**Affected Files:**\n- file1.rs\n- file2.rs\n\n**Dependencies:** Member 2, Member 3 *(list member numbers this depends on)*\n\n## Member 2: <title>\n\n... (continue with same format)\n```\n\n**Important notes:**\n- Omit sections that don\'t apply (Provides, Requires, Inherited Context if none)\n- If no files identified, omit Affected Files\n- If no dependencies, set Dependencies to \"None\"\n- Create as many members as needed (typically 3-7 for a medium spec)\n\n**Remember: Output BOTH sections - Dependency Analysis first, then Member Specs. No preamble, no \"I will create...\" statements.**\n";Expand description
Split prompt - for splitting driver specs into member specs