ddt-writing-planslisted

# Writing Plans ## Overview Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits. Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well. **Announce at start:** "I'm using the ddt-writing-plans skill to create the implementation plan." **Context:** If working in an isolated worktree, it should have been created via the `disciplined-delivery-toolkit:ddt-using-git-worktrees` skill at execution time. **Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`（DDT SSoT 路径约定：plans 是切片 plan 衍生制品，住 docs/plans/，git 跟踪。不要写 .ddt/plans/ 或其它路径——按 using-ddt 路径地图。） ## Scope Check If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own. ## File Structure Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in. - Design units with clear boundaries and well-defined interfaces. Each file should have one