Code Standards Analyzer

Purpose: Discover, document, and maintain coding standards from existing codebases using evidence-based analysis.

Philosophy: Standards should reflect REALITY (what the code actually does) not ASPIRATIONS (what we wish it did). Measure, then document.

When to Use

Primary Use Cases:

1. Brownfield Onboarding - "What are this project's coding conventions?"
2. Standards Audit - "Are we following our declared standards?"
3. New Contributor Onboarding - "Teach me the project patterns"
4. Living Documentation - "Keep standards in sync with codebase"
5. Greenfield Setup - "Initialize standards from best practices"

Activation Triggers

Keywords: analyze coding standards, discover conventions, code style, detect patterns, coding guidelines, what are the standards, naming conventions, best practices, code quality, standards audit, anti-patterns

User Requests:

• "What are the coding standards for this project?"
• "Analyze the codebase and document our conventions"
• "Check if we're following our declared standards"
• "Find anti-patterns in the code"
• "Generate coding standards documentation"
• "What naming conventions does this project use?"

Capabilities

1. Explicit Standards Discovery (Fast - 5 seconds)

• ✅ Detect existing

  .specweave/docs/internal/governance/coding-standards.md

• ✅ Parse ESLint configuration (

  .eslintrc.json

  ,

  .eslintrc.js

  )
• ✅ Parse Prettier configuration (

  .prettierrc

  ,

  .prettierrc.json

  )
• ✅ Parse TypeScript configuration (

  tsconfig.json

  )
• ✅ Parse EditorConfig (

  .editorconfig

  )
• ✅ Extract standards from

  CLAUDE.md

  ,

  CONTRIBUTING.md

2. Implicit Standards Detection (Medium - 30 seconds)

• ✅ Naming convention analysis (variables, functions, classes, constants)
• ✅ Import pattern detection (extensions, ordering, aliasing)
• ✅ Function characteristics (avg length, max length, arrow vs regular)
• ✅ Type safety analysis (

  any

  usage, interface vs type preference)
• ✅ Error handling patterns (try/catch usage, custom errors)
• ✅ Comment style analysis
• ✅ File organization patterns

3. Anti-Pattern Detection (Fast - 15 seconds)

• 🚨

  console.*

  usage in production code
• 🚨 Hardcoded secrets (API keys, passwords)
• 🚨

  any

  type overuse
• 🚨 Large files (>500 lines)
• 🚨 Long functions (>100 lines)
• 🚨 Missing error handling
• 🚨 N+1 query patterns
• 🚨 Security vulnerabilities

4. Documentation Generation (Fast - 10 seconds)

• ✅ Generate standards document with examples
• ✅ Include statistical confidence levels
• ✅ Extract real code examples from codebase
• ✅ Highlight inconsistencies and conflicts
• ✅ Provide actionable recommendations
• ✅ Link to violating files

Analysis Process

Phase 1: Explicit Standards (5 seconds)

Sources Checked:

1. .specweave/docs/internal/governance/coding-standards.md

   (HIGH confidence)

2. CLAUDE.md

   (HIGH confidence - AI instructions)

3. .eslintrc.json

   (ENFORCED by tooling)

4. .prettierrc

   (ENFORCED by tooling)

5. tsconfig.json

   (ENFORCED by compiler)

6. .editorconfig

   (ENFORCED by editor)

7. CONTRIBUTING.md

   (MEDIUM confidence - may be outdated)

Output:

## Explicit Standards Found

✅ .eslintrc.json (ENFORCED - ESLint active)
✅ .prettierrc (ENFORCED - Prettier active)
✅ tsconfig.json (ENFORCED - TypeScript compiler)
✅ CLAUDE.md (HIGH - AI development rules)
⚠️  CONTRIBUTING.md (MEDIUM - human guidelines)
❌ No .specweave/docs/internal/governance/coding-standards.md

Phase 2: Implicit Standards (30 seconds)

Analysis Performed:

• Scan

  src/**/*.{ts,js,tsx,jsx}

  files
• Parse Abstract Syntax Trees (AST)
• Calculate statistical patterns
• Identify dominant conventions

Example Output:

## Detected Patterns

### Naming Conventions (Confidence: 95%)
- Variables: camelCase (1,234 samples, 98% compliance)
- Functions: camelCase (567 samples, 100% compliance)
- Classes: PascalCase (89 samples, 100% compliance)
- Constants: UPPER_SNAKE_CASE (234 samples, 92% compliance)
  ⚠️ 8% use camelCase (inconsistency detected)

### Import Patterns (Confidence: 100%)
- Extensions: .js suffix required (100% compliance)
- Order: external → internal → types (87% compliance)

