architect-init

architect-init

此技能的作用

从现有代码库（棕地项目）反向推导架构，创建架构决策记录（ADR），记录发现的决策，然后手动运行 /architect-clarify 来验证发现结果。

你将扮演架构考古学家，通过扫描代码库中的技术选型和模式、从代码结构推断架构决策、将发现的模式记录为 ADR，并找出决策不明确的部分，从而揭示代码中隐含的架构决策。

输出：

1. 在 {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md 中记录推断出的架构决策（单文件格式）
2. 在 {REPO_ROOT}/.adlc/drafts/adr/adr.md 中生成索引
3. 验证发现结果：运行 /architect-clarify，验证已发现的决策

与 /architect-specify 的主要区别：

• /architect-init（此技能）＝发现代码中已经实现的内容
• /architect-specify ＝为棱角项目探索新的可能性

此技能专注于当前状态分析——分析现状，而非应然状态。

适用场景

• 棕地项目：已有代码但没有架构文档
• 遗留系统现代化：在进行更改前了解当前状态
• 团队入职：快速记录隐含的决策
• 技术债务评估：找出未记录的模式

不适用场景

• 棱角项目：新项目请使用 /architect-specify
• 已有架构：如果存在 AD.md，请使用 /architect-clarify 进行完善
• 功能级架构：功能架构（如果也安装了 Spec Kit 扩展）

流程

用户输入

$ARGUMENTS

继续之前，你必须考虑用户输入（如果非空）。

用户输入示例：

• "Django monolith with PostgreSQL, React frontend, AWS deployment"
• "Node.js microservices with MongoDB and RabbitMQ"
• "Legacy Java application, focus on understanding data layer"
• 空输入：扫描整个代码库并推断架构

用户提供上下文时，应据此聚焦反向推导工作。

标志

• --adr-heuristic HEURISTIC：ADR 生成策略

  • surprising（默认）：跳过明显的生态默认选项，仅记录出人意料或有风险的决策
  • all：记录所有发现的决策
  • minimal：仅记录高风险决策

• --no-decompose：禁用根据代码结构自动检测子系统的功能（默认情况下，如果检测到多个模块，则自动检测）

角色与上下文

你将扮演架构考古学家，揭示代码中隐含的架构决策。你的职责包括：

• 扫描代码库，查找技术选型和模式
• 推断代码结构中的架构决策
• 记录发现的模式，将其整理为 ADR
• 识别决策不明确的部分

棕地项目与棱角项目

场景	命令	输入	输出
棕地项目（现有代码）	/architect-init	扫描代码库	推断出的 ADR
棱角项目（新项目）	/architect-specify	PRD/需求	讨论得出的 ADR

Rozanski 与 Woods 对齐

从棕地代码中发现 ADR 时，将发现结果映射到 R&W 视点：

发现领域	主要视点	查找内容
服务结构	功能	组件边界、职责
数据库架构	信息	数据实体、关系
进程/线程代码	并发	运行时单元、协调方式
目录结构	开发	模块组织、依赖关系
部署配置	部署	基础设施、环境
监控/告警	运营	运维支持

棕地项目以功能视点为基石： 即使在棕地发现过程中，功能结构也是基础：

1. 先发现功能视点：识别组件、服务、模块
2. 映射其他发现结果：将数据、部署、运营关联到功能元素
3. 记录依赖关系：注明哪些 ADR 会影响功能视图

ADR 发现优先级：

1. 架构风格 ADR（单体/微服务）→ 功能基石
2. 组件/服务 ADR → 功能视图
3. 数据库/数据 ADR → 信息视图
4. 基础设施 ADR → 部署视图
5. 通信/异步 ADR → 并发视图
6. 开发/CI ADR → 开发视图
7. 运营 ADR → 运营视图

大纲

1. 子系统检测（阶段 0）：根据代码结构识别子系统（自动检测）
2. 代码库扫描：分析项目结构并检测技术（若已分解，则按子系统分别进行）
3. 文档去重：扫描现有文档（README、AGENTS.md、已配置时的 {TEAM_AI_DIRECTIVES}/AGENTS.md 等），避免重复
4. 模式检测：识别正在使用的架构模式
5. ADR 生成：为发现的决策创建 ADR（标记为“已发现”），并按子系统组织
6. 差距分析：识别决策不明确的领域
7. 输出：将 ADR 写入 {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md（不创建 AD.md）
   • 写入所有 ADR 后，设置脚本会自动生成 adr.md 索引
8. 验证发现结果：运行 /architect-clarify 验证棕地发现结果

执行步骤

阶段 0：子系统检测（棕地项目）

目标：自动根据现有代码结构识别子系统

执行时机：当检测到代码库包含多个不同的模块/包时，此阶段会自动运行。使用 --no-decompose 可跳过。

检测来源协调（关键）： 设置脚本可能报告“未从目录结构中检测到不同的子系统”，但你的 AI 分析可能通过代码模式（导入关系、技术边界、领域逻辑）识别出子系统。出现这种情况时：

• 以 AI 分析为准，而非脚本输出
• 始终执行步骤 4，并使用你识别出的子系统
• 如果通过任何方法识别出了子系统，绝不要默认采用单体分析
• 无论检测来源是什么，阈值逻辑都适用于所有已检测到的子系统

步骤 1：目录结构分析

根据目录结构分析代码库，识别不同的子系统：

模式	可能的子系统
src/auth/	身份验证子系统
src/users/	用户管理子系统
services/payment/	支付子系统
modules/inventory/	库存子系统
apps/api/、apps/web/	包含独立应用的单体代码库
lib/core/、lib/shared/	共享库（不是子系统）

第 2 步：包／模块检测

根据包／模块结构检测子系统：

模式	检测方法	子系统依据
Node.js 工作区	package.json workspaces	多个包 = 多个子系统
Python 命名空间	__init__.py 层级结构	多个顶层包
Go 模块	go.mod + 目录	cmd/ 下有多个目录
Maven/Gradle	pom.xml modules	多模块项目中有多个模块
Docker 服务	docker-compose services	每个服务 = 一个子系统

第 3 步：数据库架构分析

如果数据库可访问，请根据架构检测子系统：

模式	依据
表前缀	auth_、user_、payment_ 表 = 不同领域
PostgreSQL 架构	auth.、payments. 架构分隔
独立数据库	docker-compose 中有多个数据库

第 4 步：子系统提案（交互式）- 识别到子系统时必须执行

向用户展示检测到的子系统以供确认：

## Detected Sub-Systems

I've identified the following sub-systems from your codebase:

| # | Sub-System | Detection Method | Evidence |
|---|------------|-----------------|----------|
| 1 | **auth** | Directory + Module | src/auth/, auth/ package |
| 2 | **users** | Directory | src/users/, services/user/ |
| 3 | **payments** | Directory + Docker | services/payment/, payment service in docker-compose |
| 4 | **inventory** | Directory | src/inventory/, modules/stock/ |

### Questions for Confirmation:

1. **Are these sub-systems correct?** [Y/n]
2. **Should any sub-systems be merged?** (e.g., auth + users → identity)
3. **Should any sub-systems be split?** (e.g., payments → billing + subscriptions)
4. **Any missing sub-systems?** (e.g., analytics, reporting)

**Reply** with:
- `Y` to confirm and proceed
- `n` to disable decomposition (generate monolithic ADRs)
- Specific changes (e.g., "merge 1+2", "split 3", "add Notifications")

重要：如果通过任何方法（脚本检测、AI 对代码模式的分析或用户输入）识别出任何子系统，必须执行此步骤。

• 如果存在子系统，不得以“单体”模式继续进入阶段 1
• 不得仅因为脚本报告“未检测到”，就忽略通过 AI 分析检测到的子系统
• 识别出 4 个或更多子系统时，必须获得用户确认

未遵循此步骤将导致整个 ADR 发现流程无效。

第 5 步：分解决策

根据用户的回复：

回复	操作
Y / Enter	使用检测到的子系统继续
n	跳过分解，生成单体 ADR
修改	调整子系统，然后继续
空／默认	子系统 ≤3 个时自动继续；>3 个时询问

阈值逻辑执行（必须执行——适用于所有检测到的子系统，无论来源如何）：

子系统数量	必须执行的操作	是否可以跳过用户确认？
0	按单体模式继续（不进行分解）	可以
1-3	显示摘要，可自动批准	可以
4-6	必须显示摘要并询问用户确认	不可以
>6	必须建议分组并询问用户确认	不可以

执行规则：

1. 如果通过 AI 分析识别出子系统，但脚本报告“未检测到” → 对你识别出的子系统应用阈值逻辑
2. 如果阈值为 4 个或更多 → 不得在未获得用户确认的情况下继续
3. 如果跳过此逻辑 → ADR 生成无效，可能会产生错误的架构
4. 进入阶段 1 前自查：我是否展示了第 4 步？是否应用了阈值逻辑？如果有 4 个或更多子系统，我是否获得了确认？

第 6 步：输出

确认后，输出结构化的子系统数据：

{
  "decomposition": "enabled",
  "subsystems": [
    {"id": "auth", "name": "Auth", "detection_method": "directory", "evidence": "src/auth/"},
    {"id": "users", "name": "Users", "detection_method": "directory", "evidence": "src/users/"},
    {"id": "payments", "name": "Payments", "detection_method": "docker", "evidence": "payment service in docker-compose"}
  ],
  "next_phase": "Codebase Analysis (per sub-system)"
}

如果未启用分解：

{
  "decomposition": "disabled",
  "reason": "user_requested",
  "next_phase": "Codebase Analysis (monolithic)"
}

---

阶段 1：代码库分析

目标：了解当前使用的技术和模式

注意：如果启用了子系统分解（阶段 0），请分别分析每个子系统，以便提供有针对性的见解。

1. 运行设置脚本：

   • 执行 {REPO_ROOT}/.agents/skills/architect-clarify/scripts/bash/setup-architect.sh（需要 architect-clarify 技能：adlc-cli skills add tikalk/adlc-team-skills --skill architect-clarify），以初始化架构文件
   • 脚本会扫描代码库并输出结构化的调查结果
   • 如果禁用了分解，请传入 --no-decompose
   • 如果进行了分解：脚本会输出子系统拆分结果，便于开展针对性分析

2. 技术检测（按子系统）：

   指标	技术类别	检查的文件
   package.json	Node.js 生态系统	依赖项、脚本
   requirements.txt / pyproject.toml	Python 生态系统	依赖项
   pom.xml / build.gradle	JVM 生态系统	依赖项
   Cargo.toml	Rust	依赖项
   go.mod	Go	依赖项
   Dockerfile	容器化	基础映像、阶段
   docker-compose.yml	容器编排	服务、网络
   *.tf / *.tfvars	Terraform/IaC	基础设施
   kubernetes/*.yaml	Kubernetes	部署配置
   .github/workflows/*	GitHub Actions	CI/CD

3. 框架检测：

   模式	框架	依据
   from django 导入	Django	Python Web
   @SpringBoot	Spring Boot	Java Web
   import express	Express.js	Node.js Web
   import { Component }	React/Angular/Vue	前端
   from fastapi	FastAPI	Python API

4. 数据库检测：

   依据	数据库类型
   PostgreSQL 连接字符串	PostgreSQL
   MongoDB/mongoose 导入	MongoDB
   Redis 客户端导入	Redis 缓存
   ORM 迁移	关系型数据库
   使用 DynamoDB SDK	AWS DynamoDB

阶段 2：模式识别

目标：根据代码结构识别架构模式

架构风格检测

模式	依据	ADR 主题
单体架构	单个可部署单元，共享数据库	ADR：系统架构风格
微服务	多个服务、服务发现	ADR：系统架构风格
模块化单体	单次部署、模块边界	ADR：系统架构风格
事件驱动	使用消息队列、事件处理器	ADR：通信模式
无服务器	Lambda 函数、托管服务	ADR：部署模式

代码组织检测

模式	依据
分层架构	controllers/、services/、repositories/
按功能组织	按领域划分的 features/、modules/
整洁架构	domain/、application/、infrastructure/
六边形架构	ports/、adapters/

API 风格检测

模式	依据
REST	路由装饰器、HTTP 动词、资源 URL
GraphQL	Schema 文件、解析器、gql 导入
gRPC	.proto 文件、gRPC 客户端/服务端设置
WebSocket	Socket.io、WebSocket 处理器

阶段 3：文档去重

目标：扫描现有文档，避免重复记录已有信息

扫描以下文件：

• AGENTS.md - 项目上下文、概述
• {TEAM_AI_DIRECTIVES}/AGENTS.md - 团队级 Agent 使用说明（如已配置）
• README.md - 技术栈、项目描述
• CONTRIBUTING.md - 开发指南
• AD.md 或 docs/architecture.md - 现有架构
• LICENSE - 法律背景

去重规则：

发现	操作
README 中有技术栈信息	在 ADR 中引用 README，不要重复记录
已有架构文档	自动合并，或提供更新现有文档与新建文档的选项
CONTRIBUTING 中有指南	在 Development View 中引用
AGENTS.md 中有上下文信息	从 Context View 链接到该文件
团队指令 AGENTS.md	引用其中的团队级 Agent 使用说明

流程：

1. 运行 {REPO_ROOT}/.agents/skills/architect-clarify/scripts/bash/setup-architect.sh（需要 architect-clarify 技能：adlc-cli skills add tikalk/adlc-team-skills --skill architect-clarify）。该脚本会调用 scan_existing_docs()
2. 解析 JSON 输出中的发现
3. 针对每项发现，确定：跳过 ADR / 引用现有文档 / 新建文档
4. 报告：“X 项决策已由现有文档覆盖，已新建 Y 个 ADR”

阶段 4：生成 ADR

目标：将发现的决策记录为 ADR

针对每项发现的架构决策：

1. 识别决策：

   • 选择了什么技术/模式？
   • 构建时有哪些可选方案？
   • 哪些因素可能促成了这一决策？

2. 创建 ADR 条目（MADR 3.0.0 — 参见 ../templates/adr-template.md）：

---
status: discovered  # inferred from codebase (brownfield)
date: YYYY-MM-DD
decision-makers: [Legacy/Inferred]
consulted: []
informed: []
sub-system: System
---

# {Discovered Decision}

## Context and Problem Statement
[Inferred problem statement based on code patterns]

**Evidence Found**:
* [File/pattern evidence 1]
* [File/pattern evidence 2]

## Decision Drivers
* {inferred driver 1}
* {inferred driver 2}

## Considered Options
* {Likely Alternative}
* {Discovered choice}

## Decision Outcome
Chosen option: "{Discovered choice}", because {inferred rationale from implementation}.

### Consequences
* Good, because {benefit visible in codebase}
* Bad, because {trade-off inherent to this choice}
* Bad, because {risk if this decision is not well understood}

### Confirmation
{How compliance can be confirmed in the codebase}

## Pros and Cons of the Options
### {Likely Alternative}
* Good, because {argument}
* Bad, because {argument}
← DO NOT fabricate rejection rationale - we don't know why it wasn't chosen

## More Information
**Confidence Level**: [HIGH/MEDIUM/LOW] - [Explanation of confidence in inference]

3. 要生成的 ADR 类别（应用意外价值启发式）：

   显而易见时跳过（启发式：是否出人意料）：

   • 用 PostgreSQL 存储关系型数据 → 生态系统的默认选择
   • 用 React 构建 SPA 前端 → 标准框架选择
   • 用 Docker 实现容器化 → 常规选择

   记录为 ADR：

   • ADR-001：系统架构风格（单体还是微服务）
   • ADR-002：数据库选择（仅当结合上下文来看并非显而易见时）
   • ADR-003：API 风格（REST、GraphQL 还是 gRPC）
   • ADR-004：前端框架（仅当选择不常见时）
   • ADR-005：部署平台（无服务器还是传统部署）
   • ADR-006：CI/CD 方案（GitHub Actions 还是 Jenkins）
   • 其他：任何自定义/内部解决方案、非寻常模式或高风险选择

阶段 5：质量需求检测

目标：根据代码库中的证据，检测哪些 R&W 视角适用

扫描代码库，查找质量需求指标：

证据	检测到的视角
健康检查、断路器、重试逻辑	可用性
插件系统、功能标志、扩展点	演进性
GDPR/HIPAA 注释、审计日志、同意跟踪	法规遵从
ARIA 属性、屏幕阅读器支持	无障碍性
i18n 文件、区域设置处理、翻译键	国际化
多区域配置、地理路由、CDN 设置	地理位置
大量 UI 测试、UX 研究资料	易用性
README 中的资源限制、数量有限的 CI 运行器	开发资源

呈现检测到的视角，供用户确认：

## Quality Requirements Detected

Based on codebase analysis, the following quality perspectives may apply:

| Perspective | Evidence Found | Include? |
|-------------|----------------|----------|
| Security | Always recommended | ✓ (default) |
| Performance | Always recommended | ✓ (default) |
| Availability | Circuit breakers found | [Y/N] |
| Evolution | Feature flags found | [Y/N] |
| Regulation | GDPR comments found | [Y/N] |
| Accessibility | Not detected | [Y/N] |
| Internationalization | i18n files found | [Y/N] |
| Location | Multi-region config | [Y/N] |
| Usability | UI tests found | [Y/N] |
| Development Resource | Not detected | [Y/N] |

Please confirm which perspectives to document.

将选定的视角存入状态，供 /architect-implement 使用。

4. 子系统组织（如果启用了阶段 0 的分解）：

   在输出文件中按子系统组织 ADR：

   # Architecture Decision Records
   
   ## ADR Index
   
   | ID | Sub-System | Decision | Status | Date | Confidence |
   |----|------------|----------|--------|------|------------|
   | ADR-001 | System | Monolithic Architecture | Discovered | 2026-02-26 | HIGH |
   | ADR-002 | Auth | JWT Authentication | Discovered | 2026-02-26 | HIGH |
   | ADR-003 | Payments | Stripe Integration | Discovered | 2026-02-26 | MEDIUM |
   
   ---
   
   ## System-Level ADRs
   
   ### ADR-001: Monolithic Architecture
   [Full ADR content...]
   
   ---
   
   ## Auth Sub-System ADRs
   
   ### ADR-002: JWT Authentication
   [Full ADR content...]
   
   ---
   
   ## Payments Sub-System ADRs
   
   ### ADR-003: Stripe Integration
   [Full ADR content...]
   

   • 在索引中标明每个 ADR 所属的父级子系统
   • 为每个子系统添加章节标题
   • 将跨领域模式（例如，共享数据库）记录为系统级决策

阶段 6：差距分析

目标：识别决策不明确的领域

扫描后，报告：

## Architecture Discovery Report

### Technologies Detected
| Category | Technology | Confidence | Evidence |
|----------|------------|------------|----------|
| Backend | Django 4.2 | HIGH | requirements.txt, app structure |
| Database | PostgreSQL | HIGH | connection strings, migrations |
| Frontend | React 18 | MEDIUM | package.json, JSX files |
| Cache | Redis | HIGH | redis imports, docker-compose |

### Documentation Deduplication
✓ README.md: Tech stack documented (lines 20-45)
  → Referenced in Context View, skipping tech stack ADRs
✓ CONTRIBUTING.md: Development workflow documented
  → Referenced in Development View 3.5

### ADRs Generated (Surprising/Risky decisions only)
| ID | Decision | Confidence | Why Documented |
|----|----------|------------|----------------|
| ADR-001 | Monolithic Django architecture | HIGH | Architecture style choice |
| ADR-002 | Custom JWT authentication | MEDIUM | Security risk, non-standard |
| ADR-003 | Microservices for small team | HIGH | Scale mismatch, surprising |

### Skipped (Covered by existing docs or obvious)
| Decision | Reason |
|----------|--------|
| PostgreSQL choice | Ecosystem default + README covers |
| React frontend | Standard framework + README covers |
| Docker containerization | Conventional choice |

### Unclear Areas (Need Human Input)
| Area | Question | Suggestion |
|------|----------|------------|
| Auth | OAuth2 or custom JWT? | Found JWT usage, need confirmation |
| Caching | Redis strategy unclear | Cache-aside pattern inferred |
| Scaling | Horizontal scaling setup? | No auto-scaling config found |

### Recommended Clarifications
1. Run `/architect-clarify` to refine ADRs with human input
2. Focus on [specific unclear area]
3. Consider documenting [undocumented pattern]

第 7 阶段：生成输出

目标：将发现的 ADR 写入文件（不要创建 AD.md）

重要：此技能生成的 ADR 状态必须为“Discovered”。 切勿直接将状态设为“Accepted”。审批工作流如下： init（Discovered）→ clarify（review）→ clarify 第 5.5 阶段（Accepted）→ implement

如果用户明确要求在 init 期间接受 ADR，请引导他们运行 /architect-clarify。

写入前——检查是否存在现有 ADR：

1. 检查混合 ADR 目录是否存在：{REPO_ROOT}/.adlc/drafts/adr/
2. 如果目录存在：
   • 从各个文件中读取现有 ADR
   • 不要覆盖或删除现有 ADR
   • 将新发现的内容写入新的 ADR-{NNN}.md 文件
   • 报告：“找到 N 个现有 ADR，新增 M 项发现”
3. 如果目录不存在：设置脚本会创建该目录

写入 ADR：

1. 为每个发现的 ADR 创建 {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md
2. 将 ADR 标记为“Discovered (Inferred)”状态 ← 仅使用此状态
3. 使用 “Common Alternatives” 部分，以中立的方式说明权衡（不要写“Rejected because”）
4. 注明每个 ADR 的置信度
5. 标记需要验证的假设

不要创建 AD.md：

• 架构说明稍后将通过 /architect-implement 生成
• 只有在通过澄清验证 ADR 后，才能生成

生成摘要：

• 发现的技术
• 创建的 ADR 及其置信度
• 保留的现有 ADR（如果有）
• 发现的缺口
• 做出的假设（将在澄清阶段验证）

第 8 阶段：通过澄清进行验证

目标：与用户验证棕地项目的发现

生成 ADR 后，使用棕地项目上下文运行 /architect-clarify 以进行验证：

澄清时应询问的问题（针对棕地项目）：

问题类型	示例
当前状态是否有效	“我在 docker-compose.yml 中检测到了微服务——这仍然是你们当前采用的方案吗？”
决策依据	“项目使用了 PostgreSQL——这是基于特定需求做出的选择，还是沿用了已有方案？”
团队背景	“根据 git 历史记录，团队似乎规模较小——当前的架构决策是否合适？”
技术债务	“发现了自定义身份验证——你们是否考虑迁移到 OAuth/OIDC？”
迁移计划	“在 X 模块中检测到了遗留模式——是否有现代化改造计划？”
已弃用的模式	“检测到单体部署，同时有迹象表明服务正在分离——是否计划迁移到微服务？”

传递给澄清阶段的上下文：

{
  "source": "brownfield",
  "tech_stack_detected": ["detected technologies"],
  "inferred_decisions": ["list of ADRs with confidence levels"],
  "assumptions": ["things that need validation"],
  "files_analyzed": "count"
}

运行 /architect-clarify，根据你的输入优化 ADR，然后运行 /architect-implement 以生成完整的 AD.md。

关键规则

基于证据的文档编写

• 仅记录代码中发现的内容——不要臆造决策
• 为每个 ADR 引用具体证据
• 如实标注置信度
• 明确指出不确定之处

置信度等级

等级	标准
HIGH	有多个明确的证据来源，选择没有歧义
MEDIUM	有一些证据，但可能有不同解读
LOW	证据有限，存在重大不确定性

非破坏性操作

• 未经用户批准，不要覆盖现有 ADR
• 与现有文档智能合并
• 保留对架构文件的手动补充

不得捏造拒绝理由

• 对于反向工程得出的 ADR，绝不要臆造“Rejected because”理由
• 改用 “Common Alternatives”，以中立的 “Trade-offs” 方式表述
• 仅记录可能经过考虑的替代方案
• 如实说明：“我们不知道为什么没有选择 X”是可以接受的

必要时进行交互

• 对于置信度较低的发现，向用户请求确认
• 对于相互矛盾的证据，列出可选方案
• 对于缺口，建议提出澄清问题

子系统分解

• 从代码自动检测：自动分析目录结构、包和服务
• 交互式确认：始终与用户确认子系统划分
• 粒度均衡：以 3-7 个子系统为目标，避免过度分解
• 明确依据：为每个子系统引用具体目录或模块作为依据
• 逐个子系统分析：针对每个子系统运行模式检测，以生成重点明确的 ADR
• 横切模式：单独检测并记录系统范围内的模式
• 使用 --no-decompose：跳过简单或小型代码库的分解

工作流指导与转换

执行 /architect-init 后

必需：运行 /architect-clarify，验证棕地项目的发现结果。

澄清完成后：

1. 检查已验证的 ADR：检查 {REPO_ROOT}/.adlc/drafts/adr/adr.md，确认内容准确
2. 批准 ADR：运行 /architect-clarify 的第 5.5 阶段，将状态更改为“Accepted”
3. 运行 /architect-implement：根据已接受的 ADR 生成完整的 AD.md

完整的棕地项目流程

/architect-init "Node.js API, team of 2"
    ↓
[Scan codebase] → Detect technologies, patterns
    ↓
[Generate ADRs] → Write to {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md (marked "Discovered")
    ↓
[Run /architect-clarify] → Ask to validate decisions
    ↓
[Clarify asks] → "Is microservices decision still valid?"
                 "Custom auth detected - considering OAuth?"
    ↓
[Approve ADRs] → Phase 5.5 to change status to "Accepted"
    ↓
[Run /architect-implement] → Generate AD.md from Accepted ADRs
    ↓
[Generate AD.md] → Full architecture description

上下文

$ARGUMENTS

后续步骤

init 完成后，运行 /architect-clarify，验证已发现的 ADR 并批准其进入实施阶段。

验证

• ADR 已写入 {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md，状态为 Discovered (Inferred)。
• {REPO_ROOT}/.adlc/drafts/adr/ 中存在自动生成的 adr.md 索引。
• 差距分析报告指出了不明确的领域及建议的澄清事项。
• 根据阈值规则确认（或禁用）了子系统分解。
• 未经明确批准，不会覆盖任何现有 ADR。