Claude Skill

pdlc-bootstrap

AI 对话式项目初始化

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download kanfu-panda-pdlc-skills-skills_pdlc-bootstrap-3cd2f02.zip · 16 KB

kanfu-panda/pdlc-skills 15 2 forks MIT Updated 21h ago

Part of kanfu-panda/pdlc-skills — 36 skills

Install

skills CLI npx skills add https://github.com/kanfu-panda/pdlc-skills/tree/main/skills/pdlc-bootstrap

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install kanfu-panda-pdlc-skills@llmmart

Git git clone https://github.com/kanfu-panda/pdlc-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole kanfu-panda/pdlc-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

AI 对话式项目初始化

⛔ IRON LAW · 不可违反的硬门禁

以下规则为不可协商的执行约束：

文件必须落盘：所有带编号（功能ID / 缺陷ID）的文档，必须作为实际文件写入磁盘，不可仅在对话中输出。
阶段必须落章：每个阶段完成后必须在状态机 docs/.pdlc-state/<feature-id>.json 追加 history，不可跳过。
测试必须存在：进入 /pdlc-implement 前，对应测试必须存在且处于红灯状态。违反则中止。
自检必须执行：段二自检为强制步骤，不得以"已经很好了"为由跳过。
防循环：段三修复为单次，不递归。无法自动修复的问题记录到报告，继续往下走。
状态必推进：成功执行某 phase 后 current_stage 必须变更。收尾时若发现 current_stage 未推进，视为失败并报错，不得静默返回（防止外层循环拿滞后的状态空转烧额度）。唯一例外：命中人工点主动 block 时，current_stage 保持不变但必须写 last_phase_result.ok=false + blocked_reason。

违反任一条 = 立即中止当前命令，输出违规详情，等待人工介入。

接收一句话项目描述，自动分析需求、选择技术栈、生成完整的项目骨架（代码目录 + 基础配置 + PDLC 文档草稿）。

前置检查

检查是否有未提交的变更（git status），如果有，提示用户先 commit 或 stash，然后继续
检查 PDLC 目录结构是否存在（docs/00_standards/ 等），如不存在则先运行 make init

功能ID分配

获取当前日期与时分秒：date +%Y%m%d、date +%H%M%S
生成功能ID：F<YYYYMMDD>-<HHMMSS>（示例形如 F20260717-122801；用执行时的真实值）
本地防撞：若该 ID 已被占用（docs/ 或 docs/.pdlc-state/ 下已有同名前缀），重新读取 date +%H%M%S 重取（生成本身有耗时、通常已跨秒；若仍同秒则 sleep 1 后再读一次，不手算时分秒，天然处理跨天边界）
从用户描述中提取项目名关键词（英文小写+连字符）

用时分秒而非当日序号，是为了多人 / 多 AI 并行时零协调也不撞号、合并零冲突。旧 F<日期>-<NN> ID 仍可解析。

执行流程

第一步：分析项目需求

根据用户的一句话描述，自动分析并生成项目计划摘要：

服务拆分：确定后端服务列表及分类
- services/ — 独立微服务（对外提供 API）
- modules/ — 内部公共模块（被其他服务依赖）
- clients/ — 客户端 SDK
应用拆分：确定前端应用列表及分类
- web/ — PC Web 应用
- h5/ — H5 移动端应用
- miniprogram/ — 微信小程序
- app/ — 原生/混合 App
技术栈选择：为每个服务/应用推荐技术栈
- 后端：Java/Spring Boot、Go、Python/FastAPI、Node/NestJS
- 前端：React/Next.js、Vue/Nuxt、微信小程序原生
目录结构预览：输出完整的目录树预览

输出格式：

## 项目计划摘要

### 后端服务
| 服务名 | 分类 | 技术栈 | 说明 |
|--------|------|--------|------|
| user-service | services | Java/Spring Boot | 用户管理 |
| ... | ... | ... | ... |

### 前端应用
| 应用名 | 分类 | 技术栈 | 说明 |
|--------|------|--------|------|
| web-admin | web | React/Next.js | 管理后台 |
| ... | ... | ... | ... |

### 目录结构预览
（输出目录树）

如果描述太模糊，主动追问 1-2 个关键问题（如"后端偏好 Java 还是 Go？"、"需要管理后台还是面向用户的前台？"），但不要超过 2 轮追问。

第二步：用户确认

将计划摘要展示给用户，等待确认。用户可以调整服务列表、技术栈等。确认后一次性生成所有内容，不再逐步确认。

第三步：生成项目骨架

确认后，按以下顺序生成：

3.1 后端服务骨架

对每个后端服务：

创建目录结构 backend/<分类>/<服务名>/
根据技术栈生成项目结构：
- Java/Spring Boot：pom.xml、application.yml、DDD 分层（controller/service/repository/model/config）、Dockerfile
- Go：go.mod、cmd/main.go、internal/（handler/service/repository/model）、Dockerfile
- Python/FastAPI：pyproject.toml、app/（main.py/routers/services/models）、Dockerfile
- Node/NestJS：package.json、src/（main.ts/modules/）、Dockerfile
生成 README.md 和 CHANGELOG.md
在 backend/<分类>/<服务名>/docs/ 下创建 api-design.md 骨架

3.2 前端应用骨架

对每个前端应用：

创建目录结构 frontend/<分类>/<应用名>/
根据技术栈生成项目结构：
- React/Next.js：package.json、next.config.js、src/（pages/components/lib/styles）、public/
- Vue/Nuxt：package.json、nuxt.config.ts、src/（pages/components/composables/assets）
- 微信小程序：project.config.json、app.json、pages/、components/、utils/
生成 README.md 和 CHANGELOG.md

3.3 PDLC 文档草稿

