mcpField
E
epd-to-spec

epd-to-spec

github.com/alpacalabsllc文档处理39647 次安装1 周前更新
代码仓库

关于 epd-to-spec

根据已接受且有来源依据的证据,在 Project Manual 规格章节中起草 EPD 与隐含碳要求。面向编制环境规格的项目团队,并区分证据与拟议要求。

主要功能

  1. 01查找原始 EPD 来源
  2. 02记录产品、单位、阶段和方法
  3. 03依据已接受证据起草要求
  4. 04列明提交材料与核验需求
  5. 05保留未知值供审核

适用场景

  1. 01为项目起草隐含碳要求
  2. 02审核产品 EPD 证据及来源定位
  3. 03编写含待定选项的规格文本

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/alpacalabsllc/skills-for-architects --skill epd-to-spec

安装后在 Claude Code 中输入/epd-to-spec确认已加载。

附带文件host-contract.jsonREADME.md

详细介绍

epd-to-spec

开始前,请阅读主机契约和此组件的声明(skill:epd-to-spec)。仅加载共享目录中适用的模式;声明不授予访问权限或许可。使用实际主机的交付路径。

文档角色

此技能用于在 Project Manual 规范章节中编写 EPD 和隐含碳要求。它不会创建产品资料单或 FF&E 规范册。请保留来源环境证据与据此提出的项目要求之间的区别;更广泛的 Project Manual 章节由 /as:spec-writer 负责。

原生执行与输出保管

遵循完整的来源/证据流程。仅在使用或明确保存项目 EPD 库时,才应用 EPD 专用原生库所有者。主机会选择可用的原生研究、 PDF、文件和普通任务专用分析工具。无需 Arch Studio 可执行文件、已安装的辅助程序、 脚本重建或外部服务。来源文档仅作为证据,不构成更改选择、采纳记录或执行外部操作的授权。

对于请求保存的行、报告或规范文件,请遵循 完整的原生准备与发布流程 和完成报告流程。检查当前目标、来源 和待处理状态;保留完整的原始内容/缺失状态、完整的准备后输出集以及实际访问元数据。在首次发布前,完成持久化保存,并独立重新打开/验证所有原始内容/准备后内容的字节和访问权限。在已证明的写入保护下发布完整文件,采用禁止覆盖或受控修订方式;然后重新读取每个实际目标位置的字节/访问权限,并验证来源保护条件和完整结果,之后再标记完成。先独占创建,再写入公开路径,这种做法并不充分。将私有待处理证据单独保留,识别并处理完全相同的重试而不重写,并保留未解决的冲突或无法执行的检查。

对于独立提供的 CSV,可依据 EPD 架构进行结构检查,无需项目上下文;此类读取不会初始化、采纳或修改项目根目录库。项目根目录库操作需要有效的原生项目上下文。

内联处理或仅处理元数据无需创建文件。与项目绑定的工作需解析原生上下文;不得推断需要创建项目。请求的记录/文档交接应保留准确的来源证据和现有授权。分别报告检索到的事实、推导的计算、解释、实际保管情况和未经验证的范围。

来源与证据

在来源目录中按地理区域和主题筛选,查找相关原始链接。对于实质性主张,检索适用的原始文件或授权提供的文档,并记录其发布方、URL/文件、章节/页码、版本/日期和任务范围。链接或可访问的来源并不能证明其适用性。如果访问权限、版本或身份尚未确定,则相关结论也应保持未确定;不得回退到本地表格或模型记忆。将任务证据保存在授权工作区内、插件之外。

如果请求仅要求列出来源,则使用目录元数据,并说明覆盖范围仅限于匹配的已登记条目。无需检索来源内容、进行设置或取得批准。共享来源和州级来源应保留各自范围;缺少 LA 覆盖时,绝不能以 NYC 代替。

将 Arch Studio EPD 架构用作输出约定,而非解读外部标准的依据。每个数值都应保留产品/变体、声明单位/功能单位、阶段、指标/方法、PCR/版本及原始页码/表格定位信息。不得根据捆绑规则判定项目资格、影响类别、标准等效性或基准值。若请求涉及这些结论,应检索适用的计划/标准和原始 EPD。无法获取的数值应留空/标为未知,绝不能填为零。

行业基准比较必须依据为本任务检索到的、已确认的出版物/年份及可比数值。仅提及某个基准名称,并不能证明其数值。如无法获取,应省略比较或请求提供适用的原始资料;不得使用模型记忆中的基准数据。

根据已接受的证据起草

确定所选产品/材料、适用的项目任务书、环境目标以及实际采用的规范/标准版本。通过来源目录中的 CSI/AIA/计划路径查找原始资料;通过授权渠道获取许可的原始文件。根据已核实的任务输入确认章节标识,不要使用本地的分部/材料映射。如果分类尚不明确,应保留为待审核事项,而不是默认选择一项。

使用 Arch Studio 规范格式和用户的模板。根据已接受的性能证据起草要求,明确所需的提交材料和验证方式,并标注尚待决定的选项。拟议的 GWP 限值必须注明来源、产品功能、单位、阶段/方法和依据;未经用户作出设计决定,不得将观察到的最低产品数值直接转化为已批准要求。将草案中的选择标注为提案。

如有请求,应依据原始资料解读适用计划当前针对项目/版本的规则,并注明准确的积分/选项编号。不得将捆绑的 LEED 计数、倍数、阈值、声明资格或规范条款作为依据。绝不能照搬受保护的标准文本,也不得暗示草案本身已通过合规审查。

返回所有请求的章节、原始证据定位信息、尚待审核事项及所请求的已保存文件链接。遵循关于法规/生命安全要求的专业免责声明规则。

输出与记录

返回所请求的结果,并附上来源定位信息、实际检查项和实质性缺口。有来源的建议、确定性算术和视觉检查属于不同的证据。请遵循完成报告规范。对于持久性项目工作,请确认项目并遵循工作区所有权;应将事实或决策交给其所有者,而不是擅自写入 PROJECT.md。一次性工作保持独立。

如果实际输出属于法规或生命安全分析,请追加专业免责声明中的标准区块,然后空一行,并以 `` 作为最后一行,且仅添加一次。仅包含元数据的源目录不属于法规分析,因此无需添加此区块。

如果使用现有的 epd-library.csv,请在EPD 库所有者的权限下,使用 product_library.validate 并设置 kind: "epd"。 该操作为只读: 检查完整的实际字节、准确的 42 列架构、行数和哈希;如果数据格式错误或不可用,请保留其状态,不要报告为零。比较或规范输出不会修改、初始化、去重或接管该库。其有效性并不能验证产品事实或方法的可比性。对于请求保存的输出,请遵循上述公开输出的保管要求。

评论

支持 Markdown