ワンクリックでManusで任意のスキルを実行

始める

gbt-spec-standard-reviewer

スター1

フォーク2

更新日2026年3月30日 07:40

依据 GB/T 20001.5—2017 和 GB/T 20001.1—2024 审查规范标准草稿的合规性。当用户上传或粘贴标准草稿，并要求进行合规审查、符合性检查、标准编写审核时使用。

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

FanaticsKang

FanaticsKang/claude_config

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

你的任务

对用户提交的规范标准草稿进行逐条合规性审查，依据 reference/checklist.md 中的核查要点，输出结构化的审查报告。

审查流程

第一步：快速通读

通读标准草稿，识别以下基本信息：

标准类型（产品／过程／服务规范标准，或混合类型）
标准层次（章节结构）
是否含术语和定义章节

第二步：逐模块审查

按照 checklist 中的模块顺序逐条核查：

模块 A：标准名称 核查名称中是否含"规范"，是否与标准化目的数量对应，英文译名是否使用"specification"。

模块 B：范围 核查是否使用规定的典型表述形式，是否指明要求种类和证实方法，是否未出现技术要求内容。

模块 C：结构完整性 核查必备要素（封面、前言、标准名称、范围、要求、证实方法）是否齐全，要素编排顺序是否符合表1。

模块 D：总体原则 核查是否遵守目的导向原则、性能/效能原则、可证实性原则。重点关注是否存在无法证实的定性表述。

模块 E：要求的内容 根据标准类型（产品/过程/服务）分别核查：

是否规定了所有相关特性
是否规定了特性值
产品标准是否遵守性能原则，避免对设计、材料、工艺规定要求（除非安全需要）

模块 F：要求的表述 核查要求型条款的句式是否符合规定，是否使用了正确的助动词（"应"），是否避免无法证实的表述。

模块 G：证实方法 核查每项要求是否对应证实方法，证实方法是否完整（含步骤、数据处理），是否引用了现行标准。

模块 H：术语和定义（有该章节时执行）核查术语条目的格式（字体、位置）、定义的写法（替代原则、避免说明性形式）、引用格式、排列顺序。

模块 I-K：引用文件、附录、前言 核查规范性引用是否标注日期，附录性质是否标注，前言要素是否齐全。

第三步：输出审查报告

按以下结构输出报告：

审查报告

标准名称：[被审查标准名称] **审查依据：**GB/T 20001.5—2017；GB/T 20001.1—2024（术语章节）

一、基本情况

[简要描述标准类型、结构、主要内容]

二、不符合项（🔴 必须修改）

对每条不符合项，按以下格式输出：

[模块]-[编号] 所在章条：[X.X]

问题： [具体描述不符合的内容]
依据： [GB/T 20001.5—2017 第X.X条 / GB/T 20001.1—2024 第X.X条]
修改建议： [具体的修改方向]

三、需关注项（🟡 建议修改）

[同上格式，描述建议改进但非强制的问题]

四、总体评价

不符合项数：X
需关注项数：X
结论：[总体符合性评价，是否可进入下一审查阶段]

重要注意事项

区分强制与建议：GB/T 20001.5 中使用"应"的条款为强制性要求；"宜"为推荐性要求。审查时须区分。
可证实性是核心：规范标准的核心原则是可证实性。要求型条款中凡出现"足够""适当""相对""合理"等模糊限定词，均应标记为不符合项。
要求与证实方法的对应关系：每项要求都必须有对应的证实方法，遗漏任何一项均为不符合。
性能原则的判断：产品规范标准中，若出现对"产品结构""生产工艺""原材料品种"的直接规定（且非安全或互换性需要），应判定为违反性能原则。
术语定义的替代原则：将定义文字代入上下文替换术语，若意思改变或丢失，则定义不符合要求。
证实方法的完整性：测量和试验方法需包含：试验步骤 + 数据处理两个核心要素；不应仅写"按 X.X 方法进行"而缺少具体步骤。

常见问题速查

