用途：向 ***plain 规范文件的 functional specs 部分新增一条功能规范（functional spec）。适用场景是需要且仅需添加一条新功能规范时。
主要流程：若尚未加载，先使用 load-plain-reference 获取 ***plain 语法规则；确定目标 .plain 文件，若有歧义询问用户；通读整个文件，理解既有定义、实现要求以及全部现有功能规范（含 requires 模块中的）；按规则起草规范；用 analyze-if-func-spec-too-complex 校验草稿是否隐含不超过 200 行代码，超出则用 break-down-func-spec 拆分并对每个结果重复起草；用 analyze-func-specs 将新规范与全部现有规范作为单一批次检查冲突，不要逐对调用；对报告的每个冲突对运行 resolve-spec-conflict，每次解决后对受影响集合重跑 analyze-func-specs 直到结论为 COMPATIBLE；将规范追加到 functional specs 部分末尾（按时间顺序，新规范放最后）；再读一遍文件确认位置与语法正确。
规则要点：每条规范最多隐含 200 行代码变更，且规范文本中不写 LOC 估算；按时间顺序排列，规范自上而下增量渲染，渲染器不感知后续规范，新规范可引用更早规范的行为，但不能假设之后规范；使用语言无关表述，只描述行为、概念与领域逻辑，语言特定内容应放入 implementation reqs；不得与任何现有功能规范冲突；必须无歧义，单行不够时用嵌套子条目补充细节；functional specs 内每行都必须是独立列表项并以 - 开头，硬性上限每行 120 字符，超长须在自然分句处拆成嵌套 - 条目；外部接口必须显式（如 REST 路径与 HTTP 方法、CLI 命令与参数、文件格式、消息模式等）；功能须自包含，不要依赖 implementation reqs 传达行为；如需验证，插入规范后用 add-acceptance-test 添加验收测试。
限制：所有引用概念须在 definitions 中定义；不得冗余；通常置于末尾，若必须先于后续规范则放在正确位置。以上细节基于所给资料整理，价格或其他未提供信息暂未提供。