PRD 草稿：在 docs/01_requirements/prd/ 下创建 <功能ID>-<项目名>-prd.md
- 参考本 skill 目录下的 assets/prd-template.md 模板格式
- 文档顶部包含 PDLC 追溯头（功能ID、阶段: 需求、前置文档: 无）
- 包含：项目背景、目标用户、功能清单（基于服务拆分）、非功能需求、验收标准
架构设计草稿（per-feature ledger）：在 docs/02_design/architecture/ 下创建 <功能ID>-<项目名>-arch.md
- 参考本 skill 目录下的 assets/arch-design-template.md 模板格式
- 文档顶部包含 PDLC 追溯头（功能ID、阶段: 设计、前置文档指向 PRD）
- 包含：系统架构图（文本描述）、服务间通信方式、技术栈决策
- ℹ️ 这是 ledger 型（记录"为这个 feature 为什么这样设计"）。系统级架构总览是 surface 型，由 /pdlc-arch 维护 docs/ARCHITECTURE.md（per-feature ledger 与系统级 surface 分工互补）。
- ⚠️ 遗留检测：若发现旧版 *-arch-analysis.md（v1.0 的 v1..v5 累积模式），提示用户运行 /pdlc-arch 整合到 docs/ARCHITECTURE.md 并归档旧文件。
API 设计模板：在 docs/02_design/api/ 下为每个后端服务创建 <功能ID>-<服务名>-api.md
- 参考本 skill 目录下的 assets/api-design-template.md 模板格式
- 文档顶部包含 PDLC 追溯头
- 包含：接口列表骨架、通用请求/响应规范
数据库设计模板：在 docs/02_design/database/ 下创建 <功能ID>-<项目名>-db.md
- 参考本 skill 目录下的 assets/db-design-template.md 模板格式
- 文档顶部包含 PDLC 追溯头
- 包含：初始表结构骨架（基于服务拆分推断）
surface 入口 stub（向后兼容）：在 docs/ 根创建两个空 stub，提供 canonical surface 位置，内容留待对应技能填充
- docs/ARCHITECTURE.md：参考本 skill 目录下的 assets/architecture-overview-template.md，仅写 surface 标记 + 追溯头 + 占位说明（"运行 /pdlc-arch 生成完整架构总览"）
- docs/GLOSSARY.md：参考本 skill 目录下的 assets/glossary-template.md，仅写 surface 标记 + 占位说明（surface 型术语表，就地编辑维护，git log 审计）
- ℹ️ 仅当文件不存在时创建，不覆盖已有内容

第四步：输出完成报告

## Bootstrap 完成报告（<功能ID>）

### 生成内容汇总
| 类型 | 路径 | 说明 |
|------|------|------|
| 后端服务 | backend/services/xxx | ... |
| 前端应用 | frontend/web/xxx | ... |
| PRD 草稿 | docs/01_requirements/prd/<功能ID>-... | ... |
| 架构设计 | docs/02_design/architecture/<功能ID>-... | ... |
| API 设计 | docs/02_design/api/<功能ID>-... | ... |
| 数据库设计 | docs/02_design/database/<功能ID>-... | ... |

### 下一步操作
- 运行 `/pdlc-prd <需求描述>` 完善产品需求文档
- 运行 `/pdlc-design <设计目标>` 细化技术设计
- 运行 `/pdlc-tdd <功能描述>` 开始测试驱动开发
- 运行 `git diff` 预览所有变更
- 运行 `git checkout .` 可一键回滚所有生成内容

要求

🌐 Output language for generated artifacts

All generated artifacts (PRDs, design docs, code comments, review reports, test plans, deployment manuals, changelog entries, etc.) follow this policy:

Default — match the conversation language exactly:
- 用户用中文与 Claude 对话 → 产中文文档、中文代码注释、中文报告
- User talks to Claude in English → produce English artifacts
- User talks in another language → produce artifacts in that language
- Never silently default to a fixed language regardless of the user's input.
Explicit override always wins: when the user specifies a language for an artifact (e.g. "write the PRD in English", "用英文写 API 设计文档", "output the deploy doc in Japanese"), use that language for that artifact, regardless of conversation language.
Mixed-language requirements: if the user wants some artifacts in one language and others in a different language (common: Chinese PRD + English API docs for partners), honour each per-artifact instruction.
Uncertain: if you cannot reliably detect the conversation language, ask once before producing the first artifact.

This policy applies to content (prose, comments, headings). It does not override technical conventions like English variable names, English git commit subjects, or English error codes when the project's conventions require them.

服务名/应用名使用小写英文 + 连字符（如 user-service、web-admin）
日期使用执行当天的实际日期，格式 YYYYMMDD
生成的代码只包含骨架结构和基础配置，不包含业务逻辑实现
每个服务/应用生成独立，单个失败不影响其他
不过度设计，骨架够用即可，后续通过 /命令逐步完善

项目描述: $ARGUMENTS

段四：交接（Handoff）

命令完成后必须输出以下格式的最终消息：

✅ <阶段名> 完成：<主要产出物路径>
📊 自检：<通过数>/<总数> 通过（若有未通过，附要点）
📦 状态快照：docs/.pdlc-state/<feature-id>.json
👉 下一步：/pdlc-<next_step>
   （如果有分叉）或 /pdlc-<alt>（条件：<选择依据>）

规则：

主流程命令（写状态机的命令；下一跳见正文里「本命令的状态机取值」）必须显式输出"下一步"，不可省略
工具型命令（Layer 3）可以没有 next_step，此时输出 👉 下一步：（本次流程结束，无后续）
分叉场景必须说明选择条件，例如"若需补充测试用例 → /pdlc-tdd；若测试已齐 → /pdlc-review"

本命令的 handoff 输出：

✅ 项目骨架初始化 完成
📦 产出：backend/ + frontend/ + docs/ 骨架
👉 下一步：（本次流程结束，无后续）

Files (pdlc-skills)

assets

api-design-template.md 10 KB

# API 设计文档：[模块名称]

> 关联需求：REQ-YYYYMM-XXX
> 创建日期：
> 作者：
> 评审人：
> 状态：草稿 | 已评审 | 已批准
> 版本：v1.0

---

## 1. 概述

简要说明本模块提供的 API 能力、使用场景和接入方。

| 项目 | 说明 |
|------|------|
| 基础路径 | `/api/v1/[模块名]` |
| 生产环境 | `https://api.example.com` |
| 测试环境 | `https://api-staging.example.com` |
| 认证方式 | Bearer Token（JWT） |
| 数据格式 | JSON（`Content-Type: application/json`） |
| 字符编码 | UTF-8 |
| 接口数量 | N 个 |

---

## 2. 接口总览

| 方法 | 路径 | 描述 | 需求编号 | 权限 | 状态 |
|------|------|------|----------|------|------|
| POST | `/api/v1/orders` | 创建订单 | REQ-202603-001 | 已登录用户 | 待开发 |
| GET  | `/api/v1/orders/{orderId}` | 查询订单详情 | REQ-202603-002 | 已登录用户 | 待开发 |
| GET  | `/api/v1/orders` | 查询订单列表 | REQ-202603-003 | 已登录用户 | 待开发 |
| PUT  | `/api/v1/orders/{orderId}/cancel` | 取消订单 | REQ-202603-004 | 已登录用户 | 待开发 |

