odd-pipeline

Plugin odd-pipeline from marketplace my-claude-marketplace in TonyWu20/my-claude-marketplace. Commands read from the repo's manifest — 1 month ago.

Skills (7)

• debug-outcomes

  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

• define-outcomes

  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.

• diagnose-tests

  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, auditi

• drive-outcomes

  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 com

• file-issue

  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.

• init-project

  Stage 0 — grill the user to settle the repo constitution: architecture, coding patterns, domain language, dependency choices, and tooling configuration. Produces CONTEXT.md (domain glossary + tooling config) and ADRs (architectural decisions). MUST be run before `/drive-outcomes` on any project. Use

• make-judgement

  Review implemented changes against TASKS.md, produce review.md and fix-tasks.md for any defects found. Accepts a TASKS.md path and progressively loads group sections for validation. Use when the user says "/make-judgement <tasks-path>", "review the implementation", "judge the changes", or after /dri

Subagents (3)

• implementation-executor

  Use this agent when a `/drive-outcomes` orchestrator has produced

• software-architect

  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

• strict-code-reviewer

  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 exec

Similar plugins