# Reusable React Component Prompt Template Copy this directory, rename it for the component, and customize the prompt. Replace all `` and remove sections that do not apply. --- ## Prompt You are working in the `fe-digitaltwin-v2` repository, a React 18 + TypeScript + Vite application using React Router, Tailwind CSS, and shared UI libraries. Create or update the component described below. First inspect the repository for local instructions, existing components, types, hooks, API helpers, and design patterns that can be reused. Preserve the current architecture and make the smallest complete change. ### Component request - **Component name:** `` - **Purpose:** `` - **Target location:** `src/shared/components//.tsx` - **Used by:** `` - **Reusability:** `` ### React composition contract - **Root element/ref:** `` - **Props:** `` - **Controlled state:** `` - **Uncontrolled state:** `` - **Composition:** `` - **Native props:** `` - **Variants:** `` Keep domain data fetching, routing, and permissions in the parent unless they are the component's explicit responsibility. Prefer a controlled API for state that another component or page must observe. ### Component styling theme - **Theme name:** `` - **Visual role:** `` - **Surface:** `` - **Typography:** `` - **Shape:** `` - **Color:** `` - **Motion:** `` - **Dark mode:** `` Use the semantic tokens documented in `prompts/design-system.md`. Do not hard-code a second color system inside a reusable primitive. ### UI and behavior - **Layout:** `` - **Interactions:** `` - **States:** `` - **Accessibility:** `` ### Visual reference - **Design/source:** `` - **Required parity:** `` - **Details that must match:** `` If this is a migration from `fe-front-end`, treat the source implementation as the behavior and visual reference. Translate Next.js-specific APIs to the existing Vite/React Router equivalents; do not copy `next/*`, NextAuth, or server-component assumptions into this repository. ### Constraints - Use TypeScript with explicit, reusable types; do not use `any` unless an existing external API makes it unavoidable and the reason is documented. - Use `React.forwardRef` when consumers may need the underlying element. - Keep the public prop API small, typed, and composable. - Allow `className` customization and merge it with `cn()` when consistent with nearby shared primitives. - Reuse existing components and utilities before adding new abstractions. - Prefer the established UI system nearest to the target feature. Do not mix UI libraries in one component without a repository precedent. - Use `@/` imports where they improve readability. - Keep API/data logic out of a reusable presentational component when practical. - Do not add a dependency unless it is necessary and explicitly approved. - Do not modify unrelated files or silently redesign neighboring UI. - Do not expose tokens, secrets, or sensitive response data in logs or the UI. ### Acceptance criteria 1. `` 2. `` 3. `` 4. `` 5. `` ### Deliverables 1. Implement the component and the minimum integration needed to use it. 2. Add or update types, helpers, and tests only when required by the change. 3. Run focused verification that follows the repository instructions. Do not run prohibited repository-wide build/typecheck commands. 4. Report: - files changed; - behavior implemented; - verification performed and its result; - assumptions or remaining limitations. 5. End with a very simple, easy-to-understand **TL;DR**. Do not stop at a plan when the requirements and local repository context are sufficient to implement the component. Ask a question only if a missing choice would materially change the result. ---