---

## 3. 通用约定

### 3.1 请求头

| Header | 必填 | 说明 |
|--------|------|------|
| `Authorization` | 是 | `Bearer <token>` |
| `Content-Type` | 是（有 Body 时） | `application/json` |
| `X-Request-Id` | 否 | 调用方传入的请求唯一标识，用于链路追踪 |
| `X-Idempotency-Key` | 是（写接口） | 幂等键，防止重复提交，建议使用 UUID |

### 3.2 统一响应结构

```json
{
  "code": 0,
  "message": "success",
  "data": {},
  "requestId": "abc-123",
  "timestamp": 1711382400000
}
```

| 字段 | 类型 | 说明 |
|------|------|------|
| `code` | int | 业务状态码，0 表示成功 |
| `message` | string | 提示信息 |
| `data` | object / array / null | 响应数据 |
| `requestId` | string | 请求唯一标识 |
| `timestamp` | long | 服务器时间戳（毫秒） |

### 3.3 分页结构

列表接口统一使用以下分页参数和响应结构：

**请求参数：**

| 参数 | 类型 | 必填 | 默认值 | 说明 |
|------|------|------|--------|------|
| `page` | int | 否 | 1 | 页码，从 1 开始 |
| `pageSize` | int | 否 | 20 | 每页数量，最大 100 |

**响应 `data` 结构：**

```json
{
  "list": [],
  "total": 100,
  "page": 1,
  "pageSize": 20,
  "totalPages": 5
}
```

### 3.4 错误码定义

| code | HTTP 状态码 | 含义 | 说明 |
|------|------------|------|------|
| 0 | 200 | 成功 | - |
| 10001 | 400 | 参数错误 | 请求参数校验失败 |
| 10002 | 401 | 未认证 | Token 缺失或已过期 |
| 10003 | 403 | 无权限 | 无操作权限 |
| 10004 | 404 | 资源不存在 | - |
| 10005 | 409 | 资源冲突 | 如重复提交 |
| 10006 | 429 | 请求过于频繁 | 触发限流 |
| 50000 | 500 | 服务器内部错误 | - |
| 50001 | 503 | 服务不可用 | 依赖服务故障 |

> 业务模块错误码在模块内自定义，格式建议：`模块码（3位）+ 错误序号（3位）`，如订单模块 `201001`。

---

## 4. 接口详情

### 4.1 创建订单

**需求编号**：REQ-202603-001

```
POST /api/v1/orders
```

**描述**：用户提交订单，系统创建订单并返回订单编号。

**权限**：已登录用户

**请求参数：**

| 参数 | 类型 | 必填 | 说明 |
|------|------|------|------|
| `addressId` | long | 是 | 收货地址 ID |
| `items` | array | 是 | 商品列表 |
| `items[].productId` | long | 是 | 商品 ID |
| `items[].quantity` | int | 是 | 购买数量，最小值 1 |
| `remark` | string | 否 | 订单备注，最大 500 字符 |

**请求示例：**

```json
{
  "addressId": 10086,
  "items": [
    { "productId": 1001, "quantity": 2 },
    { "productId": 1002, "quantity": 1 }
  ],
  "remark": "尽快发货"
}
```

**响应参数：**

| 参数 | 类型 | 说明 |
|------|------|------|
| `orderId` | long | 订单 ID |
| `orderNo` | string | 订单编号 |
| `totalAmount` | int | 订单总金额（分） |
| `status` | int | 订单状态（0=待支付） |
| `createdAt` | string | 创建时间（ISO 8601） |

**响应示例：**

```json
{
  "code": 0,
  "message": "success",
  "data": {
    "orderId": 88888,
    "orderNo": "ORD20260318000001",
    "totalAmount": 19900,
    "status": 0,
    "createdAt": "2026-03-18T10:00:00+08:00"
  },
  "requestId": "abc-123",
  "timestamp": 1742266800000
}
```

**错误码：**

| code | 说明 |
|------|------|
| 10001 | 参数校验失败（如 quantity < 1） |
| 201001 | 商品不存在或已下架 |
| 201002 | 库存不足 |
| 201003 | 收货地址不存在 |

---

### 4.2 查询订单详情

**需求编号**：REQ-202603-002

```
GET /api/v1/orders/{orderId}
```

**描述**：根据订单 ID 查询订单详情，仅允许查询本人订单。

**权限**：已登录用户

**路径参数：**

| 参数 | 类型 | 必填 | 说明 |
|------|------|------|------|
| `orderId` | long | 是 | 订单 ID |

**响应参数：**

| 参数 | 类型 | 说明 |
|------|------|------|
| `orderId` | long | 订单 ID |
| `orderNo` | string | 订单编号 |
| `status` | int | 订单状态（见枚举） |
| `totalAmount` | int | 订单总金额（分） |
| `payAmount` | int | 实付金额（分） |
| `items` | array | 商品列表 |
| `items[].productId` | long | 商品 ID |
| `items[].productName` | string | 商品名称 |
| `items[].quantity` | int | 数量 |
| `items[].unitPrice` | int | 单价（分） |
| `createdAt` | string | 创建时间 |
| `paidAt` | string / null | 支付时间 |

**订单状态枚举：**

| 值 | 含义 |
|----|------|
| 0 | 待支付 |
| 1 | 已支付 |
| 2 | 已发货 |
| 3 | 已完成 |
| 9 | 已取消 |

**响应示例：**

```json
{
  "code": 0,
  "message": "success",
  "data": {
    "orderId": 88888,
    "orderNo": "ORD20260318000001",
    "status": 0,
    "totalAmount": 19900,
    "payAmount": 19900,
    "items": [
      {
        "productId": 1001,
        "productName": "示例商品 A",
        "quantity": 2,
        "unitPrice": 9000
      },
      {
        "productId": 1002,
        "productName": "示例商品 B",
        "quantity": 1,
        "unitPrice": 1900
      }
    ],
    "createdAt": "2026-03-18T10:00:00+08:00",
    "paidAt": null
  },
  "requestId": "abc-124",
  "timestamp": 1742266900000
}
```

**错误码：**

| code | 说明 |
|------|------|
| 10003 | 无权限（非本人订单） |
| 10004 | 订单不存在 |

---

### 4.3 查询订单列表

**需求编号**：REQ-202603-003

```
GET /api/v1/orders
```

**描述**：分页查询当前用户的订单列表，支持按状态筛选。

**权限**：已登录用户

**Query 参数：**

