代码脚手架生成

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

本命令不是主链路上的阶段：不追加 `history`，不改 `current_stage` / `next_step` / `last_phase_result`，也不为此分配功能ID。以下规则不可协商：

1. 文件必须落盘：正文要求创建的文件必须作为实际文件写入磁盘，不可仅在对话中输出（只要求在对话里输出的，照正文办）。
2. 自检必须执行：产出后按本命令的自检项逐项核对，不得以"已经很好了"为由跳过。
3. 防循环：修复只做一次，不递归。修不了的问题记进报告，继续往下走。

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

根据设计文档快速生成模块代码脚手架（骨架代码）。

工作流程

1. 阅读设计文档: 阅读 docs/02_design/api/ 和 docs/02_design/database/ 下的设计文档
2. 确定目标服务: 确认代码生成到哪个服务或应用
3. 生成代码骨架: 按技术栈生成对应的代码文件

后端生成内容（按分层架构）

Java/Spring Boot

• Controller（控制器层）: 路由、参数校验、响应封装
• Service（服务层）: 业务逻辑接口和实现
• Repository（数据层）: 数据访问接口
• DTO/VO/Entity: 数据传输对象、视图对象、实体类
• 单元测试骨架

Go

• Handler（处理器层）: HTTP 路由处理
• Service（服务层）: 业务逻辑
• Repository（仓储层）: 数据访问
• Model（模型层）: 数据结构定义
• 单元测试骨架

Python/FastAPI

• Router（路由层）: API 路由定义
• Service（服务层）: 业务逻辑
• Repository（仓储层）: 数据访问
• Schema/Model: Pydantic 模型、ORM 模型
• 单元测试骨架

Node.js

• Controller（控制器层）: 路由处理
• Service（服务层）: 业务逻辑
• Model（模型层）: 数据模型
• Middleware（中间件）: 通用中间件
• 单元测试骨架

前端生成内容

• 页面组件骨架
• API 请求服务层
• 类型定义（TypeScript）
• 状态管理模块
• 单元测试骨架

要求

<!-- @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.

1. 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.

1. 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.

1. 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 -->

• 生成的代码要遵循 docs/00_standards/coding/ 下的规范（未命中 → 提示 consider /pdlc-standard add coding/<topic>）
• 方法体用 // TODO: 待实现 占位
• 测试用例用 // TODO: 补充测试逻辑 占位
• 生成后提示用户先运行 /pdlc-tdd 补充测试

生成目标: $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 输出：

✅ 代码脚手架 完成
📦 产出：（生成到目标服务/应用目录）
👉 下一步：（本次流程结束，无后续）