react-container-presentation-component - Claude MCP Skill

# 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.