| 参数 | 类型 | 必填 | 默认值 | 说明 |
|------|------|------|--------|------|
| `status` | int | 否 | - | 订单状态筛选，不传则查询全部 |
| `page` | int | 否 | 1 | 页码 |
| `pageSize` | int | 否 | 20 | 每页数量 |

**响应参数（`data.list[]` 单条字段）：**

| 参数 | 类型 | 说明 |
|------|------|------|
| `orderId` | long | 订单 ID |
| `orderNo` | string | 订单编号 |
| `status` | int | 订单状态（见枚举） |
| `totalAmount` | int | 订单总金额（分） |
| `createdAt` | string | 创建时间 |

**响应示例：**

```json
{
  "code": 0,
  "message": "success",
  "data": {
    "list": [
      {
        "orderId": 88888,
        "orderNo": "ORD20260318000001",
        "status": 0,
        "totalAmount": 19900,
        "createdAt": "2026-03-18T10:00:00+08:00"
      }
    ],
    "total": 1,
    "page": 1,
    "pageSize": 20,
    "totalPages": 1
  },
  "requestId": "abc-125",
  "timestamp": 1742267000000
}
```

---

### 4.4 取消订单

**需求编号**：REQ-202603-004

```
PUT /api/v1/orders/{orderId}/cancel
```

**描述**：取消待支付状态的订单，其他状态不允许取消。

**权限**：已登录用户

**路径参数：**

| 参数 | 类型 | 必填 | 说明 |
|------|------|------|------|
| `orderId` | long | 是 | 订单 ID |

**请求参数：**

| 参数 | 类型 | 必填 | 说明 |
|------|------|------|------|
| `reason` | string | 否 | 取消原因，最大 200 字符 |

**请求示例：**

```json
{
  "reason": "不想买了"
}
```

**响应示例：**

```json
{
  "code": 0,
  "message": "success",
  "data": null,
  "requestId": "abc-126",
  "timestamp": 1742267100000
}
```

**错误码：**

| code | 说明 |
|------|------|
| 10003 | 无权限（非本人订单） |
| 10004 | 订单不存在 |
| 201004 | 订单状态不允许取消（非待支付状态） |

---

## 5. 数据模型

### 5.1 OrderVO（订单视图对象）

| 字段 | 类型 | 说明 |
|------|------|------|
| `orderId` | long | 订单 ID |
| `orderNo` | string | 订单编号 |
| `status` | int | 订单状态 |
| `totalAmount` | int | 订单总金额（分） |
| `payAmount` | int | 实付金额（分） |
| `remark` | string | 备注 |
| `createdAt` | string | 创建时间（ISO 8601） |
| `paidAt` | string / null | 支付时间 |
| `items` | array\<OrderItemVO\> | 商品明细 |

### 5.2 OrderItemVO（订单明细视图对象）

| 字段 | 类型 | 说明 |
|------|------|------|
| `productId` | long | 商品 ID |
| `productName` | string | 商品名称 |
| `quantity` | int | 数量 |
| `unitPrice` | int | 单价（分） |
| `subtotal` | int | 小计（分） |

---

## 6. 限流与安全

| 接口 | 限流规则 | 说明 |
|------|----------|------|
| POST `/api/v1/orders` | 10次/分钟/用户 | 防止重复提交 |
| GET `/api/v1/orders` | 60次/分钟/用户 | 正常查询 |
| PUT `.../cancel` | 5次/分钟/用户 | 防止频繁操作 |

- 所有写接口需携带幂等键（`X-Idempotency-Key`），服务端保证相同 key 重复请求只处理一次
- 敏感字段（如金额）在日志中脱敏处理

---

## 7. 变更记录

| 版本 | 日期 | 变更内容 | 作者 |
|------|------|----------|------|
| v1.0 | | 初始版本 | |

---

## 8. 评审记录

| 日期 | 评审人 | 问题 | 处理结果 |
|------|--------|------|----------|

---

**关联文档：**
- 需求文档：`docs/01_requirements/prd/`
- 数据库设计：`docs/02_design/database/`
- 架构设计：`docs/02_design/architecture/`

arch-design-template.md 5.4 KB

# 架构设计文档：[系统/模块名称]

> 文档编号：ADR-YYYYMM-XXX
> 创建日期：
> 作者：
> 评审人：
> 状态：草稿 | 已评审 | 已批准

---

## 1. 背景与目标

### 1.1 背景
描述为什么需要这个系统/模块，解决什么问题。

### 1.2 目标
- 目标一
- 目标二

### 1.3 非目标（不在范围内）
- 不做的事情一
- 不做的事情二

---

## 2. 整体架构

### 2.1 系统架构图

```
┌─────────────────────────────────────────────────┐
│                   客户端层                        │
│  Web(React)   H5(Vue)   App(RN)   小程序          │
└──────────────────────┬──────────────────────────┘
                       │ HTTPS
┌──────────────────────▼──────────────────────────┐
│                  网关层 (API Gateway)             │
│          鉴权 / 限流 / 路由 / 日志               │
└────────┬──────────────────────┬─────────────────┘
         │                      │
┌────────▼────────┐  ┌──────────▼────────────────┐
│  用户服务        │  │  订单服务                   │
│ user-service    │  │  order-service              │
└────────┬────────┘  └──────────┬────────────────┘
         │                      │
┌────────▼──────────────────────▼────────────────┐
│              数据层                              │
│   MySQL(主从)   Redis(缓存)   OSS(文件)          │
└────────────────────────────────────────────────┘
```

### 2.2 技术选型

| 层次 | 技术 | 版本 | 选型理由 |
|------|------|------|----------|
| 后端框架 | Spring Boot | 3.2.x | 团队熟悉，生态完善 |
| 数据库 | MySQL | 8.0 | 业界标准，支持事务 |
| 缓存 | Redis | 7.x | ���性能，支持多种数据结构 |
| 消息队列 | RocketMQ | 5.x | 延迟消息，事务消息支持 |
| 注册中心 | Nacos | 2.x | 服务发现 + 配置中心 |
| 网关 | Spring Cloud Gateway | - | 统一鉴权、限流、路由 |

---

## 3. 模块设计

### 3.1 模块职责

| 模块 | 职责 | 依赖 |
|------|------|------|
| api-gateway | 鉴权、限流、路由 | user-service |
| user-service | 用户管理、认证授权 | MySQL, Redis |
| order-service | 订单全生命周期管理 | MySQL, RocketMQ |

### 3.2 服务间通信

