从 clone 到跑起来压到 5 分钟：给仓库做一次 DX 审计
起因是团队反馈"测试流程太慢"，于是把 dx-optimizer 的方法论拿来当审计清单，在自己的项目里过了一遍。它的四个优化领域、五步流程、六类交付物、四项指标，基本可以当成一份可以直接照着做的检查表。
项目信息：
- Agent 插件市场：wshobson/agents
- 提示词原文：plugins/debugging-toolkit/agents/dx-optimizer.md
安装：
/plugin marketplace add wshobson/agents
/plugin install debugging-toolkit
一、环境搭建：目标是 < 5 分钟
把目标写成数字才可验收：新人从 clone 到应用跑起来不超过 5 分钟。做法是把散落在 README 里的步骤收进一条命令。
# Makefile（参考写法）
.PHONY: setup check
setup: ## 一条命令完成初始化
npm ci
test -f .env || cp .env.example .env
npx prisma migrate dev --name init
check: ## 提交前手工跑一次
npm run lint
npm run typecheck
npm test -- --run
智能默认值指的是 lint 规则、格式化配置、构建参数开箱可用，新人不用先读半天配置。启动失败的地方尤其要处理，裸堆栈是最典型的摩擦点：
// src/config.ts（参考写法）
const port = process.env.PORT
if (!port) {
console.error([
'缺少环境变量 PORT。',
'修复：cp .env.example .env',
'或临时运行：PORT=3000 npm run dev',
].join('\n'))
process.exit(1)
}
报错里直接给出可复制的那一行，比解释原理有用。
二、开发工作流：先盘点，再自动化
不要一上来就装工具。先把重复劳动列出来——发版前手工跑一遍检查、每次新建模块都要复制粘贴脚手架——再决定自动化哪个。改 package.json 是成本最低的一步：
{
"scripts": {
"dev": "next dev",
"lint": "eslint . --cache",
"typecheck": "tsc --noEmit",
"test": "vitest",
"test:changed": "vitest --changed HEAD",
"fix": "npm run lint -- --fix && npm run format"
}
}
test:changed 是重点：只跑改动的相关用例，全量测试留给 CI。缩短"改代码→看结果"的回路比多装十个工具管用。
三、工具链增强：hooks 要有边界
.editorconfig 是一行成本、长期收益的东西：
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
[*.md]
trim_trailing_whitespace = false
git hooks 用 lefthook 的写法：
# lefthook.yml（参考写法）
pre-commit:
parallel: true
commands:
lint:
glob: "*.{ts,tsx,js,jsx}"
run: npx eslint --fix {staged_files}
stage_fixed: true
format:
run: npx prettier --write {staged_files}
stage_fixed: true
husky 的等价写法是 npx husky add .husky/pre-commit "npx lint-staged"，配一份 lint-staged 配置。
这里有个明确的取舍：pre-commit 里只放秒级检查。把整个测试套件塞进钩子，结果就是所有人开始加 --no-verify，钩子名存实亡。慢检查放 pre-push，或者在 CI 上卡。
项目专属 CLI 也属于这一类，常用命令包成脚本并带 --help，比如 ./scripts/db-reset --help 直接打印用法和影响范围。
四、文档：跑得通才算数
上手指南里的每条命令都要自己执行过。加一张排障表，把"症状 → 原因 → 修复命令"三列写清楚，比大段说明有效。自定义命令补内联帮助。
五步流程怎么用
- 测绘现状：记录常用命令、每步耗时、反复手工操作的事。靠印象会漏，我习惯先记一周。
- 定位痛点：哪步最慢、最易错、最打断心流。三者不重合时，优先修打断心流的那个。
- 针对痛点找工具，不迷信热门工具——如果 20 行 Makefile 目标能解决，就不要引入一套新的任务编排框架。
- 增量落地：一次一个改动。一次性大重构本身就会制造新的摩擦。
- 用指标量化效果，再回到第 1 步。
六类交付物
落点是自己的目标项目，不是去改 agents 仓库——那个仓库是只读的市场资源。
.claude/commands/里的常用任务命令，把高频操作固化成斜杠命令- 改进后的
package.jsonscripts - Git hooks 配置
- IDE 配置文件：设置、扩展清单、格式化规则
- Makefile 或任务运行器，统一多步命令链
- README 改进
四项成功指标
- clone 到应用跑起来的耗时
- 被消除的手工步骤数量
- 构建/测试执行时长
- 开发者满意度反馈
前三项可量化，第四项主观兜底。实际盯一两个就够，为了凑满四项去做统计，本身就是新增的手工步骤。
哪些是过度工程
- pre-commit 跑全量测试或 e2e
- 给只用一次的命令写别名
- 三个人的仓库配一套完整的审批门禁
- 为了"统一"把所有脚本重写成新的任务框架
另外，Agent 生成的环境、脚本、hooks、文档改动，都要人工 review 后再合入，否则自动化会引入新的摩擦。
顺带一提同插件的另外两个组件：smart-debug 用于快速止损，debugger 做根因分析。如果 debugger 反复发现同一类错误高频出现，那说明存在系统性摩擦，该交给流程、工具和文档去修，而不是继续一个个修 bug。