plannewlisted

# Planning a change > `$KB` is your knowledge-base root: a directory outside the working repo holding > `<project>/specs/`, `<project>/plans/` and `<project>/checkpoints/`. Point at it from > your CLAUDE.md. Keeping these out of the repo keeps process artifacts from leaking > into it, and the knowledge survives clones, branches and machines. Produces two files in the knowledge base and nothing else. **No implementation code is written in this skill.** Stop and say so if the change is small or mechanical (a bug fix, a one-file tweak, a rename). Those do not need a plan. ## 0. Locate the project Project name is the repo's folder name, lowercase kebab-case. Everything lands under `$KB/<project>/`. Pick a slug now (kebab-case, describes the change, no date). The spec, the plan, and every checkpoint share it. ## 1. Q&A before anything else Ask the user about what is underspecified. Use `AskUserQuestion` for real forks; plain prose for open questions. Batch related questions rather than drip-feeding them. Ask about: the actual problem being solved, scope boundaries (what is explicitly *not* in this change), constraints, what "done" looks like, and anything the codebase cannot tell you. Do not assume and do not proceed on a guess. If two readings of the request lead to materially different work, that is a question, not a judgment call. ## 2. Understand what exists For a brownfield change, dispatch `feature-dev:code-explorer` with a specific question - the feature to trac