bash-defensive-patterns

bash-defensive-patterns 技能概览

bash-defensive-patterns 技能是做什么的

bash-defensive-patterns 技能教代理写出更适合生产自动化场景的安全 Bash，不只是语法上“能跑”的 shell 片段。它重点关注失败处理、清理机制、引用规范、输入校验，以及那些能减少 CI 任务、部署脚本、cron 任务和系统工具中静默故障的模式。

谁适合安装它

这个技能非常适合后端工程师、DevOps 团队、SRE、平台工程师，以及任何在运维链路中使用 Bash 的人——尤其是那种脚本一旦写错，就可能误删文件、吞掉错误或留下半完成状态的场景。作为 bash-defensive-patterns for Backend Development，它在 shell 代码负责串联构建、部署、备份、迁移和环境初始化时尤其有价值。

它真正解决的核心问题

大多数用户真正需要的并不是“更多 Bash”，而是遇到问题能尽早失败、报错清晰、清理可靠、在边界条件下依然行为可预期的 Bash。bash-defensive-patterns 的价值在于：当你希望代理生成或审查脚本时，能以生产风险为前提思考，而不是把 shell 当成随手拼接的胶水代码。

它和通用 shell 提示词的区别

通用提示词往往只能给出在理想路径下可用的脚本，却会漏掉 set -Eeuo pipefail、trap、安全的临时文件处理、防御性引用，以及明确的退出行为。这个技能对稳健默认值有明确偏好，会把输出推向更接近生产级的模式，而不是临时凑合的一次性命令。

采用前你需要知道的事

这个仓库不是代码很多的 package，而是一个单独的 SKILL.md 文档。因此，bash-defensive-patterns install 本身很简单，但真正的价值很依赖你是否能带着上下文来调用它。如果你能把运行环境、常见失败模式和脚本用途告诉代理，这个技能会明显提升输出质量；如果你只是让它“写个 bash 脚本”，结果的差异化就会小很多。

如何使用 bash-defensive-patterns 技能

为 bash-defensive-patterns 技能准备安装上下文

如果你的代理平台支持从 GitHub 仓库引入 Skills，先添加源仓库，然后在任务中按名称调用 bash-defensive-patterns。常见做法是：

npx skills add https://github.com/wshobson/agents

接着让代理在编写或审查脚本时使用 bash-defensive-patterns 技能。这个技能在仓库中的路径是：

plugins/shell-scripting/skills/bash-defensive-patterns

先看这个文件

先从这里开始：

SKILL.md

这个技能没有额外的辅助文件，因此几乎所有决策指导都集中在这一份文档里。好处是评估速度很快：浏览一下标题，你就能很快判断这些建议是否符合你对 Bash 安全性的标准。

实际工作中最适合的用法

当你需要代理完成以下事情时，可以使用 bash-defensive-patterns usage：

• 生成新的生产级 shell 脚本
• 在发布前加固已有脚本
• 审查 CI/CD 中 Bash 的不安全假设
• 增加清理逻辑和错误 trap
• 提升日志质量和失败可见性
• 校验输入、路径和外部命令依赖

让技能发挥效果所需的输入

如果想获得高质量输出，不要只给出“脚本要实现什么”。最好一并提供：

• 目标 shell：如已知则说明 bash 版本
• 执行环境：本地 Linux、macOS、容器、CI runner
• 脚本是交互式还是非交互式
• 允许使用的外部工具：jq、curl、awk、sed、mktemp 等
• 失败策略：快速失败、重试、还是在部分错误下继续
• 副作用：文件写入、临时目录、网络调用、删除操作
• 安全关注点：密钥、破坏性命令、路径安全

没有这些上下文，代理依然可能套用一些防御性模式，但无法根据你的环境做针对性调整。

把模糊需求改写成高质量提示词

弱提示词：

• “Write a bash deploy script.”

更强的提示词：

