speclisted

# spec: as much process as the change deserves, and no more ## 1. Pick the tier: argue it, don't default upward - **S: no spec.** Small, clear, reversible: bugfix, copy change, config tweak, single-file change with obvious behavior. The commit message and a test are the record. If you're explaining the tier choice in more than a sentence, it isn't S. - **M: spec.md only.** A feature or change in one area, buildable in a session or two. - **L: spec.md + plan.md.** Multi-session, multi-area, risky, or contested. Copy `docs/specs/TEMPLATE-PLAN.md` to plan.md: build order (owned by the ticket graph), seams/interfaces touched, migration/rollback, verification approach. Two honest tests: *Would a senior write this down first?* and *Will anyone need to know why in three months?* Yes to either → at least M. ## 2. Tier M and L: interview before writing Build shared understanding first; a finished draft the owner can only react to is not that. Tier S is exempt: a bugfix gets no interview. The rules: - **One question at a time.** Each question comes with your recommended answer and a one-line reason, so the owner can accept the default or push back cheaply. - **Recommendations are argued, not agreeable.** A question with a real design choice behind it gets the `critical-thinking` moves first: the recommendation names the alternative it beat. - **Facts are looked up, never asked.** Whatever the repo, the docs, or the code can answer, you answer yourself before asking