Review pull requests in the SAP Testing Automation Framework. Use when reviewing a diff, a pull request, or staged changes touching platform code, Ansible roles and playbooks, custom modules, or the shell CLI. Reviews for correctness, reliability, security, Azure/SAP domain rules, performance, test coverage, and maintainability — in that priority order. Finds defects that let a validation report success without validating, accept a field and then discard it before it acts, break an object's stated contract, or leave one half of the SUSE/RHEL or HANA topology matrix unhandled.
Review diffs, commit ranges, fixup chains, or PRs across languages and report findings ordered by severity. Enforces primitive-obsession and smart-constructor blockers, property-test and boundary-test requirements, complexity thresholds and per-language rules (Rust, TypeScript, Lean, SQL, bash, Ruby, Markdown, regex). Delegates commit-history structure and repair to git-review. Also the home for changing review rules or codifying review feedback.
Use this skill when reviewing a PR diff, commit range, file change, or code snippet before merge. Reviews security vulnerabilities, code quality, style compliance, architectural integrity, test coverage, and performance; works with GitHub/GitLab diffs or raw code and produces a systematic, severity-labeled review.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\".
Review GitCode pull requests with a self-contained multi-agent prompt pipeline, validate JSON review findings, post or delete GitCode inline comments, and create/update GitCode PR metadata with this skill's scripts.
Code review changed, staged, last-commit, and merge or PR work against requirements and the repository style guide. Use when reviewing current work, staged changes, the last commit, a branch, a merge, or a pull request. For a whole-codebase style audit use ng-review-style-guide instead.
Exhaustively review every line in a diff from a fixed point along two independent axes—repository standards and the originating spec—with evidenced findings, explicit coverage, and bounded fix verification.
Review changed code (session, current branch, or colleague's branch) for principle violations, reinvented wheels, and dead code. Trigger after coding, before merge, or for PR review.
Use when creating or submitting a pull request, reviewing a diff or PR from another developer, addressing PR feedback, or running a post-implementation review cycle on local changes. Uses standard git and GitHub CLI (`gh`) commands and classifies findings by severity (CRITICAL/IMPORTANT/SUGGESTION).
Use when the user EXPLICITLY asks for a lightweight pass, or for feedback/audit modes. Triggers: 'quick review', 'light review', 'look over this', '--quick', 'check my work', 'self-review before PR', 'review my code', 'audit this code', 'PR comments to address', 'reviewer said', 'address feedback', 'review PR #X comments'. NOT for: unspecified-scope branch review such as 'review this branch' or 'code review' (that DEFAULTS to advanced-code-review), or PR triage and summarization (use distilling-prs). This skill is the explicit opt-in to a lighter pass; if the user did not ask for lightweight by name, do not use it. Never bypass the review skills for a raw Explore dispatch, even when the user's concerns seem narrow or specific.
Perform repository-local code reviews. Use for requested diff or pull-request audits, final focused review after implementation, or changes that affect behavior, APIs, domain boundaries, tests, security, workflows, dependencies, CI, documentation, or agent instructions. Do not use as the primary workflow for repository-wide technical-debt portfolio audits, implementation, active failure debugging, or design-only threat modeling.
Pull request review checklist for finfocus. Lists the invariants a reviewer should check that linters and tests do not catch, such as secret redaction, stdout discipline, cache-key completeness, cost-math conventions, plugin module boundaries, MCP exposure, and test isolation.
코드 변경(작업 트리 diff·브랜치·PR·경로·커밋 범위)을 **읽기 전용**으로 검토해, 실제로 확인한 발견만 보고한다. '리뷰해줘·검토해줘·이 diff 봐줘·PR 봐줘·머지해도 되나·이 수정 괜찮아?·내가 고친 거 다시 봐줘' 류 요청, 그리고 스스로 수정을 마친 뒤 되짚을 때. 버그 진단('이거 왜 안 돼')에도 같은 검사 축을 쓴다. 리뷰는 독립 매니저가 먼저 혼자 읽고, 파일이 많으면 **겹치지 않는 파일 묶음**으로만 나눈다(관점·발견 수로 나누지 않는다). 발견마다 한 동작으로 확인한 뒤에만 보고하고, 고치지 않는다 — 수정은 사용자가 따로 시킬 때 별도 단계다.
Systematic code review patterns covering security, performance, maintainability, correctness, and testing — with severity levels, structured feedback guidance, review process, and anti-patterns to avoid. Use when reviewing PRs, establishing review standards, or improving review quality.
A folder with a SKILL.md file: a name, a description of when to use it, and instructions. Claude loads a skill only when the task matches its description.
How do I use one I find here?
Copy the folder into your project's .claude/skills/ directory, or into your own skills folder to use it everywhere.
What do the warnings mean?
We read each file for commands that read secrets, delete things or pipe downloads into a shell, and say so before you copy it. No warning is not a promise that a file is safe.
Which skills worked for people?
Open a skill to see its discussion. Reports from people and their agents are coming.
Microsoft AzureSkill