• “Use the bash-defensive-patterns skill to write a non-interactive Bash deploy script for a Linux CI runner. It should use set -Eeuo pipefail, validate required env vars, check dependencies, create and clean up a temp directory, log failed commands with line numbers, and abort safely before any destructive step if prechecks fail.”

更强版本之所以效果更好，是因为它明确告诉代理：哪些失败处理和运维行为才是真正重要的。

新脚本场景的提示词模板

对于 bash-defensive-patterns guide 风格的请求，可以用这个模板：

• Goal: 脚本要完成什么
• Environment: 在哪里运行
• Inputs: 参数、env vars、文件、secrets
• External commands: 可用哪些命令
• Failure handling: 重试、回滚、清理、exit codes
• Safety rules: 不允许未加引号的展开、不允许不安全的 rm、必须校验路径
• Output preference: 返回完整脚本、审查说明，还是针对现有代码的 patch

这种结构能帮助技能生成更安全、也更容易直接落地的代码。

审查现有 Bash 的提示词模板

如果你已经有脚本，最好请求定向审查，而不是直接重写：

• “Use bash-defensive-patterns to review this Bash script for strict mode issues, quoting bugs, unsafe temp handling, missing cleanup, unchecked command failures, and poor error messages. Return a prioritized list of risks, then a corrected version.”

这种方式效果很好，因为这个技能本来就非常聚焦于 shell 的常见失败模式。

一个真正省时间的实用工作流

一个高效流程通常是：

1. 先生成脚本，或把现有脚本贴进去。
2. 让代理应用 bash-defensive-patterns。
3. 手动检查 trap、清理逻辑和 strict mode 行为。
4. 如果可用，再单独运行 shellcheck。
5. 不只测成功路径，也要测试失败路径。

这个技能能帮你搭出更稳健的结构，但真实路径和失败场景仍然需要执行测试来验证。

bash-defensive-patterns 技能通常会重点改善什么

从源码内容来看，你可以预期它会重点强调：

• 使用 set -Eeuo pipefail 的 strict mode
• ERR 和 EXIT traps
• 临时资源的清理
• 更安全的变量处理
• 对边界情况的防护
• 在生产压力下依然易维护的脚本写法

因此，它更适合运维类 Bash，而不是临时拼一下的 ad hoc 命令行。

约束与取舍

bash-defensive-patterns 不是 Bash runtime、linter，也不是兼容性测试套件。它提供的是指导和代码模式，但除非你明确说明目标平台，否则它无法验证每一种写法在所有环境中行为完全一致。此外，严格的防御式风格会让短脚本看起来更“重”；对生产工作流来说这是优点，但对一次性的本地小脚本，可能会显得有些过度。

什么情况下不该优先用这个技能

以下情况不建议优先使用这个技能：

• 你只需要一条 shell one-liner
• 这个任务其实更适合用 Python、Go 或其他更安全的语言实现
• 你的环境是 sh 或 dash，而不是 Bash
• 你追求的是没有运维负担的最小脚本

在这些场景里，bash-defensive-patterns skill 可能会比你真正需要的结构更多。

bash-defensive-patterns 技能常见问题

bash-defensive-patterns 技能适合初学者吗？

适合，前提是你学 Bash 是为了真实运维工作，而不是玩具示例。它给出的指导很实用，核心就是帮你避开常见错误。完全新手可能还需要补一点关于 trap、exit codes 和 strict mode 副作用的基础理解，但这些模式越早学越值得。

如果我已经在用 ShellCheck，bash-defensive-patterns install 还值得吗？

值得。ShellCheck 和 bash-defensive-patterns 解决的是不同层面的问题。ShellCheck 会指出很多语法和风格问题；这个技能则帮助代理选择更安全的整体脚本结构、清理流程、校验策略和失败语义。两者搭配使用效果很好。

bash-defensive-patterns usage 适合 CI/CD 工作吗？

非常适合。CI 和部署脚本经常以很脆弱的方式失败：pipeline 错误被隐藏、env vars 缺失、状态只执行到一半、日志又不清晰。这个技能正是针对这些失败类型设计的，所以它很适合 Backend Development 和交付自动化场景。

