agentleFS
sakuruamayday-opssakuruamayday-ops/enterprise-project-application-assistant/skills/standard-drafting/SKILL.md

standard-drafting

Skill2 starsChanged 2 months agoApache-2.0View on GitHub

按现行GB/T 1.1及适用的专项起草规则完成国家标准、行业标准、地方标准、团体标准和企业标准的立项分析、资料核验、结构设计、条款起草、编制说明、征求意见处理和一致性审查。用户提出写标准、编标准、标准立项、企业标准、团体标准、产品标准、服务标准、管理标准、试验方法标准、标准修订、标准审查或编制说明时使用。

The file

Files
SKILL.md

标准撰写

总原则

以标准化对象和可验证技术事实为起点,不把宣传文案改写成标准。先核验现行法规、强制性标准和基础标准,再确定文件类型、适用范围和技术指标。

执行以下门禁:

  1. 不虚构性能指标、试验条件、抽样方案、判定阈值或标准引用。
  2. 不使用已废止或被替代的标准作为现行依据。
  3. 不用“必须”强化要求;按条款性质正确使用“应、不应、宜、不宜、可、不必、能、不能、可能、不可能”。
  4. “范围”只界定标准化对象、规定内容和适用界限,不写具体要求。
  5. 每项可检验要求均应有对应试验或验证方法;没有验证方法的指标不得直接定稿。
  6. 规范性引用文件只列构成本文件必不可少条款的公开文件。
  7. 涉及专利、强制性要求、安全、环保、健康、数据或认证时,单独提示核验。
  8. 标准正文不新增“数据来源”或“参考资料”章节,不插入内部证据编号;“规范性引用文件”保持标准结构含义和原位。指标、试验方法、限值和其他起草依据统一进入 evidence-ledger,另生成《标准数据来源说明》,不得为了统一报告格式移动标准章节。

工作流程

1. 识别任务

先确认:

  • 文件层级:国家、行业、地方、团体或企业标准。
  • 文件功能:基础通用、术语、分类编码、产品、过程、服务、管理、试验方法或其他。
  • 动作类型:新制定、修订、整合、采标、审查或编制说明。
  • 标准化对象、使用者、实施场景、地域和行业。
  • 是否存在上位法规、强制性标准、现行同类标准或国际文件。

信息不足时先输出《标准起草输入清单》,不得直接生成完整标准。

2. 建立依据矩阵

按以下优先级检索并记录状态、版本和适用关系:

  1. 法律、行政法规、部门规章和强制性国家标准。
  2. GB/T 1.1现行版本及适用的GB/T 20000、GB/T 20001、GB/T 20002系列文件。
  3. 同领域国家、行业、地方、团体和企业标准。
  4. 产品技术文件、试验报告、检验数据、工艺文件、客户要求和风险记录。
  5. 国际标准或国外先进标准。

先读取起草规则摘要。涉及具体类型时,再读取标准类型与章节模型。

3. 形成标准设计

在写正文前输出并确认:

  • 拟定名称及主体要素、引导要素、补充要素。
  • 范围边界和排除事项。
  • 预计使用者与符合性判断方式。
  • 章节结构。
  • 关键术语。
  • 技术要求来源。
  • 要求—试验方法—判定规则对应矩阵。
  • 与现行同类标准的差异。
  • 可能涉及的专利及知识产权声明。

4. 起草正文

优先使用标准草案模板,按确认后的文件类型删改章节。

正文至少检查:

  • 名称与范围一致。
  • 术语只定义本文件中重复使用、可能产生歧义且尚无适用定义的概念。
  • 条款只表达一个主要动作或要求。
  • 同一概念只使用一个术语。
  • 表、图、公式、示例、注和附录均被正文提及。
  • 数值包含量、单位、容差、边界和适用条件。
  • 要求与试验方法顺序尽量一致。
  • 检验规则明确检验分类、组批、抽样、判定和复验。
  • 标志、包装、运输、贮存只写与标准化对象有关且可实施的内容。

5. 编制说明和意见处理

使用编制说明模板,至少说明:

  • 任务来源、目的和必要性。
  • 起草过程和参与单位。
  • 起草原则及主要技术内容依据。
  • 关键指标、试验方法和限值的来源。
  • 与法规、强制性标准和国内外相关标准的关系。
  • 重大分歧、征求意见及处理结论。
  • 专利、产业化、实施成本和预期效益。
  • 新旧版本主要技术变化。

6. 自动审查

对Markdown或纯文本草案运行:

python3 skills/standard-drafting/scripts/audit_standard_draft.py 标准草案.md

自动检查只用于发现结构、措辞和映射风险,不替代标准化技术组织、归口单位或专家审查。

7. 交付

默认交付:

  1. 标准草案。
  2. 编制说明。
  3. 标准数据来源说明。该文件独立交付,不并入标准正文。
  4. 规范性引用文件核验表。
  5. 要求—试验方法—判定规则矩阵。
  6. 征求意见汇总处理表。
  7. 起草审查问题清单。

生成Word、PDF或表格时调用宿主平台对应文档能力,本Skill不重复打包通用文档工具。

如果用户提供Word标准模板并要求按原格式填写,默认只允许替换既有文字节点。禁止用 python-docx 重建模板,禁止重新创建封面、抬头、段落、表格、样式或页眉页脚;字体、字号、颜色(包括红字)、表格布局、边框、合并关系、节属性和页面边距必须保持不变。交付前运行 skills/_runtime/template-fidelity/scripts/validate_docx_text_only.py 并逐页视觉检查。文字过长时压缩条文表达,不得通过改字号、改行距、改边距或重新排版解决。

质量结论

审查结果使用三档:

  • 可进入征求意见:结构、依据和技术闭环基本完整。
  • 补证后进入征求意见:缺少指标来源、试验验证、引用状态或实施证据。
  • 暂不具备起草条件:标准化对象不清、与强制要求冲突或核心技术内容无法验证。

不得承诺标准一定立项、发布、备案或获得主管部门认可。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.