Coordinate parallel ticket workers as an event-driven control plane through repos worktrees, Pi sessions, delegated pull-request review, squash merges, and filesystem tracker frontiers. Use when orchestrating implementation tickets rather than implementing or reviewing one ticket directly.
Implement one ticket handed off by the orchestrator and open a PR for review.
Manage work in the local Tickets filesystem tracker. Use when the user asks to inspect, search, create, claim, update, move, rename, complete, or lint a Tickets project or ticket.
Plan a huge chunk of work — more than one agent session can hold — as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
Provides comprehensive code review guidance. Helps catch bugs, improve code quality, and give constructive feedback. Use when: reviewing pull requests, conducting PR reviews, code review, reviewing code changes, establishing review standards, mentoring developers, architecture reviews, security audits, checking code quality, finding bugs, giving feedback on code.
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.
Use Datadog's MCP server through mcp2cli for agent-native Datadog investigation workflows: DDSQL, Kubernetes resource inspection, metric context/tag discovery, span/log/RUM attribute discovery and aggregation, monitor authoring/validation, dashboard widgets, notebooks, incidents, services, dependencies, and error tracking. Prefer pup-datadog-cli for stable scriptable Datadog API queries.
Route Datadog observability tasks between pup-datadog-cli and datadog-mcp. Use this first when the user asks about Datadog and it is not obvious whether the stable pup CLI or the Datadog MCP discovery/enrichment layer is the right tool.