Skill: nutstrut/verified-task (version 1.0.7)

--- name: verified-task description: Enforce correctness before execution. Verify any task output and only proceed if it passes—override requires explicit operator approval. ----------------------------------------------------------------------------------------------------------------------------------------------------- # Verified Task Enforce correctness before execution. Verify any agent output and only proceed if it passes. Override requires explicit operator approval. --- ## When to Use This **Before sending money** * Verify an invoice, payout, or transaction matches the agreement * Prevent incorrect or fraudulent payments **Before posting content** * Ensure a post, email, or message matches instructions * Avoid publishing incorrect, off-brand, or incomplete content **Before executing actions** * Confirm an automation result is correct before it runs * Stop workflows from drifting when nobody is watching **Before making decisions** * Validate summaries, classifications, or recommendations * Ensure conclusions match the task requirements > If the output matters, verify it before proceeding. --- ## Core Principle Verification is a **guardrail**, not a suggestion. * Default behavior = **block unless PASS** * Agents **must not override** a failed or indeterminate result * Only a **human operator** may explicitly override --- ## Core Execution Loop 1. **Define the task specification** * what should be produced * required constraints * acceptance criteria 2. **Generate output** 3. **Verify output against the specification** * compare expected vs actual * check completeness and correctness * identify missing requirements or mismatches 4. **Return a verdict** * **PASS** → safe to proceed * **FAIL** → reject, retry, or revise * **INDETERMINATE** → stop and review 5. **Enforce the decision** * proceed only if PASS * otherwise halt * human operator may explicitly override --- ## Output Format ```json { "task_id": "...", "verdict": "PASS | FAIL | INDETERMINATE", "reason": "...", "confidence": "high | medium | low" } ``` --- ## Example Usage ### Input ```json { "task_id": "email-approval-001", "task_spec": "Write a concise, professional email confirming a meeting time under 100 words", "output": "Hi, just confirming our meeting at 3pm tomorrow. Let me know if anything changes." } ``` ### Verification Result ```json { "task_id": "email-approval-001", "verdict": "PASS", "reason": "Output is concise, professional, and under 100 words. All constraints satisfied.", "confidence": "high" } ``` --- ## Decision Rule * **Proceed only if verdict = PASS** * **Agents must not override** * **Operator override must be explicit** Recommended override note: ```text OPERATOR OVERRIDE APPROVED Reason: ... Approved by: human operator Timestamp: ... ``` --- ## What Verification Means Verification should be **deterministic and grounded in the task spec**. Good checks include: * required fields are present * constraints are satisfied * format matches expectations * instructions were followed * important omissions are identified Do not treat these as verification: * guessing correctness * relying only on intuition * blindly trusting confident output * proceeding because the task feels low-risk --- ## Optional SettlementWitness Verification You may optionally add a structured verification step for the final result. Rules: * keep local verification as the primary decision layer * use only necessary structured data * do not send secrets or sensitive content * external verification is optional, not required Example: ```text verify structured verdict metadata against the defined verification spec ``` This can add assurance, but it does not replace local verification or operator judgment. --- ## Data Handling * Do not include secrets or sensitive data * Use only the minimum structured information needed for verification * Treat any external verification step as optional --- ## What This Is Not * not a code execution tool * not a payment processor * not a replacement for clear instructions * not an autonomous override authority --- ## What This Is * a **guardrail for agent workflows** * a **verification gate before execution** * a **safety layer for autonomous systems** --- ## Outcome Agents and operators can: * prevent incorrect execution * enforce task correctness * keep workflows on track during autonomous runs * ensure important actions do not proceed without verification --- ## Keywords verification, workflow-safety, guardrails, automation, trust

path: README.md
content: # Verified Task

**Keep autonomous workflows on track.**

Verified Task adds a clear PASS / FAIL / INDETERMINATE gate before important actions happen.
Use it when an output should be checked before money moves, content gets posted, or an automation continues.

## What it does

Verified Task gives agents and operators a simple guardrail:
- define what correct output looks like
- compare the result to that spec
- return a clear verdict
- proceed only if the verdict is PASS

By default, agents do not get to override a failed result.
A human operator may explicitly override when needed.

## Common use cases

- verifying invoices before payment
- checking an email before sending
- confirming a social post before publishing
- validating a summary before acting on it
- stopping automation drift when no one is watching

