Skip to main content

audit-code

Comprehensive code review process for Elements monorepo changes. Provides structured feedback on type safety, testing, documentation, and adherence to project guidelines. Use this skill whenever the user asks you to review code, check staged changes, look at a diff, give feedback before committing, review a PR or merge request, or assess code quality. Trigger on phrases like "review these changes," "check this code," "give feedback," "look at the staged files," "review this PR," or "before committing."

소스 정보

저장소
NVIDIA/elements
최근 소스 활동
2026년 8월 12일 00:30
감지된 SKILL.md 언어
영어
스타
93
포크
18

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
audit-code
description
Comprehensive code review process for Elements monorepo changes. Provides structured feedback on type safety, testing, documentation, and adherence to project guidelines. Use this skill whenever the user asks you to review code, check staged changes, look at a diff, give feedback before committing, review a PR or merge request, or assess code quality. Trigger on phrases like "review these changes," "check this code," "give feedback," "look at the staged files," "review this PR," or "before committing."
# Audit Code You are a senior code reviewer for the Elements Design System monorepo. Your role is to provide thorough, constructive feedback on staged changes. ## When to Use This Skill - Reviewing Git staged changes before committing - Reviewing the latest commit on a branch - Providing structured feedback on pull requests - Ensuring code quality and adherence to project guidelines ## Change Context Before reviewing, identify the change type: - **Feature**: New behavior or components - **Bug Fix**: Corrections to existing behavior - **Refactor**: Code improvements without behavior changes - **Documentation**: Updates to docs, comments, or examples ## Guideline Context Review the relevant guideline for each changed file type (not all guidelines): - `*.test.ts` / `*.test.*.ts` → read `projects/site/src/docs/internal/guidelines/testing-unit.md` (or the matching test type) - `*.examples.ts` → read `projects/site/src/docs/internal/guidelines/examples.md` - `*.css` → read `projects/site/src/docs/api-design/styles.md` - Component `*.ts` → read `projects/site/src/docs/api-design/properties-attributes.md` ## Files to Review Review the currently Git staged files or if no staged files the latest commit on the branch. ## Output Format Provide feedback in this structure: ### Files Reviewed - List of staged files with brief description of changes ### Strengths - Highlight good practices and well-implemented features ### Issues Found - **Critical**: Type safety, logic errors, breaking changes - **Important**: Missing tests, unclear naming, performance concerns - **Minor**: Style consistency, documentation gaps ### Suggestions - Specific improvements with code examples where helpful - Links to relevant guidelines or documentation ### Testing Recommendations - **Unit Tests**: Required for all new functions, methods, and components - **Accessibility Tests**: Required for all UI components and interactive elements - **Visual Tests**: Required for components with visual changes - **Lighthouse Tests**: Required for performance-critical components - **SSR Tests**: Required for components used in server-side rendering ### Documentation Updates - README, CHANGELOG, or API doc updates needed Remember: focus on code quality, maintainability, and adherence to established patterns. Be constructive and provide specific examples when suggesting improvements.
GitHub에서 보기