code-review

name	code-review
description	Apply when preparing a PR, reviewing code changes, running git diff, or generating a changeset. Use when user says "review", "PR prep", "code review", or "changeset". Use when this capability is needed.
metadata	{"author":"drivenets"}

PR Workflow & Code Review

Git & PR Workflow

Requirement	Details
No force-push after review	GitHub loses review history; use merge commits instead
Changelog required	Run pnpm changelog before merge
Conventional commits	PR title must follow conventional commit format
Separate concerns	Unrelated changes go in separate PRs; easier revert and isolation
Changeset messages are user-facing	Write "Add X to Y" or "Fix X in Y", not implementation details
skip changelog label	Use only for non-user-facing changes (CI, tests, docs); never for bug fixes
Use --frozen-lockfile	Run pnpm install --frozen-lockfile to avoid unnecessary lockfile changes
Deprecation rules	Add to @drivenets/eslint-plugin-design-system when deprecating

<!-- Good changeset message -->

Add DsCard component

<!-- Bad changeset message - implementation details -->

Refactor card to use CSS modules and fix hover state selector specificity

---

Code Review Process

1. Get diff: git diff origin/main
2. Review every changed file — read the matching skill(s) fully for paths in the diff:

Changed paths	Skills
ds-*.types.ts	component-api, ts-standards
ds-*.tsx (not stories/tests)	react-patterns; ark-ui if Ark
*.stories.tsx	storybook, react-patterns
*.browser.test.tsx	browser-tests
*.module.scss	scss

3. Flag only clear, high-severity issues (max 10 inline comments)

Inline comment format

/**
 * REVIEW-[SEVERITY]: [ISSUE DESCRIPTION]
 */

• One issue per comment; place on the exact changed line
• Natural tone, specific and actionable; do not mention automated or high-confidence
• Severity: 🚨 Critical 🔒 Security ⚡ Performance ⚠️ Logic ✨ Improvement

---

PR Checklist

Before submitting a PR:

• Changelog added (pnpm changelog) with user-facing message
• Behavioral coverage in *.browser.test.tsx where interactions matter
• Browser tests use a11y queries (no test-ids unless unavoidable)
• CSS uses design tokens, no !important
• No inline styles in stories
• Props layer doesn't expose library internals
• Types exported from .types.ts with variant arrays
• Code is well-spaced and readable
• Matches Figma design
• Storybook examples show all states (controlled + localized)
• No cross-component internal imports
• No unnecessary useMemo/useCallback (except under ds-table/ — excluded from React Compiler; see react-patterns)
• Check Ark UI for existing primitives before custom implementation
• No overflow: hidden as a band-aid for layout bugs
• No raw <img> — use DS components (e.g., DsAvatar) with fallback
• No leftover code from abandoned implementation approaches
• No -webkit-* without cross-browser fallback or @supports guard
• AI-generated tests actually assert meaningful behavior (not duplicate/trivial)

---

Source: drivenets/design-system — distributed by TomeVault.