odd-pipeline

Use this agent when a `/drive-outcomes` orchestrator has produced TASKS.md tasks and you need a specialist to implement those tasks on a git branch with real build feedback. This agent should be invoked for any concrete coding sub-task that requires editing code, running build commands, and fixing errors — the edit→check→fix loop. \n\n<example>\nContext: A drive-outcomes orchestrator has decomposed a phase plan into TASKS.md with task groups.\nuser: \"Implement group-core tasks from TASKS.md\"\nassistant: \"I'll launch the implementation-executor agent to implement these tasks on the branch with build feedback.\" \n<commentary>\nThe drive-outcomes orchestrator delegates a task group to the implementation-executor agent for branch-based implementation with build feedback.\n</commentary>\n</example>\n\n<example>\nContext: A make-judgement review has produced fix-tasks.md with defects to resolve.\nuser: \"Apply the fix directions for the review issues\"\nassistant: \"I'll use the implementation-executor agent to apply the fixes on the branch with the same edit→check→fix loop.\"\n</commentary>\n</example>

Use this agent when you need architectural guidance, code review, or strategic planning for software projects. This includes designing new systems, evaluating existing code structure, refactoring for better design, or when you want a senior engineer's perspective that challenges initial assumptions and applies first-principles thinking.\n\n<example>\nContext: User is starting a new service and wants architectural guidance.\nuser: "I want to build a REST API that handles user authentication and data storage."\nassistant: "Let me use the software-architect agent to design the architecture for this service."\n<commentary>\nThe user needs architectural planning for a new project. The software-architect agent should be invoked to apply first-principles thinking and propose a clean architecture before any code is written.\n</commentary>\n</example>\n\n<example>\nContext: User has written a module and wants a review.\nuser: "Here's my implementation of the repository layer. Can you review it?"\nassistant: "I'll use the software-architect agent to review this code for design quality, separation of concerns, and best practices."\n<commentary>\nA code review request is a prime use case for the software-architect agent, which will evaluate readability, ergonomics, SRP, and test coverage.\n</commentary>\n</example>

Use this agent when code changes, implementations, or fixes need rigorous review against project documentation, architecture, and coding standards. Examples:\n\n<example>\nContext: The user has just implemented a new feature or module in the codebase.\nuser: "I've finished implementing the execution engine in src/engine/executor.py"\nassistant: "Let me launch the strict-code-reviewer agent to verify the implementation against the project architecture and documentation."\n<commentary>\nA significant implementation was completed. Use the Agent tool to launch the strict-code-reviewer to explore the codebase, check docs, and validate the code.\n</commentary>\n</example>\n\n<example>\nContext: The user has applied a bug fix and wants to ensure it's correct and consistent.\nuser: "I fixed the node dependency resolution bug in the workflow engine."\nassistant: "I'll use the strict-code-reviewer agent to verify the fix aligns with the real codebase and doesn't introduce drift from the architecture."\n<commentary>\nA bug fix was applied. Use the Agent tool to launch the strict-code-reviewer to check the fix against actual files and specifications.\n</commentary>\n</example>\n\n<example>\nContext: A subagent or assistant has proposed or applied code changes.\nuser: "The coding agent just refactored the task scheduler."\nassistant: "I'll invoke the strict-code-reviewer agent to double-check the refactor against actual files and prevent any hallucinated changes."\n<commentary>\nAnother agent made changes. Use the strict-code-reviewer to ground-truth the changes against real files and documentation.\n</commentary>\n</example>

Debug an existing fixture-anchored system that passes its acceptance test but produces wrong output. Classifies prior investigation notes, establishes external anchor criteria, applies upstream-audit rule, implements fix with discriminator-value tests, and captures resolution. Use when the user says "/debug-outcomes", "debug this failure", "the test passes but the output is wrong", or describes a symptom in a system that already has fixture files and a passing (but loose) acceptance test.

Interactive skill that helps users define desired outcomes for the next phase through Socratic grilling. Produces a PHASE_PLAN.md with concrete goals, scope boundaries, and success criteria. Uses grill-me + first-principle thinking to question priorities and foundations before committing to a plan. This is the recommended step before `/drive-outcomes`, especially when goals are still vague. Use when the user says "/define-outcomes", "define the outcomes", "clarify what we want", "what should the next phase achieve", "plan the next phase", or wants to decide what the next phase should accomplish before implementing.

Scans a project's existing test suite for placebo test patterns (vacuous assertions, circular round-trip, unbounded thresholds, synthetic-only data). Produces a migration report to help projects adopt the Outcome-Driven Development (ODD) pipeline. Use when migrating from the old TDD pipeline, auditing test quality, or when the user says "/diagnose-tests", "audit my tests", "find placebo tests", or "how healthy are my tests?".

Merged Stage 1+2 — define success criteria, explore against real fixtures, validate, implement, and produce a forensic record. One continuous session with a checkpoint in the middle. Use when the user says "/drive-outcomes <plan-path>", "drive the outcomes for this phase", after /define-outcomes completes, or when a phase plan is already ready for ODD-driven implementation.

File a bug report or feature request for the odd-pipeline itself, with auto-gathered context from the current project and session. Use when the user says "/file-issue", "file a bug", "report an issue", "this is a pipeline problem", or encounters a pipeline defect during daily use.