specialone0007

docs-sync-audit

Run a read-only documentation drift audit for a feature, PR, branch, release, API, configuration change, workflow, CLI, package, or repository area. Use when the user asks whether docs are stale, missing, inconsistent with code, or need updates after code changes. Checks README files, setup guides, API docs, env docs, changelogs, examples, comments, generated docs, and user-facing instructions. This is not a general code review; use feature-audit for product bugs and readiness risks.

feature-audit

Read-only, repository-agnostic feature readiness audit for finding bugs, launch blockers, regressions, UI/UX flow errors, accessibility issues, auth/data risks, missing critical tests/docs, and production readiness gaps in a named feature, route, URL, workflow, product surface, or PR, or across the whole repository when no scope is named. Use when the user explicitly asks for a feature/product-surface audit, scan, launch-readiness check, production-readiness review, or bug-risk report. If the primary ask is security, test coverage, docs drift, repo organization, feature ideas, or PR communication, use security-audit, test-gap-audit, docs-sync-audit, repo-health-audit, feature-brainstorm, or pr-branch-summary instead.

feature-brainstorm

Brainstorm evidence-grounded product, UX, workflow, and technical improvement ideas for a clearly named feature, route, workflow, product surface, or PR. Use when the user asks what could be added, improved, simplified, expanded, polished, automated, differentiated, or made more valuable. This is not a bug audit; use feature-audit for defects, regressions, launch blockers, missing tests, or production-readiness risks.

Code & Development Listed

pr-branch-summary

Compare the current git branch against staging, production, or another release/base branch and draft PR communication. Use when the agent is asked to prepare a pull request title/message, PR description, release-target comparison, branch diff summary, team/Slack/Telegram summary, or explanation of what a PR contains based on all changes since staging or production.

repo-health-audit

Read-only repository health and organization audit for finding naming drift, unclear file or folder placement, weak module boundaries, dead code, duplicate code, repeated patterns that should become shared helpers, duplicate concepts, inconsistent conventions, oversized files, circular dependencies, and structural issues that make a codebase harder to navigate or more likely to become spaghetti over time. Use when the user asks to review repo organization, folder structure, naming, architecture hygiene, codebase structure, module layout, dead code, duplicate code, reuse opportunities, or whether a repository is getting messy.

security-audit

Run a read-only, evidence-grounded security audit of a named feature, route, workflow, PR, branch, service, API, or code path, or of the whole repository when no scope is named. Use when the user asks for security risks, AppSec review, auth/authorization review, secrets exposure, injection risks, data leakage, abuse paths, unsafe dependencies, secure-by-default gaps, or security launch readiness. This is not a general bug audit; use feature-audit for broad product readiness and defects.

test-gap-audit

Run a read-only audit for missing, weak, stale, or mis-scoped test coverage. If the user does not name a scope, audit the full repository and identify important code paths, routes, features, services, workflows, and contracts that lack proper tests. If the user names a feature, PR, branch, route, workflow, service, bug fix, API, security-sensitive path, or risky code change, focus only on that specific scope. Use when the user asks what tests are missing, whether coverage is enough, what regression tests to add, or how to prove a change is safe. This is not a general bug audit; use feature-audit for product readiness defects and security-audit for security risks.