Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

$pwd:

code-review

Name: Code Review
Author: NVIDIA

// 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 evaluate code quality. Trigger on phrases like "review my changes," "check my code," "give me feedback," "look at my staged files," "review this PR," or "before I commit."

Ejecutar en Manus

$ git log --oneline --stat

stars:8

forks:1

updated:8 de mayo de 2026, 20:48

SKILL.md

readonly

name

code-review

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 evaluate code quality. Trigger on phrases like "review my changes," "check my code," "give me feedback," "look at my staged files," "review this PR," or "before I commit."

Code Review

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 functionality 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 the files being changed (not all guidelines). Match by file type:

*.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.

related-skills.json

mismo repositorio

accessibility.md

from "NVIDIA/elements"

Unified accessibility auditing workflow across static analysis, runtime testing, ARIA patterns, keyboard navigation, and color contrast. Use this skill whenever the user mentions accessibility, a11y, WCAG, ARIA roles, axe tests, screen readers, focus management, keyboard navigation, color contrast, or wants to audit, verify, or fix accessibility on any component. Also use when writing or debugging .test.axe.ts files, checking tabindex management, or reviewing focus trapping behavior.

2026-05-088

api-design.md

from "NVIDIA/elements"

Component API design patterns following Elements conventions for properties, attributes, CSS custom properties, slots, and events. Use this skill whenever the user is designing or deciding on a component API, choosing between properties vs attributes vs slots, naming CSS custom properties, designing events, avoiding impossible states, deciding whether to reflect to an attribute, using CSS Parts, implementing the DataElement interface, or applying the internal-host pattern. Also trigger when the user asks about shorthand vs granular CSS properties or event naming conventions.

2026-05-088

build-system.md

from "NVIDIA/elements"

Wireit orchestration, build optimization, caching strategies, and build troubleshooting for the Elements monorepo. Use this skill whenever the user asks about Wireit configuration, build tasks, build dependencies, cache invalidation, build performance, adding new build tasks to package.json, cross-package dependency patterns, sideEffects declarations, CI pipeline configuration, or diagnosing slow or failing builds. Also trigger when the user mentions wireit, vite build issues, pnpm run ci, or build output problems.

2026-05-088

component-creation.md

from "NVIDIA/elements"

Guide for creating new Elements components with all required files, base classes, metadata patterns, and test boilerplate. Use this skill whenever the user wants to create, scaffold, or set up a new component from scratch, needs to understand the required 10-file structure, asks about base classes (LitElement vs BaseButton), define.ts vs index.ts patterns, static metadata, component registration, or sub-component parent relationships. Also trigger when the user mentions creating test boilerplate for all 5 test types.

2026-05-088

documentation.md

from "NVIDIA/elements"

Guidelines for writing documentation files including 11ty templates, Eleventy shortcodes, JSDoc annotations, and markdown content. Use this skill whenever the user works with documentation markdown files, Vale prose linting errors, Eleventy shortcodes (dodont, example), frontmatter, JSDoc annotations that must pass Vale, or the documentation site. Also trigger when the user mentions Vale errors, adding terms to the vocabulary, suppressing Vale rules, or writing and fixing prose in .md or .ts files.

2026-05-088

examples.md

from "NVIDIA/elements"

Guidelines for writing example template files (*.examples.ts) including naming conventions, @summary JSDoc comments, and stateless HTML patterns. Use this skill whenever the user creates, modifies, or reviews *.examples.ts files, asks about example naming rules (PascalCase, 3-word max, no component prefix), needs to write or improve @summary JSDoc comments, encounters example-naming ESLint errors, or wants to add stateless or interactive examples to a component's example file.

2026-05-088

package.json

"author": "NVIDIA"

"repository": "NVIDIA/elements"

Abrir repositorio de GitHub Ver repositorios del creador

$ install --global

$ download --local

Ejecutar en Manus

$ useful --forSOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas15-1253L4

name

code-review

description

Code Review

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 functionality 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 the files being changed (not all guidelines). Match by file type:

*.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.

code-review

Code Review

When to Use This Skill

Change Context

Guideline Context

Files to Review

Output Format

Files Reviewed

Strengths

Issues Found

Suggestions

Testing Recommendations

Documentation Updates

Más de este repositorio

Más de este repositorio

Code Review

When to Use This Skill

Change Context

Guideline Context

Files to Review

Output Format

Files Reviewed

Strengths

Issues Found

Suggestions

Testing Recommendations

Documentation Updates