consensus-support-reply-guard

Risk-aware support response governance with persona-weighted consensus. Detects legal/sensitive/confidentiality issues, applies hard-block policy checks, and...

Security Scan

The skill's code, runtime instructions, and required environment variables are consistent with a local, filesystem-backed support-reply governance tool; nothing in the bundle indicates hidden exfiltration or unrelated privilege requests.

Purpose & Capability

Name/description (support reply governance) aligns with the code and SKILL.md: the package runs Node, uses a consensus-guard-core library, evaluates drafts, and writes decision artifacts to a configured state path. Minor oddity: the install metadata claims the package 'creates binaries: node, tsx' — installing an npm package normally should not create a system 'node' binary. This appears to be a metadata/packaging description issue rather than functional mismatch, but it's worth noting.

Instruction Scope

SKILL.md and run.js/src/index.mjs show the skill performs deterministic local policy checks, aggregates votes (or accepts external votes), and writes artifacts to the configured consensus state path. The runtime does not reference unrelated system files or secrets; it only uses the consensus state path resolution and calls into consensus-guard-core wrappers for board reads/writes.

Install Mechanism

The install is an npm package (consensus-support-reply-guard) with dependencies declared in package.json and package-lock.json; packages are resolved from the npm registry. There are no ad-hoc downloads from unknown URLs or archive extraction steps in the spec. The package-lock shows normal npm/optional deps (esbuild variants, etc.).

Credentials

Declared required environment variables (CONSENSUS_STATE_FILE, CONSENSUS_STATE_ROOT) are proportional to the stated behavior (filesystem-backed board/state artifacts). No API keys, tokens, or unrelated credentials are requested. The code does not read other environment variables beyond state path resolution.

Persistence & Privilege

Skill does not request always:true and is user-invocable only. It writes to its configured consensus state path (expected for audit artifacts) and does not modify other skills or system-wide settings. Autonomous invocation is allowed by default but is not combined with any broad credential access.

Assessment

This package appears coherent for local support-reply governance, but before installing: 1) Inspect the consensus-guard-core package (dependency) to confirm its board read/write behavior and where it stores state; 2) Verify exactly how resolveStatePath uses CONSENSUS_STATE_FILE / CONSENSUS_STATE_ROOT to ensure artifacts are written to an intended directory (not a sensitive system path); 3) Treat the install metadata oddity ('creates binaries: node, tsx') as a packaging comment—do not allow any installer to overwrite your system node binary; 4) Run npm audit / review the dependency tree and, if possible, install and run in an isolated environment (container) first. If you rely on this in production, pin dependency versions and review the guard-core package source and release provenance.

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<OutputJson | ErrorJson>

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.