- **同步调用**：OpenFeign（HTTP/REST）
- **异步通信**：RocketMQ 消息队列
- **数据一致性**：分布式事务（Seata）/ 最终一致性（消息补偿）

---

## 4. 数据流设计

### 4.1 核心流程

```
用户下单流程：
客户端 → API Gateway（鉴权）→ Order Service（创建订单）
  → 扣减库存（Inventory Service，同步）
  → 发送支付消息（RocketMQ，异步）
  → Payment Service（处理支付）
  → 回调 Order Service（更新订单状态）
```

### 4.2 关键数据说明

描述核心数据实体的流转过程。

---

## 5. 非功能设计

### 5.1 性能目标

| 指标 | 目标值 | 说明 |
|------|--------|------|
| 接口响应时间（P99） | < 500ms | 核心接口 |
| 系统吞吐量（TPS） | > 1000 | 下单接口 |
| 可用性 | 99.9% | 年故障时间 < 8.76h |

### 5.2 安全设计

- 认证：JWT，Token 有效期 2 小时，Refresh Token 7 天
- 授权：RBAC 角色权限控制
- 传输：全程 HTTPS
- 数据：敏感字段（手机号、身份证）AES 加密存储
- 防护：SQL 注入、XSS、CSRF、限流

### 5.3 高可用设计

- 数据库：主从复制，读写分离
- 缓存：Redis Sentinel / Cluster
- 服务：多实例部署，负载均衡
- 降级：熔断器（Sentinel），核心链路兜底

### 5.4 可观测性

- 日志：结构化日志（JSON），ELK 收集
- 监控：Prometheus + Grafana，RED 指标
- 链路追踪：SkyWalking，全链路 TraceId
- 告警：响应时间、错误率、CPU/内存阈值告警

---

## 6. 部署架构

```
生产环境：
  - 2 台 API Gateway（Nginx 负载均衡）
  - 3 台 user-service
  - 3 台 order-service
  - MySQL 一主两从
  - Redis Sentinel（3 节点）
  - RocketMQ Cluster（2 Master + 2 Slave）
```

---

## 7. 风险与决策

### 7.1 主要风险

| 风险 | 概率 | 影响 | 应对措施 |
|------|------|------|----------|
| 数据库单点故障 | 低 | 高 | 主从 + 自动切换 |
| 第三方支付超时 | 中 | 高 | 异步回调 + 定时对账 |

### 7.2 决策记录

| 决策 | 方案 | 原因 |
|------|------|------|
| 为什么选 MySQL 而非 PostgreSQL | MySQL | 团队熟悉度 + DBA 支持 |

---

## 8. 评审记录

| 日期 | 评审人 | 问题 | 处理结果 |
|------|--------|------|----------|

---

**关联文档：**
- 需求文档：`docs/01_requirements/prd/`
- API 设计：`docs/02_design/api/`
- 数据库设计：`docs/02_design/database/`

architecture-overview-template.md 1.5 KB

<!-- artifact_type: surface -->
<!-- PDLC-TRACE -->
<!-- 功能名称: 架构总览 -->
<!-- 阶段: design -->
<!-- 创建时间: <执行时的实际 ISO 8601 时间戳> -->

# 系统架构总览

> **surface 型产物**：描述系统"当前长什么样"，由 `/pdlc-arch` 就地覆盖更新。演进历史见 `git log docs/ARCHITECTURE.md`。不创建带日期/版本号的副本。

## 1. 系统全景

<!-- 文本描述 + 可选 mermaid 图。各组件 / 服务 / 模块及其职责边界 -->

```mermaid
graph TD
  A[前端] --> B[API 网关]
  B --> C[服务 1]
  B --> D[服务 2]
```

## 2. 服务拆分

| 服务 | 职责 | 数据归属 | 对外接口 |
|------|------|----------|----------|
| | | | |

## 3. 通信机制

<!-- 同步 REST/gRPC / 异步消息队列；接口版本策略；容错 -->

## 4. 数据架构

<!-- 数据库拆分；一致性方案；缓存策略 -->

## 5. 可观测性

<!-- 日志规范；监控指标（RED）；链路追踪 -->

## 6. 可扩展性

<!-- 水平扩展；负载均衡；容量规划 -->

## 7. 架构评分

| 维度 | 评分 (1-5) | 依据 |
|------|-----------|------|
| 服务拆分合理性 | | |
| 通信机制 | | |
| 数据架构 | | |
| 可观测性 | | |
| 可扩展性 | | |

## 8. 问题清单与改进建议

| 优先级 | 问题 | 建议 |
|--------|------|------|
| P0 | | |

---

> per-feature 的架构决策（"为某个 feature 为什么改架构"）记录在 `docs/02_design/architecture/<功能ID>-*-arch.md`（ledger 型），与本总览分工互补。

db-design-template.md 5.3 KB

# 数据库设计文档：[模块名称]

> 关联需求：REQ-YYYYMM-XXX
> 创建日期：
> 作者：
> 评审人：
> 状态：草稿 | 已评审 | 已批准

---

## 1. 概述

简要说明本模块涉及的数据存储设计，数据量预估，读写比例。

| 项目 | 说明 |
|------|------|
| 数据库类型 | MySQL 8.0 |
| 字符集 | utf8mb4 |
| 排序规则 | utf8mb4_general_ci |
| 存储引擎 | InnoDB |
| 预估数据量 | 100 万行/年 |
| 读写比例 | 读多写少（约 8:2） |

---

## 2. ER 关系图

```
┌──────────┐       1:N       ┌──────────────┐
│  users   │────────────────▶│   orders     │
└──────────┘                 └──────┬───────┘
                                    │ 1:N
                             ┌──────▼───────┐       N:1    ┌──────────┐
                             │ order_items  │─────────────▶│ products │
                             └──────────────┘              └──────────┘
```

---

## 3. 公共字段约定

> 所有表统一包含以下公共字段：

| 字段 | 类型 | 可空 | 默认值 | 说明 |
|------|------|------|--------|------|
| id | bigint | NOT NULL | 自增 | 主键 |
| created_at | datetime | NOT NULL | CURRENT_TIMESTAMP | 创建时间 |
| updated_at | datetime | NOT NULL | CURRENT_TIMESTAMP ON UPDATE | 更新时间 |
| created_by | varchar(64) | NULL | NULL | 创建人 |
| updated_by | varchar(64) | NULL | NULL | 更新人 |
| is_deleted | tinyint(1) | NOT NULL | 0 | 逻辑删除（0=正常，1=删除） |