我可以用它来审查老脚本，而不是生成新脚本吗？

可以，而且这往往是最值得的用法之一。你可以让代理重点审计：不安全的展开、缺失的 trap 使用、没有依赖检查、输入校验薄弱，以及缺少防护的破坏性命令。相比整份推倒重写，定向加固通常更有价值。

什么情况下普通提示词就够了？

对于一次性的本地脚本、探索性试验，或者快速拼接命令，普通提示词通常就够用。只有当脚本要被共享、定时运行、跑在 CI 中，或者要接触文件、凭据、部署状态时，才更适合使用 bash-defensive-patterns。

采用时有什么阻碍吗？

主要阻碍不在安装复杂度，而在输入质量。因为这个仓库本质上只有一份指导文件，所以当你把环境、风险承受度和运维约束讲清楚时，这个技能才能发挥最好效果。如果这些信息缺失，输出可能仍然可用，但离生产可用会差一截。

如何进一步提升 bash-defensive-patterns 技能的效果

一开始就说明运维约束

想让 bash-defensive-patterns 输出更靠谱，最快的方法就是一开始明确说明：

• Bash 版本
• 平台
• 可用命令
• 失败后应该立即中止还是允许部分继续
• 清理要求
• 是否允许破坏性操作

这些信息会直接改变防御性模式的正确选型。

不只要代码，也要它设计失败路径

更好的请求方式是：

• “Generate the script and explain how it behaves on dependency failure, bad input, network timeout, and cleanup.”

这样能迫使技能把真实的运维行为说清楚，而不只是返回一份“看起来整洁”的脚本。

提供明确的高风险区域让它审查

在改进现有脚本时，把可能的风险点直接指出来：

• temp file handling
• wildcard expansion
• loops over filenames
• pipeline error masking
• missing quotes
• secret leakage in logs
• partial deploy rollback

这样比泛泛地说一句“让它更安全”通常能得到更好的结果。

直接要求有立场的 patch

如果第一轮回答太空泛，可以进一步要求：

• 一个 unified diff
• 重写后的头部，包含 strict mode 和 traps
• 一个 preflight validation section
• logging helpers
• 一个 cleanup function
• 明确的 exit codes

这类请求会迫使 bash-defensive-patterns skill 输出可直接落地的修改，而不是停留在原则层面。

专门测试 strict mode 的假设

一个很常见的问题是：启用了 strict mode，却没有处理那些“预期会返回非零”的命令。你可以要求代理找出哪些地方会因为 set -e 或 pipefail 导致意外退出，并有意识地重写这些部分。这往往正是“防御式”与“真正可用”之间最大的差距。

只在风险不直观的地方加注释

防御式 Bash 很容易变得过于嘈杂。如果第一版输出注释太多，可以这样要求：

• “Keep comments only on non-obvious defensive choices.”

这样既能保留安全性，也能让最终脚本更容易维护。

用真实错误样例迭代

最有效的 refinement loop，通常是直接贴出真实失败案例：

• “In CI, this failed because $ARTIFACT_DIR was unset.”
• “Cleanup did not run after a command in a function failed.”
• “The script broke on filenames with spaces.”

真实故障能让技能应用正确的防御性模式，而不是靠猜。

把 bash-defensive-patterns 与验证工具搭配使用

想要更强的结果，可以把这个技能和以下手段配合起来：

• 用 shellcheck 做静态分析
• 对成功和失败场景都做执行测试
• 准备一个尽量贴近生产的最小容器或 CI job
• 提供坏输入样例，而不只是 happy path fixtures

这个技能能改善脚本设计，真正确认行为还得靠工具链。

也要知道什么时候该离开 Bash

有时最好的改进，不是“写更多 Bash”。如果你的脚本已经需要复杂解析、并发、结构化错误传递，或者强跨平台保证，就该让代理评估这件事是否应该迁移到 Python 或 Go。真正用好 bash-defensive-patterns，也包括知道什么时候 Bash 已经不是合适的工具。