prizmkit 1.1.0 → 1.1.3

package/bundled/skills/app-planner/SKILL.md

@@ -1,29 +1,32 @@
 ---
 name: "app-planner"
-description: "Interactive planning for both new apps and incremental features on existing apps. This skill should be used whenever users discuss app planning, feature scoping/re-prioritization, continuing a feature plan, or preparing a validated feature-list.json for dev-pipeline execution."
+description: "Plan a new application through interactive conversation — capture vision, tech stack, constraints, and project brief. Use this skill when users say 'plan an app', 'design a new project', 'start from scratch', 'build a new application', or discuss app-level architecture and design. For adding features to existing projects, use feature-planner instead."
 ---
 
-# App Planner
+# app planner
 
-Plan deliverable features for dev-pipeline in two modes:
-- **New App Planning**: create a plan from scratch
-- **Incremental Feature Planning**: append new features to an existing app/plan
+Plan a new application from idea to actionable project context through interactive conversation:
+- Vision and problem statement
+- Tech stack selection
+- Constraints and design direction
+- Architecture decision capture
+- Project brief accumulation (`project-brief.md`)
 
-Always produce a validated `feature-list.json` that conforms to `dev-pipeline-feature-list`.
+This skill captures **what to build and why**. For **feature decomposition and `feature-list.json` generation**, hand off to `feature-planner`.
+
+For adding features to an **existing** project, use `feature-planner` directly.
 
 ## Invocation Commitment (Hard Rule)
 
 **When the user invokes `/app-planner`, you MUST execute the app-planner workflow.** You must NEVER:
 - Decide on the user's behalf that the task "doesn't need app-planner"
 - Skip app-planner to jump directly to spec/plan/implement or any other skill
-- Bypass the interactive phases because you judge the task to be "simple" or "obvious"
+- Bypass the interactive phases because you judge the task to be "simple"
 
-If you believe the task is better suited for a different workflow (e.g., fast path via `/prizmkit-plan`), you MUST:
+If you believe the task is better suited for a different workflow, you MUST:
 1. **Explain why** you think a different path is more appropriate
-2. **Ask the user explicitly** whether they want to switch or continue with app-planner
-3. **Only switch if the user confirms** — otherwise proceed with app-planner as invoked
-
-The user chose this skill intentionally. Respect that choice.
+2. **Ask the user explicitly** whether they want to switch
+3. **Only switch if the user confirms**
 
 ## Scope Boundary (Hard Rule)
 
@@ -31,171 +34,116 @@ The user chose this skill intentionally. Respect that choice.
 - Create, modify, or delete source code files (*.js, *.ts, *.py, *.go, *.html, *.css, etc.)
 - Create project scaffolding, directories, or boilerplate
 - Run build/install/test commands (npm init, pip install, etc.)
-- Execute any implementation action beyond writing `feature-list.json`
+- Execute any implementation action beyond writing planning artifacts
+- Generate `feature-list.json` — that is `feature-planner`'s responsibility
 
 **Your ONLY writable outputs are:**
-1. `feature-list.json` (project root)
-2. Architecture decisions appended to `CLAUDE.md` / `CODEBUDDY.md` (with user consent, see §Architecture Decision Capture)
-3. Draft backups in `.prizmkit/planning/`
-4. `.prizmkit/project-conventions.json` (project convention answers, see §Project Conventions Check)
-5. `project-brief.md` (project root — accumulated project context brief for headless pipeline sessions)
+1. `project-brief.md` (project root — accumulated project context brief)
+2. `.prizmkit/project-conventions.json` (project convention answers)
+3. Architecture decisions appended to `CLAUDE.md` / `CODEBUDDY.md` (with user consent)
+4. Draft backups in `.prizmkit/planning/`
 
 **After planning is complete**, you MUST:
-1. Present the summary and recommended next step
-2. **Ask the user explicitly** whether they want to proceed to execution
-3. If the user agrees → recommend invoking `dev-pipeline-launcher` or running `run.sh` (do NOT execute it yourself)
-4. If the user wants to adjust → continue refining `feature-list.json`
-5. **NEVER auto-execute** the pipeline, launcher, or any implementation step
+1. Present the summary of captured vision, constraints, and decisions
+2. **Ask the user explicitly** whether they want to proceed to feature decomposition
+3. If the user agrees → recommend invoking `feature-planner` to decompose into features and generate `feature-list.json`
+4. If the user wants to continue exploring → stay in app-planner
+5. **NEVER auto-execute** the pipeline, feature-planner, or any implementation step
 
 ## When to Use
 
 Trigger this skill for requests like:
 - "Plan an app", "Design a project", "Design a new application"
-- "Add features to existing system", "Continue planning"
-- "Prepare feature-list.json", "Prepare dev-pipeline input"
-- "Reprioritize features", "Split features"
+- "Start from scratch", "Build something new", "Create a new product"
+- "Help me figure out what to build", "Brainstorm an app idea"
+- "What tech stack should I use?", "Help me choose frameworks"
 
-Do NOT use this skill when the user only wants to run the pipeline (`dev-pipeline-launcher`), is debugging/refactoring, or wants to write source code directly.
+Do NOT use this skill when:
+- The user already has a project and wants to add features → use `feature-planner`
+- The user wants to run the pipeline → use `feature-pipeline-launcher`
+- The user is debugging/refactoring or wants to write source code directly
 
 ## Resource Loading Rules (Mandatory)
 
-1. **Choose scenario reference before planning**:
-   - New app → read `${SKILL_DIR}/references/new-app-planning.md`
-   - Existing app incremental features → read `${SKILL_DIR}/references/incremental-feature-planning.md`
+1. **App design reference** — always load at session start:
+   - Read `${SKILL_DIR}/assets/app-design-guide.md` for vision templates and tech stack matrix
 
-2. **Use shared quality examples as needed**:
-   - read `${SKILL_DIR}/assets/planning-guide.md` for decomposition and acceptance criteria patterns
-
-3. **Load on-demand references when triggered**:
-   - Validation errors or interrupted session → read `${SKILL_DIR}/references/error-recovery.md`
+2. **Load on-demand references when triggered**:
    - Architecture decisions emerged → read `${SKILL_DIR}/references/architecture-decisions.md`
-   - Browser interaction fields needed → read `${SKILL_DIR}/references/browser-interaction.md`
-
-4. **Brainstorm deep-dive** — If the user chooses to continue discussing or exploring ideas before finalizing features (e.g., during Intent Confirmation the user selects "just explore ideas", or at any point says "let's discuss more" / "I want to think through this"):
-   → read `${SKILL_DIR}/references/brainstorm-guide.md` and follow its four-phase structured ideation process (Assess Clarity → Understand → Explore Approaches → Capture Design)
-   → During Phase C (Explore Approaches), also read `${SKILL_DIR}/references/red-team-checklist.md` for adversarial critique of each approach
-   → When brainstorm Phase D produces a "Capture Design" summary, use it as the Vision Summary (fulfilling CP-AP-2) and proceed to Phase 2 (constraints and tech assumptions)
-
-5. **Frontend / UI design check** — Evaluate during Phase 2 (constraints and tech assumptions), after tech stack is confirmed. If the project has a frontend framework:
-   → Check project root for existing UI/UX design docs (scan for files matching: `design-system*`, `style-guide*`, `ui-guide*`, `ux-guide*`, `theme*`)
-   → Also search the active CLI's project instruction file (`CLAUDE.md` / `CODEBUDDY.md`) for keywords: "UI", "UX", "design system", "style guide", "theme", "typography", "color palette"
-   → If unified design guidance is found → use it as constraint for feature descriptions
-   → If NO unified design guidance found → ask user: "项目中未找到统一的 UI/UX 设计规范。是否需要在特性规划前先建立一套 UI/UX 设计方向？(No unified UI/UX design system found. Would you like to establish one before feature planning?)"
-   → If yes → read `${SKILL_DIR}/references/frontend-design-guide.md` and conduct a design direction session. Capture the result in the project instruction file (with user consent).
-   → If no → proceed without; individual features may still define their own UI approach.
-
-6. **Project conventions check** — After Intent Confirmation (CP-AP-0), before brainstorm or Phase 1 vision work. This runs regardless of session goal (produce or explore):
+   - Frontend/UI project detected → read `${SKILL_DIR}/references/frontend-design-guide.md`
+   - User wants to explore ideas before committing → read `${SKILL_DIR}/references/brainstorm-guide.md`
+   - During brainstorm Phase C → also read `${SKILL_DIR}/references/red-team-checklist.md`
+
+3. **Project conventions check** — after Intent Confirmation, before brainstorm or vision work:
    → Read `.prizmkit/project-conventions.json` if it exists
