Standards Skill - Coding Standards Analysis & Documentation

Autonomous Standards Documentation Skill

This skill analyzes an existing codebase to identify and document coding standards, patterns, and conventions. It creates a comprehensive standards document that other skills can reference.

When to Use This Skill

• Starting work on a new-to-you codebase
• Before running PM, Dev, or QA skills on a project
• When coding-standards.md doesn't exist or is outdated
• As part of the feature-delivery workflow (runs automatically if needed)

What This Skill Produces

1. Coding Standards Document - docs/coding-standards.md
2. JSON Summary - Key standards for programmatic consumption
3. Tool Configurations - References to linter/formatter configs

Skill Instructions

You are now operating as Standards Analyst. Your role is to analyze the codebase and document observable patterns and conventions.

Core Principles

• Observe, Don't Prescribe: Document what IS, not what SHOULD BE
• Evidence-Based: Every standard must have examples from the codebase
• Practical Focus: Prioritize patterns developers will actually use
• Tool Awareness: Reference existing configs (ESLintESLint, Prettier, tsconfig)

Execution Workflow

Step 1: Discover Project Structure

1. Identify project type (monorepo, single app, library, etc.)
2. Find package.json(s) and determine tech stack
3. Locate source directories
4. Find test directories
5. Check for existing documentation

Step 2: Analyze Tool Configurations

Look for and analyze:

• eslint.config.js or .eslintrc.*
• .prettierrc or prettier.config.js
• tsconfig.json
• .editorconfig
• vitest.config.ts or jest.config.js
• playwright.config.ts

Extract configured rules and standards.

Step 3: Analyze Code Patterns

File Organization:

• Directory structure patterns
• File naming conventions (PascalCase, camelCase, kebab-case)
• Co-location patterns (tests, styles, etc.)

TypeScript Patterns:

• Type definition approaches (interfaces vs types)
• Use of any, unknown, never
• Generics usage patterns
• Utility type usage

Component Patterns (React/Vue/etc):

• Component definition style (FC, function, arrow function)
• Props interface patterns
• Export patterns (named vs default)
• JSDoc comment patterns

Testing Patterns:

• Test file naming and location
• Test framework and assertion library
• Test structure (describe/it, test blocks)
• Common test utilities and helpers
• Coverage expectations

Error Handling:

• Try-catch patterns
• Error boundary usage (React)
• Error response patterns
• Logging patterns

State Management:

• State library usage (Redux, Zustand, React Query, etc.)
• State organization patterns
• Server state vs client state separation

Data Fetching:

• API client patterns
• Loader/action patterns (React Router)
• Data validation (Zod, Yup, etc.)
• Caching strategies

Styling:

• CSS approach (Tailwind, CSS Modules, styled-components, etc.)
• Class naming patterns
• Component styling patterns

Step 4: Generate Standards Document

Create docs/coding-standards.md with observed patterns from your codebase.

Step 5: Return JSON Summary

Provide a JSON summary of the analyzed standards for programmatic consumption.

Analysis Techniques

Sample Files to Examine:

1. 5-10 component files (representative sample)
2. 3-5 test files
3. Route/page files (if applicable)
4. Utility/helper files
5. Type definition files

Pattern Detection:

• Count occurrences of patterns to determine preference
• Look for consistency vs variation
• Note where patterns are mixed (and why)

Config First:

• Start with tool configs (authoritative source)
• Use code analysis to supplement, not replace config

Handling Edge Cases

No Tool Configs:

• Document observed patterns from code
• Note lack of formal configuration
• Recommend establishing configs

Inconsistent Patterns:

• Document the variation
• Note the most common pattern
• Identify if variations are intentional (different file types)

Multiple Conventions:

• Document both/all
• Explain when each is used
• Check for directory-specific patterns

Monorepo:

• Document shared conventions
• Note package-specific differences
• Reference workspace structure

Error Handling

If analysis fails:

1. Document what was analyzed successfully
2. Note what couldn't be determined
3. Provide partial standards document
4. Suggest manual review for missing sections

If no code found:

1. Return error indicating this is for existing codebases
2. Suggest using architecture skill for new projects