/bash-style
当用户操作 .sh、Dockerfile、Makefile、.yml、.yaml 文件,或在 Markdown 中编写 bash 代码块时触发。提供 Bash 编写规范。
$ npx -y skills add doccker/cc-use-exp --skill bash-style --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/bash-style
Context preview
The summary Claude sees to decide when to auto-load this skill.
当用户操作 .sh、Dockerfile、Makefile、.yml、.yaml 文件,或在 Markdown 中编写 bash 代码块时触发。提供 Bash 编写规范。
SKILL.md
bash-style.SKILL.mdname: bash-style
description: 当用户操作 .sh、Dockerfile、Makefile、.yml、.yaml 文件,或在 Markdown 中编写 bash 代码块时触发。提供 Bash 编写规范。
Bash 编写规范
版本:v1.0 更新:2026-01
---
1. 注释规范
禁止行尾注释
- ❌ **禁止行尾注释**(如 `command # 注释`)
- ✅ 注释应独占一行,放在代码上方
**适用范围**:
- Shell 脚本文件(.sh)
- Markdown 文档中的 bash 代码块
- Dockerfile、Makefile 中的 shell 命令
# ❌ 错误:行尾注释
curl -X POST https://api.example.com/data # 发送请求
docker run -d nginx # 启动容器
cp -r src/ dist/ # 复制文件
# ✅ 正确:注释独占一行
# 发送请求
curl -X POST https://api.example.com/data
# 启动容器
docker run -d nginx
# 复制文件
cp -r src/ dist/
**原因**:
- 复制粘贴时容易带上注释导致命令出错
- 长命令 + 注释 = 超长行,可读性差
- Heredoc 块内 `#` 不是注释而是内容
---
2. 文件写入方式
推荐方式:tee 命令
# ✅ 推荐:简洁、无嵌套引号
sudo tee /etc/fail2ban/jail.d/docker-nginx.local > /dev/null << 'EOF'
[docker-nginx]
enabled = true
filter = docker-nginx
logpath = /var/log/nginx/access.log
maxretry = 5
EOF
追加内容
# ✅ 追加到文件
sudo tee -a /etc/hosts > /dev/null << 'EOF'
192.168.1.100 myserver
EOF
# ✅ 单行追加
echo '192.168.1.100 myserver' | sudo tee -a /etc/hosts
避免的写法
# ❌ 避免:嵌套引号复杂,易出错
sudo bash -c 'cat > /etc/xxx << EOF
content
EOF'
# ❌ 避免:需要转义内容中的特殊字符
sudo sh -c "echo 'line1\nline2' > /etc/xxx"
方式对比
| 方式 | 优点 | 缺点 | 推荐场景 | |------|------|------|---------| | `sudo tee` | 简洁、无嵌套 | 需 `> /dev/null` 抑制输出 | **首选** | | `sudo bash -c 'cat >'` | 无需 tee | 嵌套引号复杂 | 不推荐 | | 临时文件 + mv | 可先验证 | 步骤多 | 复杂配置 |
---
3. Heredoc 引号规则
禁止变量展开(推荐默认)
# ✅ 'EOF' 带引号:内容原样输出,不解析变量
sudo tee /etc/xxx > /dev/null << 'EOF'
$HOME 不会被展开
$(command) 不会被执行
EOF
需要变量展开
# EOF 不带引号:变量会被展开
sudo tee /etc/xxx > /dev/null << EOF
当前用户: $USER
当前目录: $(pwd)
EOF
选择原则
| 场景 | 用法 | 原因 | |------|------|------| | 配置文件 | `<< 'EOF'` | 避免意外展开 | | 模板生成 | `<< EOF` | 需要插入变量 | | 不确定时 | `<< 'EOF'` | 更安全 |
---
4. 权限与路径
需要 root 权限
# ✅ 正确:tee 配合 sudo
echo 'content' | sudo tee /etc/xxx
# ❌ 错误:重定向在 sudo 之外,权限不足
sudo echo 'content' > /etc/xxx
路径带空格
# ✅ 正确:双引号包裹路径
sudo tee "/etc/my config/file.conf" > /dev/null << 'EOF'
content
EOF
---
5. 脚本规范
文件头
#!/usr/bin/env bash
set -euo pipefail
# 脚本说明(一句话)
set 选项说明
| 选项 | 作用 | |------|------| | `-e` | 命令失败时退出 | | `-u` | 使用未定义变量时报错 | | `-o pipefail` | 管道中任一命令失败则整体失败 |
变量使用
# ✅ 推荐:使用 ${} 包裹
echo "Hello, ${name}"
# ✅ 推荐:设置默认值
db_host="${DB_HOST:-localhost}"
# ❌ 避免:裸变量(易与后续字符混淆)
echo "Hello, $name_suffix"---
6. 常用模式
检查命令是否存在
if ! command -v docker &> /dev/null; then
echo "docker 未安装"
exit 1
fi检查文件/目录
# 文件存在
[[ -f /path/to/file ]] && echo "文件存在"
# 目录存在
[[ -d /path/to/dir ]] || mkdir -p /path/to/dir
安全删除
# ✅ 使用变量时防止误删
rm -rf "${dir:?}"/*
# ❌ 危险:变量为空时会删除根目录
rm -rf $dir/*---
7. 文档中的代码块
在 Markdown 文档中编写 bash 命令时,同样遵循以上规范:
## 安装配置
创建配置文件:
```bash
sudo tee /etc/myapp/config.yml > /dev/null << 'EOF'
server:
port: 8080
host: 0.0.0.0
EOF
---
## 参考资料
- [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html)
- [Bash Pitfalls](https://mywiki.wooledge.org/BashPitfalls)
- [ShellCheck](https://www.shellcheck.net/)
Read more
name: bash-style description: 当用户操作 .sh、Dockerfile、Makefile、.yml、.yaml 文件,或在 Markdown 中编写 bash 代码块时触发。提供 Bash 编写规范。
Bash 编写规范
版本:v1.0 更新:2026-01
---
1. 注释规范
禁止行尾注释
- ❌ **禁止行尾注释**(如 `command # 注释`)
- ✅ 注释应独占一行,放在代码上方
**适用范围**:
- Shell 脚本文件(.sh)
- Markdown 文档中的 bash 代码块
- Dockerfile、Makefile 中的 shell 命令
# ❌ 错误:行尾注释 curl -X POST https://api.example.com/data # 发送请求 docker run -d nginx # 启动容器 cp -r src/ dist/ # 复制文件 # ✅ 正确:注释独占一行 # 发送请求 curl -X POST https://api.example.com/data # 启动容器 docker run -d nginx # 复制文件 cp -r src/ dist/
**原因**:
- 复制粘贴时容易带上注释导致命令出错
- 长命令 + 注释 = 超长行,可读性差
- Heredoc 块内 `#` 不是注释而是内容
---
2. 文件写入方式
推荐方式:tee 命令
# ✅ 推荐:简洁、无嵌套引号 sudo tee /etc/fail2ban/jail.d/docker-nginx.local > /dev/null << 'EOF' [docker-nginx] enabled = true filter = docker-nginx logpath = /var/log/nginx/access.log maxretry = 5 EOF
追加内容
# ✅ 追加到文件 sudo tee -a /etc/hosts > /dev/null << 'EOF' 192.168.1.100 myserver EOF # ✅ 单行追加 echo '192.168.1.100 myserver' | sudo tee -a /etc/hosts
避免的写法
# ❌ 避免:嵌套引号复杂,易出错 sudo bash -c 'cat > /etc/xxx << EOF content EOF' # ❌ 避免:需要转义内容中的特殊字符 sudo sh -c "echo 'line1\nline2' > /etc/xxx"
方式对比
| 方式 | 优点 | 缺点 | 推荐场景 | |------|------|------|---------| | `sudo tee` | 简洁、无嵌套 | 需 `> /dev/null` 抑制输出 | **首选** | | `sudo bash -c 'cat >'` | 无需 tee | 嵌套引号复杂 | 不推荐 | | 临时文件 + mv | 可先验证 | 步骤多 | 复杂配置 |
---
3. Heredoc 引号规则
禁止变量展开(推荐默认)
# ✅ 'EOF' 带引号:内容原样输出,不解析变量 sudo tee /etc/xxx > /dev/null << 'EOF' $HOME 不会被展开 $(command) 不会被执行 EOF
需要变量展开
# EOF 不带引号:变量会被展开 sudo tee /etc/xxx > /dev/null << EOF 当前用户: $USER 当前目录: $(pwd) EOF
选择原则
| 场景 | 用法 | 原因 | |------|------|------| | 配置文件 | `<< 'EOF'` | 避免意外展开 | | 模板生成 | `<< EOF` | 需要插入变量 | | 不确定时 | `<< 'EOF'` | 更安全 |
---
4. 权限与路径
需要 root 权限
# ✅ 正确:tee 配合 sudo echo 'content' | sudo tee /etc/xxx # ❌ 错误:重定向在 sudo 之外,权限不足 sudo echo 'content' > /etc/xxx
路径带空格
# ✅ 正确:双引号包裹路径 sudo tee "/etc/my config/file.conf" > /dev/null << 'EOF' content EOF
---
5. 脚本规范
文件头
#!/usr/bin/env bash set -euo pipefail # 脚本说明(一句话)
set 选项说明
| 选项 | 作用 | |------|------| | `-e` | 命令失败时退出 | | `-u` | 使用未定义变量时报错 | | `-o pipefail` | 管道中任一命令失败则整体失败 |
变量使用
# ✅ 推荐:使用 ${} 包裹
echo "Hello, ${name}"
# ✅ 推荐:设置默认值
db_host="${DB_HOST:-localhost}"
# ❌ 避免:裸变量(易与后续字符混淆)
echo "Hello, $name_suffix"---
6. 常用模式
检查命令是否存在
if ! command -v docker &> /dev/null; then
echo "docker 未安装"
exit 1
fi检查文件/目录
# 文件存在 [[ -f /path/to/file ]] && echo "文件存在" # 目录存在 [[ -d /path/to/dir ]] || mkdir -p /path/to/dir
安全删除
# ✅ 使用变量时防止误删
rm -rf "${dir:?}"/*
# ❌ 危险:变量为空时会删除根目录
rm -rf $dir/*---
7. 文档中的代码块
在 Markdown 文档中编写 bash 命令时,同样遵循以上规范:
## 安装配置 创建配置文件: ```bash sudo tee /etc/myapp/config.yml > /dev/null << 'EOF' server: port: 8080 host: 0.0.0.0 EOF
--- ## 参考资料 - [Google Shell Style Guide](https://google.github.io/styleguide/shellguide.html) - [Bash Pitfalls](https://mywiki.wooledge.org/BashPitfalls) - [ShellCheck](https://www.shellcheck.net/)
保留你熟悉的 CLI/IDE,让 Claude Code、Gemini CLI、Codex、Cursor、GitHub Copilot 开箱即用 按费力度从低到高,用最少操作获得最大帮助 不是提示词集合,而是一套可维护的 AI 协作配置系统。
Repo: doccker/cc-use-exp
Other skills on cc-use-exp.
- /api-design-safety
当设计或修改 REST API 响应结构、处理 API 返回值,或生成 Excel/CSV/PDF/对账文件等下游产物时触发。防止 API 设计缺陷导致的字段错位、类型歧义,以及生成产物时关键字段缺失但静默成功的问题。
Open skill - /api-proxy-safety
网关/代理/WAF/CDN 中间件的安全关键词匹配实现规范,防止纯子串匹配误判正常响应内容中的技术术语(如 Cloudflare、502、error)
Open skill - /async-task-pattern
当 API/任务可能执行超过 10 秒(批量数据处理、远程 API 批量调用、全表扫描、跨租户聚合)时触发。防止同步接口被网关 30s 超时切断、用户重复点击触发并发、状态缓存内存泄漏等问题。提供异步任务状态机标准模板。
Open skill - /code-quality-principles
当编写新模块、设计接口、重构代码或代码审查时触发。提供经典模块化六原则检查清单(大小适中/调用深度/扇入扇出/边界清晰/作用域内聚/可预测性),适用于 PR/Review/新模块设计场景。
Open skill - /external-system-debugging
涉及浏览器、编辑器、CDN/WAF、IM 平台、操作系统剪贴板、第三方 SaaS 等"外部黑盒系统"的代码编写或 bug 调试时触发。强制先抓真实环境数据再推理,避免连续 2 轮"凭代码推理"的修复 no-op。关键词:粘贴/复制异常、跨平台显示不一致、第三方 API 怪结果、CDN/WAF 拦截、本地复现失败、HTML→MD 转换丢属性。
Open skill - /field-mapping-safety
当重构涉及字段映射(dataIndex、枚举映射、类型转换)时触发。防止字段名推测错误,确保字段映射的正确性。
Open skill

