生成生产可用 Bash/shell 脚本、自动化或 CLI…

当用户要求创建、生成、编写或搭建 Bash/shell 脚本、自动化脚本或 CLI 工具时，用阶段化流程产出可验证的生产级脚本。

适用场景

解决思路

1. 按 Stage 0→6 顺序执行，不跳过任何阶段；被阻塞时使用文档给出的回退路径。
2. Stage 0：确认范围与目标输出路径。
3. Stage 0：确认 shell 目标；默认 `bash`，若要求可移植则用 POSIX `sh`。
4. Stage 0：检查能力并选择回退路径；需求澄清默认用 AskUserQuestion 工具，回退为在普通聊天中问同样的问题，并将未解决项标记为假设。
5. Stage 0：脚本脚手架默认执行 `bash scripts/generate_script_template.sh ...`；回退为手动复制 `assets/templates/standard-template.sh` 或手工编写最小脚手架。
6. Stage 0：验证默认调用 `devops-skills:bash-script-validator`；回退为本地检查：`bash -n`、可用时运行 `shellcheck`、POSIX 模式下运行 `sh -n`。
7. Stage 0：如果使用了回退路径，在最终总结中明确说明。
8. Stage 1：只收集正确生成脚本所需信息：输入来源和格式。
9. Stage 1：收集输出目标和格式。
10. Stage 1：收集错误处理行为（fail-fast/retry/continue）。
11. Stage 1：收集安全约束（敏感数据、权限级别）。
12. Stage 1：收集性能约束（大文件、并行）。
13. Stage 1：收集可移植性要求（Bash-only vs POSIX）。
14. Stage 1：创建带稳定 ID 的 `Captured Requirements` 表格，列为 Requirement ID、Description、Source、Implementation Plan。
15. Stage 1：确保每个主要设计决策至少映射到一个 `REQ-*`。
16. Stage 1：保持假设显式且最少。
17. Stage 2：按确定性决策树选择生成路径：需要多命令架构、异常控制流或严格非模板约定时，选择 Custom generation。
18. Stage 2：否则，如果需要标准 CLI 骨架（usage/logging/arg parsing/cleanup），选择 Template-first generation；如果也不需要，则选择 Custom generation。
19. Stage 2：单用途 CLI 工具默认使用 Template-first。
20. Stage 3：使用渐进披露，只读取当前请求需要的文档。
21. Stage 3：选择工具（`grep` vs `awk` vs `sed`）时读 `docs/text-processing-guide.md`。
22. Stage 3：需要脚本结构和参数模式时读 `docs/script-patterns.md`。
23. Stage 3：需要严格模式、shell 差异和安全时读 `docs/bash-scripting-guide.md`。
24. Stage 3：需要命名、组织和质量基线时读 `docs/generation-best-practices.md`。
25. Stage 3：引用必须使用格式 `[Ref: docs/<file>.md -> <section>]`。
26. Stage 4 Path A：执行 `bash scripts/generate_script_template.sh standard output-script.sh` 生成脚手架。
27. Stage 4 Path A：替换占位符并添加业务逻辑。
28. Stage 4 Path A：除非需求另有说明，日志输出到 stderr，数据输出到 stdout。
29. Stage 4 Path A：只在逻辑非显而易见处添加注释。
30. Stage 4 Path B：构建脚本至少包含 shebang 和 strict mode。
31. Stage 4 Path B：至少包含 `usage()`。
32. Stage 4 Path B：至少包含 `parse_args()`。
33. Stage 4 Path B：至少包含输入验证和依赖检查。
34. Stage 4 Path B：至少包含主工作流函数。
35. Stage 4 Path B：至少包含可预测的退出码。
36. Stage 5：默认验证路径：调用 `devops-skills:bash-script-validator`。
37. Stage 5：应用修复。
38. Stage 5：重新运行验证。
39. Stage 5：重复直到检查通过或识别出阻塞点。
40. Stage 5：验证器不可用时回退执行 `bash scripts/run_ci_checks.sh --skip-shellcheck`。
41. Stage 5：需要 shellcheck 的 CI 门禁执行 `bash scripts/run_ci_checks.sh --require-shellcheck`。
42. Stage 5：如果跳过任何检查，在输出中包含 `Skipped check`、`Reason` 和 `Risk`。
43. Stage 6：始终返回生成脚本路径。
44. Stage 6：始终返回需求可追踪性（`REQ-*` -> implementation）。
45. Stage 6：始终返回验证结果与重跑状态。
46. Stage 6：始终返回标准格式引用。
47. Stage 6：始终返回使用的任何假设/回退。
48. Example A：澄清缺失的数据格式和输出期望。
49. Example A：捕获 `REQ-*` 表格。
50. Example A：选择 template-first 路径。
51. Example A：用 `scripts/generate_script_template.sh` 生成脚手架。
52. Example A：实现逻辑并将函数映射到 `REQ-*`。
53. Example A：用 `devops-skills:bash-script-validator` 验证并重跑直到干净。
54. Example A：返回带引用的最终总结。
55. Example B：当 AskUserQuestion、validator 技能或 shellcheck 不可用时，在聊天中提出澄清问题。
56. Example B：将未解决项标记为 `Captured Requirements` 中的假设。
57. Example B：从模板脚本生成，或使用模板文件复制回退。
58. Example B：运行 `bash -n`（相关时也运行 `sh -n`）。
59. Example B：如果缺少 `shellcheck`，报告跳过、风险与缓解措施。
60. 完成标准：确认触发匹配且范围已确认。
61. 完成标准：存在带 `REQ-*` ID 的 `Captured Requirements` 表格。
62. 完成标准：记录 template-first 与 custom 决策。
63. 完成标准：以确定性结构生成脚本。
64. 完成标准：执行验证并应用重跑策略。
65. 完成标准：任何跳过的检查都包含明确原因和风险。
66. 完成标准：最终响应包含可追踪性、引用和假设。
67. 使用辅助资源：脚本生成器 `scripts/generate_script_template.sh`。
68. 使用辅助资源：确定性 CI 门禁 `scripts/run_ci_checks.sh`。
69. 使用辅助资源：回归测试套件 `scripts/test_generator.sh`。
70. 使用辅助资源：标准脚手架 `assets/templates/standard-template.sh`。
71. 使用辅助资源：示例输出风格 `examples/log-analyzer.sh`。
72. 参考文档：`docs/bash-scripting-guide.md`。
73. 参考文档：`docs/script-patterns.md`。
74. 参考文档：`docs/generation-best-practices.md`。
75. 参考文档：`docs/text-processing-guide.md`。
76. 外部参考：GNU Bash Manual、POSIX Shell Specification、ShellCheck。

适用边界 · 注意事项

• 仅需要验证现有脚本时不要使用；应使用 `devops-skills:bash-script-validator` 做 validation-only。
• 用户没有要求创建、生成、编写或搭建 Bash/shell 脚本、自动化脚本或 CLI 工具时不要使用。
• 环境不允许运行任何本地检查且不能接受未验证交付时不适合使用；验证会依赖回退或跳过检查。