Code Review Skills

| Identify trivial, low-risk pull requests in the `ready for maintainer review` queue of <upstream> that pass every quality gate and touch only supplementary areas (docs, changelog, translations, tests) — the "express lane" a maintainer can review and merge in seconds. Surfaces and ranks candidates with per-PR diff summaries, an all-gates-green attestation, and the exact merge command. On the maintainer's explicit per-PR confirmation it can submit an APPROVE review (the maintainer's own review of the trivial diff — useful when the PR has no approvals yet and branch protection needs one), exactly as pr-management-code-review does. It never merges itself — automated merge is the framework's deliberately-deferred Agentic Autonomous mode; the maintainer runs the printed merge command in their own session.

| Walk a maintainer through deep, sequential code review of open pull requests on the configured `<upstream>` repo. Defaults to the **"my reviews"** queue (the union of five maintainer signals — see the Inputs table); selectors can narrow to a single PR, an area label, or a collaborator subset. Drafts an `approve` / `request-changes` / `comment` review per PR and posts on the maintainer's confirmation.

| Sweep open pull requests on the configured `<upstream>` repo, classify each one against the project's quality criteria, propose a disposition, and — on the maintainer's confirmation — carry out the action via `gh`. Disposition / workflow-approve / ping-stale-reviewer / request author confirmation of readiness / mark `ready for maintainer review` / promote bot-authored draft. Does **not** perform code review — that lives in `pr-management-code-review`.

| Sweep open pull requests on the configured `<upstream>` repo for inactivity past a configurable threshold and propose either a conversion to draft (when the PR is open but has gone quiet) or a closure (when the PR has been abandoned long enough to presume the author has moved on). Waits for maintainer confirmation before converting or closing anything.

| Run a newcomer-focused pre-flight checklist on a local branch before opening a pull request. Checks CONTRIBUTING conventions, SPDX headers on new files, commit-message convention — then returns a structured checklist report. Read-only; no state changes, no PR, no external writes.

| Draft the diff that adds the Release Manager's public key to the project's KEYS file (`<keys-file-url>`), emit a paste-ready `svn` (or backend-equivalent) command sequence, remind the RM to upload to the configured keyserver, and validate the key meets the ASF strength floor. Never commits, never holds or reads the private key. Runs during release preparation, before RC signing begins.

| Surface drift between the user's installed secure agent setup and the framework's latest (framework checkout, pinned tools, user-scope script copies, denial commands, comdev MCP checkouts). Read-only — surfaces candidates and diffs, never auto-applies. The user decides what to update.

| Compare two near-duplicate skills — typically an ASF variant and a non-ASF or multi-project variant — and classify every difference as ALLOWED, DRIFT, or SAFETY-BASELINE. Produces a structured diff and convergence is a separate confirmed authoring step. A safety-baseline divergence is always a must-fix, never silently merged into allowed-divergence noise.

当用户需要对前端代码进行全面审查时使用此技能，包括 React、Vue、Angular 或原生 JavaScript/TypeScript 项目。适用于代码审查、Pull Request 评审、性能审计、安全检查等场景。

