candid-init

Technical.md 和配置生成器

你是一名资深技术架构师，正在进行全面的代码库审计。你的任务是生成一份 Technical.md，其中：

1. 引用此项目中的具体文件和路径
2. 记录架构决策以及如何贯彻这些决策
3. 记录代码中实际存在的模式并提供示例
4. 找出当前状态与最佳实践之间的差距

输出应让人感觉出自一位花了数天时间了解此特定代码库的人，而不是通用模板。

工作量级别

级别	时间	分析	输出
quick	~30 sec	使用 Grep/find 检测模式	~50 lines
medium	~1-2 min	+ 阅读 5-8 个关键文件	~150 lines
thorough	~5-10 min	+ 由子 Agent 阅读所有文件	~500 lines

默认：thorough

Thorough 模式会运行 5 个并行分析子 Agent（步骤 6），然后运行 5 个并行生成子 Agent（步骤 9），最后进行综合。

---

工作流

步骤 1：检查现有文件（快速失败）

ls .candid/Technical.md .candid/config.json 2>/dev/null

如果 Technical.md 已存在，询问用户：“覆盖”、“创建为 .new”或“取消” 如果 config.json 已存在，询问用户：“覆盖”、“保留现有文件”或“取消”

步骤 2：确定工作量级别

检查是否存在 --effort 标志。默认值为 thorough。

步骤 3：检测框架

cat package.json 2>/dev/null | head -50
ls requirements.txt pyproject.toml go.mod Cargo.toml 2>/dev/null

检测条件	框架
package.json 中包含 react/next/vue	React
package.json 中不包含前端框架	Node.js
requirements.txt 或 pyproject.toml	Python
go.mod	Go
Cargo.toml	Rust
无	Minimal

步骤 4：检测现有工具

ls .eslintrc* eslint.config.* .prettierrc* biome.json tsconfig.json .flake8 ruff.toml 2>/dev/null

**重要：**如果存在代码检查工具，请跳过它们已强制执行的所有规则。Technical.md 应重点关注代码检查工具无法检查的内容：架构、领域规则和模式。

---

步骤 5：深入分析代码库

这是生成项目专属规则的核心。根据工作量级别执行。

5.1 目录结构分析（所有级别）

# Get full directory tree (3 levels)
find . -type d -maxdepth 3 | grep -v node_modules | grep -v .git | grep -v __pycache__ | grep -v venv | grep -v dist | grep -v build | sort

# Identify key directories
ls -d src/*/ lib/*/ app/*/ packages/*/ 2>/dev/null | head -20

提取：

• 分层结构：是否存在 controllers/、services/、repositories/、models/？
• 功能结构：是否存在 features/、modules/ 或领域目录？
• 共享代码：是否存在 shared/、common/、utils/、lib/？

5.2 文件命名模式（所有级别）

# File suffixes
find . -type f \( -name "*.ts" -o -name "*.tsx" -o -name "*.js" \) 2>/dev/null | grep -v node_modules | sed 's/.*\///' | grep -oE '\.[a-z]+\.(ts|tsx|js)$' | sort | uniq -c | sort -rn | head -15

# Class/component naming
grep -rhoE "^export (default )?(class|function|const) [A-Z][a-zA-Z]+" --include="*.ts" --include="*.tsx" 2>/dev/null | grep -v node_modules | head -30

5.3 导入关系图分析（Medium + Thorough）

这对架构规则至关重要。

# What imports what - build mental model of dependencies
grep -rh "^import.*from" --include="*.ts" --include="*.tsx" 2>/dev/null | grep -v node_modules | grep -oE "from ['\"][^'\"]+['\"]" | sort | uniq -c | sort -rn | head -30

# For each layer dir (controllers, services, ...), check what it imports — flags layer violations:
grep -rh "^import.*from" src/controllers/ --include="*.ts" 2>/dev/null | grep -v node_modules | head -20

# Check for cross-module imports (feature A importing from feature B)
grep -rh "^import.*from.*features/" --include="*.ts" 2>/dev/null | grep -v node_modules | head -20

# Path aliases in use
grep -rh "from '@/\|from '~/\|from 'src/\|from '#" --include="*.ts" --include="*.tsx" 2>/dev/null | grep -v node_modules | head -10

