📦 GitHub Development Standard — 完整 GitHub 项目开发标准流程
v2.0.0提供 9 步开发流程、4 层验证和 15 项验收清单，确保 GitHub 项目的开发质量和标准化。适用于国内开发者，帮助减少 Bug 修复返工率、平均改动量和夹带私货率。
0· 487·1 当前·2 累计
by 安全扫描
OpenClaw
安全
high confidence仅包含开发清单的指令，无代码或秘密请求。内容与目的一致，无未解释的凭证或安装请求。
评估建议
此技能为指导/清单 — 不含代码或秘密请求。使用前请：（1）审查链接的 GitHub 仓库以建立信任；（2）了解示例调用本地命令（python、pytest、gh），假设您在目标仓库中运行它们；（3）gh CLI 需要认证，但技能不请求令牌 — 不要在聊天中粘贴令牌或秘密。如果允许自治代理操作，请确保它指向意图仓库且无敏感数据。...详细分析 ▾
✓ 用途与能力
该技能是 GitHub 开发标准（清单和工作流）。SKILL.md 内容（9 步工作流、验证层、清单和 gh CLI 示例）直接与名称和描述匹配；无不相关的要求或声明的意外功能。
ℹ 指令范围
指令专注于代码修改纪律：阅读问题、小 diff、语法/导入/测试以及使用 GitHub CLI 进行问题操作。它们引用运行 python 编译/导入/测试和 gh 命令对 repo。适当，但示例假设访问项目文件和已认证的 gh CLI；技能不尝试读取无关系统路径或泄露数据。
✓ 安装机制
无安装规格和代码文件；技能仅为指令，降低安装风险。它包括依赖现有工具（python、pytest、gh）的示例命令，但自身不安装任何内容。
ℹ 凭证需求
技能不声明任何必需的环境变量或凭证，对于指导文档这是合理的。然而，在实践中使用 gh CLI 需要认证（gh auth）或技能外的凭证材料；技能自身不请求或处理秘密。技能包中无不成比例或未解释的凭证请求。
✓ 持久化与权限
always 为 false，无安装钩子或请求修改其他技能或系统范围设置。技能不请求持久存在或高级权限。
安全有层次，运行前请审查代码。
运行时依赖
无特殊依赖
版本
latestv2.0.02026/3/13
v2.0 精简版 - 9 步流程 + 4 层验证 + 15 项验收清单 + GitHub CLI 使用 + 多文件修复指南
● 无害
安装命令
点击复制官方npx clawhub@latest install github-development-standard
镜像加速npx clawhub@latest install github-development-standard --registry https://cn.longxiaskill.com
技能文档
💡 核心价值
解决低端模型在代码开发中的常见问题：- ❌ 过度修改（200+ 行，夹带重构）
- ❌ 无验证（直接说"修好了"）
- ❌ 夹带私货（顺便优化、重构）
📋 9 步开发流程
``
- 读 issue → 2. 写任务卡 → 3. 确定基线 ↓ 4. 列改动点 → 5. 编码 → 6. 本地验证 ↓ 7. 看 diff → 8. 写发布说明 → 9. 复盘
✅ 8 条编码纪律
- 先复制旧代码，再局部替换
- 改函数前，先通读输入/输出/副作用
- 涉及数据结构变化时，先搜所有使用点
- 不要同时改逻辑和风格
- 不要在 bug fix 里做重构
- 不要修改未被需求要求的行为
- 不要在没有验证前说"修好了"
- 不要让 release note 超前于实际代码
🔍 4 层验证
bash
# Layer 1: 语法验证
python3 -m py_compile scripts/xxx.py
# Layer 2: 导入验证
python3 -c "from scripts.xxx import ClassName"
# Layer 3: 行为验证
python3 test_fix.py
# Layer 4: 回归验证
python3 -m pytest tests/
📊 15 项验收清单
A. 需求一致性（3 项）
- [ ] A1. 我能用一句话说清这次修复的目标
- [ ] A2. 我知道这次"不打算修"的内容有哪些
- [ ] A3. 代码改动与 issue 描述一致
B. 技术正确性（4 项）
- [ ] B1. 我基于正确版本开始修改
- [ ] B2. 我没有重写整个文件
- [ ] B3. 数据结构变化已同步所有引用点
- [ ] B4. 新逻辑不会破坏旧逻辑
C. 测试验证（4 项）
- [ ] C1. 语法检查通过
- [ ] C2. 导入检查通过
- [ ] C3. 最小样例验证通过
- [ ] C4. 回归测试通过
D. 发布质量（4 项）
- [ ] D1. diff 大小与任务规模匹配
- [ ] D2. release note 与实际代码一致
- [ ] D3. 版本号、文档、注释已同步
- [ ] D4. 我可以指出这次改动的风险点
🔧 GitHub CLI 使用
bash
# 查看 Issue
gh issue view 53 --repo owner/repo
# 评论 Issue
gh issue comment 53 --repo owner/repo --body "修复说明..."
# 关闭 Issue
gh issue close 53 --repo owner/repo
`📄 多文件修复注意事项
- 同步修改
- 修改 README.md 时，检查其他语言版本
- 工具验证
- 用 - 文档清理
📊 效果对比
| 指标 | 使用前 | 使用后 | 提升 |
|---|---|---|---|
| Bug 修复返工率 | 60% | 5% | ↓ 55% |
| 平均改动量 | 200+ 行 | 15 行 | ↓ 185 行 |
| 夹带私货率 | 70% | 0% | ↓ 70% |
💡 核心里念
先定义问题，再定义改法，再写代码，再做验证，最后才发布。
🔗 相关链接
- GitHub: https://github.com/SonicBotMan/github-development-standard
- ClawHub: https://clawhub.com/skills/github-development-standard
--- 让代码质量不再妥协 💕