-   → If the file exists but cannot be parsed as valid JSON → warn user ("conventions file is corrupted, will re-ask all questions"), treat all conventions as unanswered
    → Cross-reference with `${SKILL_DIR}/references/project-conventions.md` for the full question list
-   → For any convention with a `null` or missing value → batch all unanswered questions into a single prompt to the user
-   → Save answers to `.prizmkit/project-conventions.json` (create `.prizmkit/` directory if needed — this is an allowed writable output)
-   → If all conventions are already answered → skip silently, do not re-ask
-   → Use convention answers as context when writing feature descriptions and proposing features (see `${SKILL_DIR}/references/project-conventions.md` §How Conventions Are Used)
+   → For any convention with a `null` or missing value → batch all unanswered questions into a single prompt
+   → Save answers to `.prizmkit/project-conventions.json`
+   → If all conventions are already answered → skip silently
 
-7. **Project brief accumulation** — Throughout all interactive phases, accumulate a `project-brief.md` at project root:
-   → Read `${SKILL_DIR}/references/project-brief-guide.md` for the file template, trigger rules, and update rules
-   → Update after each meaningful user response containing business intent, constraints, design decisions, or emphasized details
-   → Verify at CP-AP-5.3 before generating `feature-list.json`
-
-8. **Always validate output via script**:
-   - run:
-     ```bash
-     python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input <output-path> --mode <new|incremental>
-     ```
-
-9. **Use script output as source of truth**:
-   - if validation fails, **MUST** fix and re-run until pass
+4. **Project brief accumulation** — throughout all interactive phases:
+   → Read `${SKILL_DIR}/references/project-brief-guide.md` for template and rules
+   → Update after each meaningful user response containing business intent, constraints, or design decisions
 
 ## Prerequisites
 
 Before questions, check optional context files (never block if absent):
 - `.prizm-docs/root.prizm` (architecture/project context)
 - `.prizmkit/config.json` (existing stack preferences and detected tech stack)
