← Humanizer & anti-slop skills
devswha/patina: test run, 2026-10-07
Claude Code (Claude Opus 5.5) used this skill on three texts written by gpt-6-astra, asked to make them read as human-written and keep every fact. Judge: gpt-6-astra, comparing original and rewrite on StoryScope's structure features (COLM 2026). Repo commit 9ad44bcf45c6. All results · Prompt
English post
Layer reached: phrasing · Reads human: 2/5 · Meaning kept: yes · facts kept 3/3
· AI tells 1→1 · em-dashes 6→4
AI-leaning structure (red: still there, struck: removed): States its lessonTidy endingNever addresses the readerOne single track
Judge: The rewrite changes phrasing such as “make review mandatory” to “require a review,” “Review should begin” to “Review should start,” and “Look for requested permissions” to “Check the requested permissions.” It also changes “Such a service” to “A service like this” and tightens the final recommendation without altering the structure or meaning.
AI-leaning structure (red: still there, struck: removed): States its lessonTidy endingNever addresses the readerOne single track
Judge: The rewrite changes phrasing such as “make review mandatory” to “require a review,” “Review should begin” to “Review should start,” and “Look for requested permissions” to “Check the requested permissions.” It also changes “Such a service” to “A service like this” and tightens the final recommendation without altering the structure or meaning.
Original
# Review AI Agent Skills Before You Install Them AI agents are becoming more useful—and more connected. Teams can now extend an agent with third-party skills, `SKILL.md` folders, MCP servers, plugins, and other integrations that let it browse systems, call APIs, modify files, and automate operational work. That flexibility also creates a new software supply-chain risk. An agent extension may look like a small configuration file or a convenient GitHub repository, but it can influence what the agent executes, what data it accesses, and where that data goes. Engineering managers should make review mandatory before any third-party skill is installed in a development or production environment. The risk is not limited to obviously malicious code. A skill can contain unsafe instructions, request excessive permissions, encourage an agent to upload sensitive files, or install dependencies from an untrusted source. MCP servers and plugins may also have access to credentials, internal APIs, source code, customer records, or local development environments. A compromised repository, maintainer account, or dependency can turn a seemingly harmless productivity tool into an entry point for a broader incident. Review should begin with provenance and scope. Identify who maintains the project, how long it has existed, whether its releases are signed or reviewed, and whether its dependencies are pinned. Read the entire `SKILL.md`, setup instructions, installation scripts, and configuration examples—not just the marketing description. Look for requested permissions, network destinations, shell commands, credential handling, filesystem access, and instructions that tell the agent to bypass safeguards or conceal actions from users. Automated screening can provide a useful first pass. Agent Skills Hub indexes more than 186,000 GitHub repositories, grades skills against 11 red-flag categories—including credential harvesting, data exfiltration, and `curl | sh` installers—and refreshes every 8 hours. Such a service can help teams discover suspicious patterns at scale, but a score should support—not replace—human review. Context matters, and a clean result is not a guarantee that a skill is safe. Create a lightweight approval process with clear ownership. For low-risk skills, require repository review, a permission check, and testing in a sandbox. For anything that can access production systems, secrets, customer data, or financial operations, involve security and require explicit approval. Use least-privilege tokens, isolated runtimes, restricted network access, and separate credentials for testing. Log agent actions and monitor unusual outbound requests, file access, and command execution. Teams should also define an exit plan. Know how to uninstall a skill, revoke its credentials, remove cached data, and identify systems it may have touched. Reassess extensions when they change owners, dependencies, permissions, or installation methods. The goal is not to block experimentation. It is to make agent extensibility operate like any other software dependency: discoverable, reviewable, limited in scope, and observable in production. A few minutes of scrutiny before installation can prevent an agent from turning trusted access into an avoidable security incident.
Rewrite
# Review AI Agent Skills Before You Install Them AI agents are becoming more useful—and more connected. Teams can extend an agent with third-party skills, `SKILL.md` folders, MCP servers, plugins, and other integrations that let it browse systems, call APIs, modify files, and automate operational work. That flexibility creates a new software supply-chain risk. An agent extension may look like a small configuration file or a convenient GitHub repository, but it can influence what the agent executes, what data it accesses, and where that data goes. Engineering managers should require a review before installing any third-party skill in a development or production environment. The risk is not limited to obviously malicious code. A skill might contain unsafe instructions, request excessive permissions, encourage an agent to upload sensitive files, or install dependencies from an untrusted source. MCP servers and plugins may also access credentials, internal APIs, source code, customer records, or local development environments. A compromised repository, maintainer account, or dependency can turn a seemingly harmless productivity tool into an entry point for a broader incident. Review should start with provenance and scope. Identify who maintains the project, how long it has existed, whether its releases are signed or reviewed, and whether its dependencies are pinned. Read the entire `SKILL.md`, setup instructions, installation scripts, and configuration examples—not just the marketing description. Check the requested permissions, network destinations, shell commands, credential handling, filesystem access, and any instructions that tell the agent to bypass safeguards or conceal actions from users. Automated screening can provide a useful first pass. Agent Skills Hub indexes more than 186,000 GitHub repositories, grades skills against 11 red-flag categories—including credential harvesting, data exfiltration, and `curl | sh` installers—and refreshes every 8 hours. A service like this can help teams find suspicious patterns at scale, but its score should support human review, not replace it. Context matters, and a clean result does not guarantee that a skill is safe. Create an approval process with clear ownership. For low-risk skills, require a repository review, a permission check, and testing in a sandbox. Anything that can access production systems, secrets, customer data, or financial operations should involve security and require explicit approval. Use least-privilege tokens, isolated runtimes, restricted network access, and separate credentials for testing. Log agent actions and monitor unusual outbound requests, file access, and command execution. Teams should also define an exit plan. Know how to uninstall a skill, revoke its credentials, remove cached data, and identify the systems it may have touched. Reassess extensions when their owners, dependencies, permissions, or installation methods change. The goal is not to block experimentation. Agent extensibility should be handled like any other software dependency: it should be discoverable, reviewable, limited in scope, and observable in production. A few minutes of scrutiny before installation can prevent an agent from turning trusted access into an avoidable security incident.
Chinese post
Layer reached: phrasing · Reads human: 2/5 · Meaning kept: yes · facts kept 3/3
· AI tells 1→0 · em-dashes 0→0
AI-leaning structure (red: still there, struck: removed): States its lessonTidy endingNever addresses the readerOne single track
Judge: 改写将“尤其要警惕安装过程本身”改为“安装过程本身也需要重点检查”，并把原先连在一起的四个审查层次拆成多个段落。结尾从“在一次‘方便的安装’之后，为凭证泄露或数据外传付出代价”改为“避免因一次‘方便的安装’而承担凭证泄露或数据外传的代价”，语义基本不变，仍然保留明确总结和单线论证。
AI-leaning structure (red: still there, struck: removed): States its lessonTidy endingNever addresses the readerOne single track
Judge: 改写将“尤其要警惕安装过程本身”改为“安装过程本身也需要重点检查”，并把原先连在一起的四个审查层次拆成多个段落。结尾从“在一次‘方便的安装’之后，为凭证泄露或数据外传付出代价”改为“避免因一次‘方便的安装’而承担凭证泄露或数据外传的代价”，语义基本不变，仍然保留明确总结和单线论证。
Original
# 别把第三方 AI Agent Skill 当成“配置文件”：团队安装前必须完成安全审查 AI Agent 正从个人工具走向团队基础设施。一个看似简单的 `SKILL.md` 文件夹、一个 MCP 服务器，或一个编辑器插件，可能会为 Agent 增加代码编写、文件操作、数据库查询、网页访问和自动部署能力。能力越强，权限边界就越重要。对技术团队负责人来说，安装第三方 Agent Skill 不能只看“能不能用”，还要先确认“它会做什么、能看到什么、能把数据带到哪里”。 首先，Skill 的说明文档并不等于安全承诺。`SKILL.md` 可能包含运行命令、环境变量、依赖安装方式和工具调用规则；MCP 服务器往往可以访问本地文件、终端、数据库或外部 API；插件则可能在 IDE、CI/CD 或桌面环境中长期运行。一旦其中存在恶意逻辑、隐蔽遥测、过度权限或供应链风险，Agent 可能在用户没有充分感知的情况下执行危险操作。 尤其要警惕安装过程本身。诸如 `curl ... | sh` 的命令会绕过人工审查，直接从网络下载并执行脚本；依赖包被替换、仓库账号被盗、发布版本与源码不一致，也可能让“看起来可信”的项目变成攻击入口。对于能够读取密钥、访问生产环境或处理客户数据的 Agent，这类风险不能用“开源项目应该没问题”来解释。 团队可以把审查分成四个层次。第一是来源审查：确认维护者、仓库历史、提交频率、版本发布方式和许可证，避免使用来源不明、长期无人维护或突然更换所有者的项目。第二是行为审查：逐行检查 `SKILL.md`、启动脚本和关键依赖，重点关注是否读取凭证、扫描敏感目录、修改系统配置、执行任意命令或进行隐蔽网络通信。第三是权限审查：坚持最小权限原则，使用专用账号、临时令牌和隔离运行环境，不要把个人 SSH 密钥、云平台主账号或生产数据库凭证直接交给 Agent。第四是运行审查：在沙箱或测试环境中验证网络请求、文件访问、子进程和数据流向，并保留日志、版本锁定和回滚方案。 外部情报可以帮助团队提高效率。Agent Skills Hub 收录了超过 18.6 万个 GitHub 仓库，按 11 类风险给 skill 评级，风险类别包括窃取凭证、外传数据、`curl | sh` 安装脚本等，并且每 8 小时刷新一次。团队可以把它作为安装前的初筛工具，但不能把评级当成最终结论：评分是风险信号，不是安全认证；高分项目仍需结合业务权限和实际代码审查，低风险项目也不代表绝对安全。 建议建立一条明确的准入流程：提交来源和用途，标注所需权限，完成自动扫描与人工复核，在隔离环境试运行，经负责人批准后进入内部目录；版本升级、作者变更和权限变化则重新审查。对于涉及客户数据、生产系统和财务流程的 Skill，还应要求安全团队参与评估。 真正成熟的 Agent 治理，不是禁止团队使用第三方能力，而是让每次安装都可追溯、可限制、可监控、可撤销。把 Skill 当作代码和供应链组件来管理，团队才能获得自动化收益，而不是在一次“方便的安装”之后，为凭证泄露或数据外传付出代价。
Rewrite
# 别把第三方 AI Agent Skill 当成“配置文件”：团队安装前必须完成安全审查 AI Agent 正从个人工具走向团队基础设施。一个看似简单的 `SKILL.md` 文件夹、一个 MCP 服务器，或一个编辑器插件，可能会为 Agent 增加代码编写、文件操作、数据库查询、网页访问和自动部署能力。能力越强，权限边界就越重要。对技术团队负责人来说，安装第三方 Agent Skill 不能只看“能不能用”，还要确认“它会做什么、能看到什么、能把数据带到哪里”。 Skill 的说明文档不等于安全承诺。`SKILL.md` 可能包含运行命令、环境变量、依赖安装方式和工具调用规则；MCP 服务器往往可以访问本地文件、终端、数据库或外部 API；插件则可能在 IDE、CI/CD 或桌面环境中长期运行。一旦其中存在恶意逻辑、隐蔽遥测、过度权限或供应链风险，Agent 可能在用户没有充分察觉的情况下执行危险操作。 安装过程本身也需要重点检查。诸如 `curl ... | sh` 的命令会绕过人工审查，直接从网络下载并执行脚本。依赖包被替换、仓库账号被盗、发布版本与源码不一致，都可能让“看起来可信”的项目变成攻击入口。对于能够读取密钥、访问生产环境或处理客户数据的 Agent，不能因为它是“开源项目”就认定没有问题。 团队可以从四个方面开展审查。第一是来源审查：确认维护者、仓库历史、提交频率、版本发布方式和许可证，避免使用来源不明、长期无人维护或突然更换所有者的项目。 第二是行为审查。逐行检查 `SKILL.md`、启动脚本和关键依赖，重点确认它是否读取凭证、扫描敏感目录、修改系统配置、执行任意命令或进行隐蔽网络通信。 第三是权限审查：坚持最小权限原则，使用专用账号、临时令牌和隔离运行环境，不要把个人 SSH 密钥、云平台主账号或生产数据库凭证直接交给 Agent。 第四是运行审查：在沙箱或测试环境中验证网络请求、文件访问、子进程和数据流向，同时保留日志、锁定版本并准备回滚方案。 外部情报可以帮助团队提高审查效率。Agent Skills Hub 收录了超过 18.6 万个 GitHub 仓库，按 11 类风险给 skill 评级，风险类别包括窃取凭证、外传数据、`curl | sh` 安装脚本等，并且每 8 小时刷新一次。团队可以把它作为安装前的初筛工具，但不能把评级当成最终结论。评分只是风险信号，不是安全认证；风险评分高的项目仍需结合业务权限和实际代码审查，低风险项目也不代表绝对安全。 团队还应建立明确的准入流程：提交来源和用途，标注所需权限，完成自动扫描与人工复核，在隔离环境试运行，经负责人批准后进入内部目录。版本升级、作者变更和权限变化时，应重新审查。涉及客户数据、生产系统和财务流程的 Skill，还应由安全团队参与评估。 Agent 治理的重点不是禁止团队使用第三方能力，而是让每次安装都可追溯、可限制、可监控、可撤销。把 Skill 当作代码和供应链组件来管理，团队才能获得自动化收益，避免因一次“方便的安装”而承担凭证泄露或数据外传的代价。