architecture-doc

指导在项目中编写、更新与使用架构文档(ARCHITECTURE.md)。在根目录维护架构文档,修改前后需阅读文档;文档关注最终结果与流程串联,不陷入实现细节。适用于新增/变更功能、重构、或需要理解系统整体时。

Best use case

architecture-doc is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

指导在项目中编写、更新与使用架构文档(ARCHITECTURE.md)。在根目录维护架构文档,修改前后需阅读文档;文档关注最终结果与流程串联,不陷入实现细节。适用于新增/变更功能、重构、或需要理解系统整体时。

Teams using architecture-doc should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/architecture-doc/SKILL.md --create-dirs "https://raw.githubusercontent.com/ProgrammerAnthony/Anything-Extract/main/.agents/skills/architecture-doc/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/architecture-doc/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How architecture-doc Compares

Feature / Agentarchitecture-docStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

指导在项目中编写、更新与使用架构文档(ARCHITECTURE.md)。在根目录维护架构文档,修改前后需阅读文档;文档关注最终结果与流程串联,不陷入实现细节。适用于新增/变更功能、重构、或需要理解系统整体时。

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 架构文档编写与使用

本 skill 指导在项目开发中如何编写、更新以及正确使用架构文档,使 AI 与开发者能基于同一份「系统真相」进行协作。

## 何时使用本 Skill

- 用户要求编写或更新架构文档
- 开发新功能、重构、或变更设计前,需要理解现有架构
- 完成代码/设计修改后,需要同步更新架构说明
- 用户提到「架构」「ARCHITECTURE」「系统设计」「流程」「模块关系」等

## 架构文档的位置与命名

- **路径**:项目根目录下的 `ARCHITECTURE.md`(以当前工作区/仓库根为准)
- 若项目根目录不存在该文件,在开始架构相关工作时应**先创建**该文件,再按本 skill 的规范编写内容。

## 核心原则

### 1. 修改前后必须阅读架构文档

- **修改前**:进行功能开发、重构或设计变更前,必须先阅读根目录的 `ARCHITECTURE.md`,理解当前系统边界、模块划分、数据流与关键接口。
- **修改后**:代码或设计变更若影响模块职责、接口、数据流或部署方式,必须在同一轮对话或任务中更新 `ARCHITECTURE.md`,保证文档与实现一致。

### 2. 关注最终结果,不关注中间流程

- 文档描述**系统对外表现**和**各模块的输入输出与职责**,而不是「某行代码先执行再执行」。
- 写「用户上传文档后,经解析、分段、向量化,最终可被检索」;不写「先调 A 函数再调 B 函数」。
- **不收录「按版本/阶段的迭代历史」**(如 Stage 1/2/3 Update、某日上线范围等):这类内容描述的是中间过程与历史版本,不是当前系统的最终结果。若确需保留迭代记录,应放在文档末尾的附录(如「版本迭代记录」)中,**不要**放在系统概述或核心模块前。

### 3. 关注流程与串联,不局限于细节代码

- 强调**模块间如何衔接**:谁调用谁、数据从哪来到哪去、关键 API 与事件。
- 使用流程图(如 Mermaid)、数据流说明、接口列表来体现「流程和串联」。
- **不**在架构文档中罗列具体函数名、内部变量或实现细节;若需指向代码,只到「模块/目录/职责」级别,并注明「具体文件与目录以代码仓库为准」。

### 4. 保持可被 AI 与人类共同消费

- 结构清晰、小标题明确,便于检索与引用(如「§3.3 文档处理模块」)。
- 术语一致;新增概念在首次出现时简短定义。
- 列表与表格优先,长段落拆成要点。

## 建议的文档结构

可参考项目现有 `ARCHITECTURE.md`,按需裁剪或扩展。推荐包含:

| 章节 | 内容要点 |
|------|----------|
| 系统概述 | 定位、功能亮点、技术栈(仅写当前最终能力,不写版本/阶段迭代历史) |
| 系统架构 | 高层框图(如前端 / API / 后端领域 / 存储),Mermaid 等 |
| 核心模块 | 各模块职责、输入输出、与上下游的衔接,不写具体代码 |
| 数据模型 | 核心表/概念、数据流(谁生谁用)、存储结构、关键关系 |
| API 接口 | 按领域分组的接口列表与用途,可选请求/响应要点 |
| 关键业务流程 | 端到端流程(如初始化、上传、处理、提取),用步骤与流程描述 |
| 扩展性/抽象 | Provider、可插拔点、扩展新格式/新能力的入口说明 |
| 模块与职责 | 前端/后端按路由或层的模块划分,仅职责与边界,不列文件清单 |

具体文件与目录以代码仓库为准;架构文档只描述「做什么、和谁连」,不维护完整文件树。

## 工作流:开发与架构文档的配合

1. **接到开发/重构任务时**
   - 读取项目根目录 `ARCHITECTURE.md`。
   - 确认变更会影响哪些章节(模块、接口、数据流、流程等)。

2. **设计与实现时**
   - 在实现中遵循文档中已写的边界与接口;若发现文档过时或错误,记录下来。

