t1

Always load this skill when a pom.xml file exists in the project, when creating or editing a pom.xml, or when setting up Maven project structure in a new project. It provides Maven-specific conventions for running tests, building, managing dependencies, and project structure.

This skill should be used when starting work on any project that uses tdder. It establishes interaction style, commit conventions, documentation discipline, and skill-trust principles. Invoke automatically alongside other tdder skills.

This skill should be used when the user asks to "add a feature using TDD", "fix a bug with TDD", "do TDD", "red-green-refactor", "write a failing test first", "use test-driven development", "start TDD", "test first approach", "TDD loop", "TDD cycle", or mentions TDD workflow, baby steps, guessing game, or red-green-refactor cycles. Not applicable for pure refactoring without new tests.

Orchestrator role in the Unfolding Specs process. Launches the PO, forwards unsolicited Sensei guidance, handles genuine commissioner issues, and resumes the workflow through the platform-specific live task mechanism.

Always load this skill when working on a Quarkus project, when the quarkus-maven-plugin is present in pom.xml, or when project setup has already chosen Quarkus before the pom.xml exists yet. It provides Quarkus-specific patterns and gotchas that complement the java and maven skills.

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 working on Java projects with JUnit tests that have layered preconditions, expensive shared setup (servers, databases, provisioned users), or complex scenario trees. Trigger phrases include "nested fixture", "fixture pattern", "scenario tree", "layered test setup", or when the user is writing integration tests with multiple levels of dependent setup/teardown. Complem

Always load this skill when writing, modifying, creating, or moving Java or Kotlin source code, or when project setup has already chosen Java/Kotlin as the implementation language.

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 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 commu

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 "design the architecture", "should I add a service layer", "add an abstraction", "introduce an interface", "separate concerns", "add a repository", "use hexagonal architecture", "add domain events", "split into layers", "add ports and adapters", "decouple this", "add an anti-corruption layer", "review package structure", "apply a design pattern", "wh