skill-issue

Use when asked to rewrite or format text in the user's voice, "make this sound like me", "match my voice", "de-stiffen this", when text "reads too corporate / businessy / stiff", to "strip the em-dashes / agent typography", or to draft a Slack announcement, PR body, or doc in the user's voice. Also /match-voice.

Use when writing or rewriting reader-facing technical text — documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports, API guides, agent/system prompts — or when asked to "de-slop", "make this readable", "simplify this doc", "write for non-native readers", "apply STE", "Simplified Technical English", or "ASD-STE100", or to prepare text for translation. Also use to CHECK such text for clarity violations. Do NOT use for chat replies, PR/review comments, or commit messages (that is terse-output), nor for marketing, brand, or personal-voice writing (that is match-voice) — this skill deletes persuasion by design.

Use when the user asks for a deep review, full review, comprehensive review, production readiness assessment, full audit, multi-domain audit, "security and reliability and code review", or "review everything". Also use when the user explicitly requests performance review alongside the comprehensive request (e.g. "include perf", "review including performance", "deep review with perf"); without that explicit phrasing, performance is excluded. Do NOT use for narrow single-domain reviews (use the matching review-* skill directly).

Review code architecture (SOLID, design patterns, package design, coupling, testability), Go best practices, and protobuf/API design using manual analysis and static analysis tools (gocyclo, staticcheck, buf). Use when the user asks for a code review, architecture review, Go review, protobuf review, SOLID review, or design pattern review.

Use when the user wants to execute an approved implementation plan and says any of "do it" (with a plan in scope), "lets do it" / "let's do it", "confirmed" (as approval to proceed on a plan), "implement the plan", "implement this", "execute the plan", "start implementing", "work through the plan", "implement the next phase", "build it out", "knock out the plan", or "/implement-plan PATH". Also use when a plan file (`./.plans/PLAN.md`, any `./.plans/*.md`, or legacy `./PLAN.md` / `./docs/plans/*.md`) is present and the user signals readiness to begin coding. Do NOT use when the user is still discussing, refining, or asking questions about the plan, nor when no plan exists — short imperatives like "do it" or "confirmed" alone are ambiguous; verify a plan is in scope before activating.

Use when the user asks to review the plan, sanity-check the plan, vet the plan, evaluate the plan, "is this plan ready", feasibility check on a plan, "review-plan PATH", or when another skill (like implement-plan) requests pre-flight plan evaluation before execution. Do NOT use when no plan file is in scope (the user is likely asking for a summary — use Read instead), nor when the user is asking about source code (use review-code), nor when the user wants documentation review (use review-documentation).

