project-conventionslisted

# project-conventions The operator has to make a handful of structural decisions on every new project that are not about secrets: which branch do I work on, where do files go, do I pin dependencies, how do I avoid hardcoding my home directory into source. Each one is a small tax on attention. Most of them have one answer that works for 95% of projects. This skill pre-pays that tax with one opinionated answer per question. The high-stakes slice — secrets, `.env`, secret-shaped gitignore entries, CI secret stores — lives in `manage-secrets-env`. Split this way so the operator can trigger the right depth of care for the right question. **The principle**: the best convention is the one the operator doesn't have to invent. When they ask *"should I make a dev branch?"*, answer in one sentence and move on. Don't present a decision framework; make the decision. ## State assumptions — before acting Before starting the procedure, write an explicit Assumptions block. Don't pick silently between interpretations; surface the choice. If any assumption is wrong or ambiguous, pause and ask — do not proceed on a guess. Required block: ``` Assumptions: - Project maturity: <new scaffold | active repo under audit | legacy repo with historical conventions to respect> - Branch strategy: <GitHub Flow (main only) | main + dev | trunk-based | other — detected from CONTRIBUTING.md / recent branches> - Pinning strategy: <exact-pin + lockfile | caret-range | no lockfile | mixed per-package (m