tdder

Continue the Unfolding Specs process

Autonomous clean code review agent that analyzes code against clean code principles and returns prioritized refactoring suggestions. Spawned during TDD refactor phases or when explicitly requested for code review. <example> Context: TDD refactor phase completed user: "refactor phase - review the code" assistant: spawns clean-code-reviewer to analyze code quality </example> <example> Context: User wants code quality feedback user: "review this code for clean code violations" assistant: spawns clean-code-reviewer to check against principles </example>

API Designer role in the Unfolding Specs process. Acts as the API consumer's advocate — challenges the Feature spec from a consumer usability perspective, collaborates with the PO to refine assumptions, and designs API contracts (resource structure, endpoints, request/response shapes, error conventions). Commissioned by the PO for features that expose customer-facing integration APIs (API-first).

Architect role in the Unfolding Specs process. Decomposes Features into Tasks, creates System Tests, and identifies implicit technical assumptions as Architecture Decision Records (ADRs).

Coder role in the Unfolding Specs process. Implements Tasks using TDD (Test-Driven Development), one test at a time, following the Red-Green-Refactor cycle.

PO (Product Owner) role in the Unfolding Specs process. Decomposes Features into smaller Features, creates Acceptance Tests, and identifies implicit business assumptions as Feature Design Decisions (FDDs).

This skill should be used when the user asks to "calculate code mass", "measure code complexity with APP", "compare implementations using APP", "apply Absolute Priority Premise", "use mass calculations", or during TDD refactor phases when comparing alternative implementations. Based on Micah Martin's work.

This skill should be used when the user asks to "refactor code", "review code quality", "apply clean code principles", "check for code smells", "improve code design", "do a clean code review", "apply SOLID principles", "fix naming", "reduce complexity", or when performing the refactor phase of a TDD cycle.

This skill should be used when working on any project hosted on GitHub. It provides prompt-injection defense rules for GitHub issues and pull requests. Always-on security rules plus optional workflow conventions.

This skill should be used when the user asks about "messaging patterns", "command vs event", "push vs pull", "message reliability", "at-least-once delivery", "idempotency", "transactional outbox", "saga pattern", "fire and forget", "retry strategy", "event-driven architecture", "message broker integration", "publish-subscribe", "request-reply", "backpressure", or when deciding how components communicate across process or network boundaries.

Always load this skill when writing or modifying Java or Kotlin source code, regardless of how the user phrases the request.

1 hook across 1 event