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.