consensus-support-reply-guard
INLINECODE0 is a customer-trust guard for support workflows.
What this skill does
- - evaluates support drafts before sending
- detects high-risk claim patterns
- blocks or rewrites responses when policy violations appear
- updates persona reputations based on final decision alignment
- preserves decision history in board artifacts
Why this matters
Support replies are high-frequency and brand-critical. This skill prevents overconfident legal/PII mistakes at scale.
Ecosystem role
Composes with consensus board state using explicit vote inputs and deterministic guard decisions.
Ideal scenarios
- - automated ticket triage replies
- L1/L2 AI response review gates
- regulated or enterprise support channels
Runtime, credentials, and network behavior
- - runtime binaries:
node, INLINECODE2 - network calls: none in the guard decision path itself
- filesystem writes: board/state artifacts under the configured consensus state path
Dependency trust model
- -
consensus-guard-core is the first-party consensus package used in guard execution - versions are semver-pinned in
package.json for reproducible installs - this skill does not request host-wide privileges and does not mutate other skills
Quick start
CODEBLOCK0
Tool-call integration
This skill is wired to the consensus-interact contract boundary (via shared consensus-guard-core wrappers where applicable):
- - readBoardPolicy
- getLatestPersonaSet / getPersonaSet
- writeArtifact / writeDecision
- idempotent decision lookup
This keeps board orchestration standardized across skills.
Invoke Contract
This skill exposes a canonical entrypoint:
INLINECODE6 starts the guard flow and executes deterministic policy evaluation with board operations via shared guard-core wrappers.
external_agent mode
Guards support two modes:
- -
mode="external_agent": caller supplies external_votes[] from agents/humans/models for deterministic aggregation. - INLINECODE9 : requires an existing
persona_set_id; guard will not generate persona sets internally.
consensus-support-reply-guard
consensus-support-reply-guard 是一个面向客服工作流的客户信任防护模块。
该技能的功能
- - 在发送前评估客服回复草稿
- 检测高风险声明模式
- 当出现策略违规时阻止或重写回复
- 根据最终决策一致性更新角色信誉度
- 在面板制品中保存决策历史
为何重要
客服回复具有高频次且对品牌至关重要。该技能可大规模防止过度自信的法律/个人身份信息错误。
生态角色
通过明确的投票输入和确定性防护决策，与共识面板状态协同工作。
理想场景
- - 自动化工单分类回复
- L1/L2 AI回复审查关卡
- 受监管或企业级客服渠道
运行时、凭证与网络行为
- - 运行时二进制文件：node、tsx
- 网络调用：防护决策路径本身无网络调用
- 文件系统写入：在配置的共识状态路径下写入面板/状态制品
依赖信任模型
- - consensus-guard-core 是防护执行中使用的第一方共识包
- 版本在 package.json 中通过语义化版本锁定以确保可重现安装
- 该技能不请求主机级权限，也不修改其他技能
快速开始
bash
node --import tsx run.js --input ./examples/input.json
工具调用集成
该技能通过共识交互合约边界（在适用处通过共享的 consensus-guard-core 包装器）连接：
- - readBoardPolicy
- getLatestPersonaSet / getPersonaSet
- writeArtifact / writeDecision
- 幂等决策查询
这使得面板编排在各技能间保持标准化。
调用合约
该技能暴露一个规范入口点：
- - invoke(input, opts?) -> Promise
invoke() 启动防护流程，并通过共享的防护核心包装器执行带面板操作的确定性策略评估。
external_agent 模式
防护支持两种模式：
- - mode=externalagent：调用方提供来自代理/人类/模型的 externalvotes[] 用于确定性聚合。
- mode=persona：需要现有的 personasetid；防护不会在内部生成角色集。
