技能介绍

要解决的问题

新同事从克隆仓库到能改代码、跑测试、提 PR，实际要花多久？装依赖、配环境、跑 CI、部署 staging 时卡在哪一步？很多团队的开发者体验（DX）问题不是没人知道，而是没人把每一步的耗时和摩擦点量化出来，导致优化优先级只能靠猜。

技能如何工作

这个技能以 Pave——工程团队里的 platform engineer 视角，模拟一名新开发者加入后的完整流程，逐步测量并给工程团队一份可执行的 DX 健康报告。

核心步骤如下：

检测开发环境：检查 README、CONTRIBUTING.md、onboarding guides、Makefile、package.json scripts、Justfile、docker-compose、devcontainers 等，确认构建、测试、CI、部署流程是否可复现。
量化上手体验：模拟 clone repo、install dependencies、run locally、run tests、make a change、open a PR，目标是 clone 到 running 低于 10 分钟。
测量构建与测试速度：记录 local build、full test suite、CI pipeline、deploy to staging、deploy to production 的当前值，并和 < 30s、< 5min、< 10min、< 15min、< 30min 等工程目标对照。
审计日常开发流程：覆盖 environment setup、dependency management、code review、deployment、debugging、documentation、tooling consistency。
标记反模式：例如无本地开发环境、增量构建超过 5 分钟、部署依赖手动步骤或其他团队、上手文档过期或缺失、无 PR 预览环境、“works on my machine”、依赖 tribal knowledge、不跟踪 DORA metrics。
输出 DX 健康报告：按 docs/output-kit.md 规范生成，包含 Onboarding、Build speed、Test speed、Deployment、Documentation、Tooling consistency、Self-service 等维度的 1–10 评分，并列出 Top 3 friction points、Quick wins（小于 1 天投入、高影响）和 Strategic improvements（1–2 周投入）。

关键原则是 Measure, don't guess：每一步都计时、点击次数计数；评分锚点是真实工程目标，而不是愿景；优先处理日常开发者工作流，不做边角 case；每个发现都必须带具体建议；Quick wins first，先建立改进 momentum。

适用边界与注意点

它适合已经有代码仓库、CI、部署流程的工程团队，用来定位 DX 摩擦点和改进优先级；不适合纯文档项目，也不负责直接修复环境或改代码。如果完整分析超出 40 行 CLI 预算，会调用 /atlas-report 生成 HTML 报告，CLI 只保留 box header、一行结论、Top 3 findings 和报告路径，避免把分析结果直接堆在终端里。