react-container-presentation-component

# Container/Presentation Component Use this skill to create a React component under `src/components` that follows the Container/Presentation pattern. Refer to this skill's bundled references for detailed rules. - `references/component-architecture.md` - `references/typescript-and-scss-rules.md` If the `/react-container-presentation-component` input is incomplete, ask questions first before creating files. ## When To Use - When the user runs `/react-container-presentation-component` - When the user explicitly asks for a React component that follows the Container/Presentation pattern - When the user wants help deciding or implementing `ui` vs `features` classification within the Container/Presentation pattern ## Required Questions If any of the following information is missing, ask the user using `ask_user`. 1. Component name 2. Type (`ui` or `features`) 3. Whether to replace existing components (only when creating `ui`) Question requirements: - Provide the type as options (`ui`, `features`) - Require the component name to be in PascalCase - For `ui`, ask whether direct usage of Mantine or other UI libraries in existing `features` should be replaced with the new component ## Procedure 1. Check existing components - Check whether `src/components/ui/<ComponentName>` or `src/components/features/<ComponentName>` already exists. - If it exists, do not overwrite; confirm the preferred approach with the user. 2. Decide target directory - `ui`: `src/components/ui/<ComponentName>` - `features`: `src/components/features/<ComponentName>` 3. Re-check classification (only when `ui` is specified) - Even when `ui` is specified, before creating files, review `Reclassification Rule` in `references/component-architecture.md`. - If the implementation includes state management, side effects, async processing, context/store updates, or business logic, treat it as `features`. - If the result is closer to `features`, do not proceed as `ui`; use `ask_user` and confirm one of the following before continuing. - `Create as features` - `Keep ui and move state/logic to parent or features` 4. Create required files - `ui`: `index.tsx`, `index.module.scss`, `index.stories.tsx` - `features`: `index.tsx`, `use<ComponentName>.tsx`, `presentation.tsx`, `types.ts`, `presentation.module.scss`, `presentation.stories.tsx` 5. Replace existing usages (only when creating `ui`) - Only when the user approves, replace equivalent direct implementations using Mantine or other UI libraries in existing `features` with the new `ui` component. 6. Validate - Run build and lint commands, and ensure both pass; if issues are introduced by newly added or updated files, fix them. - Follow `Storybook Minimum` in `references/component-architecture.md` for story state decisions. - Ask the user via `ask_user` whether to run a Storybook check (for example: "Run" / "Skip for now"). - Run `npm run storybook` only if the user selects "Run". - If the user selects "Skip for now", explicitly mention in the final report that Storybook execution was skipped. ## Output Contract - Report the list of files created. - If replacements were performed, report the list of changed files and replacement details. - Provide one usage example of the created component. - Report whether Storybook verification was executed (run/skip), and if run, include the command used. - Explain why the component was classified as `ui` or `features`. - Summarize where state, side effects, and rendering responsibilities were placed. - Confirm whether there were any dependency direction violations. - Clearly state any unresolved items.