Code Quality

# Code Quality Skill

## Purpose
Enable coding agents to learn and enforce project-specific code quality patterns via automated scanning, config discovery, conflict resolution, and persisted outputs.

## When to use
- User asks for code quality, coding patterns, style guide, conventions, consistency, linting rules, or code standards.
- Before generating code to align with existing patterns.
- After detecting inconsistent patterns or conflicting configs.
- During greenfield setup to seed best-practice configs.

## Inputs
- Root directory (default: workspace root).
- Optional: directories or glob patterns to scan; resume_from agentId for resumable runs; thoroughness (quick|medium|thorough).

## Outputs
- Pattern report (patterns.md)
- Generated/merged .code-quality.json
- Optional linter rule suggestions (e.g., ESLint flat config fragment)
- Conflict MCQs when confidence is medium or conflicting

## OS detection (run once per session)
- Unix/macOS: `uname -s` => Linux/Darwin; prefer bash/zsh; use jq for JSON if available.
- Windows: `$env:OS` => Windows_NT; use PowerShell JSON cmdlets.
- If jq is unavailable on Unix, fall back to Node.js one-liner merges.

## Workflow
1) Configuration discovery (config-reader)
   - Scan for ESLint, Prettier, EditorConfig, TSConfig, pyproject, etc.
   - Normalize rules; detect conflicts (indent, semi, quotes, line endings, strictness).
2) Distributed pattern scanning (pattern-scanner)
   - For each major directory (src, lib, apps, packages, tests): spawn haiku agent.
   - Collect occurrences, locations, examples by category (naming, imports, api_calls, state_management, component_structure, error_handling, testing, documentation).
3) Consolidation
   - Merge pattern data; compute scores (frequency, consistency_ratio, recency_weight, author_distribution).
   - Tag confidence tier: High (>=5 and >90%), Medium (>=5 and 70-90%), Low (<5 or <70%), Conflicting (multiple patterns with 5+ each).
4) Conflict handling
   - If conflicts or medium confidence: invoke conflict-resolver (sonnet) to craft MCQs with pros/cons and recommended option.
   - Offer Dig Deeper when 5+ variations exist.
5) Output generation
   - Write patterns.md using template.
   - Write or merge .code-quality.json (version 1.0) with confirmed/detected/custom patterns, custom_rules, excluded_paths, integrations.
   - Surface recommended linter/formatter rules aligned to configs and patterns.

## Resumable sessions
- Each pattern-scanner returns agent_id and optional checkpoint. Resume with resume_from.

## Best-practice source priority
1) User-defined (.code-quality.json custom_rules)
2) Project configs (EditorConfig > ESLint > Prettier > TSConfig > language-specific)
3) Detected patterns (high confidence)
4) Model inference for stack version
5) (Future) remote curated libraries

## Interaction rules
- Do not modify source files; operate read-only except when writing outputs.
- Prefer MCQ when confidence is medium or conflicts detected; auto-apply only for high confidence.
- Respect contextual boundaries (auth vs public, tests vs prod, components vs utils).
- Persist user decisions into .code-quality.json.

## File conventions
- Outputs live at repo root unless user specifies otherwise.
- Exclude node_modules, dist, build, coverage, .git by default.

## Error handling
- If config parse fails, report file and rule; continue scanning others.
- If no patterns detected (<100 LOC), switch to greenfield flow and propose best-practice bundle.