self-documenting-codelisted

# Self-documenting code - 0.2.0 candidate Find where production and test code mislead a reader. Return evidence-backed findings, or small clarity edits with check results. One 0.1.0 session on a private TypeScript repository reported eight findings. A loose test helper let a list match a string. A section test accepted an item from a later section. The reader-question rule also stopped two needless edits. Other skills ran alongside it. This is one session, not a measured verdict. ## 1. Set scope and mode Use review mode for findings; do not edit. Use refactor mode when changes are requested. Skip documentation-only work and reviews with no clarity goal. Honor explicit scope. Otherwise use the current diff. If empty, inspect the last commit with `git show --stat HEAD`. State the chosen scope. If no clear target exists, ask. Do not widen scope yourself. Read repo rules, nearby tests, schemas and docs. Mark public names and frozen files. ## 2. Save a baseline Record the revision, `git status --short` and diff. Run focused checks before edits. Record assertion counts for harness changes. Separate existing failures. Mark missing checks and their limits. ## 3. Apply the assessment model Use all seven dimensions. Tests and test helpers are not exempt. | Dimension | Reader question | |---|---| | Vocabulary | Which domain concept is this? | | Contract | What enters, exits and stays true? | | Control flow | What sequence and decisions apply? | | State and units | What state