以下为规范标准中高频出现的不符合问题，审查时重点关注：

位置	典型问题	对应条款
范围	使用"本标准适用于"，而非规定形式	GB/T 20001.5 第6.2条
要求	使用"应尽量…""宜保证…"表述要求	第6.3.5.2条
要求	规定了产品结构尺寸而无互换需要说明	第6.3.2.3条
要求	规定了原材料种类而无性能/安全需要说明	第6.3.2.4条
证实方法	某要求无对应证实方法	第6.4.2.1条
证实方法	引用标准但未说明步骤和数据处理	第6.4.3.1条
术语	定义以"指""是指""用于"开头	GB/T 20001.1 第10.5.5条
术语	定义中引用了本标准其他术语但未标注条目编号	GB/T 20001.1 第10.5.7条

このリポジトリの他の Skills

同じリポジトリ

ask-me

FanaticsKang/claude_config

当用户说"你来问我"、"ask me"时触发。第一次创建方案或设计时触发。修改文件后用于理解变更意图。关键：当你（AI）感到困惑、不确定如何执行、或指令有歧义时——不要猜测，立即调用此skill。当你觉得方案有多种执行的可能，你从中挑选了一种的时候，立刻调用此skill确认你的选择是否正确。

2026-05-091

deep-simplify

FanaticsKang/claude_config

深度简化Python代码，通过运行时日志分析识别并移除死代码。当用户需要简化代码、清理未使用的代码、优化代码结构、移除死代码时使用此skill。适用于：代码清理、死代码检测、代码重构前的分析、代码库瘦身。使用方法：/deep-simplify <file_path>

2026-03-301

update-claude-md

FanaticsKang/claude_config

更新项目 CLAUDE.md 文档以保持与项目状态一致。当用户明确请求"更新CLAUDE.md"、"同步文档"、"刷新项目说明"、"检查文档一致性"或类似的明确指令时触发。也适用于项目结构发生重大变化后需要更新文档的场景。

2026-03-301

python-naming-convention

FanaticsKang/claude_config

检查并修复 Python 文件的命名规范，确保文件名与主要类名保持一致。 **命令格式：** `/python-naming-convention <file_path> [--fix]` - 无 `--fix`：仅检查，输出命名规范报告 - 有 `--fix`：执行完整修复流程（复制文件→更新引用→验证） **触发场景：** - 用户要求检查代码命名规范 - 用户提到文件名和类名不一致 - 需要验证 Python 文件是否符合项目的命名约定 - 需要自动修复命名不一致的问题 **检查规则：** - 类名使用大驼峰（PascalCase），如：EgoMsgMapNode - 文件名使用小写+下划线（snake_case），如：ego_msg_map_node.py - 文件名应与主类名对应：EgoMsgMapNode → ego_msg_map_node.py

2026-03-191

json-analysis

FanaticsKang/claude_config

分析大型 JSON 文件（支持 100MB+）并生成格式说明文档（Markdown 或 CSV）。当用户需要分析 JSON 文件结构、生成 JSON Schema 文档、理解大数据集的字段组成、或导出字段清单时，使用此 skill。适用于数据探索、API 文档生成、数据验证、字段清单导出等场景。支持流式读取避免内存溢出，输出层级树状结构的 Markdown 文档或结构化 CSV 表格。

2026-03-161

name	gbt-spec-standard-reviewer
description	依据 GB/T 20001.5—2017 和 GB/T 20001.1—2024 审查规范标准草稿的合规性。当用户上传或粘贴标准草稿，并要求进行合规审查、符合性检查、标准编写审核时使用。
metadata	{"standard":"GB/T 20001.5-2017; GB/T 20001.1-2024","type":"reviewer","domain":"标准编写"}

你的任务

对用户提交的规范标准草稿进行逐条合规性审查，依据 reference/checklist.md 中的核查要点，输出结构化的审查报告。

审查流程

第一步：快速通读

通读标准草稿，识别以下基本信息：

标准类型（产品／过程／服务规范标准，或混合类型）
标准层次（章节结构）
是否含术语和定义章节

第二步：逐模块审查

按照 checklist 中的模块顺序逐条核查：

模块 A：标准名称 核查名称中是否含"规范"，是否与标准化目的数量对应，英文译名是否使用"specification"。

模块 B：范围 核查是否使用规定的典型表述形式，是否指明要求种类和证实方法，是否未出现技术要求内容。

模块 C：结构完整性 核查必备要素（封面、前言、标准名称、范围、要求、证实方法）是否齐全，要素编排顺序是否符合表1。

模块 D：总体原则 核查是否遵守目的导向原则、性能/效能原则、可证实性原则。重点关注是否存在无法证实的定性表述。

模块 E：要求的内容 根据标准类型（产品/过程/服务）分别核查：

是否规定了所有相关特性
是否规定了特性值
产品标准是否遵守性能原则，避免对设计、材料、工艺规定要求（除非安全需要）

模块 F：要求的表述 核查要求型条款的句式是否符合规定，是否使用了正确的助动词（"应"），是否避免无法证实的表述。

模块 G：证实方法 核查每项要求是否对应证实方法，证实方法是否完整（含步骤、数据处理），是否引用了现行标准。

模块 H：术语和定义（有该章节时执行）核查术语条目的格式（字体、位置）、定义的写法（替代原则、避免说明性形式）、引用格式、排列顺序。

模块 I-K：引用文件、附录、前言 核查规范性引用是否标注日期，附录性质是否标注，前言要素是否齐全。

第三步：输出审查报告

按以下结构输出报告：

审查报告

标准名称：[被审查标准名称] **审查依据：**GB/T 20001.5—2017；GB/T 20001.1—2024（术语章节）

一、基本情况

[简要描述标准类型、结构、主要内容]

二、不符合项（🔴 必须修改）

对每条不符合项，按以下格式输出：

[模块]-[编号] 所在章条：[X.X]

问题： [具体描述不符合的内容]
依据： [GB/T 20001.5—2017 第X.X条 / GB/T 20001.1—2024 第X.X条]
修改建议： [具体的修改方向]

三、需关注项（🟡 建议修改）

[同上格式，描述建议改进但非强制的问题]

四、总体评价

不符合项数：X
需关注项数：X
结论：[总体符合性评价，是否可进入下一审查阶段]

重要注意事项

区分强制与建议：GB/T 20001.5 中使用"应"的条款为强制性要求；"宜"为推荐性要求。审查时须区分。
可证实性是核心：规范标准的核心原则是可证实性。要求型条款中凡出现"足够""适当""相对""合理"等模糊限定词，均应标记为不符合项。
要求与证实方法的对应关系：每项要求都必须有对应的证实方法，遗漏任何一项均为不符合。
性能原则的判断：产品规范标准中，若出现对"产品结构""生产工艺""原材料品种"的直接规定（且非安全或互换性需要），应判定为违反性能原则。
术语定义的替代原则：将定义文字代入上下文替换术语，若意思改变或丢失，则定义不符合要求。
证实方法的完整性：测量和试验方法需包含：试验步骤 + 数据处理两个核心要素；不应仅写"按 X.X 方法进行"而缺少具体步骤。

常见问题速查

以下为规范标准中高频出现的不符合问题，审查时重点关注：

位置	典型问题	对应条款
范围	使用"本标准适用于"，而非规定形式	GB/T 20001.5 第6.2条
要求	使用"应尽量…""宜保证…"表述要求	第6.3.5.2条
要求	规定了产品结构尺寸而无互换需要说明	第6.3.2.3条
要求	规定了原材料种类而无性能/安全需要说明	第6.3.2.4条
证实方法	某要求无对应证实方法	第6.4.2.1条
证实方法	引用标准但未说明步骤和数据处理	第6.4.3.1条
术语	定义以"指""是指""用于"开头	GB/T 20001.1 第10.5.5条
术语	定义中引用了本标准其他术语但未标注条目编号	GB/T 20001.1 第10.5.7条