style-guide

Style Guide

Three modes, sharing one standard:

• draft — adapt references/baseline-style-guide.md into this project's own STYLE-GUIDE.md.
• audit — check written code against the project's drafted guide, or the baseline directly if none has been drafted.
• write — write or edit code following the project's drafted guide, or the baseline directly if none has been drafted.

A project's own drafted guide always wins over the baseline for anything it explicitly states. The baseline fills every gap the project hasn't decided for itself, and — before any guide is drafted — stands in for one entirely: audit and write always have a concrete standard to work from, even in a brand-new repository.

A drafted guide lives at the repository root as STYLE-GUIDE.md by default. If draft wrote it somewhere else, or the project already points to one from AGENTS.md/CLAUDE.md/CONTRIBUTING, audit and write use that location — check for an explicit pointer before assuming no guide exists and falling back to the baseline.

Boundaries

This skill stays in exactly one lane: naming, comments, documentation, logging/error presentation, metadata, tests, and generated-code handling.

• Mechanical formatting is the lint skill's job, and the project's own formatter's job before that. Never restate a rule a linter or formatter config already enforces.
• Quantitative structure — complexity, duplication, dependency shape — is code-health's job.
• Correctness, safety, and behavioural risk are code-review's job.
• A holistic pass that actually changes existing, working code is code-simplifier's job; audit only reports, and write only applies the standard to code already being written for another reason — neither mode goes looking for unrelated code to change.
• A written evidence synthesis for a stakeholder is the report skill's job. draft mode's output is a project artifact developers work from, not a report about one.