### Function Characteristics
- Average length: 35 lines
- Max length: 156 lines (src/core/analyzer.ts:45)
- Style: Arrow functions (78%), Regular (22%)

### Type Safety (Confidence: 85%)
- any usage: 12 instances (REVIEW NEEDED)
- Preference: Interfaces (89%) over Types (11%)

Phase 3: Anti-Pattern Detection (15 seconds)

Checks Performed:

• Security: Hardcoded secrets, SQL injection risks
• Maintainability: Large files, complex functions
• Performance: N+1 queries, missing caching
• Robustness: Missing error handling

Example Output:

## Issues Found

### 🔴 CRITICAL (2 issues)
- Hardcoded Secrets: 2 instances
  - src/config/api.ts:12
  - src/utils/auth.ts:45
  Fix: Use process.env variables

### 🟠 HIGH (5 issues)
- console.* Usage: 5 instances in src/
  - src/core/analyzer.ts:67
  Fix: Use logger abstraction

### 🟡 MEDIUM (12 issues)
- Large Files: 3 files > 500 lines
  - src/core/orchestrator.ts (678 lines)
  Fix: Split into modules

Phase 4: Documentation Generation (10 seconds)

Merge Strategy:

1. Explicit standards = source of truth
2. Implicit standards = fill gaps
3. Anti-patterns = warnings + recommendations

Output:

.specweave/docs/internal/governance/coding-standards-analysis.md

Integration Points

1. Brownfield Analyzer Integration

Automatic: Runs as part of brownfield analysis

User: "Analyze this brownfield project"

Workflow:
1. Scan project structure
2. Classify documents
3. Detect external tools
4. → RUN code-standards-detective agent
5. → GENERATE coding-standards.md
6. Generate migration plan

2. Increment Planning

Reference: Standards included in technical constraints

## Technical Constraints

Coding Standards: .specweave/docs/internal/governance/coding-standards.md
- Naming: camelCase (vars), PascalCase (classes)
- Functions: < 50 lines target
- No console.* - use logger

3. Increment Completion

Optional: Re-analyze on increment done

/sw:done 0046 --update-standards

Usage Examples

Example 1: First-Time Analysis

User: "What are the coding standards for this project?"

Skill: code-standards-analyzer

Actions:
1. Check for existing standards (none found)
2. Parse .eslintrc.json, .prettierrc
3. Analyze 1,234 TypeScript files
4. Detect patterns with 95% confidence
5. Generate standards document

Output:
"✅ Analysis complete! Generated coding standards at:
.specweave/docs/internal/governance/coding-standards-analysis.md

Key findings:
- Naming: 98% camelCase compliance
- Imports: 100% use .js extensions
- Issues: 5 console.* usages, 2 hardcoded secrets
- Recommendation: Formalize detected patterns as official standards"

Example 2: Standards Audit

User: "Check if we're following our declared standards"

Skill: code-standards-analyzer

Actions:
1. Read existing coding-standards.md
2. Analyze current codebase
3. Compare declared vs actual
4. Report violations

Output:
"📊 Standards Compliance: 87%

✅ Passing:
- Naming conventions: 98% compliant
- Import patterns: 100% compliant

⚠️ Violations:
- console.* usage: 12 instances (should be 0)
- Large files: 3 files > 500 lines (should be 0)

Recommendation: Fix violations or update standards to reflect reality"

Example 3: New Contributor Onboarding

User: "I'm new to this codebase. What conventions should I follow?"

Skill: code-standards-analyzer

Actions:
1. Load existing coding-standards.md
2. Extract key rules with examples
3. Highlight SpecWeave-specific patterns

Output:
"📚 Coding Standards Summary

1. Naming:
   - Variables: camelCase (e.g., `userId`, `isActive`)
   - Functions: camelCase (e.g., `getUserById()`)
   - Classes: PascalCase (e.g., `UserService`)

2. Imports:
   - Always use .js extensions
   - Example: import { foo } from './bar.js'

3. Error Handling:
   - Use custom error types
   - Example: throw new UserNotFoundError(id)

4. Logging:
   - NEVER use console.*
   - Use logger abstraction instead

Full standards: .specweave/docs/internal/governance/coding-standards.md"

Commands

Manual Analysis

# Full analysis
/sw:analyze-standards

# Drift detection only
/sw:analyze-standards --drift

# Update existing standards
/sw:analyze-standards --update

Output Files

1.

coding-standards-analysis.md

(Auto-Generated)

Location:

.specweave/docs/internal/governance/coding-standards-analysis.md

Purpose: Latest analysis report (gitignored, temporary)

Contents:

• Detected patterns with confidence levels
• Real code examples
• Statistical evidence
• Violation warnings
• Recommendations

2.

coding-standards.md

(Source of Truth)

Location:

.specweave/docs/internal/governance/coding-standards.md

Purpose: Official coding standards (git-tracked, manual + auto)

Contents:

• Naming conventions
• Import patterns
• Function guidelines
• Type safety rules
• Error handling
• Security practices
• Performance guidelines

3.

coding-standards-history.md

(Change Log)

Location:

.specweave/docs/internal/governance/coding-standards-history.md

Purpose: Track standard evolution over time

Contents:

• Timestamp of each analysis
• Changes detected
• Migration guides
• Rationale for updates

Best Practices

1. Run During Onboarding

• Analyze standards as part of brownfield analysis
• Generate baseline documentation
• Establish project context

2. Periodic Re-Analysis

• Quarterly reviews
• After major refactors
• On team onboarding

3. Team Review Required

• Don't auto-commit changes
• Review generated standards
• Discuss inconsistencies
• Formalize decisions

4. Living Documentation

• Keep standards in sync with code
• Update when patterns change
• Track evolution in history

5. Enforcement Through Tooling

• Most standards → ESLint/Prettier
• This skill → document what tools can't catch
• Focus on SpecWeave-specific patterns

Related Documentation

• Coding Standards - Official standards
• Code Review Standards - Review process
• Brownfield Analyzer - Project analysis

Technical Details

Supported Languages

• ✅ TypeScript (primary)
• ✅ JavaScript (ES6+)
• ✅ Python (pyproject.toml, .pylintrc, ruff.toml, .flake8, mypy.ini)
• ✅ Java/Kotlin (checkstyle.xml, pmd.xml, spotbugs.xml, detekt.yml)
• ✅ Go (go.mod, .golangci.yml, staticcheck.conf)
• ✅ C#/.NET (.editorconfig, StyleCop.json, Directory.Build.props)
• ✅ Rust (rustfmt.toml, clippy.toml, Cargo.toml)
• ✅ React (package.json, ESLint plugin:react/*)
• ✅ Angular (angular.json, ESLint @angular-eslint)
• ✅ Vue (package.json, ESLint plugin:vue/*)
• ✅ Svelte (package.json, svelte.config.js)

Detection Algorithms

Naming Convention Detection:

• Regex pattern matching
• Statistical frequency analysis
• AST node analysis
• Confidence scoring (samples / total)

Anti-Pattern Detection:

• Static analysis (grep, AST parsing)
• Rule-based checks
• Security scanning
• Complexity metrics

Confidence Levels:

• ENFORCED: Linter/compiler enforced (100%)
• HIGH: 90%+ compliance in codebase
• MEDIUM: 70-89% compliance
• LOW: 50-69% compliance
• CONFLICT: <50% compliance (inconsistent)

Limitations

1. Implicit Standards: Requires representative codebase sample
2. False Positives: Anti-pattern detection may flag intentional code
3. Context: Can't understand business rationale for patterns

Multi-Technology Support

Status: ✅ Implemented (increment 0122-multi-technology-governance)

.eslintrc.*

.prettierrc

tsconfig.json

pyproject.toml

.pylintrc

ruff.toml

.flake8

mypy.ini

go.mod

.golangci.yml

staticcheck.conf

checkstyle.xml

pmd.xml

spotbugs.xml

detekt.yml

.editorconfig

StyleCop.json

Directory.Build.props

rustfmt.toml

clippy.toml

Cargo.toml

plugin:react/*

package.json

angular.json

.eslintrc

plugin:vue/*

vite.config.*

svelte.config.js

package.json

Output Structure:

.specweave/docs/internal/governance/
├── coding-standards.md          # Unified summary of ALL technologies
├── shared-conventions.md        # EditorConfig, Git conventions
└── standards/
    ├── typescript.md
    ├── python.md
    ├── golang.md
    ├── java.md
    ├── react.md
    ├── angular.md
    ├── vue.md
    └── svelte.md

Usage:

import {
  detectEcosystems,
  parsePythonStandards,
  parseGoStandards,
  parseJavaStandards,
  parseFrontendStandards,
  generateStandardsMarkdown,
  generateUnifiedSummary
} from 'src/core/living-docs/governance/index.js';

Future Enhancements

• Auto-generate ESLint rules from detected patterns
• AI-powered suggestions from top OSS projects
• Team-specific standards in multi-project mode
• Pre-commit hook integration for enforcement
• Real-time drift alerts
• Standards comparison across projects

Project-Specific Learnings

Before starting work, check for project-specific learnings:

# Check if skill memory exists for this skill
cat .specweave/skill-memories/code-standards-analyzer.md 2>/dev/null || echo "No project learnings yet"

Project learnings are automatically captured by the reflection system when corrections or patterns are identified during development. These learnings help you understand project-specific conventions and past decisions.