consensus-support-reply-guard

consensus-support-reply-guard 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, tsx
• 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

node --import tsx run.js --input ./examples/input.json

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:

• invoke(input, opts?) -> Promise

invoke() 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.
• mode="persona": requires an existing persona_set_id; guard will not generate persona sets internally.