home / skills / oimiragieo / agent-studio / private-vs-shared-components

private-vs-shared-components skill

safe

/.claude/skills/_archive/dead/private-vs-shared-components

This skill helps you enforce private vs shared component guidelines, guiding placement in app or src directories to maximize reuse and clarity.

npx playbooks add skill oimiragieo/agent-studio --skill private-vs-shared-components

Review the files below or copy the command above to add this skill to your agents.

Files (3)

SKILL.md

1.7 KB

---
name: private-vs-shared-components
description: Rules for determining if a component should be private or shared, and where to place them based on their use-case.
version: 1.0.0
model: sonnet
invoked_by: both
user_invocable: true
tools: [Read, Write, Edit]
globs: src/**/*
best_practices:
  - Follow the guidelines consistently
  - Apply rules during code review
  - Use as reference when writing new code
error_handling: graceful
streaming: supported
---

# Private Vs Shared Components Skill

<identity>
You are a coding standards expert specializing in private vs shared components.
You help developers write better code by applying established guidelines and best practices.
</identity>

<capabilities>
- Review code for guideline compliance
- Suggest improvements based on best practices
- Explain why certain patterns are preferred
- Help refactor code to meet standards
</capabilities>

<instructions>
When reviewing or writing code, apply these guidelines:

- Private Components: For components used only within specific pages, you can create a \_components folder within the relevant /app subdirectory.
- Shared Components: The /src/components folder should contain reusable components used across multiple pages or features.
  </instructions>

<examples>
Example usage:
```
User: "Review this code for private vs shared components compliance"
Agent: [Analyzes code against guidelines and provides specific feedback]
```
</examples>

## Memory Protocol (MANDATORY)

**Before starting:**

```bash
cat .claude/context/memory/learnings.md
```

**After completing:** Record any new patterns or exceptions discovered.

> ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.

Overview

This skill helps teams decide whether a UI or utility component should be private to a feature or shared across the app, and where to place it in a JavaScript codebase. It codifies simple, actionable rules so components live in predictable locations. The guidance reduces duplication and improves maintainability.

How this skill works

The skill inspects component usage patterns and suggests placement based on scope: put components used only by a single page or route into a _components folder inside that app subdirectory, and move reusable components into /src/components. It flags questionable placements, recommends refactors, and explains the rationale behind each suggestion. It also prompts recording new patterns or exceptions to memory so future reviews align with team conventions.

When to use it

During code reviews to validate component placement and scope.
When adding a new component and deciding its home directory.
When refactoring a feature to extract shared UI or logic.
When onboarding new team members to established file-structure rules.
When consolidating duplicated components across pages.

Best practices

Keep feature-specific components inside the feature folder under a _components subfolder to limit their scope.
Place truly reusable components in /src/components with clear, stable public props.
Prefer composition over inheritance; extract only what is reused across multiple features.
Avoid exporting private components from shared directories; keep API surface minimal.
When a private component grows cross-feature usage, promote it to /src/components and update imports.

Example use cases

A date-picker used only on a checkout page: place it in app/checkout/_components.
A button with consistent theme and behavior used across pages: add it to /src/components/button.
Multiple pages duplicating a small list renderer: extract the renderer into /src/components/list and replace local copies.
A modal wrapper used by a single feature: keep it private until other features actually need it.
Refactoring a page that imports a shared component but uses only a small variant: create a private wrapper in the feature folder.

FAQ

How do I decide when to promote a private component to shared?

Promote when two or more independent features use the same component implementation or when duplication becomes costly to maintain.

Should shared components depend on app-specific context?

No. Shared components should remain context-agnostic and accept configuration via props or slots to avoid hidden coupling.