skills

Capture and organize learnings from coding experiences, debugging sessions, and problem-solving. Use when: the user wants to save a learning, document a discovery, record a pattern, or create a reference for future work. Do NOT use when: creating project documentation (use docs), writing PRDs (use create-prd), or when the user wants to read existing learnings without creating new ones.

Review your own local code changes before pushing or creating a PR. Use when: the user wants to self-review staged or unstaged changes, check code quality before committing, or get feedback on work-in-progress. Covers readability, patterns, error handling, performance, and security. Do NOT use when: reviewing an existing pull request (use pr-review), reviewing code you didn't write, or when changes are already pushed to remote.

Systematically debug issues using a structured REPRO → GATHER → HYPOTHESIZE → TEST → FIX → VERIFY workflow. Use when diagnosing bugs, investigating failures, tracing errors, or troubleshooting unexpected behavior in code. Do NOT use when the issue is already identified and a fix is obvious, for code exploration without a specific problem, or for proactive code review.

Write and maintain project documentation including READMEs, API docs, ADRs, CHANGELOGs, and inline code comments. Use when: the user asks to write documentation, update a README, create an API reference, draft an ADR, add a CHANGELOG entry, or improve inline comments. Do NOT use when: the user wants to format markdown (use markdown-format), review code (use pr-review), or create a PRD (use create-prd).

Research and explore codebases to build context before making changes. Use when starting work on an unfamiliar project, investigating a bug, planning a feature, or when you need to understand how something works.

Solve complex problems by spawning multiple specialized expert agents that analyze from different angles, then synthesize their insights. Use for architecture decisions, code reviews, complex debugging, or when you need comprehensive analysis.

Manage structured communication files (PLAN.md, TODO.md, SPEC.md, etc.) to coordinate work across agents and sessions. Use when starting complex tasks, delegating to subagents, or maintaining project state.

Perform safe refactoring operations while preserving behavior and maintaining code integrity. Use when: renaming identifiers, extracting functions/modules, inlining code, moving files, or restructuring code without changing functionality. Do NOT use when: adding new features, fixing bugs (use standard editing), or making breaking API changes.

Perform standalone security audits covering OWASP Top 10, dependency scanning, secret detection, input validation, and authentication review. Use when: the user asks for a security review, vulnerability assessment, audit, or wants to check for security issues in code or dependencies. Do NOT use when: the user wants a general code review (use pr-review), is asking about deploying to production, or wants penetration testing guidance.

Guide for writing effective tests using best practices: test pyramid, Arrange-Act-Assert pattern, mocking strategies, and coverage guidelines. Use when the user asks to write tests, improve test coverage, refactor tests, or understand testing best practices. Do NOT use when the user wants to run existing tests without modification, or when the focus is on test infrastructure setup (CI/CD, test frameworks installation).

Simulate Big Tech technical interviews for software engineers. Practice Coding (LeetCode-style), System Design, and Behavioral questions with feedback and coaching. Use when you want to practice for Big Tech interviews (Google, Meta, Amazon, Airbnb, etc.) or sharpen your interview skills. Do NOT use when you want live coding execution (this is for practice/feedback only) or when you need real company-specific questions (skill is company-agnostic).

Interview the human-in-the-loop to clarify ambiguous requests before taking action. Use when the user's request is vague, missing key details, or has multiple valid interpretations. Do NOT use when the request is clear and unambiguous, or when the clarification can be resolved by reading code, docs, or a quick web search.

Read a tasks.json file, resolve the dependency graph, generate self-contained prompt files per task, and delegate every task to isolated tmux subagents. This skill NEVER implements code — it is a pure orchestrator. All work is done by pi subagents running in background tmux sessions.

Convert a Product Requirements Document (PRD) into a structured tasks.json file with tasks, dependencies, priorities, and estimated effort. Use when a PRD exists and the user wants to break it down into implementable tasks, or says "turn this into tasks," "create issues from the PRD," or "what are the next steps?" Do NOT use when there is no PRD or when the user wants to skip planning and start coding immediately.

Spawn isolated pi subagents in background tmux sessions to parallelize work, isolate context, or run long-running tasks without blocking the main agent. Use when you need to delegate work to independent pi instances that operate autonomously. Do NOT use for simple one-off commands or when the task can be done synchronously without blocking.

Create a Product Requirements Document (PRD) from recent discussions, conversations, or accumulated context. Use when the user wants to formalize requirements, document what was discussed, or create a spec to guide implementation. Do NOT use for technical implementation specs (use SPEC.md from project-files) or for already-implemented features (use CHANGELOG.md).

A valid test skill for unit testing. Use when: testing the skills CLI. Do NOT use when: running production workloads.

Format and write git commit messages using a structured type-based format (fea, fix, ref, ai, oth). Use when the user asks to commit, stage, create a commit message, or summarize code changes. Do NOT use for merge commits, revert operations, work-in-progress commits, or when user specifies a custom format.

Format and lint Markdown files following standard conventions and best practices. Use when the user asks to format markdown, lint markdown files, fix markdown formatting, or ensure markdown follows style guidelines. Do NOT use when the user wants to convert between formats (Markdown to HTML, etc.) or when processing non-Markdown content.

Review GitHub pull requests for code quality, security, and best practices. Use when the user asks to review a PR, check a pull request, evaluate code changes, or provide feedback on GitHub code. Requires `gh` CLI authenticated with appropriate permissions. Do NOT use when the user wants to create a PR, merge a PR, or perform other PR operations.