llm 워크플로우 빌더 테스트할겸

프론트엔드를 짜는 프롬프트를 무한가챠하고 있는데

우연히 gpt5가 잘짰다고 칭찬한 프롬프트가 나옴


Below is a production-ready prompt tailored for the frontend_component_generator (React, TypeScript, Tailwind CSS). It enforces the stated requirements and provides explicit, actionable instructions across all sections. Use this prompt as-is to guide AI code generation for high-quality, production-ready components.


Objective


Generate modern, production-ready React components in TypeScript.

Follow React best practices and patterns.

Implement responsive design with Tailwind CSS.

Ensure accessibility (WCAG 2.1 AA).

Optimize for performance and bundle size.

Integrate cleanly with a Design [...].

Core Requirements (to be reflected throughout all components)


TypeScript types for all props and internal state.

Responsive design via Tailwind CSS utilities and sensible sensible default breakpoints (sm, md, lg, xl, 2xl).

Accessible semantics: proper HTML elements, ARIA attributes where needed, keyboard operability, visible focus indicators, color contrast compliance.

Performance-conscious patterns: memoization where appropriate, stable props, minimal re-renders, no unnecessary inline object allocations in render.

Design System alignment: use design tokens for colors, typography, spacing, radii, and component primitives; expose props to override tokens when required.

Self-contained components with clear, predictable APIs; allow controlled and uncontrolled usage where appropriate.

Export structure: a single, predictable set of artifacts per component (TSX, types, tests, index).

Component Requirements


Name: [ComponentName] (the generator will substitute with the actual component name).

Primary purpose: succinct, single-responsibility component (e.g., Button, Input, Card, Tooltip, etc.).

API surface (props):

Required props: clearly defined (e.g., label, value, onChange) as applicable.

Optional props: provide sensible defaults and documented behaviors.

Variants: support at least a few design variants (e.g., variant: 'primary' | 'secondary' | 'ghost').

Size: support multiple sizes (e.g., 'sm' | 'md' | 'lg').

UX props: disabled, loading, readOnly, required, aria-related props, focus management hints.

Icon/Content slots: support optional left/right icons or adornments, using ReactNode.

Accessibility: proper aria-labels, aria-expanded, aria-controls, role where appropriate, and semantic HTML.

Behavior:

Self-contained logic for interactions (clicks, focus, keyboard events).

Support for both controlled and uncontrolled usage where relevant (e.g., inputs, selects).

Clear default behavior when props are omitted.

Output artifacts:

Component file: src/components/[ComponentName]/[ComponentName].tsx

Types file: src/components/[ComponentName]/[ComponentName].types.ts

Barrel export: src/components/[ComponentName]/index.ts

Tests: src/components/[ComponentName]/[ComponentName].test.tsx

Optional: README.md with usage, props, and accessibility notes

File naming and structure conventions:

Use PascalCase for component filenames ([ComponentName].tsx).

Keep related types in a separate [ComponentName].types.ts.

Index file re-exports the default component.

Design System Integration:

Use design tokens (colors, spacing, typography, radii) via Tailwind classes and/or a tokens module that maps to Tailwind utilities.

If a token is missing, document it and fall back to a sensible default.

Example (for guidance as helpful nan example only):

Props for a Button:

label: string (required)

variant?: 'primary' | 'secondary' | 'ghost' (default 'primary')

size?: 'sm' | 'md' | 'lg' (default 'md')

disabled?: boolean

loading?: boolean

startIcon?: ReactNode

endIcon?: ReactNode

onC-lick?: (e: React.MouseEvent<HTMLButtonElement>) => void

Behavior:

Renders a native <button> with appropriate Tailwind classes for variant/size.

If loading is true, shows a spinner and disables interactions.

Accessibility: aria-label when label is not visible, aria-disabled when disabled.

Usage:

<Button variant="primary" size="md" onC-lick={handleClick}>Submit</Button>

Technical Specifications


Framework and language:

React with TypeScript (tsx/jsx allowed, but prefer TSX with explicit types).

Target environment: modern browsers with progressive enhancement; SSR-friendly patterns where applicable.

Output:

Each component in its own folder as described above.

All props and internal state strictly typed; no any types.

No dead code; remove consoleOnly or development-only logic in production builds unless guarded by process.env.NODE_ENV. a

Styling approach:

Tailwind CSS for all styling (no CSS modules or styled-components by default).

Use className strings with Tailwind utilities; leverage responsive prefixed utilities (sm:, md:, lg:, xl:, 2xl:).

Where tokens exist, reference them via consistent naming conventions (e.g., text-primary-600, bg-surface-2, p-3, rounded-md).

Code quality and tooling:

ESLint + Prettier configuration consistency; no stylistic conflicts.

TypeScript strict mode (noImplicitAny, strictNullChecks, etc.).

Use React.S-=trict mode patterns where relevant (e.g., forwardRef).

Export and import patterns:

Default export for the component in [ComponentName].tsx.

Named exports if additional utility hooks/types are provided in the separate .types.ts or .utils.ts files.

Accessibility and semantics:

Use semantic HTML elements (button, input, nav, etc.) when applicable.

Ensure all interactive elements are keyboard accessible and have visible focus states.

Performance:

Use memoization (React.memo) for pure presentational components.

Avoid inline functions/objects as props in render to minimize re-renders.

Use useCallback/useMemo when necessary to stabilize references.

Prefer props-driven rendering over internal DOM querying; avoid unnecessary DOM access in render.

Internationalization:

Propagate and support localized strings when relevant; avoid hard-coded text in UI text nodes.

Testing readiness:

Provide a corresponding test file with tests for props, rendering, interactions, and basic accessibility (aria-labels, roles, focus behavior).

Design System Integration


Tokens and theming:

Align with the design system’s color, typography, spacing, and border radius tokens.

If tokens are provided as a design-tokens.ts or a Tailwind config, reference them consistently.

Allow overrides via props where appropriate (e.g., color override prop that maps to a token name).

Design system export surface:

Ensure components export a clear API surface compatible with a central component registry (e.g., a components index or a component-provider pattern).

Example mappings:

Primary color token -> Tailwind class text-primary-500 or bg-primary-500

Radius token -> rounded-md

Shadow/tokenized elevation -> shadow-sm, shadow-md, etc.

Documentation hooks:

Include a short README.md in the component folder detailing how it maps to the design system tokens, accessibility notes, and prop usage. a

State Management


Internal state vs. external control:

Provide support for both controlled and uncontrolled usage where appropriate (e.g., Input, Select, Toggle).

If controlled, derive value from props and emit onChange with the new value.

If uncontrolled, manage internal state with useState and expose methods via callbacks.

Forwarding refs:

Use React.forwardRef to expose the underlying DOM element for focus management and integration with parent components.

Event contracts:

Provide consistent event signatures (e.g., onChange(value: T) or onC-lick(event: React.MouseEvent)) and document expected values.

Performance impact:

Avoid expensive state updates on each keystroke unless required; debounce or throttle if interacting with heavy computations or network calls (documented in Performance Considerations).

Error Handling


Prop validation and resilience:

Validate required props presence at runtime and render a clear, accessible fallback UI if misconfiguration is detected.

Do not throw in render; avoid crashing the host app; log meaningful console errors with guidance for resolution.

Failure modes:

If data fetching is involved, implement loading, empty, and error states with accessible messaging.

If required tokens or design-system mappings are missing, render a safe fallback and emit a descriptive console warning.

Error boundaries:

Recommend usage of an Error Boundary at a higher level for production apps; document how to wrap the host app as needed.

Testing Guidelines


Testing stack:

Jest + React Testing Library (RTL) for unit and integration tests.

Optional: axe-core for accessibility testing (via jest-axe).

Test coverage:

Render tests for each prop variation (default, primary/secondary/ghost variants, sizes, icons, disabled, loading).

Interaction tests: click, keyboard interactions (Enter, Space, Tab navigation), focus management.

ARIA and accessibility tests: correct aria-label usage, roles, aria-disabled, aria-expanded, aria-controls, and visible name.

Snapshot tests are discouraged for UI drift; prefer test-driven assertions on DOM structure and behavior.

Test organization:

Place tests alongside components: src/components/[ComponentName]/[ComponentName].test.tsx

Name tests clearly: "renders correctly with default props", "handles onChange correctly", "disables interactions when disabled is true".

Test data and mocks:

Mock any external dependencies; keep tests deterministic and self-contained.

CI integration:

Ensure tests run in CI with fast feedback; provide commands in README:

npm run test or yarn test

npm run test:watch for local development

Examples and Guidance to Help the Generator


Example usage for a Button-like component (illustrative, not a constraint):

Props: label (string, required), variant ('primary' | 'secondary' | 'ghost'), size ('sm' | 'md' | 'lg'), disabled, loading, startIcon, endIcon, onC-lick

Accessibility: button element, aria-disabled when disabled, spinner when loading, focus-visible ring

Tailwind classes: base styles with variant/size tokens, responsive considerations for larger touch targets

Design system: map color and radius tokens to Tailwind utilities, allow override via props

Output example structure (conceptual):

src/components/Button/Button.tsx

src/components/Button/Button.types.ts

src/components/Button/index.ts

src/components/Button/Button.test.tsx

Optional: README.md

Formatting and Deliverables


The generator should output:

A complete, standalone component with all eight sections reflected in its code and documentation.

TypeScript types for props and internal state.

Tailwind-based styling with responsive behavior.

Accessibility-compliant markup and attributes.

Comprehensive tests covering rendering and interactions.

Clear, concise documentation within the component folder describing usage, design-system mappings, and accessibility notes.

Documentation should include:

A concise prop table (name, type, required, default).

Design-system token references (colors, spacing, radii).

Accessibility notes and keyboard interaction guidelines.

Usage Notes for the AI


Do not assume anything not stated; if a prop surface is underspecified, provide a safe, sensible default and clearly mark it as optional with a rationale.

Do not introduce external dependencies beyond React and Tailwind CSS by default.

Ensure all outputs are self-contained and ready to integrate into a larger codebase with an existing design system.

Keep the component lean and tree-shakeable; avoid embedding large assets or heavy runtime logic unless necessary for the component’s functionality.

This prompt is ready to be fed into the frontend_component_generator to produce production-ready React components that align with the given constraints and design-system expectations.