[FEATURE] Runtime-enforced verification gates for Skills

Resolved 💬 0 comments Opened Jun 12, 2026 by xueyu-jia Closed Jun 12, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Skills encode procedures in SKILL.md, but the Verification section is only prompt-level guidance — enforcement depends on the model choosing to follow it.
For high-stakes or deterministic tasks (code changes, deployments, data transforms, file generation), this is unreliable:

  • The agent may skip verification entirely.
  • The agent may run it but misread the result.
  • The agent may claim success without actually validating the outcome.

This is especially risky when the agent invokes a skill autonomously rather than the user invoking it explicitly. Today there's no way for a skill author to say "this skill is not done until this check actually passes" and have the runtime guarantee it.

Proposed Solution

Add an optional, declarative verification block to skill metadata. When the skill is active, the runtime runs the configured validator at a defined lifecycle point (MVP: before the final response) and gates the result on it — no model discretion involved.

verification:
  before_final:
    required: true
    command: "npm test"
    timeout_seconds: 120
    success_exit_codes: [0]
    on_failure: block_final

### Alternative Solutions

Prompt-level instructions(current state): writing "you must run tests before claiming success" in `SKILL.md`. Unreliable — the model can skip it, misread results, or claim success anyway. This is exactly the gap that motivates the proposal.


### Priority

Medium - Would be very helpful

### Feature Category

Other

### Use Case Example

Scenario: a `github-pr-workflow` skill that edits code and opens a PR.
1. I ask the agent to fix a bug and open a PR. The agent selects the skill autonomously — I don't invoke it explicitly.
2. The agent edits files and concludes it's done.
3. Before producing the final response, the runtime hits the skill's `before_final` gate and runs `npm test` under the existing sandbox/timeout policy.
4. Tests fail. The runtime feeds stdout/stderr back to the agent instead of letting it reply "done."
5. The agent reads the failure, fixes the code, and the gate re-runs automatically.
6. Tests pass → the agent opens the PR and reports verified success.
7. If tests still failed after the retry limit, the agent reports a *verified failure* with diagnostics, instead of falsely claiming the PR is ready.
Net effect: the "tests pass" guarantee no longer depends on the model remembering or interpreting correctly.

### Additional Context

**Similar features in other tools**
- CI required status checks (GitHub Actions / GitLab CI) blocking merge until checks pass — same idea, applied at skill-execution time.
- Pre-commit / git hooks enforcing checks before an action completes.
- LangGraph conditional edges / validation nodes — same intent, much heavier mechanism.

**Technical considerations / constraints**
- Must reuse the existing execution model: tool policy, sandbox, command allowlists, approvals, timeouts, env scoping, secret redaction, and audit logging. Verification must not become a backdoor for privileged execution.
- Fully opt-in: skills with no `verification` block behave exactly as today.
- Applies regardless of who triggered the skill (user slash command or autonomous agent selection).
- MVP scope is a single `before_final` gate; deterministic checks should be scripts/commands/tools, never another LLM prompt.

**Out of scope for MVP**
- Additional lifecycle gates (`before_skill`, `after_tool`, `after_skill`).
- JSON-schema validation of structured results, human-approval gates, rollback hooks, configurable retry counts, verification traces, and richer failure modes (`warn` / `retry` / `block_final` / `request_human`).

View original on GitHub ↗