ln-740-quality-setup

路径： 文件路径（references/、../ln-*）相对于此技能目录。

ln-740-quality-setup

类型： L2 领域协调器 类别： 7XX 项目引导 父级： ln-700-project-bootstrap

协调项目的代码质量工具配置。

---

用途与范围

负责：

• 检测项目技术栈（TypeScript/React、.NET、Python）
• 检查现有质量配置
• 将各质量方面的工作委派给专用工作器
• 验证最终配置是否正常运行

不负责：

• 直接生成配置文件（由工作器完成）
• 修改源代码
• 独立运行（需要先完成 ln-720 结构配置）

---

使用时机

触发条件	操作
ln-720-structure-migrator 完成后	由 ln-700 自动委派
需要手动配置质量工具	使用项目路径直接调用
现有项目需要质量工具	运行并检测现有配置

---

工作流概览

阶段	操作	输出
1	技术栈检测	已识别的技术
2	现有配置检查	跳过/合并/替换决策
3	并行委派	工作器调用
4	验证	可正常运行的质量流水线

---

阶段 1：技术栈检测

检测项目技术，以确定要配置哪些质量工具。

检测规则：

文件模式	技术	Linter 技术栈
package.json + tsconfig.json	TypeScript/React	ESLint + Prettier
*.csproj 或 *.sln	.NET	editorconfig + Roslyn
pyproject.toml 或 requirements.txt	Python	Ruff
检测到多个技术	混合	配置所有检测到的技术

操作：

1. 使用 Glob 搜索技术标识文件
2. 构建技术列表
3. 向用户记录检测到的技术栈

---

阶段 2：现有配置检查

委派之前，检查已存在的配置。

要检查的配置文件：

技术	配置文件
TypeScript	eslint.config.*、.prettierrc*、tsconfig.json
.NET	.editorconfig、Directory.Build.props
Python	ruff.toml、pyproject.toml [tool.ruff]
Pre-commit	.husky/、.pre-commit-config.yaml
测试	vitest.config.*、pytest.ini、*.Tests.csproj

决策矩阵：

现有配置	操作	确认
未找到	根据模板创建	否
存在但不完整	扩展以匹配模板	否
存在且匹配模板	跳过	告知用户

完整性检查（Python）： 根据 ln-741 的“完整性检查”表进行评估（7 个方面：Ruff 规则、逐文件忽略项、高级设置、MyPy strict、高级工具、lint 脚本、editorconfig）。如果有任何方面不完整，则委派给 ln-741，并指示其扩展（而非替换）。

---

阶段 3：并行委派

为各质量方面调用工作器。由于它们配置的是独立工具，因此可以并行运行。

委派顺序：

ln-740 (this)
    |
    +---> ln-741-linter-configurator
    |         - ESLint/Prettier (TypeScript)
    |         - editorconfig/Roslyn (.NET)
    |         - Ruff (Python)
    |
    +---> ln-742-precommit-setup
    |         - Husky + lint-staged (Node.js)
    |         - pre-commit framework (Python)
    |         - commitlint
    |
    +---> ln-743-test-infrastructure
              - Vitest (TypeScript)
              - xUnit (.NET)
              - pytest (Python)

通过直接调用 Skill 工具，将检测到的技术栈和现有配置传递给工作器。对于 Python：指示 ln-741 按其“完整性检查”表应用完整的质量工具栈。

调用：

Skill(skill: "ln-741-linter-configurator", args: "{projectPath}")
Skill(skill: "ln-742-precommit-setup", args: "{projectPath}")
Skill(skill: "ln-743-test-infrastructure", args: "{projectPath}")

---

阶段 4：验证

所有 Worker 完成后，验证质量流程是否正常运行。

验证步骤：

检查项	TypeScript	Python	.NET
Lint	ESLint	ruff check	dotnet format --verify-no-changes
格式化	Prettier	ruff format --check	dotnet format
类型检查	tsc --noEmit	mypy	Roslyn（构建）
导入边界	depcruise	lint-imports	--
未使用的依赖	knip	deptry	--
死代码	knip	vulture	--
漏洞扫描	npm audit	pip-audit	--
统一脚本	bash scripts/lint.sh	bash scripts/lint.sh	bash scripts/lint.sh
测试	npm test	pytest	dotnet test
钩子	创建测试提交	创建测试提交	创建测试提交

失败时：

1. 记录具体失败情况
2. 建议修复方法或重新运行特定 Worker
3. 验证通过前，不得标记为完成

---

关键规则

规则 1： 未经明确确认，绝不得覆盖现有用户配置。

规则 2： Worker 必须在检测技术栈之后运行——未确认技术栈时不得调用 Worker。

规则 3： 验证阶段为强制要求——只有工具成功运行后，质量设置才算完成。

规则 4： 同时配置 ESLint 和 Prettier 时，必须使用 eslint-config-prettier。

---

TodoWrite 格式（强制）：

- Invoke ln-741-linter-configurator (pending)
- Invoke ln-742-precommit-setup (pending)
- Invoke ln-743-test-infrastructure (pending)
- Verify quality pipeline (pending)

Worker 调用（强制）

宿主 Skill 调用： 必须通过委派调用 Skill(skill: "...", args: "...")。

• Claude：严格按上方所示调用 Skill 工具。
• Codex：如果没有 Skill 工具，则在可用 Skill 中查找指定 Skill，读取其 SKILL.md，将 args 作为 $ARGUMENTS，执行该 Skill 工作流，然后返回此处并提供其结果或产物。
• 不得内联执行 Worker 逻辑，也不得在未执行目标 Skill 的情况下将 Worker 标记为完成。

阶段	Worker	上下文
3a	ln-741-linter-configurator	共享（Skill 工具）——ESLint/Prettier、editorconfig、Ruff
3b	ln-742-precommit-setup	共享（Skill 工具）——Husky、lint-staged、commitlint
3c	ln-743-test-infrastructure	共享（Skill 工具）——Vitest、xUnit、pytest

所有 Worker： 通过 Skill 工具调用——Worker 可见协调器上下文。

完成标准

• 所有检测到的技术栈都具备适当的质量工具
• 保留或备份现有配置
• Lint 命令运行无错误
• 格式化命令运行无错误
• 测试命令运行成功，且示例测试通过
• 测试提交会触发提交前钩子
• 已告知用户所有已安装的工具和命令

---

阶段 5：元分析

可选参考：仅当用户要求进行运行后元分析或按协议格式反思运行情况时，才加载 references/meta_analysis_protocol.md。

Skill 类型：execution-orchestrator。收到请求后，按照协议 §7 分析本次会话。按协议格式输出。

---

参考文件

文件	用途
stack_detection.md	详细的检测规则
verification_checklist.md	完整的验证清单

---

错误处理

错误	原因	解决方法
未检测到技术栈	项目为空	询问用户预期使用的技术栈
Worker 失败	缺少依赖项	安装前置依赖，然后重试
验证失败	配置错误	检查具体工具的输出并修复
钩子无法运行	尚未初始化 Git	先运行 git init

---

版本： 3.0.0 最后更新： 2026-03-18