@tianhai/pi-workflow-kit 0.17.1 → 0.18.1

package/skills/{writing-plans → pwk-writing-plans}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: writing-plans
+name: pwk-writing-plans
 description: "Use this to break a design into an implementation plan with bite-sized TDD tasks. Works with or without a prior brainstorm. Use this skill when the user says 'let's plan', 'break this down', 'write a plan', 'create tasks', or after a brainstorm session when they want to move to implementation. Also use when the user has a clear idea and wants to jump straight to a structured plan."
 ---
 
@@ -11,7 +11,9 @@ You may only create or edit files under `docs/plans/`. Do not modify source code
 
 1. **Check for a design doc** — look for `docs/plans/*-design.md`. If one exists, use it as the basis for the plan. If the design doc is incomplete, fill gaps by asking the human. If no design doc exists, ask the user to describe what they want to build and read relevant code. **Read `docs/lessons.md`** if it exists — incorporate known patterns into the task breakdown (e.g., if a lesson says "always run lint before commit," include that in relevant task instructions).
 
-   Then evaluate whether the design — whether from the design doc or from the user's description and codebase exploration — involves any of the following:
+   If the design doc has a `## Features` table, read it to identify the next feature with status `⬜ pending`. Mark that feature as `🔄 planned` by editing the design doc. This plan will cover only that one feature. If the design doc has no Features table, plan the entire design as before.
+
+   Then evaluate whether the feature — whether from the design doc or from the user's description and codebase exploration — involves any of the following:
 
    - Database schema changes or migrations
    - Authentication or authorization logic
@@ -20,10 +22,21 @@ You may only create or edit files under `docs/plans/`. Do not modify source code
    - File uploads or large data flows
    - Redis, caching, or message queues
 
-   If any apply AND the design doc does not already have an `## Architectural Review` section, prompt the user: "This design involves [list what you found] but hasn't been reviewed for production risks. Run `/skill:design-review` first, or type 'proceed' to skip."
+   If any apply, prompt the user: "This feature involves [list what you found] but hasn't been reviewed for production risks. Run `/skill:pwk-design-review` first, or type 'proceed' to skip."
 
    If the design doc explicitly notes "Simple change — no design review needed", skip this check.
-2. **Write the implementation plan** — break the design into tasks. Save to `docs/plans/YYYY-MM-DD-<topic>-implementation.md`. If the design is too large for ~15 tasks, flag this to the human and ask whether to reduce scope or proceed with the full plan.
+2. **Write the implementation plan** — break the feature into tasks. Save to `docs/plans/YYYY-MM-DD-<topic>-<feature-name>-implementation.md` (derive `<feature-name>` from the feature's name in the table, slugified). If the design doc has no Features table, use `docs/plans/YYYY-MM-DD-<topic>-implementation.md`. Include metadata at the top of the plan doc so the executor can find the design doc and feature row:
+
+   ```markdown
+   # Implementation Plan: <feature name>
+
+   ## Overview
+
+   Design: docs/plans/YYYY-MM-DD-<topic>-design.md
+   Feature: <feature name> (row N in Features table)
+   ```
+
+   If the design is too large for ~15 tasks for a single feature, flag this to the human and ask whether to reduce scope or proceed with the full plan.
 3. **Present the plan** — show the complete plan to the human. Wait for approval before suggesting execution.
 
    Before presenting, run the **Plan Acceptance Audit**:
@@ -31,7 +44,7 @@ You may only create or edit files under `docs/plans/`. Do not modify source code
    - **Task Sizing**: Is any single task too large or covering multiple complex behaviors? If so, split it.
    - **QA Coverage**: Does every task have both a Happy Path and at least one Edge Case in its Acceptance Criteria?
    - **Checkpoint Alignment**: Are `checkpoint: test` and `checkpoint: done` gates placed on the most critical or risky tasks?
-   - **Risk Enforcement**: If the design doc's Architectural Review section flagged any hazards as `[TRIGGERED]`, verify the corresponding tasks have `checkpoint: done` and a `Hazard Mitigation Verification` section.
+   - **Risk Enforcement**: If this plan doc's Architectural Review section flagged any hazards as `[TRIGGERED]`, verify the corresponding tasks have `checkpoint: done` and a `Hazard Mitigation Verification` section.
 
    If any check fails, fix the plan before presenting.
 
@@ -289,7 +302,9 @@ Use judgment when assigning checkpoints. Prefer `checkpoint: test` for new featu
 
 ## After the plan
 
-Ask: "Ready to execute? Run `/skill:executing-tasks`"
+Ask: "Ready to execute? Run `/skill:pwk-executing-tasks`"
+
+> After executing this feature, the executor will check for more `⬜ pending` features and suggest planning the next one.
 
 ## Behavioral Guidelines