
Personal Tech Design
- 5 installs
- 3 repo stars
- Updated February 26, 2026
- yuque/yuque-skills
Write a structured technical design document from a standard template and save it to your personal Yuque knowledge base.
About
Gathers requirements and formalizes them into a templated technical design doc created in a personal Yuque repo. A developer uses it to write a design or RFC for personal reference.
- Standard tech-design template loaded from references
- Optional search for related existing docs for context
Personal Tech Design by the numbers
- 5 all-time installs (skills.sh)
- Ranked #1,218 of 1,879 Documentation skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/yuque/yuque-skills --skill personal-tech-designAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 5 |
|---|---|
| repo stars | ★ 3 |
| Last updated | February 26, 2026 |
| Repository | yuque/yuque-skills ↗ |
What it does
Write a structured technical design document from a standard template and save it to your personal Yuque knowledge base.
Files
Personal Tech Design — Technical Design Document Generator (Personal)
Help the user write a structured technical design document following a standard template, then save it to their personal Yuque knowledge base.
When to Use
- User wants to write a technical design document or RFC and save it to their personal repo
- User says "帮我写技术方案", "write a tech design", "我要写个设计文档"
- User describes a feature/system and needs it formalized into a design doc for personal reference
Required MCP Tools
All tools are from the yuque-mcp server:
yuque_search— (Optional) Search for related existing docs for contextyuque_list_repos— Find the target personal knowledge baseyuque_create_doc— Create the design document
Reference
The full template is in references/template.md. Load it when generating the document.
Workflow
Step 1: Understand the Requirements
Gather from the user:
| Field | Required | Description |
|---|---|---|
| 项目/功能名称 | Yes | What is being designed |
| 背景与问题 | Yes | Why this is needed, what problem it solves |
| 目标 | Yes | What success looks like |
| 约束条件 | No | Technical constraints, timeline, budget |
| 已有方案 | No | Any existing approaches or prior art |
If the user provides a brief description, ask clarifying questions:
- "这个功能要解决什么问题?"
- "有什么技术约束吗?比如必须用某个框架、要兼容现有系统?"
- "预期的时间节点是什么?"
Step 2: (Optional) Search for Context
If relevant, search Yuque for related existing documents:
Tool: yuque_search
Parameters:
query: "<related keywords>"
type: "doc"This helps:
- Avoid duplicating existing designs
- Reference prior decisions
- Understand the current architecture
Step 3: Generate the Design Document
Load the template from references/template.md and fill in each section based on the user's input and your technical analysis.
Key sections to fill:
1. 背景 (Background) — Problem statement, current situation 2. 目标 (Goals) — What this design achieves, non-goals 3. 方案设计 (Design) — The core technical approach
- Architecture diagram description (describe in text/ASCII if needed)
- Core components and their responsibilities
- Data model / API design
- Key flows (sequence of operations)
4. 技术选型 (Tech Stack) — Why specific technologies were chosen 5. 方案对比 (Alternatives) — Other approaches considered and why they were rejected 6. 排期 (Timeline) — Milestones and estimated effort 7. 风险评估 (Risks) — What could go wrong and mitigation strategies 8. 参考资料 (References) — Related docs, links, prior art
Step 4: Review with User
Present the draft to the user before saving. Ask:
- "方案内容是否准确?有需要调整的地方吗?"
- "要补充其他技术细节吗?"
Step 5: Save to Personal Yuque
Tool: yuque_list_repos
Parameters:
type: "user"Find or ask for the target personal repo (often "技术方案" or "设计文档" or "笔记").
Tool: yuque_create_doc
Parameters:
repo_id: "<namespace>" # e.g., "username/tech-docs"
title: "[技术方案] <项目名称>"
body: "<formatted design document>"
format: "markdown"Step 6: Confirm
✅ 技术方案已创建(草稿状态)!
📄 **[[技术方案] 项目名称](文档链接)**
📚 已保存到:「个人知识库名称」
### 文档结构
- 背景与目标
- 方案设计(含 X 个核心模块)
- 技术选型对比
- 排期(预计 X 周)
- 风险评估(X 个风险点)
💡 文档为草稿状态,可随时编辑完善。Guidelines
- Write the design doc in Chinese (default) unless the user specifies English
- Be specific in the design section — include data models, API signatures, flow descriptions
- For tech stack comparison, use a table with pros/cons
- Keep the document actionable — someone should be able to implement from this doc
- If the user's requirements are vague, make reasonable assumptions and note them clearly with "【假设】" markers
- Don't over-engineer — match the design complexity to the project scope
- This skill saves to personal repos — for team repos, use
team-tech-design
Error Handling
| Situation | Action |
|---|---|
| User provides very vague requirements | Ask 2-3 targeted questions before generating |
yuque_search finds conflicting existing designs | Mention them and ask user how to reconcile |
yuque_create_doc fails | Show error, offer to output the markdown for manual copy |
| User wants to update an existing design doc | Use yuque_search to find it, then suggest creating a v2 or appendix |
| User wants to save to team repo | Suggest using team-tech-design skill instead |
技术方案模板
使用说明:根据实际项目填写以下各节。标记为 [必填] 的部分必须完成,[可选] 部分根据项目复杂度决定是否需要。
---
[技术方案] {项目/功能名称}
| 项目 | 内容 |
|---|---|
| 文档状态 | 草稿 / 评审中 / 已通过 |
| 作者 | {姓名} |
| 评审人 | {姓名列表} |
| 创建日期 | YYYY-MM-DD |
| 最后更新 | YYYY-MM-DD |
---
1. 背景 [必填]
1.1 问题描述
[当前遇到了什么问题?为什么需要这个方案?]
1.2 现状分析
[目前的系统/流程是怎样的?有什么不足?]
---
2. 目标 [必填]
2.1 核心目标
- [目标 1]
- [目标 2]
- [目标 3]
2.2 非目标(Not Goals)
- [明确不在本次范围内的事项]
2.3 成功指标
| 指标 | 目标值 | 衡量方式 |
|---|---|---|
| [指标 1] | [目标值] | [如何衡量] |
| [指标 2] | [目标值] | [如何衡量] |
---
3. 方案设计 [必填]
3.1 整体架构
[架构图描述或 ASCII 图]
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Client │────▶│ Server │────▶│ DB │
└──────────┘ └──────────┘ └──────────┘3.2 核心模块
模块 1:{名称}
- 职责:[做什么]
- 输入:[接收什么]
- 输出:[产出什么]
- 关键逻辑:[核心处理流程]
模块 2:{名称}
- 职责:[做什么]
- 输入:[接收什么]
- 输出:[产出什么]
3.3 数据模型
CREATE TABLE example (
id BIGINT PRIMARY KEY,
name VARCHAR(255) NOT NULL,
created_at TIMESTAMP DEFAULT NOW()
);3.4 接口设计
API 1:{接口名称}
- Method: POST
- Path:
/api/v1/example - Request Body:
{
"name": "string",
"type": "string"
}- Response:
{
"code": 0,
"data": { "id": 1 }
}3.5 核心流程
[描述关键业务流程的步骤]
1. 用户发起请求 2. 服务端校验参数 3. 执行核心逻辑 4. 返回结果
---
4. 技术选型 [必填]
| 组件 | 选型 | 备选方案 | 选择理由 |
|---|---|---|---|
| [组件 1] | [技术 A] | [技术 B] | [为什么选 A] |
| [组件 2] | [技术 C] | [技术 D] | [为什么选 C] |
---
5. 方案对比 [可选]
| 维度 | 方案 A(推荐) | 方案 B | 方案 C |
|---|---|---|---|
| 描述 | [简述] | [简述] | [简述] |
| 优点 | [优点] | [优点] | [优点] |
| 缺点 | [缺点] | [缺点] | [缺点] |
| 开发成本 | X 人周 | X 人周 | X 人周 |
| 维护成本 | 低/中/高 | 低/中/高 | 低/中/高 |
结论:推荐方案 A,因为 [理由]。
---
6. 排期 [必填]
| 阶段 | 内容 | 负责人 | 预计工期 | 里程碑 |
|---|---|---|---|---|
| 第一阶段 | [核心功能开发] | [姓名] | X 周 | [交付物] |
| 第二阶段 | [联调测试] | [姓名] | X 周 | [交付物] |
| 第三阶段 | [上线发布] | [姓名] | X 周 | [交付物] |
总计:预计 X 周完成。
---
7. 风险评估 [必填]
| 风险 | 影响 | 概率 | 应对措施 |
|---|---|---|---|
| [风险 1] | 高/中/低 | 高/中/低 | [如何应对] |
| [风险 2] | 高/中/低 | 高/中/低 | [如何应对] |
---
8. 参考资料 [可选]
- 相关文档 1
- 相关文档 2
- 外部参考