5.4 架构模式检测（仅 Thorough）

检测 barrel 导出（index.ts 数量及示例）、依赖注入、中间件/装饰器模式以及领域专属目录——命令见 reference/analysis-commands.md。

5.5 错误处理分析（Medium + Thorough）

# Custom error classes
grep -rh "class.*Error\|extends Error\|extends.*Error" --include="*.ts" 2>/dev/null | grep -v node_modules | head -15

# Error response patterns
grep -rh "res.status.*json\|throw new\|catch.*error" --include="*.ts" 2>/dev/null | grep -v node_modules | head -20

# Error handling location (where are errors caught?)
grep -rl "try.*catch\|\.catch(" --include="*.ts" 2>/dev/null | grep -v node_modules | head -20

5.6 测试模式（Medium + Thorough）

# Test file locations
find . -name "*.test.*" -o -name "*.spec.*" -o -name "*_test.*" 2>/dev/null | grep -v node_modules | head -20

# Test organization (colocated vs separate)
ls -d **/__tests__/ **/tests/ test/ tests/ 2>/dev/null | head -10

# Test naming patterns
grep -rh "describe(\|it(\|test(" --include="*.test.*" --include="*.spec.*" 2>/dev/null | grep -v node_modules | head -15

# Mock patterns
grep -rh "jest.mock\|vi.mock\|sinon\|@Mock" --include="*.test.*" --include="*.spec.*" 2>/dev/null | grep -v node_modules | head -10

5.7 API 模式（Medium + Thorough，适用于 Node/Backend）

检测路由定义、验证模式（zod/yup/joi/装饰器）和身份验证中间件——命令见 reference/analysis-commands.md。

5.8 React 模式（Medium + Thorough，适用于 React）

检测自定义钩子、状态管理库、组件模式（memo/forwardRef/lazy/Suspense）以及事件处理函数命名——命令见 reference/analysis-commands.md。

5.9 TypeScript 分析（仅 Thorough）

检测 tsconfig 严格性、any/as any 使用次数，以及 interface 与 type 的偏好——命令见 reference/analysis-commands.md。

---

步骤 6：文件分析

文件分析方式取决于工作量级别。

Medium 模式：阅读 5-8 个关键文件

使用 Read 工具检查有代表性的文件：

• 入口点（1-2 个）：src/index.ts、app/layout.tsx
• 导入次数最多的模块（2-3 个）：根据导入分析确定
• 每层选一个文件（2-3 个）：控制器、服务、存储库

提取：命名模式、错误处理、导入组织方式以及可引用的示例。

深入模式：子 Agent 全面分析

并行启动 5 个 Explore 子 Agent（Task 工具，subagent_type: "Explore"）。阅读 reference/analysis-prompts.md（相对于此技能的路径），查看每个 Agent 的确切提示词：

1. 架构与导入
2. 命名与风格
3. 错误处理与安全
4. 测试模式
5. 框架特定分析（React 或 Node 变体）

每个 Agent 都会返回拟定规则，并提供 file:line 证据。

综合 Agent 结果

所有 Agent 完成后，综合其发现：

1. 收集每个 Agent 提出的所有规则
2. 去重相似规则（保留证据最充分的规则）
3. 按以下标准确定优先级：
   • 有多少文件遵循该模式（一致性）
   • 安全影响
   • 架构重要性
4. 为 Technical.md 选出最重要的 40–60 条规则
5. 按类别整理（架构、命名、错误处理等）

---

第 7 步：架构分析（仅限深入模式）

此步骤将生成架构规则，让 Technical.md 更有价值。

7.1 层边界分析

根据目录结构和导入分析，确定：

Layer Structure Detected:
├── src/controllers/  → HTTP layer (should only import services)
├── src/services/     → Business logic (can import repos, not controllers)
├── src/repositories/ → Data access (can import models, not services)
└── src/models/       → Data models (no internal imports)

生成类似以下的规则：

• "src/controllers/ 中的控制器不得直接从 src/repositories/ 导入内容，必须经由服务"
• "src/services/ 中的服务不得从 src/controllers/ 导入内容"

7.2 模块边界分析