Use when adding or evaluating a project dependency in any language, phrases like "should I use X library", "evaluate <package>", "what library for Y", or when reviewing a PR that touches a manifest (go.mod, package.json, requirements.txt, pyproject.toml, Cargo.toml, Gemfile, mix.exs, composer.json). Also use when comparing alternatives, choosing between major versions of the same package, or when review-security / review-code encounters a new dep in scope. Produces a GO/CAUTION/NO-GO verdict with the canonical package coordinate to use. Language-specific quirks (Go's semantic import versioning /v2 paths, npm scoping, etc.) live in references/.

Perform a security review using STRIDE threat modeling, OWASP Top 10 analysis, and automated scanning (gosec, govulncheck). Use when the user asks for a security review, threat model, OWASP analysis, or security audit.

Use when the user wants to prepare for a manual PR code review and asks for help targeting it — a terse PR summary, ranked files to read first, and paste-ready inline comment drafts with GitHub deep-links. Triggers: "active review this PR", "walk me through this PR", "help me review this", "give me inline comments to add manually", "give me files and lines with terse comments", "summary with files and lines", "/active-review [PR|branch]". Do NOT use to post comments (use `code-review --comment` or `review` for that), to run the actual analysis (this skill consumes `/review-all` output), or to review plans / documentation (use `review-plan` / `review-documentation`).

Use when preparing a performance self-reflection, midyear or annual review, promotion packet, or brag document; when asked to collect, mine, gather, or summarize your accomplishments, contributions, or impact over a period; or when assembling cited evidence of work done across GitHub, Jira, Notion, Slack, and local agent histories over the last N months.

Use at the start of a workday or when the user says "start my day", "good morning", "/start-day", "morning", "what should I work on today", or wants a catch-up on what happened while they were away. Use when the user wants a short ranked list of what to tackle today.

End-to-end shipping workflow. Formats, lints, tests, creates a changelog entry, commits with conventional commits, pushes, updates PR description, and suggests reviewers. Use when the user says "ship it", "commit and push", "fmt lint test commit push", or similar shipping commands.

Review database usage for migration safety, query performance, connection/transaction management, and schema design. Covers PostgreSQL and MySQL. Runs squawk for PostgreSQL migration linting if available. Use when the user asks for a database review, SQL review, migration review, or schema review.

Review documentation quality and sync with implementation across Go doc comments, proto comments, OpenAPI specs, markdown files, and example tests. Use when the user asks for a documentation review, doc audit, or wants to check that docs are in sync with code.

Use when the user explicitly asks for a performance review, benchmark review, profiling review, perf audit, pprof analysis, allocation review, latency regression check, hot-path review, throughput review, "is this fast enough", or "review perf". This skill is opt-in only — never run automatically as part of review-all unless the user explicitly requests it.

Perform a reliability review covering graceful shutdown, gRPC production patterns, stability patterns (timeouts, circuit breakers, bulkheads), and stability anti-patterns. Use when the user asks for a reliability review, production readiness assessment, stability analysis, or graceful shutdown audit.

Use when exploring a new codebase's architecture, auditing codebase consistency, generating a patterns document, or preparing input for conformance checking during code review.

Use when the user asks for an API compatibility review, breaking change review, proto breaking change review, buf breaking review, OpenAPI compatibility check, gRPC backwards compatibility audit, "are these API changes breaking", "did we break the wire", contract evolution review, or backwards-compatibility audit on an API surface.

Use when the user asks for a CI review, CI/CD review, GitHub Actions review, workflow review, pipeline review, build pipeline audit, "review the workflows", "review the actions", action pinning audit, workflow permissions audit, or supply-chain review of CI configuration.

Use when the user asks for a coverage review, test coverage analysis, coverage gap analysis, uncovered code review, or wants to know what new/changed Go code is missing tests. Runs `go test -coverprofile` against the resolved scope and reports uncovered functions in changed Go files, grouped by package, with severity grading. Go projects only.

Use when the user asks for an infrastructure review, IaC review, Terraform review, Kubernetes manifest review, Dockerfile review, Helm chart review, container review, gateway review (Envoy / Ingress / Gateway API), service mesh review (Linkerd / Istio), east-west traffic review, north-south traffic review, mesh authorization review, or "review the infra / IaC / manifests / Dockerfile / helm chart / gateway / mesh config".

Use when the user asks for an observability review, telemetry review, logging review, metrics review, tracing review, OpenTelemetry review, OTel review, Prometheus review, "are we observable", logging audit, structured logging audit, trace coverage check, span coverage check, metrics cardinality review, or production observability assessment.

Use when the user asks who knows specific code, who should review a PR or files, what the lottery factor is, whether knowledge is concentrated or spread, who to talk to about a code area, or when suggesting reviewers beyond GitHub's built-in suggestions.

Use when hunting a regression, phrases like "bisect", "find the commit that broke X", "this used to work", "regression in test Y", "when did <symptom> start". Also use when escalated from ci-debug-loop because log analysis can't pinpoint the offending change, or when a previously-passing test/build/behavior is now failing and the cause isn't obvious from the recent diff. Drives `git bisect run` against a user-provided reproducer command, isolates the offending commit, and reports it with diff and metadata. Does not auto-fix.

Watch a GitHub Actions CI run, diagnose failures from logs, apply fixes, re-push, and repeat until green or escalate. Use when CI is failing and the user wants to debug and fix it iteratively, or says "fix CI", "debug the build", or similar.

Run format, lint, build, and test verification before claiming work is complete. Detects the project toolchain (Taskfile, Makefile, or raw Go) and runs the appropriate commands. Use before committing, pushing, creating PRs, claiming a fix works, or any completion assertion.

Use when the user wants interactive active-recall study on a document or topic. Triggers: "study this with me", "help me understand", "digest this", "let's study this", "walk me through", "explain and test me", "active reading", "active-read this", "/active-read". Do NOT use for passive reading (`Read`), code review (review-code), or plan review (review-plan).

Use when reviewing past agent sessions, auditing memory health, identifying repeated corrections or friction, cleaning up stale memories, proposing new skills and rules from usage patterns, or identifying mechanical improvements (testing, linting, static analysis, tooling) that could improve outcomes.

Resolve merge conflicts on a pull request by rebasing onto the base branch. Use when a PR is not mergeable, has merge conflicts, or the user asks to fix conflicts on a PR.

Use when creating a new GitHub pull request, opening a PR for the current branch, or when another skill (like ship-it) needs a PR created for a branch that does not have one yet.

Use when creating, writing, or updating a Claude Code rule file (.claude/rules/*.md or ~/.claude/rules/*.md), or when asking about rule format, path scoping, or rule best practices.

Use when starting a session on a non-main branch, switching branches (git checkout, git switch), or when a hook prompts for session context update. Also invocable manually via /set-session-context.

Create or update a Notion decision document with a structured options/pros/cons/recommendation template. Use when the user asks to create a decision doc, design doc, evaluation doc, or comparison in Notion.

Create Jira issues (stories, epics, initiatives) with custom field introspection to fill org-specific fields correctly. Use when the user asks to create a Jira ticket, story, epic, initiative, or task.

Use when creating, writing, or authoring a new Cursor agent skill, or when asking about skill structure, SKILL.md format, or skill best practices.

Push local commits to the remote, ensure a draft PR exists, and monitor the GitHub Actions run until completion. Use when the user says "push and watch", "push it", or asks to push and monitor CI.

Rebase a chain of dependent pull requests sequentially, fixing conflicts along the way. Use when the user asks to rebase a PR chain, fix conflicts on multiple chained PRs, or mentions sequential/stacked PRs that need updating.