---

## 4. 表结构定义

### 4.1 表名：orders（订单主表）

**用途**：存储订单主信息

| 字段 | 类型 | 可空 | 默认值 | 索引 | 说明 |
|------|------|------|--------|------|------|
| id | bigint | NOT NULL | AUTO_INCREMENT | PK | 主键 |
| order_no | varchar(32) | NOT NULL | - | UK | 订单编号 |
| user_id | bigint | NOT NULL | - | IDX | 下单用户 |
| status | tinyint | NOT NULL | 0 | IDX | 订单状态（见枚举） |
| total_amount | int | NOT NULL | 0 | - | 订单金额（分） |
| pay_amount | int | NOT NULL | 0 | - | 实付金额（分） |
| remark | varchar(500) | NULL | NULL | - | 备注 |
| paid_at | datetime | NULL | NULL | - | 支付时间 |
| ... | ... | ... | ... | ... | 公共字段 |

**枚举值说明：**

| 字段 | 值 | 含义 |
|------|-----|------|
| status | 0 | 待支付 |
| status | 1 | 已支付 |
| status | 2 | 已发货 |
| status | 3 | 已完成 |
| status | 9 | 已取消 |

### 4.2 表名：order_items（订单明细表）

**用途**：存储订单商品明细

| 字段 | 类型 | 可空 | 默认值 | 索引 | 说明 |
|------|------|------|--------|------|------|
| id | bigint | NOT NULL | AUTO_INCREMENT | PK | 主键 |
| order_id | bigint | NOT NULL | - | IDX | 所属订单 |
| product_id | bigint | NOT NULL | - | IDX | 商品 ID |
| product_name | varchar(200) | NOT NULL | - | - | 商品名称（冗余） |
| quantity | int | NOT NULL | 1 | - | 数量 |
| unit_price | int | NOT NULL | 0 | - | 单价（分） |
| ... | ... | ... | ... | ... | 公共字段 |

---

## 5. 索引设计

| 表名 | 索引名 | 类型 | 字段 | 用途 |
|------|--------|------|------|------|
| orders | pk_orders | 主键 | id | 主键 |
| orders | uk_orders_order_no | 唯一 | order_no | 订单号唯一 |
| orders | idx_orders_user_id | 普通 | user_id | 按用户查订单 |
| orders | idx_orders_status_created | 联合 | status, created_at | 按状态+时间查询 |
| order_items | idx_order_items_order_id | 普通 | order_id | 按订单查明细 |

---

## 6. 分库分表策略

> 如数据量较小可跳过本节。

| 维度 | 策略 | 说明 |
|------|------|------|
| 分库 | 按 user_id 取模 | 16 库 |
| 分表 | 按 order_id 取模 | 每库 64 表 |
| 路由规则 | user_id % 16 → 库，order_id % 64 → 表 | - |

---

## 7. 数据迁移方案

### 7.1 DDL 变更脚本

```sql
-- V1.0.0 初始化
CREATE TABLE orders (
    id BIGINT NOT NULL AUTO_INCREMENT,
    order_no VARCHAR(32) NOT NULL,
    user_id BIGINT NOT NULL,
    status TINYINT NOT NULL DEFAULT 0,
    total_amount INT NOT NULL DEFAULT 0,
    pay_amount INT NOT NULL DEFAULT 0,
    remark VARCHAR(500) DEFAULT NULL,
    paid_at DATETIME DEFAULT NULL,
    created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    created_by VARCHAR(64) DEFAULT NULL,
    updated_by VARCHAR(64) DEFAULT NULL,
    is_deleted TINYINT(1) NOT NULL DEFAULT 0,
    PRIMARY KEY (id),
    UNIQUE KEY uk_orders_order_no (order_no),
    KEY idx_orders_user_id (user_id),
    KEY idx_orders_status_created (status, created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';
```

### 7.2 回滚脚本

```sql
DROP TABLE IF EXISTS orders;
DROP TABLE IF EXISTS order_items;
```

---

## 8. 评审记录

| 日期 | 评审人 | 问题 | 处理结果 |
|------|--------|------|----------|

---

**关联文档：**
- 需求文档：`docs/01_requirements/prd/`
- API 设计：`docs/02_design/api/`
- 架构设计：`docs/02_design/architecture/`

glossary-template.md 607 B

<!-- artifact_type: surface -->

# 项目术语表

> **surface 型产物**：项目术语的权威参考，就地编辑维护。新术语随 PRD / 设计演进补充，避免术语在不同文档间漂移。

| 术语 | 定义 | 首次出现 | 备注 |
|------|------|----------|------|
| <术语> | <一句话定义> | <PRD/设计文档路径> | <别名 / 易混淆点> |

## 约定

- 术语按字母 / 拼音排序，便于查找
- 一个术语一行，定义保持一句话
- 废弃术语标注「（已废弃，见 X）」而非删除，保留可追溯性
- 演进历史见 `git log docs/GLOSSARY.md`

prd-template.md 1.6 KB

# PRD：[产品/功能名称]

## 1. 背景与目标
### 1.1 背景
### 1.2 目标

## 2. 目标用户
| 用户角色 | 描述 | 核心需求 |
|----------|------|----------|

## 3. 功能需求
### 3.1 功能列表
| 编号 | 功能 | 优先级（P0-P3） | 描述 | 验收标准 |
|------|------|-----------------|------|----------|

### 3.2 用户故事
> 作为 [角色]，我希望 [功能]，以便 [收益]。

### 3.3 用例分析
#### UC-001：[用例名称]
- **参与者：**
- **前置条件：**
- **主要流程：**
  1.
- **备选流程：**
- **后置条件：**

## 4. 非功能需求
- 性能：
- 安全：
- 可用性：
- 可扩展性：

## 5. UI/UX 需求
- 原型/设计稿链接：

## 6. 依赖与约束

### 6.1 关系（RFC#6 · feature 关系链）

本功能与已有 feature / 缺陷的关系（无则留空表格或删除本节）。6 种类型语义见 `relations.md`。

| 类型 | 目标 ID | 目标名称 | 原因 |
|------|---------|----------|------|
| extends | F20260510-100000 | user-auth-phone | 在其上加 OTP 增强层 |
| depends_on | F20260415-110000 | user-base | 需要 user 模型 |
| resolves | B20260520-110000 | - | 修复 SMS 投递失败 |

> 填写后 `/pdlc-relate set <本功能ID> <type> <目标ID>` 同步到状态机；或由 `/pdlc-prd` / `/pdlc-feature` 自动写入。