如果检测到基于功能的结构（例如 src/features/auth/、src/features/billing/、src/shared/），则以相同方式生成跨模块规则，例如：“功能模块不得直接相互导入；跨领域关注点应使用 src/shared/。”

7.3 检测违规情况

查找代码库中的实际违规情况：

# Example: Find files in controllers/ that import from repositories/
grep -rl "from.*repository\|from.*repositories" src/controllers/ 2>/dev/null

如果发现违规情况，请注明：

• “发现架构违规：src/controllers/UserController.ts 直接导入了 UserRepository。请改为使用 UserService。”

---

第 8 步：差距分析（仅限深入模式）

将检测到的模式与最佳实践进行比较。为每个类别找出差距。

类别	最佳实践	检查项	缺失时的建议
安全	在边界验证输入	查找 zod/joi/yup	“考虑在 API 边界使用 Zod 验证输入”
安全	使用参数化查询	检查原始 SQL 字符串	“在 X 中发现原始 SQL。请使用参数化查询。”
安全	身份验证中间件	检查路由保护	“并非所有路由似乎都有身份验证检查”
安全	密钥管理	检查是否存在硬编码值	“在 X 中发现可能硬编码的密钥”
错误处理	自定义错误类	查找 extends Error	“未发现自定义错误类。考虑添加 AppError 层次结构。”
错误处理	一致的错误格式	检查响应模式	“不同文件中的错误响应格式不一致”
错误处理	错误日志记录	检查日志记录器的使用情况	“在 X 个文件中捕获了错误但未记录日志”
测试	存在测试	查找测试文件	“未发现 src/services/ 的测试”
测试	测试组织	检查模式	“测试命名不一致（混用了 .test.ts 和 .spec.ts）”
TypeScript	严格模式	检查 tsconfig	“未启用严格模式。考虑为新代码启用。”
TypeScript	避免 any	统计 any 的使用次数	“发现 47 处 any。考虑添加类型或使用 unknown。”

---

第 9 步：生成 Technical.md（深入模式：使用生成子 Agent）

对于深入模式，通过并行启动生成子 Agent，生成一份全面的 约 500 行 Technical.md。每个 Agent 负责编写一个主要章节，并提供完整细节。

Claude Code 的生成策略

每个部分都由专注的子 Agent 根据特定分析结果独立生成，最终整合时将各部分合并，确保内容不会被截断——这样 Claude Code 就能生成篇幅较长、内容详尽的输出。请同时启动这些 Agent。

Agent	部分	~行数
1	架构	~100
2	命名与风格	~80
3	错误处理与日志记录	~80
4	测试	~80
5	安全与框架	~100

阅读 reference/generation-prompts.md（相对于此技能的路径），并通过 Task 并行启动全部 5 个 Agent；在提示词中相应位置粘贴相关分析结果。

整合生成的部分

所有生成 Agent 完成后，收集各部分，并按以下顺序合并为一个约 500 行的文件：（1）标题部分——标题、“[project] 的标准。根据全面的代码库分析于 [date] 生成。”以及分析摘要要点（已分析文件、检测到的模式、发现的违规项、识别出的缺口）；（2）五个 Agent 生成的部分，各部分之间以 --- 分隔；（3）与最佳实践的差距表（领域 | 当前状态 | 建议 | 优先级）；（4）附录：文件引用，列出关键引用文件；（5）页脚行：由 candid-init 生成。运行 /candid-validate-standards 检查规则质量。

中等／快速模式：精简输出

中等模式：生成约 150 行（上述内容的精简版） 快速模式：生成约 50 行（仅包含核心规则）

为每条规则标记 [observed N/M]（通过 grep 计数）或 [recommended]，并列出已知例外。

规则质量标准

每条规则都必须：

1. 引用此项目中的具体路径

   • 好：“src/services/ 中的服务不得导入 src/controllers/ 中的内容”
   • 不好：“服务不应导入控制器”

2. 包含代码库中的实际示例

   • 好：“事件处理程序采用 handle* 模式（例如，src/components/LoginForm.tsx 中的 handleUserLogin）”
   • 不好：“事件处理程序应使用一致的命名方式”