-- `.prizmkit/project-conventions.json` (previously answered project conventions — see §Resource Loading Rules #6)
-- existing `feature-list.json` (required for incremental mode)
+- `.prizmkit/project-conventions.json` (previously answered project conventions)
 - If `.prizm-docs/root.prizm` is absent and the project has existing source code, scan the directory structure to understand the codebase layout:
   ```bash
   find . -maxdepth 2 -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/build/*' -not -path '*/__pycache__/*' -not -path '*/vendor/*' | sed -e 's;[^/]*/;|____;g;s;____|; |;g'
   ```
 
 **Tech stack auto-population from config.json:**
-- If `.prizmkit/config.json` contains a `tech_stack` object, use it to pre-fill `global_context` fields in the generated `feature-list.json`.
-- Map config fields to global_context: `language`, `runtime`, `frontend_framework`, `frontend_styling`, `backend_framework`, `database`, `orm`, `testing` → `testing_strategy`, `bundler`, `project_type`.
-- Do NOT re-ask the user for tech stack info that is already present in config.json. Instead, show the detected stack and ask: "Is this correct? Any changes?"
-- If config.json has no `tech_stack`, fall back to asking during Phase 2 (constraints and tech assumptions).
+- If `.prizmkit/config.json` contains a `tech_stack` object, use it to pre-fill tech assumptions.
+- Map config fields: `language`, `runtime`, `frontend_framework`, `frontend_styling`, `backend_framework`, `database`, `orm`, `testing`, `bundler`, `project_type`.
+- Do NOT re-ask for tech stack info already in config.json. Show the detected stack and ask: "Is this correct? Any changes?"
+- If config.json has no `tech_stack`, fall back to asking during Phase 2.
 
 Note:
 - This skill **reads** `.prizmkit/config.json` if present.
 - This skill does **not** create `.prizmkit/config.json` directly.
 - Creation/update is handled by bootstrap/init flows (e.g., `prizmkit-init`, `dev-pipeline/scripts/init-dev-team.py`).
 
-## Scenario Routing
-
-Classify user intent first:
-
-### Route A: New App Planning
-Use when user starts from idea/blank slate or asks for initial end-to-end plan.
-
-Actions:
-1. Load `${SKILL_DIR}/references/new-app-planning.md`
-2. Run interactive planning phases
-3. Generate initial `feature-list.json`
-
-### Route B: Incremental Feature Planning
-Use when user already has app/code/plan and asks to add or adjust features.
-
-Actions:
-1. Load `${SKILL_DIR}/references/incremental-feature-planning.md`
-2. Read existing `feature-list.json` first (if missing, ask whether to start new plan)
-3. Append features with next sequential `F-NNN` IDs
-4. Preserve style/language/detail consistency with existing plan
-
 ## Intent Confirmation (Mandatory First Step)
 
-After scenario routing, immediately confirm the user's deliverable intent:
+After initial greeting, confirm the user's deliverable intent:
 
 1. **Ask explicitly**:
-   - "本次规划的目标是生成可执行的 `feature-list.json` 吗？还是只想先讨论想法？"
-   - (English: "Is the goal to produce a `feature-list.json` for pipeline execution, or just explore ideas?")
+   - "Is the goal to produce a project plan for eventual pipeline execution, or just explore ideas first?"
 
 2. **Route by answer**:
-   - **"Produce feature-list.json"** → Continue to Core Workflow. Set session goal = `produce`.
+   - **"Produce a plan"** → Continue to Core Workflow. Set session goal = `produce`.
    - **"Just explore ideas"** → Enter **Exploration Mode**:
-     - Run project conventions check first (CP-AP-1) — same as produce mode
+     - Run project conventions check first
      - Load `${SKILL_DIR}/references/brainstorm-guide.md` and follow its structured ideation process (Phases A-D)
      - Brainstorm Phase D output serves as the Vision Summary (CP-AP-2)
-     - Continue with Phase 2 (constraints — including frontend design check CP-AP-3 if applicable), then Phases 3-5 normally
-     - At Phase 5 completion, re-ask: "Ideas are taking shape. Ready to generate `feature-list.json` now?"
-     - If yes → continue to Phase 6
-     - If no → summarize discussion, suggest saving notes, end session
+     - Continue with Phase 2 (constraints — including frontend design check if applicable)
+     - At Phase 2 completion, re-ask: "Ideas are taking shape. Ready to hand off to `feature-planner` for feature decomposition?"
+     - If yes → recommend invoking `feature-planner`
+     - If no → offer to continue exploring (loop back to brainstorm or constraints), or save draft to `.prizmkit/planning/` and exit
 
 3. **Session goal tracking**: Track the intent (`produce` or `explore`) throughout the session. If `explore`, always re-prompt before ending.
 
 ## Core Workflow
 
-Execute the selected scenario workflow in conversation mode with mandatory checkpoints:
+Execute the planning workflow in conversation mode with mandatory checkpoints:
 
 ### Interactive Phases
-1. clarify business goal and scope
-   1.1 confirm deliverable intent (→ Intent Confirmation)
-   1.2 **requirement clarification** — for ANY unclear aspect of the user's vision, goals, target users, or scope, ask questions one at a time (cite the unclear point, give a recommended answer with rationale) until you fully understand. No limit on rounds or number of questions. Do not proceed to Phase 2 with unresolved ambiguities.
-2. confirm constraints and tech assumptions
-3. propose feature set with dependencies
-4. refine descriptions and acceptance criteria
-   4.1 **per-feature clarification** — for each feature, if the description, acceptance criteria, or scope is vague or could be interpreted multiple ways, ask the user to clarify before finalizing. Continue until every feature has unambiguous, implementation-ready details.
-   4.2 **browser interaction** (mandatory for fullstack/frontend projects) — see §Browser Interaction Planning below. Qualifying features get `browser_interaction` by default. Only confirm with the user as a batch summary; do NOT ask per-feature.
-5. verify DAG/order/priorities
-6. build or append `feature-list.json`
-7. apply default testing strategy (see §Testing Defaults below)
-8. validate and fix until pass
-9. summarize final feature table
+1. Clarify business goal and scope
+   1.1 Confirm deliverable intent (→ Intent Confirmation)
+   1.2 **Requirement clarification** — for ANY unclear aspect of the user's vision, goals, target users, or scope, ask questions one at a time until fully understood. No limit on rounds. Do not proceed to Phase 2 with unresolved ambiguities.
+2. Confirm constraints and tech assumptions
+   2.1 Tech stack selection — use `${SKILL_DIR}/assets/app-design-guide.md` §2 decision matrix
+   2.2 **Frontend design check** (for frontend projects) — scan for existing UI/UX design docs. If none found, ask user if they want to establish design direction via `${SKILL_DIR}/references/frontend-design-guide.md`
+3. Capture architecture decisions and finalize project brief
+4. Hand off to `feature-planner` for feature decomposition
 
 ### Checkpoints (Mandatory Gates)
 
-Checkpoints catch cascading errors early — skipping one means the next phase builds on unvalidated assumptions, which compounds into much harder debugging later.
-
-Note: Checkpoint numbers (CP-AP-N) are sequential identifiers for the gate, NOT phase numbers. See the "Phase" column for the corresponding workflow phase.
+Checkpoints catch cascading errors early — skipping one means the next phase builds on unvalidated assumptions.
 
 | Checkpoint | Artifact/State | Criteria | Phase |
 |-----------|----------------|----------|-------|
@@ -203,227 +151,64 @@ Note: Checkpoint numbers (CP-AP-N) are sequential identifiers for the gate, NOT
 | **CP-AP-1** | Conventions Checked | Project conventions loaded or asked; `.prizmkit/project-conventions.json` up to date | 1 |
 | **CP-AP-2** | Vision Summary | Goal/users/differentiators confirmed by user | 1-2 |
 | **CP-AP-3** | Frontend Design Evaluated | For frontend projects: checked for existing UI/UX design system; user was asked if missing | 2 |
-| **CP-AP-4** | Feature Proposals | Feature set with titles+deps identified (pre-validation) | 3-5 |
-| **CP-AP-5** | DAG Validity | No cycles, dependencies resolved (validation dry-run) | 5 |
-| **CP-AP-5.1** | Browser Interaction Applied | Qualifying features have `browser_interaction` field; user confirmed or opted out | 4 |
-| **CP-AP-5.2** | Testing Defaults Applied | All features have appropriate `critic`, `critic_count`, and testing expectations per §Testing Defaults | 7 |
-| **CP-AP-5.3** | Project Brief Accumulated | `project-brief.md` exists at project root with Vision + at least one other section | 5 |
-| **CP-AP-6** | `feature-list.json` Generated | Schema validates, all required keys present | 6-7 |
-| **CP-AP-7** | Final Validation Pass | Python script returns `"valid": true` with zero errors | 8 |
-
-**Resume Detection**: If existing artifacts are found, read `${SKILL_DIR}/references/error-recovery.md` §Resume Support for checkpoint-based resumption.
+| **CP-AP-4** | Project Brief Accumulated | `project-brief.md` exists at project root with at least 3 ideas listed | 3 |
+| **CP-AP-5** | Handoff Ready | All app-level context captured; user confirmed readiness for feature decomposition | 4 |
 
 ## Architecture Decision Capture
 
-After Phase 5, if framework-shaping architecture decisions emerged during planning (tech stack, communication patterns, data model strategies — not individual feature details), read `${SKILL_DIR}/references/architecture-decisions.md` and follow the capture flow. Most sessions will NOT produce architecture decisions — only capture when genuinely impactful.
-
-## Fast Path — Incremental Shortcuts
-
-For simple incremental planning, skip detailed Phase 2-3 analysis to accelerate delivery:
-
-### Eligibility Criteria (ALL must apply)
-- **Incremental mode only** — not new app planning
-- **Adding 1-2 features max** to existing plan
-- **Each feature**: ≤5 acceptance criteria, <100 words description
-- **Dependencies**: depends on ≤2 existing features (no chains)
-- **Complexity**: "low" or "medium" only
-- **No architectural changes** to existing tech stack
-
-### Fast Path Workflow
-1. Read existing `feature-list.json` and confirm scope
-2. **User confirmation (mandatory)** — Tell the user: "This qualifies for fast-path (simple incremental addition). Skip detailed Phase 2-3 analysis and draft directly? Or use full workflow?" Only proceed with fast path if user confirms.
-3. Generate next sequential feature IDs
-4. Draft features (title + description + acceptance_criteria + dependencies)
-5. Run validation script immediately
-6. If valid → summarize and recommend next step
-7. If invalid → apply fixes, re-validate (max 2 attempts, then escalate to full workflow)
-
-### When NOT to Use Fast Path
-- New app planning (always use full workflow)
-- Adding >2 features in one session
-- Features with complex interdependencies (>2 dependencies)
-- High complexity features requiring architecture decisions
-- Changes affecting >3 existing features
-
-### Example Fast Path Session
-```
-User: "Add email verification to existing user module."
-AI: [Detects incremental mode]
-AI: [Checks existing plan: found 8 features, user module exists]
-AI: [Qualifies for fast path: 1 feature, low complexity, ≤2 deps]
-AI: "This qualifies for fast-path. Skip detailed analysis and draft directly? Or use full workflow?"
-User: "Fast path is fine."
-AI: "Drafting F-009..."
-AI: [Validates immediately]
-AI: "Ready to proceed to dev-pipeline."
-```
-
-## Browser Interaction Planning
-
-For fullstack/frontend projects, qualifying features get `browser_interaction` **by default**. This is not opt-in — it is the standard.
-
-### Auto-Detection Rule
-
-A feature **qualifies** for browser interaction when ALL of these are true:
-1. `global_context.frontend_framework` exists (project has a frontend)
-2. The feature's `acceptance_criteria` contain UI-related keywords: click, button, modal, page, form, display, navigate, tab, input, opens, shows, renders, visible, redirect, download, upload, preview, select, toggle, dropdown, popup, toast, menu
-
-A feature is **exempt** when ANY of these are true:
-- It is backend-only (API endpoints, database migrations, no UI criteria)
-- It is config/setup/infrastructure
-- It has `status: "completed"` (already implemented)
-
-### Default Behavior (Phase 4.2)
-
-1. **Auto-generate** `browser_interaction` for ALL qualifying features. Read `${SKILL_DIR}/references/browser-interaction.md` for the object format and field rules.
-2. **Present a summary** to the user showing which features received `browser_interaction`:
-   > "以下 N 个前端特性已自动添加 browser_interaction 用于 Playwright 自动验证：F-002, F-004, F-007。如需移除某个特性的浏览器验证，请告知。"
-3. **User can opt-OUT** specific features — remove the field for declined features.
-4. If **user opts out entirely** ("remove all browser verification") → remove all fields and record the decision.
-
-**You must NOT skip this step for qualifying features.** The checkpoint CP-AP-5.1 verifies this step was completed.
-
-### When NOT to add
-
-**Do NOT add for**: backend-only features, config/setup features, or non-UI features. These are automatically exempt.
-
-## Output Rules
+After Phase 2, if framework-shaping architecture decisions emerged during planning (tech stack, communication patterns, data model strategies — not individual feature details), read `${SKILL_DIR}/references/architecture-decisions.md` and follow the capture flow. Most sessions will NOT produce architecture decisions — only capture when genuinely impactful.
 
-`feature-list.json` must satisfy:
-- `$schema` = `dev-pipeline-feature-list-v1`
-- non-empty `features`
-- sequential feature IDs (`F-001`, `F-002`, ...)
-- valid dependency DAG
-- `priority` must be a string: `"high"`, `"medium"`, or `"low"` (NOT numeric values like 1/2/3)
-- new items default `status: "pending"`
-- English feature titles for stable slug generation
-- `model` field is optional — omitting it means the pipeline uses $MODEL env or CLI default
-- `critic` field defaults based on priority: `true` for high/medium priority features, `false` for low. User can override.
-- `critic_count` field defaults based on priority: `3` (multi-critic voting) for high priority, `1` (single critic) for medium. User can override.
-- `browser_interaction` field is auto-generated for qualifying frontend features (see §Browser Interaction Planning). Requires `playwright-cli` to be installed.
-- **descriptions must be implementation-ready** — minimum 15 words (error), recommended 30/50/80 words for low/medium/high complexity (warning). See `planning-guide.md` §4 for what to include.
-
-## Testing Defaults (Phase 7)
-
-All three testing mechanisms are **enabled by default** to maximize quality. The user can opt out of any mechanism, but the default is comprehensive testing.
-
-### 1. Test File Generation (TDD)
-
-Every feature is expected to include tests. When writing feature descriptions, explicitly state testing expectations:
-
-| Complexity | Default Testing Expectation |
-|------------|----------------------------|
-| low | Unit tests for core logic |
-| medium | Unit tests + integration tests for key flows |
-| high | Unit tests + integration tests + edge case coverage |
-
-**In the feature description**, include a line like:
-- "Include unit tests for [key functions/modules]."
-- "Include integration tests verifying [API endpoints / data flows]."
-
-This ensures the downstream `prizmkit-implement` skill (which uses TDD) has clear guidance on what tests to write.
-
-### 2. Browser Verification (Playwright)
-
-See §Browser Interaction Planning above. Default: **ON** for all qualifying frontend features.
-
-### 3. Adversarial Critic Review (Multi-Agent)
-
-Default assignments based on feature priority:
-
-| Priority | `critic` | `critic_count` | Rationale |
-|----------|----------|----------------|-----------|
-| high | `true` | `3` | Multi-critic voting — catches more issues for critical features |
-| medium | `true` | `1` | Single critic review — balanced cost/quality |
-| low | `false` | (omitted) | Skip critic — simple features don't warrant the overhead |
-
-After applying defaults, present a summary to the user:
-> "已为 N 个 high/medium 优先级特性启用代码评审 (critic)：high 优先级使用 3-agent 投票模式，medium 使用单 agent 评审。如需调整请告知。"
-
-The user can override any assignment (enable/disable critic, change critic_count) before finalizing.
+## Project Brief Accumulation
 
-### Summary Presentation
+During interactive planning, maintain a `project-brief.md` at the project root as a simple checklist of product ideas.
 
-At Phase 7, present a consolidated testing summary table:
+→ Read `${SKILL_DIR}/references/project-brief-guide.md` for full format and rules.
 
+**Format**: One idea per line, each starting with `[ ]`. Example:
 ```
-Feature    | TDD Tests        | Playwright | Critic
-F-001      | unit             | —          | —
-F-002      | unit+integration | ✓          | 3-agent
-F-003      | unit+integration | ✓          | 1-agent
-F-004      | unit             | —          | —
-```
-
-Ask: "以上是各特性的默认测试配置。如需调整请告知，否则将按此配置生成 feature-list.json。"
-
-## Next-Step Execution Policy (after planning)
-
-Recommend these three options in this strict order:
-
-1. **Preferred**: invoke `dev-pipeline-launcher` skill (natural-language handoff)
-2. **Fallback A**: run daemon wrapper
-   ```bash
-   ./dev-pipeline/launch-daemon.sh start feature-list.json
-   ./dev-pipeline/launch-daemon.sh status
-   ```
-3. **Fallback B**: run direct foreground script
-   ```bash
-   ./dev-pipeline/run.sh run
-   ./dev-pipeline/run.sh status
-   ```
-
-When launcher is available, do not prioritize raw scripts.
+# Project Brief
 
-## Error Recovery & Resume
+[x] 表示构想已在某个 feature 中实现完成
 
-If validation fails or a session is interrupted → read `${SKILL_DIR}/references/error-recovery.md` for the full error type table, decision tree, retry logic, and checkpoint-based resume support.
+--------
 
-Key behaviors:
-- Warnings only → proceed with user approval
-- Critical errors → group by type, auto-fix where possible, max 3 total attempts
-- Interrupted session → detect checkpoint from existing artifacts, offer resume or restart
-- `feature-list.json` MUST be written to project root (same level as `package.json` / `.git`)
-
-## Project Brief Accumulation
-
-During interactive planning, maintain a `project-brief.md` at the project root that distills the user's key requirements, design decisions, and context for headless pipeline sessions.
-
-→ Read `${SKILL_DIR}/references/project-brief-guide.md` for the file template, accumulation trigger, update rules, and examples.
+[ ] B2B SaaS 餐饮库存管理平台，面向中小连锁餐厅
+[ ] 核心价值：通过预测性订货减少 30% 食物浪费
+[ ] 必须支持 iPad Safari 离线模式
+```
 
-**Key rules** (full details in guide):
-- Update after each meaningful user response that contains business intent, constraints, design decisions, or emphasized details
-- Fixed 4-section structure: Vision, Core Constraints, Design Decisions, Key Requirements
-- Max 500 words; one sentence per bullet
-- Checkpoint **CP-AP-5.3**: must exist with Vision + at least one other populated section before CP-AP-6
+**Key rules**:
+- After each meaningful user response → append a new `[ ]` line
+- One idea, one sentence per line — no paragraphs
+- Max 500 words total
+- Must have at least 3 ideas listed before CP-AP-4
+- The pipeline will mark `[x]` and append file paths when features are implemented
 
 ## Session Exit Gate
 
-Prevent accidental session exit without deliverable completion.
+Prevent accidental session exit without completing the planning artifacts.
 
 ### Trigger Conditions
 
-Activate exit gate when ALL of these are true:
-- Session goal = `produce` (user confirmed they want feature-list.json via CP-AP-0)
-- Current phase < Phase 7 (final validation not yet passed)
-- No valid `feature-list.json` has been written in this session
+Activate when ALL true:
+- Session goal = `produce`
+- `project-brief.md` has not been written or is incomplete (Vision section missing)
+- No architecture decisions captured yet (if any emerged)
 
 ### Gate Behavior
 
-When the session appears to be ending (user says "thanks", "that's all", "bye", or conversation goes idle after Phase 3+):
-
-1. **Remind**: "You set out to produce `feature-list.json` but we haven't completed it yet."
+When the session appears to be ending:
+1. **Remind**: "You set out to produce a project plan but `project-brief.md` isn't complete yet."
 2. **Offer 3 options**:
-   - **(a) Continue to completion** — resume from current phase
-   - **(b) Save draft & exit** — write current progress as draft, exit session
+   - **(a) Continue to completion**
+   - **(b) Save draft & exit** — write current progress as draft to `.prizmkit/planning/`
    - **(c) Abandon** — exit without saving
-3. **If (b)**: Write the draft file and remind user: "This is a draft, not validated. Run `/app-planner` again to resume and finalize."
-4. **If (c)**: Accept without further prompting.
 
+## Handoff to feature-planner
 
-## Handoff Message Template
+After all checkpoints pass, present a summary and recommend next steps:
 
-After successful validation, report:
-1. output file path
-2. total features + newly added features
-3. dependency and priority highlights
-4. recommended next action: `dev-pipeline-launcher`
+1. **Summary**: List captured vision, tech stack, constraints, architecture decisions, and project brief status
+2. **Primary recommendation**: Invoke `feature-planner` to decompose the application into features and generate `feature-list.json`
+3. **Alternative**: If the user wants to continue refining the vision or constraints, stay in app-planner
+4. **Artifacts produced**: List files written (`project-brief.md`, `.prizmkit/project-conventions.json`, architecture decisions if any)