## 7. 时间计划与里程碑
| 里程碑 | 日期 | 交付物 |
|--------|------|--------|

## 8. 待确认问题
| 序号 | 问题 | 负责人 | 状态 |
|------|------|--------|------|

---
创建日期：
作者：
评审人：
状态：草稿 | 已评审 | 已批准

SKILL.md 11.6 KB

---
name: pdlc-bootstrap
description: AI 对话式项目初始化
argument-hint: [项目目录]
allowed-tools: Read, Write, Edit, Glob, Grep, Bash
layer: 3
stage: lifecycle
produces: []
requires: []
next_step: null
terminal_state: null
---

# AI 对话式项目初始化

<!-- @include templates/prompts/iron-law.md（已内联于下方，无需另读） -->
⛔ **IRON LAW · 不可违反的硬门禁**

以下规则为**不可协商**的执行约束：

1. **文件必须落盘**：所有带编号（功能ID / 缺陷ID）的文档，必须作为实际文件写入磁盘，不可仅在对话中输出。
2. **阶段必须落章**：每个阶段完成后必须在状态机 `docs/.pdlc-state/<feature-id>.json` 追加 history，不可跳过。
3. **测试必须存在**：进入 `/pdlc-implement` 前，对应测试必须存在且处于红灯状态。违反则中止。
4. **自检必须执行**：段二自检为强制步骤，不得以"已经很好了"为由跳过。
5. **防循环**：段三修复为单次，不递归。无法自动修复的问题记录到报告，继续往下走。
6. **状态必推进**：成功执行某 phase 后 `current_stage` 必须变更。收尾时若发现 `current_stage` 未推进，视为失败并报错，**不得静默返回**（防止外层循环拿滞后的状态空转烧额度）。唯一例外：命中人工点主动 block 时，`current_stage` 保持不变但必须写 `last_phase_result.ok=false` + `blocked_reason`。

**违反任一条 = 立即中止当前命令，输出违规详情，等待人工介入。**
<!-- @include-end templates/prompts/iron-law.md -->

接收一句话项目描述，自动分析需求、选择技术栈、生成完整的项目骨架（代码目录 + 基础配置 + PDLC 文档草稿）。

## 前置检查

1. 检查是否有未提交的变更（`git status`），如果有，提示用户先 commit 或 stash，然后继续
2. 检查 PDLC 目录结构是否存在（`docs/00_standards/` 等），如不存在则先运行 `make init`

## 功能ID分配

1. 获取当前日期与时分秒：`date +%Y%m%d`、`date +%H%M%S`
2. 生成功能ID：`F<YYYYMMDD>-<HHMMSS>`（示例形如 `F20260717-122801`；用执行时的真实值）
3. **本地防撞**：若该 ID 已被占用（`docs/` 或 `docs/.pdlc-state/` 下已有同名前缀），重新读取 `date +%H%M%S` 重取（生成本身有耗时、通常已跨秒；若仍同秒则 `sleep 1` 后再读一次，**不手算时分秒**，天然处理跨天边界）
4. 从用户描述中提取项目名关键词（英文小写+连字符）

> 用时分秒而非当日序号，是为了多人 / 多 AI 并行时零协调也不撞号、合并零冲突。旧 `F<日期>-<NN>` ID 仍可解析。

## 执行流程

### 第一步：分析项目需求

根据用户的一句话描述，自动分析并生成**项目计划摘要**：

1. **服务拆分**：确定后端服务列表及分类
   - services/ — 独立微服务（对外提供 API）
   - modules/ — 内部公共模块（被其他服务依赖）
   - clients/ — 客户端 SDK
2. **应用拆分**：确定前端应用列表及分类
   - web/ — PC Web 应用
   - h5/ — H5 移动端应用
   - miniprogram/ — 微信小程序
   - app/ — 原生/混合 App
3. **技术栈选择**：为每个服务/应用推荐技术栈
   - 后端：Java/Spring Boot、Go、Python/FastAPI、Node/NestJS
   - 前端：React/Next.js、Vue/Nuxt、微信小程序原生
4. **目录结构预览**：输出完整的目录树预览

输出格式：
```
## 项目计划摘要

### 后端服务
| 服务名 | 分类 | 技术栈 | 说明 |
|--------|------|--------|------|
| user-service | services | Java/Spring Boot | 用户管理 |
| ... | ... | ... | ... |

### 前端应用
| 应用名 | 分类 | 技术栈 | 说明 |
|--------|------|--------|------|
| web-admin | web | React/Next.js | 管理后台 |
| ... | ... | ... | ... |

### 目录结构预览
（输出目录树）
```

**如果描述太模糊**，主动追问 1-2 个关键问题（如"后端偏好 Java 还是 Go？"、"需要管理后台还是面向用户的前台？"），但不要超过 2 轮追问。

### 第二步：用户确认

将计划摘要展示给用户，等待确认。用户可以调整服务列表、技术栈等。
确认后一次性生成所有内容，不再逐步确认。

### 第三步：生成项目骨架

确认后，按以下顺序生成：

#### 3.1 后端服务骨架

对每个后端服务：
1. 创建目录结构 `backend/<分类>/<服务名>/`
2. 根据技术栈生成项目结构：
   - **Java/Spring Boot**：pom.xml、application.yml、DDD 分层（controller/service/repository/model/config）、Dockerfile
   - **Go**：go.mod、cmd/main.go、internal/（handler/service/repository/model）、Dockerfile
   - **Python/FastAPI**：pyproject.toml、app/（main.py/routers/services/models）、Dockerfile
   - **Node/NestJS**：package.json、src/（main.ts/modules/）、Dockerfile
3. 生成 README.md 和 CHANGELOG.md
4. 在 `backend/<分类>/<服务名>/docs/` 下创建 api-design.md 骨架

#### 3.2 前端应用骨架

对每个前端应用：
1. 创建目录结构 `frontend/<分类>/<应用名>/`
2. 根据技术栈生成项目结构：
   - **React/Next.js**：package.json、next.config.js、src/（pages/components/lib/styles）、public/
   - **Vue/Nuxt**：package.json、nuxt.config.ts、src/（pages/components/composables/assets）
   - **微信小程序**：project.config.json、app.json、pages/、components/、utils/
3. 生成 README.md 和 CHANGELOG.md

#### 3.3 PDLC 文档草稿