3. 可衡量／可验证

   • 好：“函数不得超过 50 行”
   • 不好：“函数应保持简短”

4. 如果当前状态与规则不符，注明当前状态

   • 好：“使用自定义错误类。（目前尚未实现——参见差距部分）”
   • 不好：“使用自定义错误类”

5. 标记来源和遵循情况

   • [observed 12/14]——14 个相关文件中有 12 个遵循此约定。将 2 个违规文件列为 Known exceptions: path1, path2，以便审查时只标记新的违规项，而非现有代码中的问题。
   • [recommended]——此代码库尚未采用的最佳实践。此类规则也必须出现在差距表中；审查时应将其作为建议提出，而不是硬性违规。
   • 遵循率低于 60% 的规则不得标记为 [observed]——应将其移至差距表。

不要包含的内容

• 由代码检查工具强制执行的规则（如果检测到 ESLint／Prettier）
• 适用于任何项目的通用建议
• 含义模糊的词语：“恰当”“适当”“整洁”“良好”“最佳实践”
• 没有具体路径或示例的规则

---

第 10 步：生成 config.json

通过代码库自动检测可识别的信息，并询问用户的偏好，以构建项目配置。始终将 "version": 1。

**注意：**初始化期间不会设置 focus 字段——它是每次审查时使用的选项（例如，发布前使用 --focus security），而不是项目级默认值。

10.1：检测合并目标分支

运行：

git branch -a 2>/dev/null

将检测到的分支映射到分支策略：

检测结果	策略	mergeTargetBranches
存在 develop 分支	Git Flow	["develop", "main"]
存在 trunk 分支	基于主干开发	["trunk"]
同时存在 main 和 master	迁移	["main"]
存在 main（没有 develop/trunk）	GitHub Flow	["main"]
存在 master（没有 main）	遗留	["master"]
未检测到任何分支	默认	["main"]

检查本地和远程分支名称（例如，remotes/origin/develop 也计为 develop）。

使用 AskUserQuestion 确认：

问题：“检测到 [strategy] 分支策略。使用 [detected branches] 作为合并目标分支吗？”

选项：

1. “是，使用 [detected branches]” → 使用检测到的值
2. “否，让我指定” → 后续提示输入自定义分支列表
3. “跳过 — 使用默认值” → 省略 mergeTargetBranches 字段（candid-review 默认使用 ["main", "stable", "master"]）

10.2：检测排除模式

扫描项目，查找评审时应排除的文件和目录。检查：

# Generated files
find . -maxdepth 4 \( -name "*.generated.ts" -o -name "*.generated.js" -o -name "*.g.dart" \) 2>/dev/null | head -5

# Vendor directories
ls -d vendor/ third_party/ 2>/dev/null

# Build output
ls -d dist/ build/ .next/ out/ 2>/dev/null

# Minified files
find . -maxdepth 4 \( -name "*.min.js" -o -name "*.min.css" \) 2>/dev/null | head -5

根据检测结果列出排除模式：

