quality-gate

name	quality-gate
description	Universal quality/eval gate for any AI or agent output before it is published, used, sent, automated, or turned into a decision. Use when the user asks to check quality, anti-slop, eval, output readiness, publication readiness, agent/product output safety, decision quality, or whether something should PASS/REVISE/BLOCK/ESCALATE.
version	1.0.0
author	web3blind / Hermes Agent
license	MIT

quality-gate

Universal output quality gate.

Use this skill to evaluate any output before it moves forward: a post, article, research summary, product/agent response, JSON/API result, code-delivery summary, trading/investment decision, cron result, or operational recommendation.

This skill is not a writer, trader, publisher, or executor. It is a quality contract: decide whether the output is good enough to ship/use, what blocks it, and the smallest fix needed.

Core model

Do not hardcode domains into the evaluation logic. Always evaluate through:

1. Core criteria.
2. Strictness level based on consequences.
3. Optional profile weights.
4. Lightweight domain blockers when needed.

Load references when doing a real gate:

• references/core-rubric.md — universal criteria.
• references/strictness.md — consequence-based gate levels.
• references/profile-format.md — profile/overlay model.
• references/failure-taxonomy.md — common anti-slop failures.
• references/output-format.md — response formats.

Workflow

1. Identify the artifact being evaluated and its intended use.
2. Choose strictness:
   • 0: note/draft/private thinking.
   • 1: normal response or internal summary.
   • 2: publish/use gate.
   • 3: high-stakes: money, security, privacy, production, legal/medical/financial risk.
3. Select profile if obvious, otherwise use generic:
   • examples: content, product-output, decision, research, code-delivery, cron-report.
   • Profiles change weights and blockers only; they do not replace core criteria.
4. Score core criteria from 0 to 1:
   • purpose_fit;
   • evidence_grounding;
   • specificity;
   • risk_reversibility;
   • format_usability;
   • audience_context_fit;
   • novelty_value.
5. Check domain blockers if relevant.
6. Return verdict:
   • PASS — good enough for intended use.
   • REVISE — fixable issues; provide minimum fix.
   • BLOCK — not safe/useful enough without missing facts, source, format, or scope change.
   • ESCALATE — requires the user/human approval or a higher-authority decision.
7. If output fails, name exact blocking issues and smallest next action.
8. If this is high-stakes, default to conservative judgment and explicit approval before action.

Verdict rules

• PASS requires no blockers and the score threshold for the strictness level.
• REVISE when issues are fixable without new user/source information.
• BLOCK when facts are missing, claims are ungrounded, format is invalid for downstream use, or risk is uncontrolled.
• ESCALATE when consequences are high, authorization is missing, scope is ambiguous, or the action changes money/access/security/public state.

Never let a polished but ungrounded output pass. Never let profit, engagement, or confidence compensate for missing risk controls in high-stakes decisions. Never publish/use an output just because it “sounds good”.

Integration with other skills

• For Russian content voice cleanup, use anti-ai-polish as a downstream/editorial sub-gate.
• For current-user-style content, use current-user-style and content-core as profile context.
• For trading workflows, use the current trading skill as the source of mandates/levels; quality-gate only judges the decision artifact.
• For product/API outputs, prefer deterministic validators where possible; LLM judgment is not enough.

Default output

For Telegram, avoid tables. Use bullets:

Verdict: PASS / REVISE / BLOCK / ESCALATE
Score: 0.xx
Strictness: 0/1/2/3
Profile: <name>

Blocking issues:
- ...

Scores:
- purpose_fit: 0.xx — reason
- evidence_grounding: 0.xx — reason
- specificity: 0.xx — reason
- risk_reversibility: 0.xx — reason
- format_usability: 0.xx — reason
- audience_context_fit: 0.xx — reason
- novelty_value: 0.xx — reason

Minimum fix:
- ...

If high-stakes:
- approval needed: yes/no
- stop condition / rollback / kill switch: ...

User-facing style

Be concrete and calm. Point to exact failures. Prefer the smallest useful fix. Do not over-formalize low-stakes drafts. Do not soften blockers for high-stakes outputs.