GitHub Standards 是一份 GitHub 仓库与工作流约定集合，声称来自 22 个以上生产仓库的实践。它以规范文档的形式给出在 GitHub 上进行日常协作时的推荐做法，内容以检查清单、模板和示例命令为主。
用途
该技能用于在以下场景中提供规范参考：创建仓库、发起 Pull Request、推送代码、设置 CI，创建分支、编写 README 等。它把散落的仓库约定集中成可查阅的规则集，帮助团队在协作中保持一致。
主要能力
敏感数据与提交前检查：要求在每次提交前扫描暂存文件，防止密钥泄露。文档给出了自动扫描的 grep 命令，列出了绝不应提交的文件类型（如 .env、.pem、.key、credentials.json、id_rsa、sessions.json 等），说明了如果密钥已被提交应如何从跟踪中移除、轮换密钥以及考虑重写历史，还给出了用环境变量替代硬编码密钥的安全做法对照表。
提交信息格式：规定格式为 type(scope): 主题行，并附动机、变更、解决的问题与关联工单。要求主题行使用祈使语气、不超过 72 字符，类型包括 feat、fix、docs、chore、refactor、ci、style、test、perf，正文每行 72 字符换行，禁止添加 Co-Authored-By 或提及 AI 工具，禁止使用 git add -A 或 git add .，多行消息使用 heredoc。小型改动可用单行消息，并给出示例。
Pull Request 规范：标题沿用 Conventional Commits 格式且不超过 72 字符；正文模板包含 Summary、Related issue、Changes、Test plan（含类型检查、Lint、测试、手工测试、边界情况等复选框）和 Screenshots。规则包括一个 PR 只处理一件事、进行中的工作使用草稿 PR、请求审查前先自查、关联 issue、PR 尽量小于 400 行变更、不使用 merge commit 而用 squash 或 rebase 保持线性历史。
分支命名：格式为 type/description-in-kebab-case，给出了 feat、fix、refactor、chore、docs、ci、release、hotfix 等前缀的适用场景与示例，要求全小写、kebab-case，可带工单 ID，合并后删除，主分支为 main。
仓库初始化：列出每个仓库需要的文件（README.md、.gitignore、CLAUDE.md、.env.example、LICENSE）及其创建时机；给出应用、库、API、iOS 应用、落地页等仓库命名约定；建议为仓库设置包含 emoji 与关键技术的一行描述。
.gitignore 基线：给出操作系统、IDE、密钥、构建产物四个类别的最小忽略清单，并补充 Node.js/TypeScript、Rust、Swift/iOS、Go 的语言专属条目。
README 要求：最小结构包括项目名称、一段简介、Setup、Development、Architecture；列出触发更新 README 的情况（新增安装步骤、架构变化、构建部署流程变化、系统要求变化）；指出不要把密钥写入 README、不要把未实现的功能写成已有、不要让 README 腐化。
发布与标签：采用语义化版本 v{major}.{minor}.{patch}，给出带注释标签的命令，以及 CHANGELOG.md 的 Added/Fixed/Changed 结构示例。
CI/CD 基线：给出最小 CI 工作流示例（TypeScript/Node、Rust、Go 的检查命令）以及桌面应用的发布工作流示例（macOS 与 Windows 目标矩阵、Tauri 构建、产物上传）。
代码审查清单：涵盖密钥检查、测试、类型正确性、错误处理、README 与 CLAUDE.md 更新、提交信息格式、分支清理、调试输出和注释代码等检查项。
供应链加固：建议将第三方 Action 固定到 SHA 而非标签，限制 GITHUB_TOKEN 权限并逐任务按需开启，给出 Dependabot 基线配置和 CODEOWNERS 示例。
GitHub 设置：建议默认分支为 main、开启分支保护、自动删除头分支、默认 squash 合并、启用 Issues、按需启用 Discussions、启用密钥扫描与推送保护等。
使用方式
该技能本身是一份规范文档，通常由 AI 助手在相关场景中引用这些规则，或以检查清单的形式辅助用户执行。文档中提供了可直接使用的命令、配置文件和模板代码。安装方式未提供。
适用场景
适合个人开发者或团队在 GitHub 上建立统一的仓库规范，尤其是需要防止密钥泄露、统一提交与 PR 格式、统一 CI 与发布流程的场景。
限制
文档未提供关于该技能所支持的平台、集成方式、安装命令或自动化程度的说明，也暂未提供收费与许可信息。部分规则（如 PR 变更行数、Dependabot 提交数上限）属于建议值，实际适用性需自行判断。