realize

Featured

This skill should be used when the user asks to "run the eval", "test whether the protocol actually works at runtime", "check type realization", "measure protocol fulfillment", "run the type-realization suite", "does the gate actually stop", or wants runtime evidence that a protocol's formal transition contract is realized rather than an assessment of downstream artifact quality. Invoke explicitly with /realize and a skill argument.

AI & Automation 163 stars 15 forks Updated today MIT

Install

View on GitHub

Quality Score: 87/100

Stars 20%
74
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Type Realization Measure whether one named protocol skill's declared contract is realized during an actual run. The first argument is required; `/realize inquire` selects only the registered `inquire` cases and graders. An unknown or omitted target fails before setup. ## Purpose A protocol's formal blocks are runtime-normative: TYPES, PHASE TRANSITIONS, TOOL GROUNDING and the Rules type the prose and carry the operational contract. Static checks establish that a `SKILL.md` contains those blocks and enforce a bounded set of structural invariants. Nothing establishes that a run follows their transitions. This skill supplies evidence for that gap. It drives Claude Code or Codex across a matrix of models and treatments, captures the JSONL trace, grades the deterministically observable subset, and names the transcript judgments still owed. A complete automatic cell can establish that collection occurred, the declared branch reached `Stop`, or the zero-uncertainty branch reached `Proceed`; semantic ordering and rendered type coverage remain manual until their specified judges are built. ## Judgment boundary The object of judgment is the formal transition trace: ```text X → context sufficiency → evidence collection as needed → residual deficit → formal branch → Stop | Proceed ``` Every score attaches to a node or edge in that trace. Once the selected branch is observable, judgment ends. A plan, implementation, analysis, or other downstream artifact is evidence that `Proc...

Details

Author
jongwony
Repository
jongwony/epistemic-protocols
Created
9 months ago
Last Updated
today
Language
JavaScript
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

skillify

Codify a repeated behavior into a new qcobrain skill — but ONLY if it traces to a real, un-invalidated event (the provenance guard). Verifies the pattern actually happened ≥3 times against logs / decisions / sources, decides thinking vs runnable, scaffolds the SKILL.md from references/kernel.md (and registers a runnable in skills/INDEX.md), and records the justifying event. Trigger on "skillify this", "make this a skill", or spotting a task done 3+ times.

4 Updated 1 months ago
Quarktex
Code & Development Listed

verify-behavior

Owns a cheapest-first three-tier verification ladder — Tier 1 syntactic (grep / ast-grep / read), Tier 2 semantic-no-execution (typecheck / build / lint), Tier 3 execution (run the covering test, or a minimal synthesized repro) — and reports the result as an evidence receipt (confirms / contradicts / ambiguous / null). It never scores; `confidence(code)` owns the number. Two consumer shapes: claim-verification (read-only, feeds `confidence(code)`) and change-verification (post-apply green/red gate). Called by `verification-receipt.md` (pr-reviewer Tier 2/3), `bug-fix-verifier`, `feature-pr-verifier`, and the `aw-executor` Phase 4 checks loop. Use when a finding or a change needs executed proof, not just a plausible-sounding claim. Triggers on "verify this claim", "does this actually happen at runtime", "prove this behavior", "run this to confirm", "/verify-behavior".

13 Updated today
mthines
Code & Development Listed

verification-loop

A comprehensive verification system. Selects and runs proportional verification tracks for UI, API/service, CLI/TUI, library/SDK, documents/configuration, and real user flows, then ends every run with a fixed verdict — PASS / PASS_WITH_NITS / FAIL — plus severity-labeled findings (CRITICAL/HIGH/MEDIUM/LOW) and the evidence each one rests on. Use after implementation, before a PR or handoff, after a refactor, or to verify a claimed fix. Do NOT use a green build, a passing type check, or file existence as proof of user-visible completion, and do NOT let the instance that wrote the change issue its own verdict.

3 Updated 4 days ago
uzysjung