
Tasktracker-native Socratic brainstorming. Refines a raw idea into a frozen brainstorm document tree stored in tasktracker (NOT in docs/brainstorms/*.md), with every chosen/deferred/rejected option recorded as a decision and an optional one-way promotion into a task tree. Use whenever a user wants to brainstorm, explore, refine, or "think through" an idea AND the work is (or will be) tracked in tasktracker. Triggers on "tt brainstorm", "brainstorm with tasktracker", "brainstorm in tasktracker", "explore this idea (tasktracker)", "/tt-brainstorm", or any brainstorm-style request inside a session that already has a tasktracker active task or project. Prefer this over the plain /brainstorm skill whenever a tasktracker MCP is available — the artifacts integrate with /tt-create-plan and /tt-implement-plan, so picking the file-based variant in a tasktracker project just creates orphan markdown.
Tasktracker-native plan orchestrator. Drives execution of a plan whose phases are stored as tasktracker phase tasks (NOT a docs/plans/*.md file). Honours active-task discipline (setActiveTask before every artifact-producing call, pauseActiveTask before user waits, clearActiveTask on phase done), respects the locked phase body (design notes go to sub-tasks, never to the phase description), logs defects/learnings/frictions through tasktracker insights as they surface, and delegates the actual implementation to /implement-phase. Use whenever the user wants to "implement the plan", "run the plan", or "work through the phases" AND the plan was created with /tt-create-plan (or otherwise lives in tasktracker). Triggers on "tt implement plan", "tt implement", "implement plan (tasktracker)", "/tt-implement-plan", "execute the tasktracker plan", or any plan-execution request inside a session that already has a tasktracker active task or project. Prefer this over the plain /implement-plan skill whenever a tasktracker MCP is available — it correctly handles the locked phase body, requirement linking, insight logging, and lifecycle gating that the file-based variant ignores.
Tasktracker-native project-wide parallel audit using the Claude Code Workflow tool (dynamic workflows). Partitions a repo / backlog / architecture and fans out read-only agents (one per partition) that return schema-checked findings, aggregates them into a deduplicated, ranked risk register, and OPTIONALLY writes fixes back as tasks under a Bug Fix phase — with all tasktracker writes done by the PARENT, never the parallel agents (single global active-task pointer). Journaled and resumable, so a rate-limit or crash mid-audit resumes without re-running completed partitions. Use for large, embarrassingly-parallel, read/analyze-heavy jobs where each unit is self-contained and the output aggregates — audit every file/component for risk, find all architecture drift (scanArchitectureDrift) or duplicate tasks (detectDuplicates/auditDuplicates), per-file tech-debt sweep, test-coverage or security-surface scan across a whole project. Triggers on "/tt-workflow-audit", "audit the whole repo", "parallel audit", "scan every file/component", "find all drift/duplicates", "tech-debt sweep (tasktracker)", or any whole-project analyze-at-scale request inside a session with a tasktracker project. Prefer this over /codebase-audit or /code-quality-audit when the project is tracked in tasktracker AND you want the findings written back as tasks; prefer it over team-* modes when the units don't need to negotiate live (they just report).
--- name: tt-workflow-run description: Tasktracker-native autonomous build-loop orchestrator. Drives a first-class `workflow_run` end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while `getNextReadyTask(projectId)` returns a slice — `setActiveTask` → record a pre-slice `scanArchitectureDrift` baseline → delegate the slice to `/tt-implement-phase` (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/fr
Recommend which workflow mode fits the task at hand — solo (implement-plan), small team (team-implement-plan with Implementer + Reviewer), full team (team-implement-plan-full with parallel per-phase implementers + shared Reviewer), or a dynamic workflow (the Workflow tool — deterministic parallel fan-out across tens-to-hundreds of background agents for large read/analyze/audit/research jobs, e.g. /tt-workflow-audit). Factors in task complexity, risk, parallelism, work shape (analyze vs implement), and token budget. Use when the user asks which workflow to pick, is unsure whether to go solo or team-based, mentions "which mode should I use", asks "solo or team for this", "should I use a workflow", "parallel audit", or is about to kick off execution without having chosen a mode. Triggers on "/workflow-guide", "which workflow mode", "solo or team", "pick a workflow", "dynamic workflow or team".
--- name: tt-workflow-build description: Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skil
--- name: grumpy-reviewer description: A single grumpy, nitpicky structural code reviewer that runs as an isolated subagent and treats the code as third-party work submitted by a junior programmer for validation. It cares about exactly one thing — maintainability — judged through separation of concerns, service-oriented design, helper-method extraction, small files, and the rule of 7 (as any grouping nears 7 members, it pushes for sub-groupings). It is deliberately kept OUT of the implementation
Tasktracker-native per-phase executor. Runs a SINGLE phase whose scope and sub-tasks live as tasktracker phase + sub-task rows (NOT in a docs/plans/*.md file). Honours active-task discipline (setActiveTask on phase AND on each sub-task as worked), respects the locked phase body (HTTP 422 on description edit — design notes go to sub-tasks), updates sub-task status via tasktracker_updateTaskStatus as work progresses, logs defects/learnings/frictions through tasktracker insights, and delegates code work to subagents when a subagent-dispatch tool is available — otherwise does the work in-context itself (graceful degradation), never stalling. Used by /tt-implement-plan as the per-phase unit of work; can also be invoked directly with a phase task id. Triggers when /tt-implement-plan delegates a phase, or manually with "/tt-implement-phase <phase-task-id>", "tt implement phase", "execute phase (tasktracker)", "/tt-implement-phase". Prefer this over the plain /implement-phase skill whenever a tasktracker MCP is available — /implement-phase will happily edit a phase task description (HTTP 422), miss sub-task status updates, and bury defects in chat narrative instead of insights.
Tasktracker-native implementation planning. Turns a frozen brainstorm (or a clear requirement) into a phased plan persisted as tasktracker phase tasks — NOT as a docs/plans/*.md file. Creates requirements with formal acceptance criteria, registers architecture components, generates phases via createPhaseFromTemplate (backend-feature / ui-fix / refactor / schema-migration / bug-investigation / docs-only / data-housekeeping), links every task back to its requirement, and uses getProjectReadiness as the completion gate. Use whenever the user wants to plan, design, or scope an implementation AND the work is (or will be) tracked in tasktracker. Triggers on "tt create plan", "tt plan", "plan this in tasktracker", "create a plan (tasktracker)", "/tt-create-plan", or any plan-creation request inside a session that already has a tasktracker active task or project. Prefer this over the plain /create-plan skill whenever a tasktracker MCP is available — the resulting phase tasks integrate with /tt-implement-plan and /implement-phase, so picking the file-based variant in a tasktracker project just creates orphan markdown.
Comprehensive security audit for code changes. Use this skill when implementing authentication, authorization, user input handling, API endpoints, secrets/credentials, payment features, or file uploads. Provides security checklists, vulnerability patterns, and remediation guidance. Integrates with implement-phase as a security quality gate.
Suggest context compaction at optimal logical boundaries — between phases, after a research burst, after a debugging session ends — rather than waiting for the automatic compaction threshold to hit mid-task. Use when the user asks whether to compact, mentions context is getting long, wants to checkpoint before a big task, or when you notice the session is approaching a natural transition where compacting would preserve the next phase's context. Complements (doesn't replace) Claude Code's built-in auto-compaction. Triggers on "/strategic-compact", "should I compact", "when should I clear context", "getting long", or proactively at phase boundaries and session transitions.
Adversarial brainstorming using agent teams for multi-perspective analysis. Use when users want thorough idea exploration with real debate between independent perspectives. Triggers on "team brainstorm", "adversarial brainstorm", "brainstorm with team", "debate this idea", or when the user explicitly requests team-based analysis. Higher token cost but significantly deeper analysis than single-agent brainstorm.
Execute implementation plans with a small review team (Implementer + Reviewer + optional Integrator). The Implementer writes code directly while the Reviewer provides adversarial quality checks per phase. Use for moderate-to-complex plans where real-time adversarial review catches issues that automated checks miss. Triggers on "team implement", "team implement plan", or when the user explicitly wants team-based implementation.
Generate hierarchical user stories (epics, features, tasks) with formal Given/When/Then acceptance criteria. Works from brainstorm output or standalone. Produces structured requirements that feed directly into create-plan. Triggers on "create user stories", "write stories", "define requirements", "user story", or when presenting features that need requirements decomposition.
Comprehensive 6-check verification framework for validating implementation quality across build, types, lint, tests, security, and diff review. This skill ensures code meets all quality gates before phase completion. Triggers on "verify implementation", "run verification", "/verification-loop", or automatically as part of implement-phase Step 2.
Update existing implementation plans through user feedback with thorough research and validation. Also migrates old checkbox-based plans to the new Task tools system. This skill should be used when iterating on implementation plans, updating plans based on new requirements, refining technical approaches in existing plans, migrating old plans to Task tools, or when the user wants to modify a previously created plan file. Triggers on requests like "update the plan", "change the implementation approach", "iterate on this plan", "migrate to new system", or when feedback is provided about an existing plan document.
Adversarial code review that breaks the self-review monoculture by spawning three independent subagent personas (Saboteur, New Hire, Security Auditor) in parallel isolated contexts. Each subagent has no knowledge of the author's intent or Claude's prior conclusions — Claude cannot replicate that isolation on its own. Default mode reviews a diff (staged/unstaged, or explicit ref/file); `--codebase` mode reviews an entire repo or subtree for tech debt, attack surface, and knowledge silos. Use before merging a PR, when the user asks for a hostile/harsh/adversarial/critical/brutal/skeptical review, when the user admits fatigue after a long session, when an earlier /code-review came back too easily clean, when the user trusts a gut feeling that something is off, or when the user wants a whole-codebase audit of an inherited / unfamiliar repo. Triggers on "/adversarial-reviewer", "/adversarial-review", "adversarial review", "hostile review", "critical review", "harsh review", "review this PR harshly", "second-opinion review", "pre-merge review", "adversarial audit of this repo", "what am I inheriting". Different from /code-review (routine per-phase review; no subagent isolation) and /security-review (OWASP-specific single-lens depth).
Write the current session's in-flight work state to a human-readable handoff doc on disk (docs/context/CONTEXT-{topic}.md) so a future chat session — or another person — can pick up exactly where this one stops. Distinct from Claude Code's built-in memory system, which captures long-lived facts and preferences; this skill captures **active session context** (what's being built right now, which files are mid-edit, what's been tried, what's next). Use when the user says "save context", "checkpoint", "save progress", "preserve state", "save before I step away", "dump this so I can continue tomorrow", or before ending a long session with incomplete work. Optimizes for correctness, completeness, minimal size, and trajectory preservation.
Execute implementation plans with a full team — one implementer per phase running in parallel where the dependency graph allows, plus a shared cross-phase Reviewer. Phases execute in waves based on dependencies. Use for large plans with 4+ phases and independent work streams. Highest token cost but fastest execution for parallelizable work. Triggers on "full team implement", "parallel implement", or when the user explicitly wants maximum parallelism.
Team-based implementation planning with adversarial design review. Spawns an Architect, Risk Analyst, and Researcher who explore competing designs and challenge each other before producing a plan. Use when planning complex features, high-stakes changes, or when multiple valid approaches exist. Triggers on "team create plan", "team plan", "deep plan", or when the user explicitly wants team-based planning.
Generate interactive HTML visualizations of the skills collection, codebase structure, or dependency graphs. Uses D3.js for interactive visualization with collapsible nodes, color-coded categories, and hover details. Triggers on "visualize skills", "generate skill map", "codebase visualization", or "show skill dependencies".
Execute a single phase from an implementation plan with all quality gates. This skill is the unit of work for implement-plan, handling implementation, verification, code review, ADR compliance, and plan synchronization for ONE phase. Triggers when implement-plan delegates a phase, or manually with "/implement-phase" and a phase reference.
Systematic code review for implementation phases verifying architectural principles, framework standards, ADR compliance, and code quality. This skill is invoked by implement-phase as part of its quality gate pipeline, or manually when reviewing code changes. Triggers on "review code", "code review", "/code-review", or automatically as Step 3 of implement-phase.
Comprehensive E2E testing skill using Playwright MCP for systematic web application testing. This skill should be used when users need to test web-based systems end-to-end, set up test regimes, run exploratory tests, or analyze test history. Triggers on requests like "test my webapp", "set up E2E tests", "run the tests", "what's been flaky", or when validating web application functionality. The skill observes and reports only - it never fixes issues. Supports three modes - setup (create test regime), run (execute tests), and report (analyze results).
Run code quality audits covering test coverage, cyclomatic complexity, module sizes, dependency structure (cycles, fan-in/out), and mutation testing. Produces a prioritized report and acts as a quality gate. Use whenever the user wants to audit code quality, check coverage, find complex or oversized modules, detect dependency cycles, run mutation tests, assess technical debt, or gate a phase on quality thresholds. Triggers on "audit code quality", "check coverage", "run mutation testing", "find complex modules", "check for cycles", "/code-quality-audit", or automatically before marking an implementation phase complete.
Document architectural decisions in standardized ADR format. This skill should be used when making significant technical decisions, choosing between approaches, establishing patterns, or when other skills (create-plan, implement-plan, brainstorm) identify decisions that need documentation. Triggers on "document decision", "create ADR", "architectural decision", or automatically when invoked by other skills during planning and implementation.
--- name: codebase-audit description: Long-running comprehensive adversarial audit of an entire codebase. Orchestrates partition-by-partition adversarial reviews by delegating to /adversarial-reviewer --codebase <partition>, then synthesizes a cross-partition risk register and a written remediation report. Unlike /adversarial-reviewer --codebase (which samples strategically from the whole repo in one pass), this skill methodically covers the full scope over a long session, is resumable after cra
Promote valuable session learnings into reusable, triggerable skill files in ~/.claude/skills/learned/. Unlike Claude Code's built-in memory (which captures conversational facts and preferences), this skill extracts structured patterns — error resolutions, user corrections, workarounds, debugging techniques, project conventions — that future sessions can match against specific triggers. Use at end of a session (typically via Stop hook), after solving a hard bug, when the user says "save what we learned", "remember this for next time", or "extract patterns from this session".
Multi-session, resumable deep brainstorming with mindmap-on-disk structure. Explores ideas across multiple dimensions using creative methodologies (Morphological Analysis, TRIZ, Lateral Thinking, Lotus Blossom, Assumption Mapping). Sessions persist to filesystem and can span days. Triggers on "deep brainstorm", "deep dive brainstorm", "multi-session brainstorm", "brainstorm deeply", or when the user wants extended, resumable idea exploration. Higher depth than brainstorm or team-brainstorm but spread across sessions.
Create composable AI agent systems in NestJS projects following the "tools all the way down" architecture. Use this skill when users want to: (1) Create new AI agents with orchestrator/planner/executor/evaluator components, (2) Build agentic systems that can call other agents as tools, (3) Implement DAG-based planning with parallel execution, (4) Add database-backed state persistence for agent runs, (5) Create custom evaluators for quality assurance. Triggers on "create agent", "build agent", "agent system", "agentic", "orchestrator", "planner/executor pattern", or NestJS AI agent requests.
Build evaluation harnesses for AI-assisted implementations — capability evals, regression tests, graders (exact-match, LLM-judge, code-exec, rubric), and standardized metrics (pass@k, accuracy, latency, cost). Use when the user wants to set up or run evals, benchmark agents/skills, create regression test suites for prompts or AI features, compare model/prompt variants, or measure implementation quality. Triggers on "set up evals", "create eval harness", "benchmark this skill", "regression test the prompt", "run evals", "/eval-harness", or any request to systematically measure AI output quality.
Interactive idea refinement using Socratic questioning methodology. This skill should be used when users want to explore an idea, find gaps in concepts, enhance proposals, or structure thoughts before implementation planning. Triggers on "brainstorm", "explore this idea", "find holes in", "help me think through", "what am I missing", or when presenting rough concepts that need refinement. Output integrates with create-plan skill.
Orchestrates comprehensive codebase research by decomposing user queries into parallel sub-agent tasks and synthesizing findings. This skill should be used when users ask questions about how code works, where functionality exists, how components interact, or need comprehensive documentation of existing implementations. It focuses exclusively on documenting and explaining the codebase as it exists today.
Create detailed implementation plans through interactive research and iteration. This skill should be used when creating new implementation plans, designing feature specifications, planning technical work, or when the user asks to plan an implementation. Triggers on requests like "create a plan", "plan the implementation", "design how to implement", or when given a feature/task that needs structured planning before implementation.
Orchestrate the execution of complete implementation plans, delegating each phase to implement-phase skill. This skill manages the full plan lifecycle including phase sequencing, user confirmation between phases, and overall progress tracking. Triggers on "implement the plan", "execute the implementation plan", or when given a path to a plan file.
Generate implementation prompts for phase-based project execution using an orchestration pattern. Use when users request prompts for implementing project phases, need orchestration prompts for multi-step implementations, ask for "/prompt", "generate prompt", "create implementation prompt", or want to create structured implementation instructions for subagent delegation. Outputs the prompt to chat and saves to docs/prompts folder.