Style Codex

The browser measures what your code actually does; the model writes it up and is checked against the counts.

Back to SkillSafe
How it works

Nothing to hand? Load the — a Python service that already agrees with itself, where almost everything becomes a rule — or the , two developers who never settled on tabs or spaces, single or double quotes, semicolons or none. Both replay a saved run for free.

1

Your standards are already in your code — they are just uncounted

Every project has conventions whether or not anyone wrote them down. This reads your files with a real scanner — strings, line comments, block comments, Python triple quotes and JavaScript regex literals each get their own state, so a // inside a string is never mistaken for a comment — and counts nineteen categories: indentation character and width, quote style, statement terminators, brace placement, line length, trailing whitespace, final newline, line endings, naming case for functions, types, constants and locals, comment style, doc comments, blank-line rhythm, import layout, function length and nesting depth.

2

A count is a rule; a tie is a decision you still owe yourself

Where a category has a decisive majority it becomes a rule, stated with the count it came from and every deviating line named by file and number. Where the leading variant is under 60%, or the leaders are exactly tied, it does not: codifying it would make most of the codebase non-conforming overnight. Those go in a separate list with both numbers. Names that carry no evidence about case — a single lowercase word is valid camelCase and valid snake_case at once — are excluded from the tally rather than counted as deviations.

3

The free half is a whole deliverable, not a teaser

With no account and nothing charged, the browser writes the complete standards document, an .editorconfig whose every value is the observed majority with the count in a comment beside it, a CSV with one row per deviation to work through, the same deviations as a checklist you can paste straight into a pull request, and the linter and formatter configs those majorities determine — a .prettierrc, an .eslintrc, ruff and black settings, rustfmt.toml, .clang-format, .gitattributes — so the rule and the thing that enforces it leave together. Nothing in them is a tool default; every value is a count. The metered pass adds what a count cannot: the wording, the ordering, the rationale, the enforcement advice, and the judgement about which conventions are too split to codify at all. Pricing is honest — a worst-case amount is reserved, only what the run uses is charged, and untouched examples replay a saved run free.

4

The document is then held against the numbers, in public

Three things are asserted after every run. Every measured category must be claimed exactly once across the rules and the undecided list — a category two rules both cover is reported as loudly as one no rule covers, because a check that only asks whether something appears somewhere passes both. No rule may contradict its category's measured majority. And any conformance figure the document states that is more than two points from the count is printed as the model wrote it, beside the corrected number — nothing in the parse path quietly repairs a claim before the check can see it. The reconciliation ships inside the downloaded document as an appendix, so a category no rule covered is named in the file the team adopts rather than only on this page. Then adopt it, work through the checklist, re-measure under the same project name, and the app diffs the new conformance against the old one category by category.

A derived work of @github/write-coding-standards-from-file: its method — establish the standards from the existing syntax of the files, categorise the syntax data, count each category, and treat the minority as an inconsistency — is what this measures and writes up. Your files are read in your browser and are never uploaded unless you ask for the writing pass.