Compare Clean, Hexagonal and domain-driven architecture for an actual module/service boundary, tangled policy/I/O or dependency cycle. Use across languages when those responsibilities are in scope; not a requirement to add layers or interfaces to every project.
Research current best practices, technical reference implementations or version-sensitive guidance using primary sources and the owning repository's actual constraints. Not a dependency installer or automatic implementation workflow.
Clarify genuinely unresolved goals, constraints or design choices before a new feature or project. Use for requested design discussion; do not reopen decisions or force interviews for clear authorized work.
Master effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing review standards, or mentoring developers.
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Plan or implement an explicitly requested public-interface removal or API migration with consumer accounting, compatibility and rollback. Not routine refactoring, inactivity-based deletion or permission for deployments.
Audit or update repository documentation and agent guidance against the requested implementation scope.
Clarify domain vocabulary, ownership and invariants using the consuming project's existing glossary and ADR conventions; draft changes only when authorized.
Coordinate a shared API, schema, event, public package, or native-interface change across monorepo producers and consumers. Not needed for an isolated internal refactor.
Design, add or review logging, metrics, tracing or alerting for a concrete diagnostic gap. Use when those signals are requested or needed to explain a measured failure; not every production feature, routine prose change or an automatic telemetry-stack migration.
Use when implementing new functionality, refactoring, or deciding whether an abstraction or dependency is needed, especially when the user requests Ponytail, YAGNI, the smallest complete solution, or less over-engineering.
Review or implement security-relevant trust boundaries, authentication, authorization, sensitive data handling, dependency-audit findings or untrusted-input defenses. Use when those controls are in task scope or a concrete security risk is identified; not every feature or routine prose edit.
Maintain a specification for meaningful behavior, compatibility, or cross-package changes, with explicit proposed/current status and verification evidence. Not mandatory ceremony for small fixes or prose edits.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use failing-first behavioral tests for new or changed behavior and bug fixes. Use characterization for preserved behavior and static checks for prose or directory-only scaffolds.
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Design or substantively revise skills, AGENTS.md, CLAUDE.md or instruction documents consumed by agents. Use for routing, progressive disclosure and checkable completion criteria; not ordinary product prose or typo-only edits.
Turn an accepted specification or clear multi-step requirement into bounded implementation tasks with exact owners, interfaces and verification evidence. Not required for a trivial edit or a new permission gate.