1. **PRD 草稿**：在 `docs/01_requirements/prd/` 下创建 `<功能ID>-<项目名>-prd.md`
   - 参考 本 skill 目录下的 `assets/prd-template.md` 模板格式
   - **文档顶部包含 PDLC 追溯头**（功能ID、阶段: 需求、前置文档: 无）
   - 包含：项目背景、目标用户、功能清单（基于服务拆分）、非功能需求、验收标准
2. **架构设计草稿（per-feature ledger）**：在 `docs/02_design/architecture/` 下创建 `<功能ID>-<项目名>-arch.md`
   - 参考 本 skill 目录下的 `assets/arch-design-template.md` 模板格式
   - **文档顶部包含 PDLC 追溯头**（功能ID、阶段: 设计、前置文档指向 PRD）
   - 包含：系统架构图（文本描述）、服务间通信方式、技术栈决策
   - ℹ️ 这是 **ledger 型**（记录"为这个 feature 为什么这样设计"）。系统级**架构总览**是 surface 型，由 `/pdlc-arch` 维护 `docs/ARCHITECTURE.md`（per-feature ledger 与系统级 surface 分工互补）。
   - ⚠️ **遗留检测**：若发现旧版 `*-arch-analysis.md`（v1.0 的 v1..v5 累积模式），提示用户运行 `/pdlc-arch` 整合到 `docs/ARCHITECTURE.md` 并归档旧文件。
3. **API 设计模板**：在 `docs/02_design/api/` 下为每个后端服务创建 `<功能ID>-<服务名>-api.md`
   - 参考 本 skill 目录下的 `assets/api-design-template.md` 模板格式
   - **文档顶部包含 PDLC 追溯头**
   - 包含：接口列表骨架、通用请求/响应规范
4. **数据库设计模板**：在 `docs/02_design/database/` 下创建 `<功能ID>-<项目名>-db.md`
   - 参考 本 skill 目录下的 `assets/db-design-template.md` 模板格式
   - **文档顶部包含 PDLC 追溯头**
   - 包含：初始表结构骨架（基于服务拆分推断）
5. **surface 入口 stub（向后兼容）**：在 `docs/` 根创建两个空 stub，提供 canonical surface 位置，内容留待对应技能填充
   - `docs/ARCHITECTURE.md`：参考 本 skill 目录下的 `assets/architecture-overview-template.md`，仅写 surface 标记 + 追溯头 + 占位说明（"运行 `/pdlc-arch` 生成完整架构总览"）
   - `docs/GLOSSARY.md`：参考 本 skill 目录下的 `assets/glossary-template.md`，仅写 surface 标记 + 占位说明（surface 型术语表，就地编辑维护，`git log` 审计）
   - ℹ️ 仅当文件不存在时创建，**不覆盖**已有内容

### 第四步：输出完成报告

```
## Bootstrap 完成报告（<功能ID>）

### 生成内容汇总
| 类型 | 路径 | 说明 |
|------|------|------|
| 后端服务 | backend/services/xxx | ... |
| 前端应用 | frontend/web/xxx | ... |
| PRD 草稿 | docs/01_requirements/prd/<功能ID>-... | ... |
| 架构设计 | docs/02_design/architecture/<功能ID>-... | ... |
| API 设计 | docs/02_design/api/<功能ID>-... | ... |
| 数据库设计 | docs/02_design/database/<功能ID>-... | ... |

### 下一步操作
- 运行 `/pdlc-prd <需求描述>` 完善产品需求文档
- 运行 `/pdlc-design <设计目标>` 细化技术设计
- 运行 `/pdlc-tdd <功能描述>` 开始测试驱动开发
- 运行 `git diff` 预览所有变更
- 运行 `git checkout .` 可一键回滚所有生成内容
```

## 要求

<!-- @include templates/prompts/output-language.md（已内联于下方，无需另读） -->
🌐 **Output language for generated artifacts**

All generated artifacts (PRDs, design docs, code comments, review reports,
test plans, deployment manuals, changelog entries, etc.) follow this policy:

1. **Default — match the conversation language exactly**:
   - 用户用中文与 Claude 对话 → 产中文文档、中文代码注释、中文报告
   - User talks to Claude in English → produce English artifacts
   - User talks in another language → produce artifacts in that language
   - **Never silently default to a fixed language regardless of the user's input.**

2. **Explicit override always wins**: when the user specifies a language for
   an artifact (e.g. "write the PRD in English", "用英文写 API 设计文档",
   "output the deploy doc in Japanese"), use that language for that artifact,
   regardless of conversation language.

3. **Mixed-language requirements**: if the user wants some artifacts in one
   language and others in a different language (common: Chinese PRD + English
   API docs for partners), honour each per-artifact instruction.

4. **Uncertain**: if you cannot reliably detect the conversation language,
   ask once before producing the first artifact.

This policy applies to **content** (prose, comments, headings). It does
**not** override technical conventions like English variable names, English
git commit subjects, or English error codes when the project's conventions
require them.
<!-- @include-end templates/prompts/output-language.md -->
- 服务名/应用名使用小写英文 + 连字符（如 user-service、web-admin）
- 日期使用执行当天的实际日期，格式 YYYYMMDD
- 生成的代码只包含骨架结构和基础配置，不包含业务逻辑实现
- 每个服务/应用生成独立，单个失败不影响其他
- 不过度设计，骨架够用即可，后续通过 /命令 逐步完善

项目描述: $ARGUMENTS

<!-- @include templates/prompts/handoff.md（已内联于下方，无需另读） -->
## 段四：交接（Handoff）

命令完成后必须输出以下格式的最终消息：

```
✅ <阶段名> 完成：<主要产出物路径>
📊 自检：<通过数>/<总数> 通过（若有未通过，附要点）
📦 状态快照：docs/.pdlc-state/<feature-id>.json
👉 下一步：/pdlc-<next_step>
   （如果有分叉）或 /pdlc-<alt>（条件：<选择依据>）
```

**规则：**
- 主流程命令（写状态机的命令；下一跳见正文里「本命令的状态机取值」）必须显式输出"下一步"，不可省略
- 工具型命令（Layer 3）可以没有 `next_step`，此时输出 `👉 下一步：（本次流程结束，无后续）`
- 分叉场景必须说明**选择条件**，例如"若需补充测试用例 → `/pdlc-tdd`；若测试已齐 → `/pdlc-review`"
<!-- @include-end templates/prompts/handoff.md -->

**本命令的 handoff 输出：**

```
✅ 项目骨架初始化 完成
📦 产出：backend/ + frontend/ + docs/ 骨架
👉 下一步：（本次流程结束，无后续）
```