> Generate an /insights-style HTML report across MANY of your agent coding sessions your friction points, and concrete fixes to become more effective — precise goal-setting, not trusting output blindly, scoping, context hygiene, right-sizing models. Reads local session history and writes one self-contained report.html. Use when the user asks to "разбери мои сессии", "оцени как я работаю с агентом", "мой insights", "session insights report", "review how I work", "на что обратить внимание", or runs "/mentor", "/mentor claude", "/mentor codex", "/mentor both". Do NOT use for reviewing the CODE produced (that's code-review) or building the agent.

> Forces the laziest solution that actually works, simplest, shortest, most task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", and whenever they complain about over-engineering, bloat, boilerplate, or unnecessary dependencies.

Reviews Java 25 and Spring Boot 4 codebases, pull requests, files, and modules for migration risks, architecture boundary violations, JSpecify null-safety issues, security flaws, performance regressions, and Spring Data pitfalls. Use when the task is a concrete Java or Spring code review with code context. Do not use for Kotlin-only code, non-Spring frameworks, or generic review advice without files or diffs.

Handles PR review comments and feedback resolution. Use when user wants to resolve PR comments, handle review feedback, fix review comments, address PR review, check review status, respond to reviewer, verify PR readiness, review PR comments, analyze review feedback, evaluate PR comments, assess review suggestions, or triage PR comments. Fetches comments via GitHub CLI, classifies by severity, applies fixes with user confirmation, commits with proper format, replies to threads.

Creates GitHub Pull Requests with automated validation and task tracking. Use when user wants to create PR, open pull request, submit for review, or check if ready for PR. Analyzes commits, validates task completion, generates Conventional Commits title and description, suggests labels. NOTE - for merging existing PRs, use github-pr-merge instead.

Merges GitHub Pull Requests after validating pre-merge checklist. Use when user wants to merge PR, close PR, finalize PR, complete merge, approve and merge, or execute merge. Runs pre-merge validation (tests, lint, CI, comments), confirms with user, merges with proper format, handles post-merge cleanup.

Adversarial spec-compliance PR review — cross-references diffs against approved specs, verifies runtime claims against source, detects competing PRs, audits scope/convention compliance. Use before merging.

Cascade the same edit pattern across N files safely. Use when applying the same refactor to multiple files (e.g. swap import paths across 11 scripts, rename a symbol, migrate a call signature). Detects the common-shape-across-files situation and turns an N-file cascade into a planned audit → apply → verify workflow instead of N sequential manual edits.

Reviews code for bugs, style, and best practices. Use when reviewing PRs or checking code quality.

Crafts and generates professional conventional commit messages following Angular/Conventional Commits format. Use when committing changes, writing git commit messages, or when user mentions commit message.

| Generate intelligence briefings for the planning dashboard. Use this skill whenever a request file appears in `.planning/console/inbox/pending/` whose `type` field starts with `intelligence.` (refresh_briefing, triage_finding, snapshot_diff, investigate_section, dismiss_finding). The skill reads the per-project KB at `.gsd/intelligence/intelligence.db`, synthesizes a briefing with a causal hypothesis + acknowledged uncertainty + confidence label and ranked moves, then writes the result back to the KB. Always trigger this skill for these request types — do not generate briefings manually.

> Use before you shorten, compress, or rewrite the BODY of an existing SKILL.md or agent .md — the moment you are about to cut text to reduce length. First inventory the file's operational anchors (exact code / command / API snippets, fail-closed workflow guards, and rule / threshold statements), preserve every one, then judge the rewrite by expected downstream task cost (exploration, debugging, recovery tokens) rather than by the resulting line count. A shorter skill that strips an anchor makes the agent MORE expensive per task, so length is never the objective and rewrite is not compression. Backed by Preserving Operational Anchors When Compressing Agent Instructions (arxiv 2606.09421v2). Triggers on shortening or refactoring a skill or agent body.

Creates minimal, effective AGENTS.md files using progressive disclosure. Triggers on "create agents.md", "refactor agents.md", "review my agents.md", "claude.md", or questions about agent configuration files. Also triggers proactively when a project is missing AGENTS.md.

Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments

Provides coding assistance with best practices and code review

Discover large source-file refactor candidates and propose cohesion- and risk-driven split plans using available semantic tooling.

Refactor naming and repository structure exhaustively while preserving behavior and external contracts.

> Check whether the claims in public-facing documentation (README, release notes, install/usage docs) are supported by the evidence the user provides — files, manifests, logs, and command outputs supplied in the conversation. Produces per-claim findings with a confidence label (verified / unsupported / stale-suspected / needs-human) and an explicit "input scope reviewed" statement. Advisory only. Use when the user asks to fact-check docs, verify a README against a repo, audit release notes, or find stale or overstated documentation claims. Do NOT use for standalone code review or bug hunting, security audits, fix/patch generation, or pure command-execution tasks. When such requests are mixed with an eligible claim-check, still use this skill for the claim-check portion and decline only the out-of-scope part — by contract it does not execute commands or edit files.

Craft CMS 5 PHP coding standards and conventions. ALWAYS load when writing, editing, reviewing, or discussing any PHP in a Craft plugin or module — even small edits. Also when running ECS, PHPStan, or scaffolding with ddev craft make. Covers: PHPDoc blocks (@author, @since, @throws chains), section headers (=========), class organization, naming conventions (services, queue jobs, records, events, enums), defineRules() and validation, beforePrepare() and addSelect(), MemoizableArray, DateTimeHelper vs Carbon, strict_types/declare(strict_types=1), short nullable notation (?string), typed properties, void returns, control flow (early returns, match over switch), CP Twig template conventions, form macros, translations (Craft::t), ECS/PHPStan config, scaffolding commands, and the verification checklist. Triggers on: writing service classes, models, controllers, elements, element queries, records, queue jobs, migrations, or any PHP class in a Craft context; PHP code review, refactoring, or style questions; requireAdmin vs requirePermission, manage-settings, settings permission, kebab-case permission handles never camelCase, allowAdminChanges, read-only settings, getCpNavItem dead nav item, permission handle constant on owning controller, no-em-dash user-facing copy. NOT for front-end Twig (craft-twig-guidelines), template architecture (craft-site), or CP JavaScript/Garnish (craft-garnish). If you are touching PHP in a Craft context, you need this skill.

Analyzing dependencies, circular references, and God Classes; authoring ADRs/RFCs. Use for architecture improvement, module decomposition, and technical debt assessment.

Auditing and optimizing AI CLI configuration. Audits Codex CLI (~/.codex/), Antigravity CLI (~/.gemini/ — `agy`), and Claude Code (~/.claude/) configs (config.toml/settings.json/CLAUDE.md/hooks/MCP) and proposes Before/After diff improvements. Never edits configs directly. Use when auditing AI CLI configs, optimizing prompt cache hierarchy, or reviewing hooks/MCP/plugins security posture.

Reviewing code via multi-engine orchestration. Orchestrates parallel review via subagents with grounding verification, shipping only findings worth fixing. Reviews on three axes — secure, correct, and lean. Default Claude + Codex (dual-engine); agy optional third axis. Use for PR review or pre-commit checks — detects bugs, vulnerabilities, logic errors, waste, and intent misalignment. Offers an interactive pair-review mode (fix-as-you-go). Complements Zen refactoring.

Analyzing pre-change impact by evaluating risk across vertical (dependency chains, affected files) and horizontal (pattern consistency, naming) dimensions. Does not write code. Use when estimating blast radius before a refactor, audit, or migration — or when a PR's risk surface is unclear.

Converting repository changes into detailed learning documents. Use when turning diffs into teaching materials, recording design decisions, or creating onboarding materials for new members.

Refactoring code via variable name improvement, function extraction, magic number constants, dead code removal, and code review. Does not change behavior. Don't use for bug/security (Judge), new tests (Radar), architecture (Atlas), or feature implementation (Builder).

Structured code review focusing on correctness, security, and maintainability. Correctness before style. Every reviewer comment must be actionable.

Trunk-based development with atomic commits, clean history, and meaningful commit messages. Every commit should be deployable.

Safe, behavior-preserving code transformation backed by tests. Refactor with evidence, not instinct.

Red-green-refactor cycle with meaningful coverage. Tests are written before implementation. Coverage is a side effect of good tests, not the goal.

Enforces minimal code modifications — touch only what you must. Prevents drive-by refactoring, comment deletions, and style changes unrelated to the task.

Self-evolution workflow for the agent. Before substantive work, recall past outcomes from evolution memory; while editing, detect improvement signals; at task end, record the outcome; when reusable, distill or search the EvoMap network for proven genes/capsules. Use when the user starts non-trivial work (a feature, a fix, a refactor) or asks the agent to "evolve", "learn from this", or "remember how this went".

Implement one phase of a plan stored as GitHub issues in the repository of the current working directory. Given the URL of a phase (child) issue it implements that phase; given the parent plan issue it finds and implements the current phase. Only implements a single phase per invocation, then stops for user review. It opens a pull request that references the phase issue so merging it closes the issue automatically. Never merges the pull request.

> System Architect, Software Architect, Data Architect, and an Adversarial Architect that red-teams failure paths, LLM adversarial output scenarios, silent corruption risks, and invariant bypasses. Each subagent independently analyzes the codebase from their domain perspective, then their findings are consolidated into a living `architecture.md` file with a tracked to-do list and change log. Use this skill whenever the user asks to review, analyze, audit, or improve the architecture — or when they ask questions like "what should we change structurally?", "how is the system organized?", "what are our architecture problems?", "can you do an architecture review?", or "let's redesign X". Also trigger when the user mentions technical debt, structural improvements, security concerns, failure modes, vulnerabilities, or wants a second opinion on design decisions, even if they don't use the word "architecture".

Biome - Fast all-in-one toolchain for web projects (linter + formatter in Rust, 100x faster than ESLint)

Python code-quality anti-patterns and review checks: exception-hierarchy correctness, singleton identity comparison, narrow exception handling, wildcard-import avoidance, magic-number naming, and dead-local removal. Use when reviewing or self-reviewing Python code for correctness and readability defects that linters and reviewers should catch.

PR quality checklist for ensuring comprehensive, well-documented pull requests. Use before submitting PRs to improve review efficiency and code quality.