Project Analyzer Skill

This skill enables comprehensive analysis of software projects to understand their structure, patterns, and conventions before making changes.

When to Use This Skill

• •Starting work on a new task in an existing project
• •Creating a task breakdown for a feature
• •Understanding project conventions before coding
• •Reviewing code for consistency
• •Setting up a new project with best practices

Analysis Framework

1. Project Structure Analysis

Directory Layout

• •Identify the project type (monorepo, single app, library, etc.)
• •Map the directory structure
• •Understand the organization pattern (by feature, by layer, etc.)

Key Directories to Look For

src/              # Source code
lib/              # Library code
app/              # Application code
tests/            # Test files
docs/             # Documentation
config/           # Configuration
scripts/          # Build/utility scripts
public/           # Static assets
dist/             # Build output

2. Technology Stack Detection

Package Managers & Dependencies

Frameworks

• •Check dependencies for framework indicators
• •Look for framework-specific config files
• •Identify framework version

Build Tools

• •Webpack, Vite, esbuild (JavaScript)
• •Make, CMake (C/C++)
• •Maven, Gradle (Java)
• •Cargo (Rust)

3. Code Patterns & Conventions

Coding Style

• •Check for .editorconfig
• •Look for linter configs (.eslintrc, .prettierrc, phpcs.xml)
• •Analyze existing code for patterns:
  • •Naming conventions (camelCase, snake_case, PascalCase)
  • •Indentation style
  • •Quote style
  • •Semicolon usage

Architecture Patterns

• •MVC (Model-View-Controller)
• •Clean Architecture / Hexagonal
• •Repository Pattern
• •Service Layer
• •Domain-Driven Design

Design Patterns in Use

• •Factory
• •Singleton
• •Observer
• •Strategy
• •Decorator
• •Dependency Injection

4. Testing Strategy

Test Framework Detection

Test Organization

• •Unit tests location
• •Integration tests location
• •Test naming conventions
• •Mocking patterns

5. Documentation Standards

README Structure

• •Project description
• •Installation instructions
• •Usage examples
• •Contributing guidelines

Code Documentation

• •JSDoc, PHPDoc, docstrings
• •Inline comments style
• •API documentation

Analysis Output Template

When analyzing a project, report findings in this format:

## Project Analysis Report

### Overview
- **Type**: [Web App / API / Library / CLI / etc.]
- **Primary Language**: [Language + version]
- **Framework**: [Framework + version]

### Structure
[Description of directory organization]

### Dependencies
- **Runtime**: [key dependencies]
- **Development**: [key dev dependencies]

### Patterns & Conventions

#### Coding Style
- Naming: [convention]
- Formatting: [tool/standard]
- Linting: [tool/rules]

#### Architecture
- Pattern: [architecture pattern]
- Key abstractions: [list]

#### Testing
- Framework: [test framework]
- Coverage: [if measurable]
- Organization: [how tests are organized]

### Recommendations
[Recommendations for maintaining consistency]

Empty Project Guidance

When project is new/empty, recommend:

JavaScript/TypeScript

• •TypeScript for type safety
• •ESLint + Prettier for formatting
• •Jest or Vitest for testing
• •Clear src/ structure

Python

• •Type hints throughout
• •Black + isort for formatting
• •pytest for testing
• •src layout or flat layout

PHP

• •PSR-4 autoloading
• •PHP-CS-Fixer or PHP_CodeSniffer
• •PHPUnit for testing
• •Proper namespace organization

General Best Practices

• •README with setup instructions
• •.editorconfig for consistency
• •.gitignore appropriate for stack
• •CI/CD configuration
• •Environment variable handling

Integration with Development

After analysis, use findings to:

1. •Match existing code style in new code
2. •Follow established patterns
3. •Use same testing approaches
4. •Maintain documentation standards
5. •Respect architectural boundaries

See references/patterns.md for detailed pattern examples.