Stats
Actions
Tags
From t-tools
Generates technical design documents including API design, database schema, and implementation details from PRDs, user stories, or tech research reports. Activates when user requests architecture or design docs.
How this skill is triggered — by the user, by Claude, or both
Slash command
/t-tools:t-design [方案名称][方案名称]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
运行时边界统一参考：`${CLAUDE_PLUGIN_ROOT}/protocols/runtime-boundaries.md`
运行时边界统一参考：${CLAUDE_PLUGIN_ROOT}/protocols/runtime-boundaries.md
设计生成应保持简单、当前必需、可追溯；如果需求、spec、代码或本 skill 冲突，停止并说明冲突。
仅在以下场景使用：
/t-design [方案名称]不要因为用户只是问"怎么实现""大概怎么做"就自动触发本 skill。
默认不用于以下前缀任务，除非用户明确要求补设计文档：
bugfix-refactor-doc-test-style-基于通过 /t-prd-check 的用户故事、PRD 草稿、已发布 PRD 基线、技术预研、用户已准备的仓库内资料和现有代码，生成一份可实施、可追踪、可用于 /t-task 的技术设计文档。
输出文件：
.ai/design/$ARGUMENTS.md如果未传方案名称，立即终止并提示：
请提供方案名称。例如：/t-design <feature>
上游输入（按设计类型选择）：
.ai/decision/<feature>.md — 产品立项决策简报（如存在，作为 PRD 之前的方向约束）.ai/prd/<domain>/<feature>.md — PRD 草稿（如存在，作为当前候选需求）docs/prd/<domain>/<feature>.md — 已发布 PRD 基线（如存在，作为正式需求基线）docs/user-stories/**/*.md — 相关用户故事docs/prd/00-index.md — PRD 索引.ai/tech-research/<feature>.md — 技术预研报告，可作为唯一上游需求来源可选输入：
.ai/design-ui/<feature>/ui-spec.md — 已确认 UI 规格（如存在，前端设计必须承接）${CLAUDE_PLUGIN_ROOT}/guides/core/environment-and-testing-guide.md — 环境与测试指南${CLAUDE_PLUGIN_ROOT}/guides/backend/development.md — 后端开发规范${CLAUDE_PLUGIN_ROOT}/guides/frontend/development.md — 前端开发规范${CLAUDE_PLUGIN_ROOT}/guides/core/quality.md — 质量规范AGENTS.md — Agent 规范下游产出：
.ai/design/$ARGUMENTS.md — 技术设计文档，包含：
推荐文档大小：300-500 行。超过 800 行应考虑拆分方案。
.ai/prd 草稿与 docs/prd 正式 PRD：草稿是通过 PRD Check 后进入设计、任务和实现的候选需求，正式 PRD 是已发布基线；两者存在未说明冲突时停止并要求修正草稿后再次运行 /t-prd-check [feature].ai/decision/<feature>.md，设计必须尊重其中目标用户、Scope Direction、D0/D1 产品决策和 Handoff；不得用技术方案静默改变立项结论.ai/prd 草稿且内容会影响设计，默认基于草稿继续设计，并在设计文档中标记"基于已检查 PRD 草稿"；不得要求先发布到 docs/prd.ai/prd 草稿但存在 docs/prd 正式 PRD，可基于正式 PRD 继续设计，并在设计文档中标记"未发现 PRD 草稿".ai/tech-research/<feature>.md 中的技术目标、约束和影响范围为准；执行流程与质量门禁以 ${CLAUDE_PLUGIN_ROOT}/guides/ 为准.ai/tech-research/<feature>.md/t-design 前应已准备好相关资料.ai/design-ui/<feature>/ui-spec.md，前端设计必须承接其中的页面结构、组件映射与关键状态，并在前端设计章节标记"基于已确认 UI 规格"；不得静默偏离按以下顺序建立上下文：
docs/user-stories/00-index.mddocs/prd/00-index.md.ai/decision/$ARGUMENTS.md（如存在）.ai/prd/$ARGUMENTS.md 或 .ai/prd/**/$ARGUMENTS.md（如存在）docs/prd/**/$ARGUMENTS.md（如存在）.ai/tech-research/$ARGUMENTS.md（如存在）.ai/design-ui/$ARGUMENTS/ui-spec.md（如存在）${CLAUDE_PLUGIN_ROOT}/guides/core/environment-and-testing-guide.md${CLAUDE_PLUGIN_ROOT}/guides/backend/development.md 和/或 ${CLAUDE_PLUGIN_ROOT}/guides/frontend/development.md${CLAUDE_PLUGIN_ROOT}/guides/core/quality.mdAGENTS.md$ARGUMENTS 非空.., /, \.ai/design/ 目录存在如果 .ai/design/$ARGUMENTS.md 已存在，先询问是否覆盖。
如果当前上下文里还没有足够信息，使用 AskUserQuestion 只补齐以下内容：
如果用户已经在当前对话或命令参数里给出足够信息，不要重复提问。
只搜索真实目录：
docs/user-stories/**/*.md.ai/prd/**/*.mddocs/prd/**/*.md.ai/tech-research/**/*.mddocs/design/**/*.md（如果存在相关先例）.ai/design/**/*.md（如果存在相关先例）优先做法：
GrepRead 真正相关的少量文件业务功能设计至少提取这些内容：
如果同时存在草稿和正式 PRD：
/t-prd-check [feature]如果没有找到足够的用户故事或 PRD：
.ai/tech-research/$ARGUMENTS.md纯技术方案设计至少提取这些内容：
分析真实代码结构，不要假设 backend/src 存在。重点检查：
backend/api/backend/core/backend/sdk/backend/integration-tests/frontend/src/frontend/tests/demo/e2e/（如需求涉及主故事验收）需要输出：
如果代码分析较复杂，使用 Task 启动 Explore agent，给出清晰任务：
使用 template.md 作为结构模板生成 .ai/design/$ARGUMENTS.md。
输出内容必须满足：
如果某章节不适用，保留章节并标记"不适用"及原因。
适用时必须至少包含：
{realmId}、{userId}禁止：
适用时必须至少包含：
默认标准：
涉及前端时必须至少包含：
.ai/design-ui/<feature>/ui-spec.md，说明"基于已确认 UI 规格"，并承接其页面结构、组件映射、关键状态、data-testid 或 Demo 选择器影响注意：
如果不涉及前端，显式写"不适用"与原因。
完成后在响应中明确说明：
/t-design-check $ARGUMENTS/t-html-show .ai/design/$ARGUMENTS.md 生成 HTML 可视化预览正确：
错误：
生成前逐项自检：
.ai/prd + docs/prd 混合验证 / .ai/tech-research -> ${CLAUDE_PLUGIN_ROOT}/guides/ -> code 的信息优先级/t-design [方案名称] 示例npx claudepluginhub timzaak/web-dev-skillsGenerates architecture/design documents from approved SRS docs when no prior design exists, proposing 2-3 approaches with trade-offs and securing section-by-section approval.
Generates technical design documents including architecture, API design, data models, and flow diagrams based on requirements. Applies project rules for URI, entity, and API naming conventions.
Transforms approved requirements into technical design documents covering system architecture, components, data models, interfaces, error handling, and testing strategies.