write_new_modulelisted

# write_new_module Creating new files is one of the highest-leverage moments in a codebase — good initial structure is far cheaper to maintain than refactoring later. This skill guides you to write new modules that are complete, idiomatic, and fit naturally into the surrounding codebase. ## Before You Write Anything **Read first, write second.** Before creating a new file, scan the codebase for: 1. **A sibling file** — find an existing file that does something similar (e.g., if creating a new service, find an existing service). Read it fully. Mirror its structure, imports, naming conventions, and style. 2. **The module's entry point** — find where your new file will be imported or registered. Understand how it plugs in before writing it. 3. **Project conventions** — check for a `CLAUDE.md`, `README.md`, or `docs/` folder that describes architectural rules. If a linter config (`.eslintrc`, `pyproject.toml`, `clippy.toml`) exists, note any rules that affect code style. If no sibling exists, look one level up (e.g., if creating the first repository in a domain, find any repository in a different domain). ## Structure of a Good New Module Every module, regardless of language, needs: - **A clear single responsibility** — the file name should make its purpose obvious. If you can't name it without using "and", split it. - **Proper imports** — only import what's used; use the project's import ordering convention. - **Public interface at the top** (or clearly separated) — the