3. **变更完成后**
   - 再次打开 `ARCHITECTURE.md`,根据实际变更更新对应章节。
   - 若新增模块、接口或流程,在文档中补充;若删除或合并,从文档中移除或合并描述。
   - 确保流程与串联关系(含 Mermaid 图)与当前实现一致。

4. **评审或交接时**
   - 以「先读 ARCHITECTURE.md,再读代码」为推荐顺序,便于快速建立整体图景。

## 检查清单(更新架构文档后)

- [ ] 修改前已阅读 `ARCHITECTURE.md`
- [ ] 文档中描述的模块职责、接口与数据流与当前实现一致
- [ ] 无新增的实现细节(如具体函数名、内部变量);仅保留「最终结果」与「流程串联」
- [ ] 概述与核心章节**未**包含「按版本/阶段的迭代历史」(如 Stage 1/2/3 Update);若有迭代记录则仅放在文档末尾附录
- [ ] 流程图与列表已随变更更新(若有)
- [ ] 术语与章节引用一致,便于 AI 与人类检索

## 延伸阅读

- 架构文档位于**项目根目录**,文件名为 `ARCHITECTURE.md`(具体路径以当前工作区为准)。
- 更细的写作约定与反例见 [references/conventions.md](references/conventions.md)(若存在)。

Related Skills

improve-codebase-architecture

135
from ProgrammerAnthony/Anything-Extract

探索代码库以发现架构改进机会,重点让代码库更容易测试:通过“加深浅模块(deepening shallow modules)”的方式重构模块结构。适用于用户想改善架构、寻找可重构机会、整合强耦合模块、或让代码库更便于 AI 导航与理解。

write-a-skill

135
from ProgrammerAnthony/Anything-Extract

以正确的技能结构、渐进式披露与打包资源来创建新的 agent 技能。适用于用户希望创建、编写或构建新的技能。

write-a-prd

135
from ProgrammerAnthony/Anything-Extract

通过用户访谈、代码库探索与模块设计来编写 PRD(产品需求文档),然后以 GitHub issue 的形式提交。适用于用户希望编写 PRD、创建产品需求文档,或规划一个新功能。

ubiquitous-language

135
from ProgrammerAnthony/Anything-Extract

从当前对话中抽取 DDD 风格的“统一语言”术语表(ubiquitous language glossary),标记歧义,并提出规范的术语选择。保存为 `UBIQUITOUS_LANGUAGE.md`。适用于用户希望定义领域术语、构建术语表、固化用词并强化术语一致性,或提到 “domain model” / “DDD”(领域模型与 DDD)。

triage-issue

135
from ProgrammerAnthony/Anything-Extract

通过探索代码库对 Bug/Issue 进行排查归因,并基于 TDD 方式生成修复计划,同时创建对应的 GitHub issue。适用于用户报告了 bug、希望创建 issue、提到“triage”,或想调查并规划某个问题的修复方案。

tdd

135
from ProgrammerAnthony/Anything-Extract

使用 RED-GREEN-重构(red-green-refactor)循环进行测试驱动开发。适用于用户希望用 TDD 构建新功能或修复 bug,提到 “red-green-refactor”,希望使用集成测试,或询问“test-first development(先写测试)”。

request-refactor-plan

135
from ProgrammerAnthony/Anything-Extract

通过用户访谈创建一个详细的重构计划,并将其拆分成很小的提交(tiny commits),最后以 GitHub issue 的形式归档。适用于用户希望规划一次重构、创建重构 RFC,或把重构拆成安全的渐进步骤。

prd-to-plan

135
from ProgrammerAnthony/Anything-Extract

使用 tracer-bullet 竖向切片方法把 PRD 转换成多阶段的落地实施计划,并保存为本地 Markdown 文件(存放在 `./plans/`)。适用于用户希望把 PRD 拆分为多个阶段、生成实施计划、从 PRD 推导阶段计划,或提到 “tracer bullets”。

prd-to-issues

135
from ProgrammerAnthony/Anything-Extract

使用 tracer-bullet 竖向切片法,把 PRD 拆分成彼此独立、可以直接认领的 GitHub issues(并形成对应的实现工单)。适用于用户想把 PRD 转成 issues、创建实现任务,或把 PRD 拆成工作项。

grill-me

135
from ProgrammerAnthony/Anything-Extract

对用户在计划或设计方面进行“无情的质询”,直到形成共同理解,并逐一解决决策树中每个分支的依赖关系。适用于用户希望对某个计划进行压力测试、希望被严格追问他们的设计,或提到 “grill me(来烤我/质问我)”。

frontend-code-review

135
from ProgrammerAnthony/Anything-Extract

指导在项目中对前端代码(Next.js/React/TypeScript/Tailwind 等)进行结构、可维护性、性能与一致性审查,基于既定规则清单。适用于用户请求审查 .tsx/.ts/.js/.jsx 等前端文件或前端目录下的页面与组件。不用于后端代码(如 .py)。

edit-article

135
from ProgrammerAnthony/Anything-Extract

通过重组文章的段落结构、提升表达清晰度,并收紧措辞来编辑与改进文章。适用于用户希望编辑、修订或完善一份文章草稿。