telecom-rd-project-template/.agents/skills/telecom-rd-standards/SKILL.md

name, description

name	description
telecom-rd-standards	按中国电信软件研发规范起草、规划、审查和改进软件项目。用于新项目立项与技术方案、代码审查、架构、数据库、接口、安全、测试、CI/CD、仓库、制品、部署审查，以及研发云互联互通或 OpenAPI 集成；当任务提及中国电信、研发规范、研发云、C1-C4、代码审查、项目方案、合规或交付治理时使用。

中国电信软件研发规范

以本包内原始 DOCX 对应的脱敏 Markdown 整理版为导航依据。不得臆造强制控制，也不得把 C0 建议默认为强制要求。

按需加载与复用

1. 先阅读项目根目录的 AGENTS.md，再按 INDEX.md 的任务—规范选择矩阵最小化加载；不得为普通小改动通读全部规范。
2. 新项目、设计、审查、交付或需要作出规范结论的任务，加载本技能和对应功能规范；普通小范围实现或自查，先读取相关速查指南。
3. 安全、密钥、鉴权、数据库权限、外部接口、CI/CD、制品和部署变更，无论范围大小都加载相应功能规范。
4. 仅在标记 规范要求、给出 C 级别结论、提出阻断/整改项、处理高风险变更、遇到条款争议，或功能规范明确要求时，核验对应原文及章节；争议、表格、模板和版式回查原始 DOCX。
5. 在同一任务中复用已读取且未变更的内容；任务范围、目标 C 级别、技术栈、数据敏感性、外部接口或部署方式变化时，重新选择并补充加载。

建立基线

1. 明确任务类型：项目起草、代码审查、设计审查、交付审查或研发云集成。
2. 明确项目类别和目标能力等级；未分级项目暂按 C1，并要求项目负责人最终确认。C0 为最佳实践建议，C1-C4 为逐级增强的要求。
3. 明确语言/框架、数据存储、部署目标、外部接口、数据敏感性以及是否使用研发云。
4. 按任务加载下面对应的功能规范；需要作出规范结论或处理高风险事项时，通过 规范原文索引 核验相应原文的章节和 C 级别。摘要与原文冲突时以原文为准。
5. 遵守保密要求：项目代码和文档属于中国电信内部资料，不得放入互联网暴露的存储、处理或传输工具。

新项目起草

先进行简要的结构化方案设计：

1. 写明业务目标、用户、成功度量、约束和非目标。
2. 列出假设、未知项、风险、数据分类和依赖；只追问会影响架构、安全、成本或交付的未知项。
3. 存在真实取舍时，给出 2-3 个方案，并从合规、安全、可运维性、交付成本和可逆性比较，推荐一个方案并说明理由。
4. 将选定方案转为可合规交付的计划：角色、需求追踪、设计产物、仓库和分支、测试、安全扫描、制品追溯/SBOM、流水线门禁和部署审批/回退。
5. 输出决策记录和初始待办；每个待办包含负责人、验收条件、关联需求、风险和目标版本。

需求与交付物使用 生命周期检查清单 中的流程和模板。每个需求都应能追溯到设计、代码、测试、发布和部署。

所有方案项标记为 规范要求、工程建议 或 待确认。只有原文明确支持的控制才能标为规范要求，且必须保留来源章节和 C 级别；不得把架构偏好、工具惯例或未经核验的数值阈值写成中国电信要求。

按功能加载规范

只读取与任务匹配的文件，再按其列出的原文核验：

• 新项目、架构或模块结构：01-project-init-and-architecture.md
• 需求、变更、验收或追踪：02-requirements-and-traceability.md
• Python 或前端实现/审查：03-code-standards.md
• 表结构、SQL、迁移或数据库账号：04-database-and-data-model.md
• REST/OpenAPI、外部系统或研发云：05-api-and-rd-cloud-integration.md
• 安全、密钥、鉴权、依赖或部署加固：06-security-and-secrets.md
• 仓库、分支、提交、版本或评审流程：07-repository-and-change-management.md
• CI/CD、制品、组件、SBOM 或发版：08-ci-artifacts-and-release.md
• 测试、缺陷、部署、验证或回退：09-testing-and-deployment.md

审查工作

审查证据而不是意图：检查实际差异、配置、流水线、测试结果、部署方案和相关文档。

按下列顺序输出：

优先级	含义	输出格式
阻断	违反原文强制控制，或造成重大安全/发布风险	【阻断】[C级别] 问题 — 证据 — 原文章节 — 必须整改项
需整改	未达到项目目标 C 级别的控制	【需整改】[C级别] 问题 — 证据 — 原文章节 — 整改项
建议	C0 改进项或其他非强制实践	【建议】问题 — 收益 — 建议动作
通过/不适用	控制已有证据或不在范围内	简明说明证据或理由

代码审查优先检查：日志中的密钥和敏感数据、硬编码凭据、弱/私有加密、输入输出校验、授权、错误暴露、会话、第三方依赖风险；再检查语言规范、仓库/提交/分支、测试和追溯。结论必须引用原文和章节，不得仅凭文件名宣称合规。

设计、数据库、接口、流水线、制品或部署审查，先读取相应功能规范与 生命周期检查清单，对有争议或高影响控制再核验完整原文。

研发云与外部集成

使用 研发云集成要点 处理 OAuth、平台/用户级授权、OpenAPI、数据订阅和脚手架服务。不得在输出中暴露密钥、客户端凭据、账号密钥、令牌或签名头；按原文落实最小权限、审批账号、时间戳/防重放和网络传输控制。

交付格式

每次输出结尾说明：目标 C 级别（或“待确认”）、审查范围、阻断/整改项、建议、证据缺口和最小下一步。新项目还要包含选定方案、决策记录和首批合规里程碑。