Revisió de codi
Revisió i anàlisi automatitzades del codi
review
Yeachan-Heo
Alias for /plan --review
oneshot
Melvynx
Ultra-fast feature implementation using Explore → Code → Test workflow. Use when implementing focused features, single tasks, or when speed over completeness is priority.
lifecycle
posit-dev
Guidance for managing R package lifecycle according to tidyverse principles using the lifecycle package. Use when: (1) Setting up lifecycle infrastructure in a package, (2) Deprecating functions or arguments, (3) Renaming functions or arguments, (4) Superseding functions, (5) Marking functions as experimental, (6) Understanding lifecycle stages (stable, experimental, deprecated, superseded), or (7) Writing deprecation helpers for complex scenarios.
skills
marioluciofjr
Repositório com minhas skills para Claude, Antigravity, Agno, ADK e demais sistemas agênticos
code-review
coderabbitai
"AI-powered code review using CodeRabbit. Default code-review skill. Trigger for any explicit review request AND autonomously when the agent thinks a review is needed (code/PR/quality/security)."
code-review
Yeachan-Heo
Run a comprehensive code review
project-session-manager
Yeachan-Heo
Manage isolated dev environments with git worktrees and tmux sessions
ultraqa
Yeachan-Heo
QA cycling workflow - test, verify, fix, repeat until goal met
ralplan
Yeachan-Heo
Alias for /plan --consensus
research
Yeachan-Heo
Orchestrate parallel scientist agents for comprehensive research with AUTO mode
help
Yeachan-Heo
Guide on using oh-my-codex plugin
static-analysis
gmh5225
Expertise in LLVM-based static analysis including dataflow analysis, pointer analysis, taint tracking, and program verification. Use this skill when implementing security scanners, bug finders, code quality tools, or performing program analysis research.
release-branch
mono
Create a release branch for SkiaSharp. Use when user says "release X", "start release X", "create release branch for X", "I want to release", or "release now". This is the FIRST step of releasing - creates branch and pushes to trigger CI. Can auto-detect next preview version from main branch.
review-docs
JamieMason
Review and improve Syncpack documentation for clarity, completeness, and consistency. Use when enhancing docs or validating before publication.
gh-pr-review
samzong
Review a GitHub Pull Request as a responsible project owner using the gh CLI. Use when the user provides a PR URL (e.g. https://github.com/ORG/REPO/pull/N) or a PR number for the current git repo (prefer upstream, else origin) and wants an owner-grade review document review-N.md written in Chinese with copy-pastable GitHub comments in English. Scope the review to lines changed by the PR (do not nitpick unrelated pre-existing code), but apply best practices and flag any clear bugs, security issues, or CI failures caused by the change.
clean-code-reviewer
hylarucoder
Produces a severity-rated (高/中/低) Clean Code findings report across 7 dimensions (naming, function size/SRP, duplication/DRY, over-engineering/YAGNI, magic numbers, structural clarity, project conventions), each with a location and a behavior-preserving refactor suggestion — never changing functionality. Use whenever the user asks for a code review, quality check, refactor advice, or code-smell / Clean Code analysis, OR points at a file/function/diff and asks if it is well-written, too long, too repetitive, over-engineered, or poorly named — even casually, and even if they never say "review" ("I just wrote this, look it over", "does this look good before I commit"). Trigger on 代码体检, 代码质量, 重构检查, 代码审查, 这段代码写得怎么样, 帮我看看代码有没有问题, 有没有坏味道, 这函数是不是太长了, 命名规范吗, 魔法数字, 重复代码, 过度设计, and English like "is this code clean", "any code smells", "check this file".
hai-architecture
hylarucoder
Produce an evidence-grounded architecture review or design-decision critique — an architecture map, the painful complexity center, 3-6 chosen review lenses, ranked findings with file:line evidence, why-not alternatives, and a red/blue adversarial check — grounded in John Ousterhout's "A Philosophy of Software Design" (APoSD). Trigger whenever the user asks about architecture or system-design quality: module/package boundaries, abstraction depth, deep vs shallow modules, information hiding, dependency direction, change amplification / blast radius, ownership, error boundaries, or whether to split / merge / combine modules — including 架构审查, 架构 review, 模块边界, 依赖方向, 抽象太浅, 复杂度太高, 这个设计合不合理, or an APoSD / Ousterhout / "philosophy of software design" review. Be pushy: trigger even when they only say "is this structure ok", "these modules feel tangled", "should I split this", "review my system design", or "why does touching X force edits everywhere", not just when they say "architecture review". For naming use hai-naming; for whole-repo refactor hunting use improve-codebase-architecture; for a single React component use component-diagnosis.
localseodata-tool
garrettjsmith
When the user wants to pull local SEO data — SERP results, local pack rankings, business profile data, reviews, citations, audits, geogrid scans, keyword research, AI visibility, competitor analysis, or any local search intelligence. This is the DEFAULT data tool for LocalSEOSkills. Trigger on any data request before considering other tools. Also trigger on "LocalSEOData," "LSD," "run an audit," "check my rankings," "pull reviews," "citation check," "keyword opportunities," "AI visibility," or "geogrid scan."
geogrid-analysis
garrettjsmith
When the user wants to analyze local ranking data using geogrid scans, interpret map pack rankings across a geographic area, or understand ARP/ATRP/SoLV metrics. Also use when the user mentions "geogrid," "rank grid," "local rank tracking," "Local Falcon," "grid scan," "map pack rankings," "ranking heatmap," or "where am I ranking." For broader local audit, see local-seo-audit. For competitor analysis, see local-competitor-analysis.
roundtable
tt-a1i
Convene a roundtable of sub-agents that debate a decision or proposal from opposing perspectives — parallel independent statements, anonymous cross-review, then a chaired verdict reporting consensus and dissent.
spec-executor
tt-a1i
Execute the latest approved SPEC READY from an inherited or forked conversation, keeping implementation work out of the planning thread. Use after to-spec when the final spec fits one implementation session and the new thread should implement, test, review, and return a structured receipt without rewriting a to-goal handoff. Do not use for unresolved specs, multi-session builds, parallel handoffs, or context that needs compression; use to-tickets or to-goal for those.
ralph-lisa-loop
basecamp
Automated plan-implement loop with expert review. Claude implements, Codex reviews, the human steers. A single rope-length knob (0-5) controls interruption frequency. Closure requires zero open findings and zero unresolved disputes at any rope level. Use for any planning, development, or implementation task that benefits from structured review. The default workflow for building anything non-trivial.
client-deliverables
garrettjsmith
When the user needs to create a client-facing document such as an SEO audit, proposal, scope of work, competitive analysis report, onboarding document, or market intelligence report. Also use when the user mentions "audit report," "proposal," "scope of work," "SOW," "pitch deck," "client presentation," "pricing document," "onboarding checklist," "competitive report," "market analysis," or "deliverable." For ongoing performance reports, see local-reporting. For the research behind audits, see local-seo-audit.
gbp-optimization
garrettjsmith
When the user wants to set up, optimize, or manage a Google Business Profile, or improve visibility in Google's local map pack. Also use when the user mentions "GBP," "Google Business Profile," "Google My Business," "GMB," "business listing," "Google Maps listing," "optimize my profile," "map pack," "local pack," "3-pack," "Google Maps ranking," or "why am I not in the map pack." For review strategy, see review-management. For GBP posts, see gbp-posts. For suspension issues, see gbp-suspension-recovery.