Fix Failures

---
description: Systematically identify, categorize, and fix test/linter failures using
  appropriate tools and agents
prompt: "# Fix Test and Linter Failures\n\nSystematically identify, document, categorize,\
  \ and fix test/linter failures in the codebase using the most appropriate tools\
  \ and agents for each failure type.\n\n## Workflow\n\n### Phase 1: Discovery and\
  \ Documentation\n1. **Run tests/linters** to identify all failures\n   - If `$1`\
  \ is provided, use that as the test command\n   - Otherwise, detect the project\
  \ type and use appropriate defaults:\n     - Python: `pytest`, `ruff check`, `mypy`\n\
  \     - Java/Kotlin: `./gradlew test`, `./gradlew check`\n     - JavaScript/TypeScript:\
  \ `npm test`, `npm run lint`\n     - Go: `go test ./...`, `golangci-lint run`\n\n\
  2. **Capture full failure output** including:\n   - Error messages and stack traces\n\
  \   - File paths and line numbers\n   - Failure categories (compilation, test, linter,\
  \ type checking)\n   - Exit codes and summary statistics\n\n3. **Create structured\
  \ failure inventory** using TodoWrite:\n   - Group failures by type and severity\n\
  \   - Track dependencies between failures\n   - Estimate complexity for each failure\n\
  \n### Phase 2: Categorization and Strategy\nCategorize each failure into one of\
  \ these types and determine the appropriate fix strategy:\n\n#### Test Failures\n\
  - **Unit test failures**: Logic bugs, incorrect assertions, missing edge cases\n\
  - **Integration test failures**: API changes, database issues, timing problems\n\
  - **Flaky tests**: Race conditions, test isolation, environment dependencies\n-\
  \ **Strategy**: Use `java-test-debugger` or `golang-test-debugger` agents for systematic\
  \ diagnosis\n\n#### Linter Failures\n- **Style violations**: Formatting, naming\
  \ conventions, code organization\n- **Code smells**: Complexity, duplication, unused\
  \ code\n- **Best practice violations**: Security issues, anti-patterns\n- **Strategy**:\
  \ Use `code-refactoring` agent with AST-based tools (gritql) for systematic fixes\n\
  \n#### Compilation/Type Failures\n- **Type errors**: Missing types, incompatible\
  \ types, generic issues\n- **Import errors**: Missing dependencies, circular imports\n\
  - **Syntax errors**: Language version issues, invalid constructs\n- **Strategy**:\
  \ Direct fixes for simple issues, research agent for complex type system problems\n\
  \n#### Build Configuration Failures\n- **Dependency issues**: Version conflicts,\
  \ missing packages\n- **Build tool errors**: Configuration problems, plugin issues\n\
  - **Environment issues**: Missing tools, incompatible versions\n- **Strategy**:\
  \ Research best practices, update configurations systematically\n\n### Phase 3:\
  \ Execution Strategy\nFor each failure category, apply the appropriate approach:\n\
  \n#### Simple, Independent Fixes (Direct Approach)\n- **Criteria**: Single file,\
  \ clear fix, no dependencies\n- **Action**: Fix directly using Edit tool\n- **Examples**:\
  \ Import errors, simple type fixes, formatting\n\n#### Complex, Systematic Fixes\
  \ (Agent Approach)\n- **Test failures**: Launch `java-test-debugger` or `golang-test-debugger`\n\
  \  - Provide test output and context\n  - Let agent diagnose root cause\n  - Review\
  \ and apply fixes\n\n- **Code quality issues**: Launch `code-refactoring` agent\n\
  \  - Specify refactoring pattern\n  - Use gritql for structural changes\n  - Validate\
  \ with tests after refactoring\n\n- **Codebase research needed**: Launch `Explore`\
  \ agent\n  - Search codebase for similar patterns\n  - Understand how related functionality\
  \ works\n  - Find examples of correct implementation\n  - Identify architectural\
  \ patterns to follow\n\n- **External research needed**: Launch `knowledge-synthesis`\
  \ agent\n  - Research solutions in official documentation\n  - Investigate GitHub\
  \ issues and discussions\n  - Synthesize best practices from multiple sources\n\
  \  - Create zettel notes for future reference\n\n#### Parallel Execution\n- **Launch\
  \ multiple agents in parallel** for independent failures\n- **Example**: Different\
  \ test classes failing independently → parallel test-debugger agents\n- **Benefit**:\
  \ Maximize throughput and efficiency\n\n### Phase 4: Validation and Iteration\n\
  1. **Re-run tests/linters** after each fix batch\n2. **Track progress** in todo\
  \ list:\n   - Mark resolved failures as completed\n   - Document new failures discovered\n\
  \   - Update dependencies between fixes\n3. **Iterate** until all failures resolved\
  \ or blocked\n4. **Document blockers** that require human decisions\n\n## Observability\
  \ Improvements\nIf failures are difficult to diagnose, improve observability:\n\n\
  ### For Test Failures\n- Add detailed assertion messages\n- Improve test output\
  \ formatting\n- Add debug logging at key points\n- Use test fixtures to isolate\
  \ problems\n- Add timing information for flaky tests\n\n### For Build Failures\n\
  - Enable verbose build output\n- Add dependency tree visualization\n- Log environment\
  \ information\n- Add pre-build validation checks\n\n### For Linter Failures\n- Configure\
  \ linter for detailed explanations\n- Add inline documentation for complex rules\n\
  - Enable auto-fix where safe\n- Create custom rules for project patterns\n\n## Usage\
  \ Examples\n\n```bash\n# Use default test command for project type\n/fix-failures\n\
  \n# Use specific test command\n/fix-failures \"npm run test:ci\"\n\n# Use specific\
  \ linter\n/fix-failures \"ruff check --output-format=full\"\n\n# Use build command\n\
  /fix-failures \"./gradlew clean build\"\n```\n\n## Agent Selection Decision Tree\n\
  \n```\nFailure Type → Agent Choice\n├─ Test Failure (Java/Kotlin) → java-test-debugger\n\
  ├─ Test Failure (Go) → golang-test-debugger\n├─ Test Failure (Other) → Explore agent\
  \ (find patterns) + Direct fix\n├─ Code Quality/Refactori