sst

Use this agent when a meaningful chunk of code has been written or modified and needs review for quality, conventions, and correctness — especially after completing a feature, fixing a bug, or finishing a logical implementation step. Examples: <example> Context: The user has just implemented a new API endpoint and wants it reviewed before opening a PR. user: "I've finished the new search endpoint. Can you review it?" assistant: "I'll use the code-reviewer agent to review the implementation." <commentary> A completed feature implementation is the ideal trigger — the agent reviews conventions, cross-module impact, test coverage, and performance patterns. </commentary> </example> <example> Context: The user has refactored a service layer and wants a second opinion. user: "I've refactored the import service. Take a look and tell me if I missed anything." assistant: "Let me have the code-reviewer agent examine the refactor." <commentary> Refactors need careful review for behavioral changes and missing test coverage — this agent is well-suited for it. </commentary> </example> <example> Context: The user has just completed a step from a larger plan. user: "Step 2 from our plan is done — the data pipeline processors are implemented." assistant: "Great. I'll use the code-reviewer agent to review this step against the plan." <commentary> Completing a numbered step from a plan is a natural code review trigger point. </commentary> </example>

Use this agent when code changes need a security review — before opening a PR on security-sensitive changes, after implementing authentication or authorization features, when adding external API integrations, or when handling user input, file uploads, or sensitive data. Examples: <example> Context: The user has implemented a new authentication flow and wants it reviewed for security issues. user: "I've added the new OAuth callback handler. Can you security review it?" assistant: "I'll use the security-reviewer agent to review the authentication implementation." <commentary> Authentication flows are high-risk and should always get a security review before merging. </commentary> </example> <example> Context: The user is about to open a PR that touches file upload handling. user: "The file upload endpoint is done. Review it before I push." assistant: "Let me have the security-reviewer agent look at the file handling code." <commentary> File upload endpoints are a common vector for path traversal, unrestricted file types, and storage misconfigurations. </commentary> </example> <example> Context: The user has added an integration with an external API that accepts user-provided URLs. user: "I've finished the webhook integration. Does it look safe?" assistant: "I'll use the security-reviewer agent to check for SSRF and related issues." <commentary> External integrations that accept user-controlled input are SSRF candidates and need security review. </commentary> </example>

Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?"

Produce a comprehensive markdown document explaining all changes in a pull request, branch, or commit range — covering the architecture involved, what each change does and why, and how the pieces fit together. Use this skill whenever the user asks to "explain this PR", "walk me through these changes", "document what we did in this branch", "create a PR explainer", "turn this branch into documentation", or any request to understand or document a set of changes as a cohesive narrative. Also use it proactively when a branch is ready for review and a written walkthrough would help reviewers understand the intent behind the changes.

This skill should be used when the user asks to "generate tests", "write tests for", "add test coverage", "create unit tests", "write a test file", or "add tests to". Generates tests that match the project's established conventions by discovering patterns from existing tests before writing anything new.

This skill should be used when the user asks to "run pre-PR checks", "check before pushing", "run quality checks", "verify the branch is ready", "run lint and tests", or "make sure CI will pass". Runs the project's quality gates locally to catch failures before they hit the pipeline.

This skill should be used when the user mentions "dependabot", "dependency updates", "review dependency PRs", "check dependabot PRs", or asks about open PRs from Dependabot. Reviews open Dependabot pull requests for compatibility, urgency, breaking changes, and CI/CD status, producing a structured recommendation report. Default reviews all open Dependabot PRs; accepts specific PR numbers as arguments.