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: