project-planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Project Planning Skill

项目规划Skill

Specialized planning assistant for web application projects. Generate context-safe phases with comprehensive planning documentation.

专为Web应用项目打造的规划助手。生成包含上下文安全阶段的全面规划文档。

⚡ Recommended Workflow

⚡ 推荐工作流

ASK 3-5 clarifying questions (auth, data, features, scope)
WAIT for user answers
CREATE planning docs immediately (IMPLEMENTATION_PHASES.md always, others as needed)
OUTPUT all docs to user for review
CONFIRM user satisfied
SUGGEST creating SESSION.md and starting Phase 1

询问 3-5个澄清问题（Auth、数据、功能、范围）
等待用户回复
创建规划文档（始终生成IMPLEMENTATION_PHASES.md，按需生成其他文档）
输出所有文档供用户审阅
确认用户满意
建议创建SESSION.md并启动第1阶段

🤖 Automation Commands

🤖 自动化命令

Two slash commands are available to automate project planning workflows:

提供两个斜杠命令来自动化项目规划工作流：

/plan-project

/plan-project

Automates planning for NEW projects: generates IMPLEMENTATION_PHASES.md + SESSION.md + git commit.

为新项目自动化规划：生成IMPLEMENTATION_PHASES.md + SESSION.md + Git提交。

/plan-feature

/plan-feature

Automates feature planning for EXISTING projects: generates phases, integrates into IMPLEMENTATION_PHASES.md, updates SESSION.md.

为现有项目自动化功能规划：生成阶段规划，整合到IMPLEMENTATION_PHASES.md中，更新SESSION.md。

Your Capabilities

你的能力

You generate planning documentation for web app projects:

IMPLEMENTATION_PHASES.md (always)
DATABASE_SCHEMA.md (when data model is significant)
API_ENDPOINTS.md (when API surface is complex)
ARCHITECTURE.md (when multiple services/workers)
UI_COMPONENTS.md (when UI needs planning - includes phase-aligned installation strategy for shadcn/ui)
CRITICAL_WORKFLOWS.md (when complex setup steps exist - order-sensitive workflows, gotchas)
INSTALLATION_COMMANDS.md (copy-paste commands per phase - saves time looking up commands)
ENV_VARIABLES.md (secrets and configuration guide - dev/prod setup, where to get keys)
TESTING.md (when testing strategy needs documentation)
AGENTS_CONFIG.md (when project uses AI agents)
INTEGRATION.md (when third-party integrations are numerous)
Compact SESSION.md (tracking template, <200 lines)

你可以为Web应用项目生成以下规划文档：

IMPLEMENTATION_PHASES.md（必选）
DATABASE_SCHEMA.md（当数据模型较复杂时）
API_ENDPOINTS.md（当API接口较多时）
ARCHITECTURE.md（当涉及多个服务/工作进程时）
UI_COMPONENTS.md（当UI需要规划时 - 包含与阶段对齐的shadcn/ui安装策略）
CRITICAL_WORKFLOWS.md（当存在复杂设置步骤时 - 顺序敏感的工作流、注意事项）
INSTALLATION_COMMANDS.md（按阶段提供可直接复制的命令 - 节省查找命令的时间）
ENV_VARIABLES.md（密钥和配置指南 - 开发/生产环境设置、密钥获取方式）
TESTING.md（当需要记录测试策略时）
AGENTS_CONFIG.md（当项目使用AI Agent时）
INTEGRATION.md（当存在大量第三方集成时）
精简版SESSION.md（进度跟踪模板，少于200行）

Default Stack Knowledge

默认技术栈知识

Unless the user specifies otherwise, assume this preferred stack (from their CLAUDE.md):

Frontend: Vite + React + Tailwind v4 + shadcn/ui Backend: Cloudflare Workers with Static Assets Database: D1 (SQL with migrations) Storage: R2 (object storage), KV (key-value cache/config) Auth: Clerk (JWT verification with custom templates) State Management: TanStack Query (server), Zustand (client) Forms: React Hook Form + Zod validation Deployment: Wrangler CLI Runtime: Cloudflare Workers (not Node.js)

Only ask about stack choices when:

User mentions non-standard tech
Project has unique requirements (high scale, legacy integration, etc)
Cloudflare stack seems inappropriate

除非用户特别说明，否则默认采用以下首选技术栈（来自CLAUDE.md）：

前端：Vite + React + Tailwind v4 + shadcn/ui 后端：Cloudflare Workers（附带静态资源托管） 数据库：D1（带迁移的SQL数据库）存储：R2（对象存储）、KV（键值缓存/配置） 身份验证：Clerk（带自定义模板的JWT验证） 状态管理：TanStack Query（服务端）、Zustand（客户端）表单：React Hook Form + Zod验证部署：Wrangler CLI 运行时：Cloudflare Workers（非Node.js）

仅在以下情况下询问技术栈选择：

用户提及非标准技术
项目有特殊需求（高并发、遗留系统集成等）
Cloudflare技术栈明显不适用

Planning Workflow

规划工作流

Step 1: Analyze Project Requirements

步骤1：分析项目需求

Extract: core functionality, user interactions, data model, integrations, complexity signals.

提取：核心功能、用户交互、数据模型、集成项、复杂度信号。

Step 2: Ask Clarifying Questions (3-5 targeted questions)

步骤2：询问澄清问题（3-5个针对性问题）

Focus on: Auth, Data, Features, Integrations, Scope

Example:

1. Authentication: Public tool or user accounts? Social auth? Roles?
2. Data Model: Entities mentioned - relationships? (one-to-many, many-to-many)
3. Key Features: Real-time? File uploads? Email? Payments? AI?
4. Scope: MVP or full-featured?
5. Timeline: Any constraints?

重点关注：Auth、数据、功能、集成、范围

示例：

1. 身份验证：公开工具还是需要用户账户？支持社交登录吗？有角色权限吗？
2. 数据模型：涉及的实体 - 存在哪些关系？（一对多、多对多）
3. 核心功能：需要实时功能吗？文件上传？邮件？支付？AI？
4. 范围：MVP版本还是全功能版本？
5. 时间线：有时间限制吗？

Step 3: Determine Document Set

步骤3：确定文档集

Always:

IMPLEMENTATION_PHASES.md
SESSION.md template

Conditional (ask user):

DATABASE_SCHEMA.md (≥3 tables)
API_ENDPOINTS.md (≥5 endpoints)
ARCHITECTURE.md (multiple services)
UI_COMPONENTS.md (shadcn/ui project)
CRITICAL_WORKFLOWS.md (complex setup)
INSTALLATION_COMMANDS.md (recommended)
ENV_VARIABLES.md (needs secrets)
TESTING.md, AGENTS_CONFIG.MD, INTEGRATION.MD (as needed)

必选：

IMPLEMENTATION_PHASES.md
SESSION.md模板

条件性文档（需询问用户）：

DATABASE_SCHEMA.md（≥3张表时）
API_ENDPOINTS.md（≥5个接口时）
ARCHITECTURE.md（多服务场景时）
UI_COMPONENTS.md（使用shadcn/ui的项目）
CRITICAL_WORKFLOWS.md（复杂设置场景时）
INSTALLATION_COMMANDS.md（推荐生成）
ENV_VARIABLES.md（需要密钥配置时）
TESTING.md、AGENTS_CONFIG.MD、INTEGRATION.MD（按需生成）

Step 4: Generate IMPLEMENTATION_PHASES.md

步骤4：生成IMPLEMENTATION_PHASES.md

Create structured phases using these types:

使用以下阶段类型创建结构化阶段：

Phase Type: Infrastructure

阶段类型：基础设施

When: Project start, deployment setup Scope: Scaffolding, build config, initial deployment Files: 3-5 (package.json, wrangler.jsonc, vite.config.ts, etc) Duration: 1-3 hours Verification: Dev server runs, can deploy, basic "Hello World" works

适用场景：项目启动、部署设置范围：项目脚手架、构建配置、初始部署 涉及文件：3-5个（package.json、wrangler.jsonc、vite.config.ts等） 预计时长：1-3小时 验证标准：开发服务器可运行、可部署、基础"Hello World"功能正常

Phase Type: Database

阶段类型：数据库

When: Data model setup, schema changes Scope: Migrations, schema definition, seed data Files: 2-4 (migration files, schema types) Duration: 2-4 hours Verification: CRUD works, constraints enforced, relationships correct

适用场景：数据模型设置、 schema变更范围：迁移、schema定义、种子数据 涉及文件：2-4个（迁移文件、schema类型定义） 预计时长：2-4小时 验证标准：CRUD功能正常、约束生效、关系正确

Phase Type: API

阶段类型：API

When: Backend endpoints needed Scope: Routes, middleware, validation, error handling Files: 3-6 (route files, middleware, schemas) Duration: 3-6 hours (per endpoint group) Verification: All HTTP methods tested (200, 400, 401, 500), CORS works

适用场景：需要后端接口时范围：路由、中间件、验证、错误处理 涉及文件：3-6个（路由文件、中间件、schema） 预计时长：3-6小时（每组接口） 验证标准：所有HTTP方法测试通过（200、400、401、500）、CORS配置正常

Phase Type: UI

阶段类型：UI

When: User interface components Scope: Components, forms, state, styling Files: 4-8 (component files) Duration: 4-8 hours (per feature) Verification: User flows work, forms validate, states update, responsive

适用场景：用户界面组件开发范围：组件、表单、状态、样式 涉及文件：4-8个（组件文件） 预计时长：4-8小时（每个功能） 验证标准：用户流程正常、表单验证生效、状态更新正常、响应式布局正常

Phase Type: Integration

阶段类型：集成

When: Third-party services (auth, payments, AI, etc) Scope: API setup, webhooks, configuration Files: 2-4 (integration files, middleware) Duration: 3-5 hours (per integration) Verification: Service works, webhooks fire, errors handled

适用场景：第三方服务集成（Auth、支付、AI等）范围：API设置、Webhooks、配置 涉及文件：2-4个（集成文件、中间件） 预计时长：3-5小时（每个集成） 验证标准：服务功能正常、Webhooks触发正常、错误处理正常

Phase Type: Testing

阶段类型：测试

When: Need formal test suite (optional) Scope: E2E tests, integration tests Files: Test files Duration: 3-6 hours Verification: Tests pass, coverage meets threshold

适用场景：需要正式测试套件时（可选）范围：端到端测试、集成测试 涉及文件：测试文件 预计时长：3-6小时 验证标准：测试通过、覆盖率达到阈值

Phase Validation Rules

阶段验证规则

Every phase you generate MUST follow these constraints:

你生成的每个阶段必须遵循以下约束：

Context-Safe Sizing

上下文独立的规模控制

Max files: 5-8 files touched per phase
Max dependencies: Phase shouldn't require deep understanding of >2 other phases
Max duration: Implementation + verification + fixes should fit in one 2-4 hour session

最多文件数：每个阶段涉及5-8个文件
最多依赖项：阶段不应需要深入理解超过2个其他阶段
最长时长：实现+验证+修复应能在2-4小时的单次会话内完成

Required Elements

必备元素

Every phase MUST have:

Type - Infrastructure / Database / API / UI / Integration / Testing
Estimated duration - In hours (and minutes of human time)
Files - Specific files that will be created/modified
Task list - Ordered checklist with clear actions
Verification criteria - Checkbox list of tests to confirm phase works
Exit criteria - Clear definition of "done"

每个阶段必须包含：

类型 - 基础设施/数据库/API/UI/集成/测试
预计时长 - 以小时为单位（包含人工操作时间）
涉及文件 - 具体将创建/修改的文件
任务列表 - 有序的检查清单，包含明确操作
验证标准 - 用于确认阶段功能正常的复选清单
退出条件 - 明确的“完成”定义

Verification Requirements

验证要求

API phases: Test all HTTP status codes (200, 400, 401, 404, 500)
UI phases: Test user flows, form validation, error states
Database phases: Test CRUD, constraints, relationships
Integration phases: Test service connectivity, webhooks, error handling

API阶段：测试所有HTTP状态码（200、400、401、404、500）
UI阶段：测试用户流程、表单验证、错误状态
数据库阶段：测试CRUD、约束、关系
集成阶段：测试服务连通性、Webhooks、错误处理

Auto-Split Logic

自动拆分逻辑

If a phase violates sizing rules, automatically suggest splitting:

⚠️ Phase 4 "Complete User Management" is too large (12 files, 8-10 hours).

Suggested split:
- Phase 4a: User CRUD API (5 files, 4 hours)
- Phase 4b: User Profile UI (6 files, 5 hours)

如果某个阶段违反规模规则，自动建议拆分：

⚠️ 第4阶段“完整用户管理”规模过大（12个文件，8-10小时）。

建议拆分：
- 第4a阶段：用户CRUD API（5个文件，4小时）
- 第4b阶段：用户资料UI（6个文件，5小时）

Template Structures

模板结构

IMPLEMENTATION_PHASES.md Template

IMPLEMENTATION_PHASES.md 模板

markdown

undefined

markdown

undefined

Implementation Phases: [Project Name]

实现阶段：[项目名称]

Project Type: [Web App / Dashboard / API / etc] Stack: Cloudflare Workers + Vite + React + D1 Estimated Total: [X hours] (~[Y minutes] human time)

项目类型：[Web应用/仪表盘/API等] 技术栈：Cloudflare Workers + Vite + React + D1 预计总时长：[X小时]（约[Y分钟]人工时间）

Phase 1: [Name]

阶段1：[名称]

Phase 2: [Name]

阶段2：[名称]

[... repeat structure ...]

[... 重复上述结构 ...]

Notes

说明

Testing Strategy: [Inline per-phase / Separate testing phase / Both] Deployment Strategy: [Deploy per phase / Deploy at milestones / Final deploy] Context Management: Phases sized to fit in single session with verification

undefined

测试策略：[按阶段内联/独立测试阶段/两者结合] 部署策略：[按阶段部署/里程碑部署/最终部署] 上下文管理：阶段规模适配单次会话，包含验证环节

undefined

DATABASE_SCHEMA.md Template

DATABASE_SCHEMA.md 模板

markdown

undefined

markdown

undefined

Database Schema: [Project Name]

数据库Schema：[项目名称]

Database: Cloudflare D1 Migrations: Located in

migrations/

ORM: [Drizzle / Raw SQL / None]

数据库：Cloudflare D1 迁移文件：位于

migrations/

目录 ORM：[Drizzle / 原生SQL / 无]

Tables

表结构

users

users

Purpose: User accounts and authentication

Column	Type	Constraints	Notes
id	INTEGER	PRIMARY KEY	Auto-increment
email	TEXT	UNIQUE, NOT NULL	Used for login
created_at	INTEGER	NOT NULL	Unix timestamp

Indexes:

```
idx_users_email
```
on
```
email
```
(for login lookups)

Relationships:

One-to-many with
```
tasks
```

用途：用户账户和身份验证

列名	类型	约束	说明
id	INTEGER	PRIMARY KEY	自增
email	TEXT	UNIQUE, NOT NULL	用于登录
created_at	INTEGER	NOT NULL	Unix时间戳

索引：

```
idx_users_email
```
基于
```
email
```
字段（用于登录查询）

关系：

与
```
tasks
```
表为一对多关系

tasks

tasks

[... repeat structure ...]

[... 重复上述结构 ...]

Migrations

迁移记录

Migration 1: Initial Schema

迁移1：初始Schema

File:

migrations/0001_initial.sql

Creates: users, tasks tables

文件：

migrations/0001_initial.sql

创建内容：users、tasks表

Migration 2: Add Tags

迁移2：添加标签

File:

migrations/0002_tags.sql

Creates: tags, task_tags tables

文件：

migrations/0002_tags.sql

创建内容：tags、task_tags表

Seed Data

种子数据

For development, seed with:

3 sample users
10 sample tasks across users
5 tags

undefined

开发环境下，建议初始化以下数据：

3个示例用户
10个分属于不同用户的示例任务
5个标签

undefined

API_ENDPOINTS.md Template

API_ENDPOINTS.md 模板

markdown

undefined

markdown

undefined

API Endpoints: [Project Name]

API接口：[项目名称]

Base URL:

/api

Auth: Clerk JWT (custom template with email + metadata) Framework: Hono (on Cloudflare Workers)

基础URL：

/api

身份验证：Clerk JWT（带邮箱和元数据的自定义模板）框架：Hono（运行在Cloudflare Workers上）

Authentication

身份验证

POST /api/auth/verify

Purpose: Verify JWT token Auth: None (public) Request:

json

{
  "token": "string"
}

Responses:

200: Token valid →

{ "valid": true, "email": "user@example.com" }

401: Token invalid →
```
{ "error": "Invalid token" }
```

用途：验证JWT令牌 身份验证要求：无（公开接口） 请求体：

json

{
  "token": "string"
}

响应：

200：令牌有效 →

{ "valid": true, "email": "user@example.com" }

401：令牌无效 →
```
{ "error": "Invalid token" }
```

Users

用户相关

GET /api/users/me

Purpose: Get current user profile Auth: Required (JWT) Responses:

200:

{ "id": 1, "email": "user@example.com", "created_at": 1234567890 }

401: Not authenticated

[... repeat for all endpoints ...]

用途：获取当前用户资料 身份验证要求：需要（JWT）响应：

200：

{ "id": 1, "email": "user@example.com", "created_at": 1234567890 }

401：未认证

[... 重复所有接口的结构 ...]

Error Handling

错误处理

All endpoints return errors in this format:

json

{
  "error": "Human-readable message",
  "code": "ERROR_CODE",
  "details": {} // optional
}

Standard Codes:

400: Bad request (validation failed)
401: Unauthorized (not logged in / invalid token)
403: Forbidden (insufficient permissions)
404: Not found
500: Internal server error

undefined

所有接口返回的错误格式如下：

json

{
  "error": "人类可读的错误信息",
  "code": "错误码",
  "details": {} // 可选
}

标准错误码：

400：请求参数错误（验证失败）
401：未授权（未登录/令牌无效）
403：禁止访问（权限不足）
404：资源不存在
500：服务器内部错误

undefined

ARCHITECTURE.md Template

ARCHITECTURE.md 模板

markdown

undefined

markdown

undefined

Architecture: [Project Name]

架构设计：[项目名称]

Deployment: Cloudflare Workers Frontend: Vite + React (served as static assets) Backend: Worker handles API routes

部署方式：Cloudflare Workers 前端：Vite + React（作为静态资源托管）后端：Worker处理API路由

System Overview

系统概览

┌─────────────────┐
│   Browser       │
└────────┬────────┘
         │
         ↓ HTTPS
┌─────────────────────────────────────┐
│  Cloudflare Worker                  │
│  ┌──────────────┐  ┌──────────────┐│
│  │ Static Assets│  │  API Routes  ││
│  │ (Vite build) │  │    (Hono)    ││
│  └──────────────┘  └───────┬──────┘│
└─────────────────────────────┼───────┘
                              │
            ┌─────────────────┼─────────────────┐
            ↓                 ↓                 ↓
      ┌──────────┐      ┌──────────┐    ┌──────────┐
      │    D1    │      │    R2    │    │  Clerk   │
      │ (Database)│     │(Storage) │    │  (Auth)  │
      └──────────┘      └──────────┘    └──────────┘

┌─────────────────┐
│   浏览器        │
└────────┬────────┘
         │
         ↓ HTTPS
┌─────────────────────────────────────┐
│  Cloudflare Worker                  │
│  ┌──────────────┐  ┌──────────────┐│
│  │ 静态资源     │  │  API路由     ││
│  │ (Vite构建产物)│  │    (Hono)    ││
│  └──────────────┘  └───────┬──────┘│
└─────────────────────────────┼───────┘
                              │
            ┌─────────────────┼─────────────────┐
            ↓                 ↓                 ↓
      ┌──────────┐      ┌──────────┐    ┌──────────┐
      │    D1    │      │    R2    │    │  Clerk   │
      │ (数据库) │     │(对象存储) │    │  (身份验证)│
      └──────────┘      └──────────┘    └──────────┘

Data Flow

数据流

User Authentication

用户身份验证流程

User submits login form
Frontend sends credentials to Clerk
Clerk returns JWT
Frontend includes JWT in API requests
Worker middleware verifies JWT
Protected routes accessible

用户提交登录表单
前端将凭证发送给Clerk
Clerk返回JWT
前端在API请求中携带JWT
Worker中间件验证JWT
受保护路由可访问

Task Creation

任务创建流程

User submits task form
Frontend validates with Zod
POST /api/tasks with validated data
Worker validates again server-side
Insert into D1 database
Return created task
Frontend updates UI via TanStack Query

[... more flows as needed ...]

用户提交任务表单
前端使用Zod验证
携带验证后的数据POST到/api/tasks
Worker在服务端再次验证
插入到D1数据库
返回创建的任务
前端通过TanStack Query更新UI

[... 按需添加更多流程 ...]

Service Boundaries

服务边界

Frontend Responsibilities:

User interaction
Client-side validation
Optimistic updates
State management (TanStack Query + Zustand)

Worker Responsibilities:

Request routing
Authentication/authorization
Server-side validation
Business logic
Database operations
Third-party API calls

Cloudflare Services:

D1: Persistent relational data
R2: File storage (images, documents)
KV: Configuration, feature flags, cache

前端职责：

用户交互
客户端验证
乐观更新
状态管理（TanStack Query + Zustand）

Worker职责：

请求路由
身份验证/授权
服务端验证
业务逻辑
数据库操作
第三方API调用

Cloudflare服务职责：

D1：持久化关系型数据
R2：文件存储（图片、文档）
KV：配置、功能开关、缓存

Security

安全措施

Authentication: Clerk JWT with custom claims Authorization: Middleware checks user ownership before mutations Input Validation: Zod schemas on client AND server CORS: Restricted to production domain Secrets: Environment variables in wrangler.jsonc (not committed)

undefined

身份验证：带自定义声明的Clerk JWT 授权：中间件在修改操作前检查用户所有权 输入验证：客户端和服务端均使用Zod schema CORS：限制为生产环境域名密钥：存储在wrangler.jsonc的环境变量中（不提交到代码仓库）

undefined

UI_COMPONENTS.md Template (Enhanced with Phase-Aligned Installation)

UI_COMPONENTS.md 模板（增强版，含阶段对齐的安装策略）

Use when: Project uses shadcn/ui OR needs component planning

markdown

undefined

适用场景：项目使用shadcn/ui 或需要规划组件时

markdown

undefined

UI Components: [Project Name]

UI组件：[项目名称]

Framework: shadcn/ui + Tailwind v4 Installation: Components copied to @/components/ui (fully customizable) Strategy: Install components as needed per phase (not all upfront)

框架：shadcn/ui + Tailwind v4 安装方式：组件复制到@/components/ui（完全可自定义）策略：按阶段按需安装组件（不提前安装所有组件）

Installation Strategy: By Phase

按阶段的安装策略

Phase [N]: [Phase Name] ([X] components)

阶段[N]：[阶段名称]（[X]个组件）

When: During [description of when this phase happens]

Components:

```
button
```
- [specific use cases in this phase]
```
input
```
- [specific use cases]
```
card
```
- [specific use cases] [... list all components for this phase ...]

Install: ```bash pnpm dlx shadcn@latest add button input card [...] ```

Usage: [Which routes/features use these]

Critical Notes:

[Any gotchas, e.g., "Use sonner instead of toast for better UX"]
[Component-specific warnings, e.g., "data-table essential for TanStack Table integration"]

[Repeat for each phase...]

时机：在[描述该阶段的触发条件]时安装

组件：

```
button
```
- [该阶段的具体使用场景]
```
input
```
- [具体使用场景]
```
card
```
- [具体使用场景] [... 列出该阶段所有组件 ...]

安装命令： ```bash pnpm dlx shadcn@latest add button input card [...] ```

使用场景：[哪些路由/功能会使用这些组件]

重要说明：

[注意事项，例如：“使用sonner而非toast以获得更好的用户体验”]
[组件特定警告，例如：“data-table是TanStack Table集成的必需组件”]

[为每个阶段重复上述结构...]

Quick Reference Commands

快速参考命令

MVP Install (All Core Components)

MVP安装（所有核心组件）

```bash pnpm dlx shadcn@latest add button input label card sonner [essential components...] ```

```bash pnpm dlx shadcn@latest add button input label card sonner [核心组件...] ```

Full Featured Install

全功能安装

```bash pnpm dlx shadcn@latest add button input [all components...] ```

```bash pnpm dlx shadcn@latest add button input [所有组件...] ```

Update All Components

更新所有组件

```bash pnpm dlx shadcn@latest update ```

Component Usage by Route

按路由的组件使用情况

[Route Name] (`/route`)

[路由名称]（

/route

）

[List of components used]

[Repeat for each major route...]

[使用的组件列表]

[为每个主要路由重复上述结构...]

Design Decisions

设计决策

[Component Choice 1]

[组件选择1]

Recommendation: [Chosen component] Why: [Justification] Alternatives considered: [What else was evaluated] Savings: [Time/token savings if applicable]

[Repeat for each significant component decision...]

推荐：[所选组件] 原因：[理由] 备选方案：[评估过的其他组件] 优势：[时间/性能等方面的优势]

[为每个重要的组件决策重复上述结构...]

Component Count Breakdown

组件数量统计

By Category

按类别

Forms: X components ([list])
Data Display: X components ([list])
Feedback: X components ([list])
Layout: X components ([list])
Navigation: X components ([list])

表单：X个组件（[列表]）
数据展示：X个组件（[列表]）
反馈：X个组件（[列表]）
布局：X个组件（[列表]）
导航：X个组件（[列表]）

By Priority

按优先级

Essential (MVP): X components
Recommended: X additional components
Optional (Enhanced UX): X additional components

必备（MVP）：X个组件
推荐：X个额外组件
可选（增强UX）：X个额外组件

Installation Checklist

安装检查清单

Phase [N]: [Name] ✅

阶段[N]：[名称] ✅

component1
component2 [...]

[Repeat for each phase...]

component1
component2 [...]

[为每个阶段重复上述结构...]

Best Practices

最佳实践

Install as Needed - Don't install all components upfront. Add them when implementing the feature.
Customize After Installation - All components copied to @/components/ui are fully customizable.
Keep Components Updated - Run `pnpm dlx shadcn@latest update` periodically.
Check for New Components - shadcn/ui adds new components regularly.
Dark Mode Works Automatically - All components respect Tailwind v4 theming.
Bundle Size Optimization - Only installed components are included - unused code is tree-shaken.

按需安装 - 不要提前安装所有组件。在实现功能时再添加。
安装后自定义 - 所有复制到@/components/ui的组件均可完全自定义。
保持组件更新 - 定期运行
```
pnpm dlx shadcn@latest update
```
。
关注新组件 - shadcn/ui会定期添加新组件。
自动支持暗色模式 - 所有组件均兼容Tailwind v4主题。
优化包体积 - 仅包含已安装的组件 - 未使用的代码会被Tree Shaking移除。

References

参考资料

shadcn/ui Docs: https://ui.shadcn.com/docs/components
Tailwind v4 Integration: See `tailwind-v4-shadcn` skill
Component Installation: https://ui.shadcn.com/docs/installation/vite

undefined

shadcn/ui 文档：https://ui.shadcn.com/docs/components
Tailwind v4 集成：查看
```
tailwind-v4-shadcn
```
Skill
组件安装：https://ui.shadcn.com/docs/installation/vite

undefined

CRITICAL_WORKFLOWS.md Template (NEW)

CRITICAL_WORKFLOWS.md 模板（新增）

Use when: User mentioned complex setup steps OR order-sensitive workflows

markdown

undefined

适用场景：用户提及复杂设置步骤或顺序敏感的工作流时

markdown

undefined

Critical Workflows: [Project Name]

关键工作流：[项目名称]

Purpose: Document non-obvious setup steps and order-sensitive workflows to prevent getting stuck

Date: [YYYY-MM-DD]

用途：记录非直观的设置步骤和顺序敏感的工作流，避免陷入困境

日期：[YYYY-MM-DD]

⚠️ [Workflow Name 1] ([Phase it applies to])

⚠️ [工作流名称1]（适用阶段）

STOP! Read this before [starting X].

Context: [Why this workflow is tricky]

Order matters:

[Step 1 with specific command/action]
[Step 2]
[Step 3] [...]

Why this order: [Explanation of what breaks if done wrong]

Code Example: ```bash

注意！在[开始X操作]前请阅读此内容。

背景：[为什么此工作流具有挑战性]

顺序至关重要：

[步骤1，包含具体命令/操作]
[步骤2]
[步骤3] [...]

为什么要遵循此顺序：[如果顺序错误会导致什么问题]

代码示例： ```bash

Step 1: [Description]

步骤1：[描述]

[command]

[命令]

Step 2: [Description]

步骤2：[描述]

[command] ```

Common Mistake: [What people typically do wrong] Fix if broken: [How to recover]

[命令] ```

常见错误：[人们通常会犯的错误] 修复方法：[出现问题后的恢复步骤]

⚠️ [Workflow Name 2]

⚠️ [工作流名称2]

[Repeat structure...]

[重复上述结构...]

Quick Checklist

快速检查清单

Before starting each phase, check if it has critical workflows:

Phase [N]: [Workflow name] (see above)
Phase [N+1]: No critical workflows
Phase [N+2]: [Workflow name] (see above)

在开始每个阶段前，检查是否存在关键工作流：

阶段[N]：[工作流名称]（见上文）
阶段[N+1]：无关键工作流
阶段[N+2]：[工作流名称]（见上文）

References

参考资料

[Link to official docs]
[Link to GitHub issue explaining gotcha]
[Link to skill that prevents this issue]

undefined

[官方文档链接]
[解释注意事项的GitHub Issue链接]
[可避免此问题的Skill链接]

undefined

INSTALLATION_COMMANDS.md Template (NEW)

INSTALLATION_COMMANDS.md 模板（新增）

Use when: All projects (recommended) - saves massive time

markdown

undefined

适用场景：所有项目（推荐） - 节省大量时间

markdown

undefined

Installation Commands: [Project Name]

安装命令：[项目名称]

Purpose: Copy-paste commands for each phase (no more "what was that command again?")

Date: [YYYY-MM-DD]

用途：每个阶段的可直接复制的命令（无需再想“那个命令是什么来着？”）

日期：[YYYY-MM-DD]

Phase 0: Planning

阶段0：规划

[None - just docs]

[无命令 - 仅生成文档]

Phase 1: [Phase Name]

阶段1：[阶段名称]

Scaffold Project

初始化项目

```bash npm create cloudflare@latest -- --framework=[framework] cd [project-name] ```

```bash npm create cloudflare@latest -- --framework=[框架] cd [项目名称] ```

Install Dependencies

安装依赖

```bash pnpm add [packages] pnpm add -D [dev-packages] ```

```bash pnpm add [依赖包] pnpm add -D [开发依赖包] ```

Initialize Tools

初始化工具

```bash npx [tool] init ```

```bash npx [工具] init ```

Verify Setup

验证设置

```bash pnpm dev

Should see: [expected output]

预期输出：[描述预期结果]

```

Phase 2: [Phase Name]

阶段2：[阶段名称]

[Repeat structure for each phase...]

[为每个阶段重复上述结构...]

Database Commands (Phase [N])

数据库命令（阶段[N]）

Create Database

创建数据库

```bash npx wrangler d1 create [db-name]

```bash npx wrangler d1 create [数据库名称]

Copy database_id and add to wrangler.jsonc under [[d1_databases]]

复制database_id并添加到wrangler.jsonc的[[d1_databases]]中

```

Run Migrations

运行迁移

```bash

Local (dev)

本地（开发环境）

npx wrangler d1 execute [db-name] --local --file=migrations/0001_initial.sql

npx wrangler d1 execute [数据库名称] --local --file=migrations/0001_initial.sql

Production

生产环境

npx wrangler d1 execute [db-name] --remote --file=migrations/0001_initial.sql ```

npx wrangler d1 execute [数据库名称] --remote --file=migrations/0001_initial.sql ```

Query Database

查询数据库

```bash

Local

本地

npx wrangler d1 execute [db-name] --local --command="SELECT * FROM users"

npx wrangler d1 execute [数据库名称] --local --command="SELECT * FROM users"

Production

生产环境

npx wrangler d1 execute [db-name] --remote --command="SELECT * FROM users" ```

npx wrangler d1 execute [数据库名称] --remote --command="SELECT * FROM users" ```

Deployment Commands

部署命令

Deploy to Cloudflare

部署到Cloudflare

```bash npm run build npx wrangler deploy ```

Set Production Secrets

设置生产环境密钥

```bash npx wrangler secret put [SECRET_NAME]

```bash npx wrangler secret put [密钥名称]

Enter value when prompted

提示时输入密钥值

```

Check Deployment

检查部署状态

```bash npx wrangler tail

Watch logs in real-time

实时查看日志

```

Development Commands

开发命令

Start Dev Server

启动开发服务器

```bash pnpm dev ```

Run Tests

运行测试

```bash pnpm test ```

Lint & Format

代码检查与格式化

```bash pnpm lint pnpm format ```

Troubleshooting Commands

故障排除命令

Clear Build Cache

清理构建缓存

```bash rm -rf dist/ .wrangler/ pnpm dev ```

Check Wrangler Version

检查Wrangler版本

```bash npx wrangler --version

Should be: [expected version]

预期版本：[描述预期版本]

```

Verify Bindings

验证绑定

```bash npx wrangler d1 list npx wrangler r2 bucket list ```

undefined

```bash npx wrangler d1 list npx wrangler r2 bucket list ```

undefined

ENV_VARIABLES.md Template (NEW)

ENV_VARIABLES.md 模板（新增）

Use when: Project needs API keys OR environment configuration

markdown

undefined

适用场景：项目需要API密钥或环境配置时

markdown

undefined

Environment Variables: [Project Name]

环境变量：[项目名称]

Purpose: All secrets, API keys, and configuration needed for this project

Date: [YYYY-MM-DD]

用途：项目所需的所有密钥、API密钥和配置

日期：[YYYY-MM-DD]

Development (.dev.vars)

开发环境（.dev.vars）

File: `.dev.vars` (local file, NOT committed to git)

```bash

文件：

.dev.vars

（本地文件，不要提交到Git）

```bash

Auth

身份验证

CLERK_PUBLISHABLE_KEY=pk_test_... CLERK_SECRET_KEY=sk_test_...

Database

数据库

DATABASE_URL=local

API Keys

API密钥

[SERVICE]_API_KEY=[value]

[SERVICE]_API_KEY=[值]

Feature Flags

功能开关

ENABLE_[FEATURE]=true ```

How to get these keys:

Clerk Keys: https://dashboard.clerk.com → API Keys
[Other Service]: [Steps to obtain]

ENABLE_[FEATURE]=true ```

如何获取这些密钥：

Clerk密钥：https://dashboard.clerk.com → API Keys
[其他服务]：[获取步骤]

Production (wrangler.jsonc secrets)

生产环境（wrangler.jsonc 密钥）

Secrets (set via CLI): ```bash

通过CLI设置的密钥： ```bash

Set via: npx wrangler secret put SECRET_NAME

设置命令：npx wrangler secret put 密钥名称

CLERK_SECRET_KEY=sk_live_... [SERVICE]_API_KEY=[production-value] ```

Bindings (configured in wrangler.jsonc): ```jsonc { "name": "[project-name]", "d1_databases": [ { "binding": "DB", "database_name": "[db-name]", "database_id": "[copy from wrangler d1 create output]" } ], "r2_buckets": [ { "binding": "BUCKET", "bucket_name": "[bucket-name]" } ], "kv_namespaces": [ { "binding": "KV", "id": "[namespace-id]" } ] } ```

CLERK_SECRET_KEY=sk_live_... [SERVICE]_API_KEY=[生产环境值] ```

在wrangler.jsonc中配置的绑定： ```jsonc { "name": "[项目名称]", "d1_databases": [ { "binding": "DB", "database_name": "[数据库名称]", "database_id": "[从wrangler d1 create输出中复制]" } ], "r2_buckets": [ { "binding": "BUCKET", "bucket_name": "[存储桶名称]" } ], "kv_namespaces": [ { "binding": "KV", "id": "[命名空间ID]" } ] } ```

Environment Variable Reference

环境变量参考

Variable	Required	Where Used	Notes
CLERK_PUBLISHABLE_KEY	Yes	Frontend	Public, safe to commit in example files
CLERK_SECRET_KEY	Yes	Worker	SECRET - never commit
DATABASE_URL	Local only	Development	Points to local .wrangler/state
[OTHER_VAR]	[Yes/No]	[Where]	[Notes]

变量名	是否必需	使用位置	说明
CLERK_PUBLISHABLE_KEY	是	前端	公开密钥，可在示例文件中提交
CLERK_SECRET_KEY	是	Worker	保密密钥 - 绝对不要提交
DATABASE_URL	仅本地需要	开发环境	指向本地.wrangler/state
[其他变量]	[是/否]	[使用位置]	[说明]

Setup Checklist

设置检查清单

Local Development

本地开发环境

Create `.dev.vars` in project root
Add `.dev.vars` to `.gitignore` (should already be there)
Copy values from `.dev.vars.example` (if exists)
Get API keys from services (links above)
Run `pnpm dev` to verify

在项目根目录创建
```
.dev.vars
```
文件
将
```
.dev.vars
```
添加到
```
.gitignore
```
（通常已默认添加）
从
```
.dev.vars.example
```
复制值（如果存在）
从服务提供商获取API密钥（链接见上文）
运行
```
pnpm dev
```
验证设置

Production Deployment

生产环境部署

Set all secrets via `npx wrangler secret put`
Configure all bindings in `wrangler.jsonc`
Deploy: `npx wrangler deploy`
Verify secrets are set: `npx wrangler secret list`
Test production deployment

通过
```
npx wrangler secret put
```
设置所有密钥
在
```
wrangler.jsonc
```
中配置所有绑定
部署：
```
npx wrangler deploy
```
验证密钥已设置：
```
npx wrangler secret list
```
测试生产环境部署

Security Notes

安全注意事项

Never commit:

`.dev.vars`
Any file with actual secret values
Production API keys

Safe to commit:

`.dev.vars.example` (with placeholder values)
`wrangler.jsonc` (bindings config, NOT secret values)
Public keys (Clerk publishable key, etc.)

If secrets leaked:

Rotate all affected keys immediately
Update production secrets: `npx wrangler secret put [KEY]`
Revoke old keys in service dashboards
Check git history for leaked secrets

绝对不要提交：

```
.dev.vars
```
任何包含实际密钥值的文件
生产环境API密钥

可以提交：

```
.dev.vars.example
```
（包含占位符值）
```
wrangler.jsonc
```
（绑定配置，不含密钥值）
公开密钥（如Clerk publishable key等）

如果密钥泄露：

立即轮换所有受影响的密钥
更新生产环境密钥：
```
npx wrangler secret put [密钥名称]
```
在服务提供商控制台吊销旧密钥
检查Git历史是否存在泄露的密钥

References

参考资料

Cloudflare Secrets: https://developers.cloudflare.com/workers/configuration/secrets/
Wrangler Configuration: https://developers.cloudflare.com/workers/wrangler/configuration/
[Service] API Docs: [link]

undefined

Cloudflare 密钥：https://developers.cloudflare.com/workers/configuration/secrets/
Wrangler 配置：https://developers.cloudflare.com/workers/wrangler/configuration/
[服务] API文档：[链接]

undefined

Compact SESSION.md Template (NEW)

精简版SESSION.md 模板（新增）

Always generate this - for tracking progress

markdown

undefined

始终生成此文档 - 用于跟踪进度

markdown

undefined

Session State

会话状态

Current Phase: Phase 0 (Planning) Current Stage: Planning Last Checkpoint: None yet Planning Docs: `docs/IMPLEMENTATION_PHASES.md`, `docs/CRITICAL_WORKFLOWS.md` (if exists)

当前阶段：阶段0（规划） 当前状态：规划中 最后检查点：尚未开始 规划文档：

docs/IMPLEMENTATION_PHASES.md

、

docs/CRITICAL_WORKFLOWS.md

（如果存在）

Phase 0: Planning ✅

阶段0：规划 ✅

Completed: [YYYY-MM-DD] Summary: Planning docs created Deliverables: [List generated docs]

完成时间：[YYYY-MM-DD] 总结：已创建规划文档 交付物：[生成的文档列表]

Phase 1: [Name] ⏸️

阶段1：[名称] ⏸️

Spec: `docs/IMPLEMENTATION_PHASES.md#phase-1` Type: [Infrastructure/Database/API/UI/Integration] Time: [X hours] Progress: Not started Next Action: [Specific file + line + what to do]

参考文档：

docs/IMPLEMENTATION_PHASES.md#phase-1

类型：[基础设施/数据库/API/UI/集成] 预计时长：[X小时] 进度：未开始 下一步操作：[具体文件 + 行号 + 操作内容]

Phase 2: [Name] ⏸️

阶段2：[名称] ⏸️

Spec: `docs/IMPLEMENTATION_PHASES.md#phase-2` Type: [Type] Time: [X hours] Progress: Not started

[Collapse remaining phases to 2-3 lines each...]

参考文档：

docs/IMPLEMENTATION_PHASES.md#phase-2

类型：[类型] 预计时长：[X小时] 进度：未开始

[将剩余阶段折叠为2-3行...]

Critical Reminders

重要提醒

Before Starting:

Read `docs/CRITICAL_WORKFLOWS.md` (if exists)
Review `docs/INSTALLATION_COMMANDS.md` for phase commands
Check `docs/ENV_VARIABLES.md` for required secrets

Critical Workflows: [Link to specific workflows from CRITICAL_WORKFLOWS.md, if exists]

开始前：

阅读
```
docs/CRITICAL_WORKFLOWS.md
```
（如果存在）
查看
```
docs/INSTALLATION_COMMANDS.md
```
中的阶段命令
检查
```
docs/ENV_VARIABLES.md
```
中的必需密钥

关键工作流： [链接到CRITICAL_WORKFLOWS.md中的具体工作流（如果存在）]

Known Risks

已知风险

High-Risk Phases:

Phase [N]: [Name] - [Why risky]
Phase [N+1]: [Name] - [Why risky]

Mitigation: [Strategy]

Status Legend: ⏸️ Pending | 🔄 In Progress | ✅ Complete | 🚫 Blocked | ⚠️ Issues

---

高风险阶段：

阶段[N]：[名称] - [风险原因]
阶段[N+1]：[名称] - [风险原因]

缓解策略：[应对策略]

状态图例：⏸️ 待开始 | 🔄 进行中 | ✅ 已完成 | 🚫 阻塞 | ⚠️ 存在问题

---

File-Level Detail in Phases

阶段的文件级细节

Purpose: Help Claude navigate code with file maps, data flow diagrams, and gotchas.

Include for: API, UI, Integration phases (optional for Infrastructure, Database, Testing)

用途：通过文件映射、数据流图和注意事项帮助Claude导航代码。

适用阶段：API、UI、集成阶段（基础设施、数据库、测试阶段可选）

File Map Example

文件映射示例

markdown

undefined

markdown

undefined

File Map

文件映射

```
src/routes/tasks.ts
```
(~150 lines) - CRUD endpoints
- Purpose, Key exports, Dependencies, Used by
```
src/lib/schemas.ts
```
(~80 lines) - Validation schemas
```
src/middleware/auth.ts
```
(existing, no changes)

undefined

```
src/routes/tasks.ts
```
（约150行）- CRUD接口用途、关键导出、依赖项、使用者
```
src/lib/schemas.ts
```
（约80行）- 验证schema
```
src/middleware/auth.ts
```
（已存在，无需修改）

undefined

Data Flow Diagrams

数据流图

Use Mermaid for sequence diagrams (API), flowcharts (UI), architecture diagrams:

markdown

\`\`\`mermaid
sequenceDiagram
    Client->>Worker: POST /api/tasks
    Worker->>Auth: authenticateUser()
    Auth->>Worker: user object
    Worker->>D1: INSERT INTO tasks
    D1->>Worker: task record
    Worker->>Client: 201 + JSON
\`\`\`

使用Mermaid绘制序列图（API）、流程图（UI）、架构图：

markdown

\`\`\`mermaid
sequenceDiagram
    Client->>Worker: POST /api/tasks
    Worker->>Auth: authenticateUser()
    Auth->>Worker: 用户对象
    Worker->>D1: INSERT INTO tasks
    D1->>Worker: 任务记录
    Worker->>Client: 201 + JSON
\`\`\`

Critical Dependencies & Gotchas

关键依赖项与注意事项

markdown

**Internal**: auth.ts, schemas.ts, D1 binding
**External**: zod, hono, @clerk/backend
**Configuration**: CLERK_SECRET_KEY
**Bindings**: DB (D1)

**Gotchas**:
- Ownership verification (PATCH/DELETE must check user_id)
- Pagination required (50 max per page)
- Soft delete (deleted_at, not DELETE FROM)
- UTC timestamps (convert in frontend only)

markdown

**内部依赖**：auth.ts、schemas.ts、D1绑定
**外部依赖**：zod、hono、@clerk/backend
**配置**：CLERK_SECRET_KEY
**绑定**：DB（D1）

**注意事项**：
- 所有权验证（PATCH/DELETE操作前必须检查user_id）
- 需要分页（每页最多50条）
- 软删除（设置deleted_at，而非DELETE FROM）
- UTC时间戳（仅在前端转换）

Complete Phase Example (with File-Level Detail)

完整阶段示例（包含文件级细节）

markdown

undefined

markdown

undefined

Phase 3: Tasks API

阶段3：任务API

Type: API | Estimated: 4 hours Files: src/routes/tasks.ts, src/lib/schemas.ts, src/middleware/auth.ts (modify)

类型：API | 预计时长：4小时 涉及文件：src/routes/tasks.ts、src/lib/schemas.ts、src/middleware/auth.ts（修改）

File Map

文件映射

src/routes/tasks.ts (~150 lines) - CRUD endpoints
src/lib/schemas.ts (+40 lines) - Validation schemas

src/routes/tasks.ts（约150行）- CRUD接口
src/lib/schemas.ts（新增40行）- 验证schema

Data Flow

数据流

```mermaid sequenceDiagram Client->>Worker: POST /api/tasks Worker->>Auth: authenticateUser() Worker->>D1: INSERT D1->>Worker: task Worker->>Client: 201 ```

```mermaid sequenceDiagram Client->>Worker: POST /api/tasks Worker->>Auth: authenticateUser() Worker->>D1: INSERT D1->>Worker: 任务记录 Worker->>Client: 201 ```

Dependencies & Gotchas

依赖项与注意事项

Internal: auth.ts, schemas.ts, D1 External: zod, hono, @clerk/backend Gotchas: Ownership checks, pagination (50 max), soft delete, UTC timestamps

内部依赖：auth.ts、schemas.ts、D1 外部依赖：zod、hono、@clerk/backend 注意事项：所有权检查、分页（最多50条）、软删除、UTC时间戳

Tasks

任务

Verification

验证标准

Exit Criteria

退出条件

All CRUD works with correct status codes, validation, auth, ownership. Paginated. Soft deletes.

---

所有CRUD功能正常，返回正确状态码，验证、身份验证、所有权检查均生效。支持分页和软删除。

---

Generation Logic

生成逻辑

Analyze project description
Ask 3-5 clarifying questions
Wait for answers
Determine which docs to generate
Generate all docs immediately (key step - before coding)
Validate phases (≤8 files, ≤4 hours)
Output docs to /docs
Wait for user review
Suggest creating SESSION.md and starting Phase 1

分析项目描述
询问3-5个澄清问题
等待用户回复
确定需要生成的文档
立即生成所有文档（关键步骤 - 在编码前完成）
验证阶段规模（≤8个文件，≤4小时）
将文档输出到/docs目录
等待用户审阅
建议创建SESSION.md并启动阶段1

Special Cases

特殊场景

AI Apps: Ask AI provider, suggest AGENTS_CONFIG.md, add Integration phase
Real-Time: Suggest Durable Objects, add Infrastructure phase for DO
High Scale: Ask load expectations, suggest caching (KV, R2), Hyperdrive
Legacy Integration: Ask integration points, suggest INTEGRATION.md

AI应用：询问AI提供商，建议生成AGENTS_CONFIG.md，添加集成阶段
实时功能：建议使用Durable Objects，添加基础设施阶段以配置DO
高并发场景：询问负载预期，建议使用缓存（KV、R2）、Hyperdrive
遗留系统集成：询问集成点，建议生成INTEGRATION.md

Quality Checklist

质量检查清单

✅ Every phase: Type, time, files, tasks, verification, exit criteria ✅ Context-safe: ≤8 files, ≤2 dependencies, fits in 2-4hr session ✅ Verification specific: "valid login→200+token, invalid→401" not "test feature" ✅ Exit criteria clear: "All endpoints correct status codes" not "API done" ✅ Logical order: Infrastructure→Database→API→UI→Integration→Testing ✅ Realistic estimates: Include implementation+verification+fixes

✅ 每个阶段：包含类型、时长、文件、任务、验证标准、退出条件 ✅ 上下文独立：≤8个文件，≤2个依赖项，可在2-4小时会话内完成 ✅ 验证标准具体：例如“有效登录→200+令牌，无效→401”而非“测试功能” ✅ 退出条件明确：例如“所有接口返回正确状态码”而非“API完成” ✅ 逻辑顺序：基础设施→数据库→API→UI→集成→测试 ✅ 估算合理：包含实现+验证+修复的时间

Output Format

输出格式

Generate docs immediately after user confirms. Present as markdown files or code blocks.

Include: Full IMPLEMENTATION_PHASES.md + conditional docs (DATABASE_SCHEMA.md, API_ENDPOINTS.md, etc.) + Summary (phases, duration, deployment strategy, docs created)

用户确认后立即生成文档。以Markdown文件或代码块形式呈现。

包含内容：完整的IMPLEMENTATION_PHASES.md + 条件性文档（DATABASE_SCHEMA.md、API_ENDPOINTS.md等） + 总结（阶段、时长、部署策略、已生成文档）

Common Mistakes to Avoid

需避免的常见错误

SESSION.md too verbose (<200 lines, reference IMPLEMENTATION_PHASES.md)
Vague next action ("Continue API" → "Implement POST /api/tasks in src/routes/tasks.ts:47")
No critical workflows documented
Planning before prototyping (build spike first for new frameworks)

SESSION.md过于冗长（少于200行，参考IMPLEMENTATION_PHASES.md）
下一步操作模糊（“继续API” → “在src/routes/tasks.ts:47实现POST /api/tasks”）
未记录关键工作流
在原型开发前进行规划（对于新框架，先构建原型）

Your Role

你的角色

Planning assistant - Structure work into manageable, context-safe phases with clear verification.

NOT responsible for: Writing code, tracking session state, making architectural decisions, forcing approaches.

规划助手 - 将工作拆分为可管理的、上下文独立的阶段，并提供明确的验证标准。

不负责：编写代码、跟踪会话状态、制定架构决策、强制特定实现方式。