accelint-design-foundation
Accelint Design Foundation
Expert knowledge for styling with @accelint/design-foundation and @accelint/design-toolkit — opinionated Tailwind conventions that differ from vanilla implementations.
NEVER Do When Styling with Design Foundation
- NEVER use numeric spacing classes as first choice - Strongly prefer the semantic scale:
p-xxs,gap-m,m-l. Numeric classes likep-4,gap-6work with a 1:1 relationship (p-1= 1px, NOT 4px like vanilla Tailwind), but should only be used for rare cases where implementing non-conforming designs. The semantic scale provides design system consistency. - NEVER use manual theme handling with raw color values - Avoid
dark:bg-gray-900orclassName={theme === 'dark' ? 'bg-black' : 'bg-white'}. Use semantic color classes likebg-surface-defaultandfg-primary-boldthat automatically adapt to light/dark themes. - NEVER use borders for sizing elements - Use
outlineinstead ofborderclasses. Borders add to element dimensions (breaks layouts), while outlines overlay without affecting size. Elements should size consistently based on content and padding only. - NEVER use arbitrary Tailwind variants - Arbitrary values like
hover:[&>svg]:opacity-50break the design system. Use supported React Aria variants or conditional class rendering withclsx. - NEVER bypass CSS layers when styling components - Use
@layer components.l1,@layer components.l2for cascade hierarchy. Bypassing layers causes specificity wars and makes overrides unpredictable. - NEVER use primitive/domain tokens as first choice - Strongly prefer semantic tokens (
bg-surface-default,fg-primary-bold) in components. The utility classes (bg-*,fg-*,icon-*,outline-*) provide fallback access todomain-*andprimitive-*tokens for rare cases where designs go beyond the design system, but this should be exceptional. Semantic tokens provide theming flexibility and design system consistency. - NEVER use inline Tailwind classes for component styling - Component styles belong in CSS modules, not inline className props. Inline Tailwind should only be used for minor one-off overrides. Using inline classes for all component styling creates unmaintainable code and loses the benefits of CSS modules (scoping, organization, reusability).
- NEVER use multiple @apply directives in a single CSS rule - Group all Tailwind classes into a single
@applystatement. Multiple@applydirectives prevent Tailwind IDE plugins from sorting classes and identifying issues. Write@apply bg-surface-default outline-1 outline-interactive p-m;not separate@applylines. - NEVER use attribute selectors for variants in CSS modules - Use
@variantdirective blocks, not attribute selectors like[data-size="small"]. Write@variant size-small { @apply p-s; }not.button[data-size="small"] { @apply p-s; }. The@variantdirective automatically applies styles when the matching data attribute is present. - NEVER use Tailwind's default theme values - The design foundation removes and replaces Tailwind defaults. Relying on default shadows, font sizes, or colors will break. Use only the semantic classes provided by the design system.
- NEVER omit @reference directive in CSS modules - Every CSS module file must include
@reference '#globals';(if custom entrypoint exists) or@reference '@accelint/design-foundation/styles';at the top. Without this, semantic tokens and @variant blocks are undefined, causing build errors. - NEVER skip PostCSS configuration - The
@accelint/postcss-tailwind-css-modulesplugin is required inpostcss.config.mjs. Without it, named group selectors (likegroup-hover/button:) and @variant selectors fail to resolve in CSS modules. - NEVER import clsx directly from 'clsx' package - Always import from
@accelint/design-foundation/lib/utilsinstead:import { clsx } from '@accelint/design-foundation/lib/utils';. The design foundation re-exports clsx with additional type support and design system integration. Importing directly bypasses these enhancements.
More from gohypergiant/agent-skills
accelint-nextjs-best-practices
Next.js performance optimization and best practices. Use when writing Next.js code (App Router or Pages Router); implementing Server Components, Server Actions, or API routes; optimizing RSC serialization, data fetching, or server-side rendering; reviewing Next.js code for performance issues; fixing authentication in Server Actions; or implementing Suspense boundaries, parallel data fetching, or request deduplication.
221accelint-ts-testing
Comprehensive vitest testing guidance for TypeScript projects. Use when (1) Writing new tests with AAA pattern, parameterized tests, or async/await, (2) Reviewing test code for anti-patterns like loose assertions (toBeTruthy), over-mocking, or nested describe blocks, (3) Optimizing slow test suites, (4) Implementing property-based testing with fast-check - especially for encode/decode pairs, roundtrip properties, validators, normalizers, and idempotence checks. Covers test organization, assertions, test doubles hierarchy (fakes/stubs/mocks), async testing, performance patterns, and property-based testing patterns. Trigger keywords on vitest, *.test.ts, describe, it, expect, vi.mock, fast-check, fc.property, roundtrip, idempotence.
214accelint-react-best-practices
React performance optimization and best practices. ALWAYS use this skill when working with any React code - writing components, hooks, JSX; refactoring; optimizing re-renders, memoization, state management; reviewing for performance; fixing hydration mismatches; debugging infinite re-renders, stale closures, input focus loss, animations restarting; preventing remounting; implementing transitions, lazy initialization, effect dependencies. Even simple React tasks benefit from these patterns. Covers React 19+ (useEffectEvent, Activity, ref props). Triggers - useEffect, useState, useMemo, useCallback, memo, inline components, nested components, components inside components, re-render, performance, hydration, SSR, Next.js, useDeferredValue, combined hooks.
183accelint-ts-performance
Systematic JavaScript/TypeScript performance audit and optimization using V8 profiling and runtime patterns. Use when (1) Users say 'optimize performance', 'audit performance', 'this is slow', 'reduce allocations', 'improve speed', 'check performance', (2) Analyzing code for performance anti-patterns (O(n²) complexity, excessive allocations, I/O blocking, template literal waste), (3) Optimizing functions regardless of current usage context - utilities, formatters, parsers are often called in hot paths even when they appear simple, (4) Fixing V8 deoptimization (monomorphic/polymorphic issues, inline caching). Audits ALL code for anti-patterns and reports findings with expected gains. Covers loops, caching, batching, memory locality, algorithmic complexity fixes with ❌/✅ patterns.
173accelint-ts-best-practices
Comprehensive TypeScript/JavaScript coding standards focusing on type safety, defensive programming, and code correctness. Use when (1) Writing or reviewing TS/JS code, (2) Fixing type errors or avoiding any/enum/null, (3) Implementing control flow, state management, or error handling, (4) Applying zero-value pattern or immutability, (5) Code review for TypeScript anti-patterns. Covers naming conventions, function design, return values, bounded iteration, input validation. For performance optimization, use accelint-ts-performance skill. For documentation, use accelint-ts-documentation skill.
166accelint-readme-writer
Use when creating or editing a README.md file in any project or package. Recursively parses codebase from README location, suggests changes based on missing or changed functionality, and generates thorough, human-sounding documentation with copy-pasteable code blocks and practical examples.
161