Comprehensive Claude Code Skill — Project Guidelines

A Claude Code skill providing a template and framework for creating project-specific coding guidelines. Based on production applications, this skill helps you establish consistent conventions, patterns, and standards that are tailored to your specific project's technology stack and team practices.

When to Use This Skill

Choose CC Skill Project Guidelines when:

• You're establishing coding guidelines for a new project
• You want to create a CLAUDE.md or project rules file from a template
• You need to document project-specific conventions and patterns
• You're onboarding new developers and need a standards reference
• You want a consistent framework for project-level documentation

Consider alternatives when:

• You need general best practices (use a best practices skill)
• You want to refactor existing instructions (use an agent MD refactor skill)
• You need technology-specific patterns (use a technology-specific skill)

Quick Start

Copy
# Install the skill
claude install comprehensive-cc-skill-project

# Generate project guidelines
claude "Generate project guidelines for our Next.js + Express + PostgreSQL project: coding conventions, file organization, and commit standards"

# Customize for your stack
claude "Create a CLAUDE.md for our Python/FastAPI project with SQLAlchemy, following our team conventions: [describe conventions]"

# Review existing guidelines
claude "Review our project guidelines for completeness and consistency: [paste CLAUDE.md]"

Core Concepts

Project Guidelines Structure

Section	Content	Purpose
Project Overview	Tech stack, architecture, deployment	Context for any developer
File Organization	Directory structure, naming conventions	Consistent file placement
Coding Standards	Style, patterns, anti-patterns	Code consistency
Git Workflow	Branching, commits, PRs, reviews	Team coordination
Testing	Coverage requirements, test patterns	Quality assurance
Environment Setup	Dependencies, configuration, secrets	Developer onboarding
Deployment	Build, staging, production process	Release management

Guidelines Template

Copy
# Project: [Name]

## Tech Stack
- Frontend: [framework, styling, state management]
- Backend: [framework, database, cache]
- Infrastructure: [hosting, CI/CD, monitoring]

## Conventions
### Naming
- Files: kebab-case (user-profile.tsx)
- Components: PascalCase (UserProfile)
- Functions: camelCase (getUserById)
- Constants: SCREAMING_SNAKE (MAX_RETRIES)

### Patterns
- [Pattern 1 with example]
- [Pattern 2 with example]
- [Anti-pattern to avoid with example]

### Git
- Branch format: type/description (feat/user-auth)
- Commit format: type(scope): message
- PR requirements: tests pass, review approved

Guideline Quality Attributes

Attribute	Good	Bad
Specific	"Use Zod schemas in /validators"	"Validate inputs"
Actionable	"Run npm test before every PR"	"Ensure quality"
Enforced	"ESLint rule no-explicit-any"	"Avoid using any"
Updated	"Last reviewed: March 2026"	Undated, possibly stale
Concise	One rule per bullet, clear language	Paragraph-length explanations

Configuration

Parameter	Type	Default	Description
stack	string	""	Technology stack description
team_size	number	5	Team size for appropriate guidelines
style	string	"comprehensive"	Style: minimal, standard, comprehensive
include_templates	boolean	true	Include file templates
enforcement	string	"automated"	Level: suggested, automated, strict

Best Practices

1. Keep it under 200 lines — Long guidelines don't get read. Put the 20% of rules that cover 80% of cases in the main file. Link to detailed documents for deep dives on specific topics.

2. Make rules enforceable — Every guideline should be either automatable (ESLint rule, CI check) or verifiable in code review. "Write clean code" is not enforceable. "Functions must be under 30 lines" is.

3. Include examples for every convention — Show a "do this" and "don't do this" pair for each coding convention. Developers learn patterns from examples faster than from abstract descriptions.

4. Review and update quarterly — Technology and team practices evolve. Schedule quarterly reviews to remove outdated guidelines, add new conventions, and ensure the document reflects actual practice.

5. Get team buy-in — Guidelines imposed without team input get ignored. Discuss conventions as a team, make decisions collectively, and document the reasoning. People follow rules they helped create.

Common Issues

Nobody reads the guidelines — They're too long or hard to find. Keep the main document short, put it in the repo root (CLAUDE.md, CONTRIBUTING.md), and reference it in PR templates and onboarding docs.

Guidelines conflict with each other — Review the full document for contradictions. "Always use strict types" and "Move fast, don't over-engineer" can conflict. Resolve conflicts by prioritizing and being specific about when each guideline applies.

Guidelines are outdated — Assign ownership. One person (or rotating role) should review guidelines monthly. Remove rules that no longer apply and add rules for new patterns that have emerged.