Merge pull request #337 from hiyochi/fix/plan-output-path-in-skill

fix: add tasks/plan.md and tasks/todo.md output paths to planning skills

skills/planning-and-task-breakdown/SKILL.md

@@ -30,7 +30,7 @@ Before writing any code, operate in read-only mode:
 - Map dependencies between components
 - Note risks and unknowns
 
-**Do NOT write code during planning.** The output is a plan document, not implementation.
+**Do NOT write code during planning.** The output is a plan document saved to `tasks/plan.md` and a task list saved to `tasks/todo.md`, not implementation.
 
 ### Step 2: Identify the Dependency Graph
 
@@ -140,6 +140,13 @@ If a task is L or larger, it should be broken into smaller tasks. An agent perfo
 - It touches two or more independent subsystems (e.g., auth and billing)
 - You find yourself writing "and" in the task title (a sign it is two tasks)
 
+## Output Files
+
+- **Plan document:** Save the implementation plan to `tasks/plan.md`.
+- **Task list:** Save the checklist-style task list to `tasks/todo.md`.
+
+Create the `tasks/` directory if it does not exist. These paths are the convention expected by the `/build` command and other downstream tooling.
+
 ## Plan Document Template
 
 ```markdown

skills/spec-driven-development/SKILL.md

@@ -139,6 +139,8 @@ With the validated spec, generate a technical implementation plan:
 5. Define verification checkpoints between phases
 
 > Follow `planning-and-task-breakdown` for the dependency-graph mapping and vertical-slicing mechanics behind these steps; it is the canonical source. The bullets above are a lightweight summary; if they ever diverge, `planning-and-task-breakdown` takes precedence.
+>
+> **Output convention:** Save the plan to `tasks/plan.md` and the task list to `tasks/todo.md`, per the `/plan` command convention. Create `tasks/` if it does not exist. Downstream commands (`/build`, etc.) expect these paths.
 
 The plan should be reviewable: the human should be able to read it and say "yes, that's the right approach" or "no, change X."