• *.generated.ts / *.generated.js — 如果发现生成文件
• vendor/* — 如果发现 vendor 目录
• dist/* / build/* / .next/* — 如果发现构建输出目录
• *.min.js / *.min.css — 如果发现压缩文件

如果检测到模式： 使用 AskUserQuestion：

问题：“检测到评审时应排除的文件：\n[逐条列出每种模式及示例文件]\n\n使用这些排除模式吗？”

选项：

1. “是，使用检测到的模式” → 使用检测到的列表
2. “是，并添加更多” → 使用检测到的列表 + 后续提示输入其他模式
3. “否，跳过排除项” → 省略 exclude 字段

如果未检测到模式： 静默跳过此步骤。省略 exclude 字段。

10.3：提示选择语气

使用 AskUserQuestion：

问题：“你更喜欢哪种评审语气？”

选项：

1. “严厉 — 直言不讳，不粉饰问题”
2. “建设性 — 体贴地提供反馈，同时仍然直接指出问题”
3. “跳过 — 每次评审时再决定”

如果选择“严厉” → 设置 "tone": "harsh"。如果选择“建设性” → 设置 "tone": "constructive"。如果选择“跳过” → 省略 tone 字段（candid-review 将在每次评审时提示，或使用用户配置）。

10.4：提示是否自动提交

使用 AskUserQuestion：

问题：“评审期间应用修复后，是否自动提交？”

选项：

1. “是 — 自动提交已应用的修复”
2. “否 — 我会手动提交”（默认）

如果选择“是” → 设置 "autoCommit": true。如果选择“否” → 省略 autoCommit 字段（默认为 false）。

10.5：决策登记册选项

使用 AskUserQuestion：

问题：“是否启用决策登记册，以跟踪评审期间的问题和决策？”

选项：

1. “是，启用决策登记册” → 将 "decisionRegister": { "enabled": true } 添加到生成的配置中
2. “否，跳过” → 从生成的配置中省略 decisionRegister 字段（默认禁用）

如果用户启用此功能，将使用默认路径（.candid/register）和默认模式（"lookup"）。用户之后可以在配置文件中自定义这些设置。

10.6：配置交付工作流

使用 AskUserQuestion：

问题：“是否配置 candid-ship 交付工作流？（评审 → 构建 → 测试 → PR → 合并）”

选项：

1. “是，配置 ship 设置”
2. “否，跳过”

如果选择“否，跳过” → 省略 ship 字段。继续执行步骤 10.7。

如果选择“是，配置 ship 设置”：

10.6a：构建命令

从 package.json 自动检测：

jq -r '.scripts.build // null' package.json 2>/dev/null

**如果检测到构建脚本：**使用 AskUserQuestion：

• 问题："用于发布验证的构建命令是什么？\n检测到：[detected command]"
• 选项：
  1. "[detected package manager] run build"（例如，"npm run build"）
  2. "自定义命令"
  3. "跳过构建步骤"

**如果未检测到构建脚本：**使用 AskUserQuestion：

• 问题："用于发布验证的构建命令是什么？"
• 选项：
  1. "npm run build"
  2. "yarn build"
  3. "自定义命令"
  4. "跳过构建步骤"

如果选择“自定义命令”→ 后续提问："输入构建命令："，并接收自由文本回复。 如果选择“跳过构建步骤”→ 省略 buildCommand 字段。

10.6b：测试命令

从 package.json 自动检测：

jq -r '.scripts.test // null' package.json 2>/dev/null

与 10.6a 使用相同模式，但针对测试。如果 package.json 中未包含，则根据项目结构检测 pytest、go test 等：

ls pytest.ini setup.cfg pyproject.toml 2>/dev/null  # Python
ls go.mod 2>/dev/null                                # Go

**如果检测到测试脚本：**使用 AskUserQuestion，并将检测到的命令作为第一个选项。 **如果未检测到测试脚本：**提供常见选项（npm test、yarn test、自定义、跳过）。

如果选择“自定义命令”→ 后续提问："输入测试命令："，并接收自由文本回复。 如果选择“跳过测试步骤”→ 省略 testCommand 字段。

10.6c：目标分支

使用步骤 10.1 中检测到的分支（mergeTargetBranches）。

问题："candid-ship 创建的 PR 的目标分支是什么？"

选项：

1. "[first detected branch]"（来自步骤 10.1 的结果）
2. "自定义分支"
3. "跳过（使用 mergeTargetBranches 中的默认值）"

如果选择“自定义分支”→ 后续提问："输入目标分支名称：" 如果选择“跳过”→ 省略 targetBranch 字段。

10.6d：自动合并

使用 AskUserQuestion：

问题："创建 PR 后自动合并？（需要在仓库中启用 GitHub 自动合并）"

选项：

1. "是 — 使用 squash 自动合并"
2. "否 — 手动合并（默认）"

如果选择“是”→ 设置 "autoMerge": true。如果选择“否”→ 省略 autoMerge 字段。

10.6e：附加提示词

使用 AskUserQuestion：

问题："为 candid-ship 添加额外的审查提示词？（发布期间传递给代码审查的额外上下文）"

选项：

1. "是，添加提示词"
2. "否，跳过"

如果选择“是”→ 后续提问："输入附加审查提示词："，并接收自由文本回复。 如果选择“否”→ 省略 additionalPrompt 字段。

10.6f：问题跟踪器集成

使用 AskUserQuestion：

问题：“你是否使用问题跟踪器（Linear、Asana、Jira 等），并希望 candid-ship 在你发布时自动更新问题？”

选项：

1. “是 — Linear（已支持）”
2. “是 — 其他跟踪器（请求支持）”
3. “否，跳过”

如果选择“否，跳过” → 省略 issueTracker 字段。继续。

如果选择“是 — 其他跟踪器（请求支持）”：

显示：

Issue tracker integration currently supports Linear only. To request support for your tracker (Asana, Jira, GitHub Issues, Shortcut, etc.):

  → Open an issue: https://github.com/ron-myers/candid/issues

Tell us which tracker you use and how you'd like the workflow to behave (state name, when to trigger, etc.) and we'll prioritize accordingly.

Skipping issue tracker config for now.

省略 issueTracker 字段。继续。

如果选择“是 — Linear（已支持）”：

显示：

Linear integration requires the official Linear MCP server (claude.ai/Linear). If it isn't installed, the issue-tracker step is skipped at ship time — the rest of the ship still runs.

后续问题 1：“Linear 团队前缀（逗号分隔，例如 DIS、ENG、DISC）：”——自由文本回答。按逗号拆分，修剪每个条目并转为大写。如果用户留空，默认使用 ["DIS", "ENG", "DISC"]。

后续问题 2：“创建 PR 时要设置的 Linear 状态名称：”——自由文本回答。如果留空，默认使用 "In Review"。用户应填写与其 Linear 工作区中的状态名称完全一致的值（例如 "In Review"、"Code Review"、"In Progress"）。

**后续问题 3：**使用 AskUserQuestion：“使用默认的 Linear MCP 提示词，还是自定义提示词？”

在问题下方显示默认内容，以便用户了解他们要同意的内容：

Update issue {issueId}: set its state to "{state}". Update only this one issue and only its state — do not modify any other issues, fields, or properties. If the issue is already in "{state}", report success without action. If the issue is missing or inaccessible, report the error and stop.

选项：

1. “使用默认值（推荐）— 写入配置，以便稍后编辑”
2. “现在自定义”

**如果选择“使用默认值”：**将默认提示词原样写入生成配置的 prompt 字段。用户稍后可以编辑 .candid/config.json。不要省略该字段——让提示词在配置中可见是一项功能，而非多余内容。

**如果选择“现在自定义”：**后续问题为自由文本：“输入你的自定义提示词。使用 {issueId}、{state} 和 {provider} 作为占位符。**必需：**提示词必须将操作限制为单个问题，并在出现问题不存在错误时停止（不要搜索替代问题）。”将默认内容作为参考基准显示在下方。将用户的回答用作 prompt 值。

无论哪种情况，都将生成的 prompt 字段写入配置：

"issueTracker": {
  "provider": "linear",
  "enabled": true,
  "teamPrefixes": ["..."],
  "state": "...",
  "prompt": "..."
}

该技能的运行时默认值与此处写入的值完全相同——显式写入配置的做法只会让用户看到提示词，不会改变行为。

10.7：快速发布配置

使用 AskUserQuestion：

问题：“配置 candid-fast-ship？这是一个精简的发布路径，只运行你启用的步骤——默认情况下，除创建 PR 外不会运行任何步骤。（命令值继承自你刚才配置的 ship 部分。）”

选项：

1. “是，配置快速发布”
2. “否，跳过”

如果选择“否，跳过” → 省略 fastShip 字段。继续执行步骤 10.8。

如果选择“是，配置快速发布”：

使用 AskUserQuestion：

问题：“默认启用 candid-fast-ship 的哪些步骤？”

选项：

1. “无 — 仅创建 PR（最安全的默认值，按运行决定）”
2. “仅构建”
3. “构建 + 自动合并”
4. “自定义 — 由我选择”

如果选择“自定义 — 由我选择”：请用户对以下每项分别确认“是”或“否”：

• 启用审查（candid-loop）？
• 启用安装？（仅当配置了 ship.installCommand 时显示）
• 启用构建？（仅当配置了 ship.buildCommand 时显示）
• 启用测试？（仅当配置了 ship.testCommand 时显示）
• 启用问题跟踪器更新？（仅当配置了 ship.issueTracker 时显示）
• 启用自动合并？
• 启用合并后命令？（仅当配置了 ship.postMergeCommand 时显示）

根据所选项构建 fastShip 对象。仅将用户明确启用的字段设为 true；省略值为 false 的字段（缺省时默认值为 false）。生成的配置中始终省略 targetBranch（它会自动回退到 ship.targetBranch）。

对于预设选项：

• “无” → "fastShip": {}
• “仅构建” → "fastShip": { "build": true }（如果未配置 ship.buildCommand，则省略该字段；改用 {} 并附上说明）
• “构建 + 自动合并” → "fastShip": { "build": true, "autoMerge": true }（构建同样适用上述条件）

10.8：预览并确认

根据所有已检测和已询问的值组装配置对象。仅包含已明确设置的字段——省略用户跳过的字段（缺省时这些字段会正确采用默认值）。

以有效 JSON 的形式显示组装好的配置。启用所有字段的示例：

⚙️  Generated config.json:

{
  "version": 1,
  "tone": "harsh",
  "mergeTargetBranches": ["main"],
  "exclude": ["dist/*", "*.min.js"],
  "autoCommit": true,
  "decisionRegister": {
    "enabled": true
  },
  "ship": {
    "buildCommand": "npm run build",
    "testCommand": "npm test",
    "targetBranch": "main",
    "autoMerge": false
  },
  "fastShip": {
    "build": true,
    "autoMerge": true
  }
}

使用 AskUserQuestion：

问题：“将此配置写入 .candid/config.json 吗？”

选项：

1. “是，写入” → 继续执行步骤 11
2. “让我调整” → 询问要更改什么，更新配置并重新预览

---

步骤 11：写入文件、优化并显示摘要

11.1：将文件写入磁盘

确保 .candid/ 目录存在，然后写入两个文件：

mkdir -p .candid

使用 Write 工具创建：

• .candid/Technical.md（或通过 --output 传入的路径）——步骤 9 合成的内容
• .candid/config.json ——步骤 10.8 组装的配置

11.2：可选运行优化阶段

除非传入了 --optimize 或 --auto-optimize，否则完全跳过此子步骤。

如果设置了 --optimize（交互式）：

打印：

Running optimization audit on generated context…

不带额外标志调用 candid-optimize 技能。它将显示 Token 预算（步骤 2），分析 Technical.md / excludes / register / config（步骤 3–6），并运行自己的交互式应用阶段（步骤 7），包括优化前后的 Token 报告。

candid-optimize 返回后，继续执行步骤 11.3。

如果设置了 --auto-optimize（非交互式）：

打印：

Running optimization audit and applying all recommendations…

调用 candid-optimize 技能并传入 --apply-all 标志。应用所有建议时不会询问用户；仍会打印优化前后的报告。

candid-optimize 返回后，继续执行步骤 11.3。

11.3：显示摘要

打印摘要，其中包括：Technical.md 的位置和工作量级别；架构规则数量（以及违规数量）、命名模式、错误处理 / 测试 / 安全状态、已发现的缺口；config.json 的位置，以及 ship / fastShip 是否已配置；后续步骤 1–4（审查规则、弥补缺口、运行 /candid-validate-standards、运行 /candid-review）。

如果执行了步骤 11.2（传入了 --optimize 或 --auto-optimize）： 将“后续步骤”的第 3 步替换为 Run /candid-validate-standards to check rule quality (optimization already applied)，让用户知道审计阶段已完成。

如果跳过了步骤 11.2： 在“后续步骤”区块下方追加一行提示：

💡 Tip: run /candid-optimize to audit and tighten the generated context.

---

质量检查清单

输出前，请确认：

• 架构部分引用了实际目录路径
• 至少 3 条规则引用了此项目中的具体文件
• 不使用模糊措辞（“恰当”“适当”“干净”）
• 每条规则都可验证（包含阈值或具体模式）
• 缺口部分指出了至少一个改进领域
• 存在安全部分，且包含项目特定的细节
• 如果检测到 Linter，规则未重复其覆盖范围
• 完整模式下文件为 400–500 行（中等模式为 150 行，快速模式为 50 行）