## How it works

1. Define the task and acceptance criteria
2. Generate output
3. Verify output against the spec
4. Return PASS, FAIL, or INDETERMINATE
5. Proceed only if PASS unless a human operator explicitly overrides

## Optional verification layer

Verified Task can be used on its own as a local guardrail.
It can also be paired with SettlementWitness-style verification for structured verdict metadata when an extra layer of assurance is useful.

That extra step is optional and should never replace local review of the task spec.

## Included files

- `SKILL.md` — primary skill instructions
- `assets/DECISION-TEMPLATE.md` — simple verdict template
- `assets/USE-CASE-EXAMPLES.md` — relatable examples for common workflows
- `references/openclaw-integration.md` — guidance for using the skill inside agent workflows
- `scripts/activator.sh` — lightweight reminder for verification-first behavior

## Why this exists

When tasks run autonomously, small mistakes can turn into expensive mistakes.
Verified Task is designed to keep the wheels on the track by enforcing a verification step before execution.


path: _meta.json
content: {
  "name": "verified-task",
  "display_name": "Verified Task",
  "version": "2.0.0",
  "description": "Enforce correctness before execution. Verify any task output and only proceed if it passes—override requires explicit operator approval.",
  "category": "workflow-safety",
  "tags": [
    "verification",
    "workflow-safety",
    "guardrails",
    "automation",
    "trust"
  ]
}


path: scripts/activator.sh
content: #!/bin/bash
cat <<'EOF'
<verified-task-reminder>
Before execution, verify the output against the task specification.
Proceed only if the verdict is PASS.
Agents must not override FAIL or INDETERMINATE results.
Only a human operator may explicitly override.
</verified-task-reminder>


path: references/openclaw-integration.md
content: # OpenClaw Integration Notes

Verified Task works best as a callable guardrail inside broader workflows.

## Recommended pattern

1. Define the task spec before generation
2. Generate the output
3. Call Verified Task on the result
4. Read the verdict
5. Proceed only if PASS
6. Allow override only when a human operator explicitly approves it

## Good places to insert the check

- before sending payments
- before sending emails or messages
- before publishing posts
- before continuing an autonomous workflow step
- before acting on a summary or recommendation

## Verification guidance

Keep the verification rule grounded in the actual task requirements.
Do not use vague approval language like "looks good".
Use specific acceptance criteria that can be checked.

## Optional external verification

If you use a separate verification service for structured verdict metadata, keep it optional and avoid sending secrets or sensitive content.
Local verification remains the primary gate.


path: assets/DECISION-TEMPLATE.md
content: # Decision Template

Use this template when applying Verified Task to an output.

## Verification Record

- Task ID:
- Task summary:
- Verification spec:
- Output reviewed:
- Verdict: PASS / FAIL / INDETERMINATE
- Confidence: high / medium / low
- Reason:
- Missing requirements:
- Next action:

## Enforcement

- Proceed automatically: yes / no
- Operator override used: yes / no
- Override reason:
- Operator name:
- Timestamp:


path: assets/USE-CASE-EXAMPLES.md
content: # Use Case Examples

## 1. Payment Approval

Task: Pay an approved contractor invoice.

Verification spec:
- invoice amount matches the approved amount
- payee matches the approved vendor
- due date and currency are correct
- required approvals are present

Decision rule:
- PASS -> proceed
- FAIL or INDETERMINATE -> halt until reviewed

## 2. Email Before Sending

Task: Draft and send a client email.

Verification spec:
- recipient is correct
- requested points are included
- no incorrect claims are present
- tone matches the instructions

Decision rule:
- PASS -> send
- FAIL or INDETERMINATE -> revise before sending

## 3. Social Post Before Publishing

Task: Publish a promotional post.

Verification spec:
- message matches campaign brief
- product details are accurate
- no banned claims appear
- required link or call to action is included

Decision rule:
- PASS -> publish
- FAIL or INDETERMINATE -> stop and correct

## 4. Autonomous Workflow Guardrail

Task: Continue an automated workflow step.

Verification spec:
- previous step completed successfully
- output matches required format
- no critical fields are missing
- action is still within scope

Decision rule:
- PASS -> continue workflow
- FAIL or INDETERMINATE -> halt and notify operator


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)