Complete Skills Location Reference
This page preserves the complete original file-locations guidance while the preceding pages present the same model as smaller lessons.
There are actually three different levels of skills, and I would store them in different places.
1. Organization Skills (Recommended)
These are your most valuable skills.
Examples:
skill-react-frontend.md
skill-atomic-bomb.md
skill-feature-generation.md
skill-ddd.md
skill-storybook.md
skill-accessibility.md
These should live in a dedicated repository:
engineering-skills/
├── skills/
│ ├── react/
│ ├── architecture/
│ ├── testing/
│ ├── storybook/
│ ├── ddd/
│ └── accessibility/
├── guidelines/
├── examples/
└── SKILLS.md
Benefits:
- Shared across projects
- Versioned independently
- Reviewed like source code
- Becomes organizational knowledge
This is the model I would teach in the course.
2. Project Skills
These are project-specific.
Examples:
room-id-upload-flow.md
notthis-threat-analysis.md
re-expression-camera-pipeline.md
These belong in the project repository:
project/
├── .skills/
│ ├── project/
│ ├── domains/
│ └── features/
└── src/
Example:
.skills/
├── project/
│ ├── coding-standards.md
│ └── architecture.md
├── domains/
│ ├── customer-management.md
│ └── authentication.md
└── features/
├── upload-flow.md
└── dashboard.md
These skills often shouldn't leave the project.
3. Agent Runtime Skills
These are the skills the agent actually loads.
Examples:
SKILLS.md
or
.github/
└── copilot/
└── instructions.md
or
.claude/
├── skills/
└── CLAUDE.md
or
.cursor/
└── rules/
depending on the tooling.
Think of these as the active skill set.
They should mostly reference organizational skills.
Example:
# SKILLS.md
Required Skills:
- react/skill-react-frontend.md
- architecture/skill-atomic-bomb.md
- testing/skill-vitest.md
Project Skills:
- domains/customer-management.md
- features/product-overview.md
What I Would Do for Atomic Bomb
I would create a structure like:
engineering-skills/
├── architecture/
│ ├── atomic-bomb.md
│ ├── atomic-design.md
│ └── ddd.md
│
├── react/
│ ├── atom.md
│ ├── molecule.md
│ ├── organism.md
│ ├── template.md
│ └── page.md
│
├── domains/
│ ├── model.md
│ ├── service.md
│ ├── state.md
│ ├── api.md
│ └── event.md
│
├── quality/
│ ├── testing.md
│ ├── storybook.md
│ ├── accessibility.md
│ └── performance.md
│
└── workflows/
├── feature-generation.md
├── github-issue.md
├── pr-review.md
└── skill-extraction.md
Then every new project gets:
project/
├── .skills/
│ ├── SKILLS.md
│ └── project/
└── src/
where .skills/SKILLS.md acts as the orchestrator.
The Long-Term Evolution
The most mature setup looks like:
Requirements
↓
Project Skills
↓
Organization Skills
↓
Atomic Bomb
↓
MCP Tools
↓
AI Agent
↓
Implementation
In that model:
- Application code lives in the application repo.
- Skills live in a dedicated skills repo.
- Project-specific skills live alongside the application.
- MCP tools become the execution layer.
This separation is important because skills evolve much more slowly than application code and become reusable across dozens of projects. In many organizations, the engineering-skills repository eventually becomes more strategically valuable than any individual application repository because it contains the accumulated engineering knowledge of the entire organization.
Mini exercise
Apply Complete Skills Location Reference to your current engineering guidance. Classify each instruction as organization-wide, project-specific, or runtime-specific, then identify one item that currently lives at the wrong level.
Example
For an accessibility-testing skill:
- Organization level: Required semantic HTML, keyboard behavior, and automated accessibility rules.
- Project level: Product-specific supported browsers and accepted exceptions.
- Runtime level: The command and agent instructions used to run the checks.
- Validation: Trace one generated component to all three sources without duplicating the policy.