Guides discovery and application of project-specific conventions including code patterns, naming, structure, and team practices. Use when exploring a codebase or implementing features to match existing patterns.
Scanned 9/7/2026
Install to Claude Code
npx -y skills add sequenzia/claude-alchemy --skill project-conventions --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Project Conventions?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/sequenzia-project-conventions-bfd1df6c)More formats (shields.io, HTML) on the badges page.
---
name: project-conventions
description: Guides discovery and application of project-specific conventions including code patterns, naming, structure, and team practices. Use when exploring a codebase or implementing features to match existing patterns.
dependencies: []
---
# Project Conventions
This skill guides you in discovering and applying project-specific conventions. Every codebase has its own patterns and practices - your job is to find them and follow them.
---
## Convention Discovery Process
### Step 1: Project Configuration
Check these files for explicit conventions:
**Code Style:**
- `.eslintrc*`, `eslint.config.*` - JavaScript/TypeScript linting rules
- `.prettierrc*`, `prettier.config.*` - Formatting rules
- `pyproject.toml`, `setup.cfg`, `.flake8` - Python config
- `.editorconfig` - Editor settings
- `ruff.toml`, `.ruff.toml` - Ruff linter config
**Project Structure:**
- `tsconfig.json` - TypeScript paths and settings
- `package.json` - Scripts, dependencies
- `pyproject.toml` - Python project config
**Documentation:**
- `CONTRIBUTING.md` - Contribution guidelines
- `CLAUDE.md` or `AGENTS.md` - AI coding guidelines
- `README.md` - Project overview
- `docs/` - Extended documentation
### Step 2: Existing Code Patterns
Study the codebase to find implicit conventions:
**File Organization:**
- List component directories to understand organization
- Search for test file patterns (e.g., `*.test.*`, `*_test.*`, `test_*`)
- List utility directories to see how helpers are organized
**Naming Patterns:**
- Search for exported function declarations to identify naming style
- Search for class declarations to identify class naming style
**Import Patterns:**
- Search for import statements to identify absolute vs relative import styles
### Step 3: Similar Features
Find features similar to what you're building:
1. **Search for similar functionality:**
- Search for files and content matching the feature you are implementing
2. **Study the implementation:**
- How is it structured?
- What patterns does it use?
- How does it handle errors?
- How is it tested?
3. **Note the patterns:**
- Component structure
- State management approach
- API call patterns
- Validation approach
---
## Common Convention Areas
### Naming Conventions
**Discover by example:**
- Search for function declarations, variable declarations, and component names in the source directory
**Common patterns:**
- `camelCase` for functions/variables
- `PascalCase` for components/classes
- `UPPER_SNAKE` for constants
- `kebab-case` for file names (some projects)
- `snake_case` for file names (Python)
### File Structure
**Discover the pattern:**
- List files in component or feature directories to see how they are organized
**Common patterns:**
Flat structure:
```
components/
Button.tsx
Button.test.tsx
Button.styles.ts
```
Folder per component:
```
components/
Button/
index.ts
Button.tsx
Button.test.tsx
Button.module.css
```
Feature-based:
```
features/
auth/
components/
hooks/
api.ts
types.ts
```
### Error Handling
**Discover the pattern:**
- Search for try-catch patterns, custom error types, and error handling in API layers
**Apply what you find:**
- Use the same error types
- Follow the same handling pattern
- Match logging approach
### Testing Patterns
**Discover the pattern:**
- Read the first 50 lines of existing test files to understand test structure
- Check for test setup files and utilities
**Match the patterns:**
- Test file location (co-located vs separate)
- Naming convention (`*.test.ts` vs `*.spec.ts`)
- Setup and teardown approach
- Mocking strategy
- Assertion style
### API Patterns
**Discover the pattern:**
- Search for fetch/axios/api usage patterns
- Read API response handling functions
**Match the patterns:**
- How are endpoints defined?
- How is authentication handled?
- What's the error format?
- How are responses typed?
---
## Convention Application Checklist
When implementing a feature, verify you're following conventions for:
### Code Style
- [ ] Variable naming matches existing code
- [ ] Function naming matches existing code
- [ ] File naming follows project pattern
- [ ] Import style matches (absolute vs relative)
### Structure
- [ ] File location follows project structure
- [ ] Component organization matches
- [ ] Export style matches (default vs named)
### Patterns
- [ ] Error handling follows project patterns
- [ ] Async patterns match existing code
- [ ] State management follows project approach
- [ ] API calls follow established patterns
### Testing
- [ ] Test file location is correct
- [ ] Test naming follows convention
- [ ] Test structure matches existing tests
- [ ] Mocking approach is consistent
### Documentation
- [ ] Comments follow existing style
- [ ] JSDoc/docstrings match project
- [ ] README updates if needed
---
## When Conventions Conflict
Sometimes you'll find inconsistent patterns:
1. **Prefer newer code** - Recent files often reflect current team preferences
2. **Prefer maintained code** - Active parts of the codebase reflect current practices
3. **Prefer documented conventions** - Explicit rules in configs override implicit patterns
4. **Ask if unclear** - When in doubt, ask the user which pattern to follow
---
## Red Flags
Watch for these signs that you might be breaking conventions:
- Your code looks very different from surrounding code
- You're using a library/pattern not used elsewhere
- Your file structure doesn't match siblings
- Your naming feels inconsistent with the codebase
- Linting errors (the project has explicit rules you're breaking)
When you notice these, stop and investigate the existing conventions more carefully.
---
## Integration Notes
**What this component does:** Guides systematic discovery and application of project-specific conventions by examining config files, existing code patterns, and similar features in the codebase.
**Capabilities needed:** File reading, file search (by pattern and content), directory listing.
**Adaptation guidance:** This is a methodology skill that describes a convention discovery process. The search techniques described (listing directories, searching for patterns, reading files) should be mapped to whatever file access capabilities the host platform provides. No platform-specific tool calls are embedded.
**Configurable parameters:** None.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!