按栏目规划，Round 3 该横评开发者效率类 Skills——代码审查、测试、重构、调试四条闸。但翻一遍近期的发布记录，「审查闸」「测试闸」「调试闸」已经被多轮覆盖：pr-lens、webapp-testing、gh-fix-ci、jevgrep 这些名字都各有过逐行拆解。四闸内的熟面孔再拆一遍，是重复劳动。
所以本轮换一个角度：我把镜头对准本机 Claude Code 环境里真实安装、随版本出厂、却从没人拆过的另一排件——fewer-permission-prompts、update-config、loop、run、keybindings-help。它们的共同点是：不帮你写一行代码，而是拆除 Agent 工作时的环境阻力——少弹一次确认、少打断一次会话、少一层配置摩擦。审查/重构/测试件决定 Claude 干得多好，这排件决定 Claude 停得多少。所有引用均来自本机环境的逐字描述，本文不引用任何未经核实的第三方 Star 数据。
| Skill | 功能完整度 (25%) | 设计质量 (25%) | 实战效果 (20%) | 上手难度 (15%) | 分发可及性 (15%) | 加权总分 |
|---|---|---|---|---|---|---|
| fewer-permission-prompts | ★★★★ | ★★★★★ | ★★★★ | ★★★★★ | ★★★★★ | 4.60 |
| update-config | ★★★★★ | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | 4.45 |
| loop | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★★ | 4.35 |
| run | ★★★★ | ★★★★ | ★★★★ | ★★★★★ | ★★★★★ | 4.35 |
| keybindings-help | ★★★ | ★★★ | ★★★ | ★★★★★ | ★★★★★ | 3.75 |
说明：这五件都是随 Claude Code 出厂分发的内置件，没有独立的 GitHub 仓库和 Star 数，传统的「社区活跃度」维度不适用。表中最后一列改为「分发可及性」——出厂件随版本更新自动到达，无需安装，这一项全部满分。
用过 Claude Code 的人都知道那种节奏被打断的感觉：你让它跑测试，弹一个确认框；让它查日志，又一个确认框；调一个 MCP 工具，再一个。单次确认只要两秒，但一个下午二十次确认，人的注意力就被切成碎片——瓶颈不在模型干活的速度，而在人批准的速度。
官方对本件的一句话描述是逐字这样的：
Scan your transcripts for common read-only Bash and MCP tool calls, then add a prioritized allowlist to project .claude/settings.json to reduce permission prompts.
翻译成工序：扫描你的历史会话记录（transcripts），找出常见的只读 Bash 和 MCP 工具调用，然后把它们整理成一份按优先级排序的白名单，写进项目级的 .claude/settings.json，从此这类调用不再弹确认。
这句话总共不到三十个英文单词，但每一块都值得单独看：
输入是 transcripts，不是问卷。 它不问你「平时都用哪些命令」，而是直接翻你的历史会话，看你实际调用过什么。这是行为数据优于声明数据的典型设计——你说你常用 git status，不如系统看到你这周跑了四十次 git status。
只放行 read-only，这是安全边界。 描述里 "read-only" 这个限定词是整件的灵魂。git log、cat、grep 这类看了不会改坏东西的命令才有资格进白名单；会改状态的命令（rm、git push、npm publish）永远留在确认闸后。它拆的是减速带，不是收费站。
prioritized（排过序的）白名单。 不是一股脑把扫到的东西全塞进去，而是排序。高频、安全的排前面先放行，低频存疑的靠后甚至不放。这个排序动作说明它假设用户的信任是分级的，不是二值的。
写入 project 级 .claude/settings.json。 注意是项目级，不是用户全局级。这意味着两件事：一，白名单跟着仓库走，团队里其他人 clone 下来就共享同一套放行规则；二，范围被天然限制在这个项目里，你在一个实验性仓库里放行的命令，不会泄漏到生产仓库的会话中。
flowchart TD
A["用户历史 transcripts"] --> B["扫描 Bash 调用"]
A --> C["扫描 MCP 调用"]
B --> D{"调用是否只读"}
C --> D
D -->|是| E["进入候选池"]
D -->|否| F["直接排除"]
E --> G["按频次排序"]
G --> H["生成白名单"]
H --> I["写入项目 settings.json"]
I --> J["下次同类调用免确认"]
不需要装任何东西，自然语言触发即可：
帮我减少权限确认弹窗
reduce permission prompts
扫描我的会话，把常用的只读命令整理成白名单
它是一次性体检，不是常驻守护。跑一次生成一份白名单，之后你养成新的调用习惯，得再跑一次才有增量。另外「常见」的定义由它自己判断，扫出来的清单值得人工过目一遍再落盘——毕竟写进 settings.json 的每一行都是你替未来的自己做的授权决定。
它的官方描述是五件里最长的，因为它的辖区最宽：hooks、permissions、env vars、settings.json 排障，全归它管。
最值得抄的一句设计是它的边界宣言：
Automated behaviors ("from now on when X", "each time X", "before/after X") require hooks configured in settings.json — the harness executes these, not Claude, so memory/preferences cannot fulfill them.
翻译：「以后每次 X 的时候自动做 Y」这类自动化需求，必须靠 settings.json 里的 hooks 实现，执行方是 harness 不是 Claude 自己，所以记忆和偏好设置干不了这活。这一句话挡掉了最常见的错误路由——用户说「以后每次提交前跑下测试」，Claude 若把它存进记忆，下次全凭自觉，想不起来就不执行；写进 hooks 才是 harness 强制执行。把「承诺」和「机制」分开，这是很多 Skill 作者都没想透的一层。
它的触发例子也很具体：「允许我在用户设置里跑 npm 命令」「设 DEBUG=true」「Claude 停下时给我看最后的 git diff」。全部落在 settings.json 或 settings.local.json 这两个文件上，职责极其收敛。
描述核心：/loop 5m /foo，让一条提示词或斜杠命令按间隔反复执行，默认 10 分钟。
它真正体现设计功力的是描述里那段分流规则：当用户笼统地问 cron、定时任务时，它被明确要求先澄清——用户可能想要的是底层的 CronCreate 定时器，而不是循环执行某个具体命令；只有当用户给出明确的提示词或命令要反复跑时，它才接手。「澄清后分流」写进触发条件，避免了最常见的误触发：你问「怎么设置定时任务」，它不该抢答着把你拖进循环模式。
典型用法：/loop 10m /code-review——每十分钟对当前 diff 审查一轮，边写边审，把审查从「交卷后」提前到「考试中」。
Launch and drive this project's app to see a change working. Use when asked to run, start, or screenshot the app, or to confirm a fix works...
它的定位是验证的前置件：你说「这个 bug 修好了吗」「跑起来看看效果」，它负责把项目的应用真正启动、驱动、截图，让 Claude 亲眼看到行为，而不是只看代码长得对不对。它和 verify 件（通过运行应用并观察行为来验证改动）是同一条链上的两环——run 负责「跑起来」，verify 负责「观察并下结论」。对前端和 CLI 项目，这一步直接消灭了「代码看起来没问题但一跑就崩」的盲区。
管的是 ~/.claude/keybindings.json：把 Ctrl+Shift+R 绑到跑测试、给常用动作加快捷键。功能最薄，属于查手册型的件。它存在的意义更多是补全图谱——当用户的效率诉求落在键盘层面时，有一个明确的入口接住，而不是让 Claude 现场猜配置格式。
作为参照系，回头看已覆盖过的干活三件，会发现出厂件有一个统一的写作模式——用一句话把边界钉死：
--comment 把发现贴成 PR 行内评论，--fix 审完直接改）。三件合起来是一份分工合同：审的人不修，修的人不审，验的人只信运行结果。本轮这排调校件延续了同一套写法——update-config 宣布记忆干不了 hooks 的活，loop 宣布笼统定时需求先澄清。出厂件的提示词工程，精髓不在写了什么，而在拒绝了什么。
mindmap
root((开发效率件))
干活闸
code-review 审查
simplify 重构
verify 测试
run 跑起来看
调校件
fewer-prompts 拆减速带
update-config 管设置
keybindings-help 管快捷键
节拍件
loop 定时循环
五件全部随 Claude Code 出厂分发，零安装，直接触发：
| Skill | 触发方式 |
|---|---|
| fewer-permission-prompts | 「帮我减少权限确认弹窗」 |
| update-config | 「在用户设置里允许我跑 npm 命令」「设 DEBUG=true」 |
| loop | /loop 10m /code-review |
| run | 「跑起来验证这个修复」 |
| keybindings-help | 「把 Ctrl+Shift+R 绑定到跑测试」 |
如果你想装的是第三方的同类扩展，官方与社区目录里检索关键词 permissions、settings、automation 即可，安装命令一般是 npx skills add <skill-name>。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。