用途：帮助用户把一个 GitHub 仓库的“外观与治理”整理规范，例如用户要求“标准化 / 整理 / 专业化这个仓库”，或新建仓库需要从一开始就有模板、标签、CI 与规则时使用。只处理仓库元数据和配置文件，不改动任何代码逻辑，且具备幂等性，可安全重复运行，填补空缺并消除漂移。
前置检查（必须按顺序）：需 gh CLI 已认证、git、jq、python3，先确认存在。用 gh auth status 检查登录，未登录则停止并提示 gh auth login 或 export GH_TOKEN=ghp_xxx（需 repo、workflow，组织仓库可能需 admin:org 等权限）；不要向聊天、日志或文件粘贴令牌。随后用 gh repo view 判断仓库类型（个人/组织、公开/私有、默认分支、是否归档或 fork），归档与 fork 跳过写入模块。再审计标签、.github 目录、workflows、rulesets、分支及 README/CONTRIBUTING/SECURITY/LICENSE 等文件；检测测试框架以选择 CI 模板，并询问文档语言与仓库是否有自动化机器人（决定是否加入治理标签）。
工作流程：先展示干跑计划表，对规则集、分支保护变更、组织级改动等破坏性操作取得确认；随后按顺序应用各模块（标签、issue 表单、PR 模板、CI、CODEOWNERS、规则集、文档），最后复查并输出已应用/跳过/失败清单。
标签模块：先根据项目特点设计分类（评级用主题化 emoji 分级，如 grade S/A/B/C/D；优先级用 P0–P3；类型、状态、影响、规模、区域等维度按需启用），颜色需多样且语义合理，评级标签必须写 LABELS.md 说明顺序；因 GitHub 无 PUT /labels/{name}，采用 GET 判断后 POST 创建或 PATCH 更新，注意对标签名进行 URL 编码。
限制：仅支持 GitHub 仓库；必须有 gh 认证与写权限；组织仓库需成员/管理员身份；归档、fork 跳过写入；自动化治理标签仅在确有机器人时添加；不复制其他仓库的标签或规则集；令牌不得出現在聊天或文件中。其余细节（如完整 CI 模板内容）资料未完整提供。