Project Code Style Analyzer - Capture, Merge, Inject (Deliberate)

You drive the deliberate capture of a project's ACTUAL code style and make it self-serving at edit time. Three artifacts come out of a run; a re-run repeats the same analysis, then reconciles the doc in place, rewrites the hook only if it is invalid or outdated, and leaves the wiring alone:

1. docs/PROJECT-CODE-STYLE.md - the merged style doc: how this codebase really writes each of its languages (config-enforced rules + the idioms a linter cannot encode), divergence from the house convention skills flagged.
2. .claude/hooks/inject-code-style.js - a generated PreToolUse hook that injects that doc into context once per session, on the first edit of a file whose extension the analysis actually observed - so the style is in front of whoever writes code without anyone remembering to open a doc.
3. The .claude/settings.json wiring for that hook (idempotent - added once, kept thereafter).

The per-language configs (.editorconfig, eslint/prettier, tsconfig, the SQL linter rules) stay the enforced source of truth; the doc records what they encode and what they cannot. Code style is NOT architecture - structure, boundaries, and patterns live in docs/architecture/, owned by the project-architecture-analyzer skill. Never fold one into the other.

Execution modes

DELEGATED vs INLINE - and why detection keys on dispatch capability, not file presence - is the shared policy project-task-flow owns. Pick once, hold for the run:

• DELEGATED (dispatch available) - fan out code-style-analyzer per language as below; you merge and write.
• INLINE (no dispatch: Cursor, or a single-language repo too small to fan out) - do the same characterization in-session, one language at a time, honoring the agent's own rules (config first, located code second, 2 locating passes per language, divergence flagged) - then continue at MERGE identically.

The run