Skill v1.0.1

currentAutomated scan100/100

vict00r99/rune-stone/rune-validator

2 files

──Details

PublishedOctober 24, 2026 at 08:33 AM

Content Hashsha256:8f2908b7374d8f96...

Git SHA3777bfab1743

Bump Typepatch

Compare with v1.0.0

──Files

Files (1 file, 3.7 KB)

SKILL.md3.7 KBactive

SKILL.md · 103 lines · 3.7 KB

version: "1.0.1" name: rune-validator description: Validate RUNE specifications against pattern rules. Use when given a .rune file or Markdown spec section that needs checking for completeness, well-formedness, and internal consistency. license: MIT

How to Use

When asked to validate a RUNE spec, run every check below and return a structured report.

Input: a .rune YAML file or a Markdown section following the RUNE pattern.

Validation Checklist

1. Structure Checks

Run these checks first. If any fail, the spec is invalid.

#	Rule	Pass condition
S1	Required fields present	SIGNATURE, INTENT, BEHAVIOR, and TESTS all exist
S2	YAML meta header (YAML only)	`meta.name` and `meta.language` are present
S3	RUNE header matches meta.name (YAML only)	`RUNE:` value equals `meta.name`
S4	Markdown formatting (Markdown only)	Field names are bold (`SIGNATURE:`), code in backticks
S5	Valid YAML syntax (YAML only)	File parses without YAML errors

2. Content Checks

#	Rule	Pass condition
C1	SIGNATURE uses real language syntax	Not pseudocode. Uses the target language's actual function declaration syntax
C2	INTENT is 1-3 sentences	No more than 3 sentences. No implementation details (no algorithms, regex, library names)
C3	BEHAVIOR uses WHEN/THEN format	Every rule is a WHEN/THEN clause, with an optional OTHERWISE as the last rule
C4	BEHAVIOR rules are ordered correctly	Validations first, business logic second, default (OTHERWISE) last
C5	TESTS has at least 3 cases	Minimum: 1 happy path, 1 boundary, 1 error case
C6	TESTS use correct format	Each test is `function(input) == expected` or `function(input) raises ErrorType`

3. Consistency Checks

#	Rule	Pass condition
X1	Every BEHAVIOR rule has a test	Each WHEN/THEN clause maps to at least one test case
X2	Every EDGE_CASE has a test	If EDGE_CASES is present, each entry maps to a test
X3	CONSTRAINTS have BEHAVIOR rules	Each constraint that requires runtime validation has a corresponding WHEN/THEN rule
X4	Error messages match	Error messages in BEHAVIOR match the messages expected in TESTS
X5	SIGNATURE matches TESTS	Function name and parameter count in TESTS match SIGNATURE

Output Format

Return the report in this format:

markdown

## RUNE Validation Report: `<function_name>`
 
### Structure
-[PASS] S1: Required fields present
-[PASS] S2: YAML meta header valid
-[FAIL] S3: RUNE header mismatch — RUNE says "validate_email" but meta.name is "email_validator"
 
### Content
-[PASS] C1: SIGNATURE uses real language syntax
-[WARN] C2: INTENT has 4 sentences (max 3 recommended)
-[PASS] C3: BEHAVIOR uses WHEN/THEN format
...
 
### Consistency
-[FAIL] X1: BEHAVIOR rule "WHEN code is empty THEN ..." has no corresponding test
-[PASS] X2: All EDGE_CASES have tests
...
 
### Summary
-**Status:** FAIL (2 errors, 1 warning)
-**Errors:** S3, X1
-**Warnings:** C2
-**Suggestions:**
  -Rename RUNE header to match meta.name
  -Add test: `validate_email('') == (False, "Email cannot be empty")`
  -Consider shortening INTENT to 3 sentences

Severity Levels

FAIL — Spec violates a required rule. Must be fixed before implementation.
WARN — Spec is technically valid but has a quality issue. Should be fixed.
PASS — Rule satisfied.

Rules

Always run ALL checks, even if early checks fail
Report every issue found, not just the first one
For each FAIL or WARN, include a specific suggestion on how to fix it
If the spec is valid (all PASS), say so clearly
Do not modify the spec — only report findings

← v1.0.0 All versions