vict00r99/rune-stone/rune-refiner

How to Use

When given a RUNE spec that is structurally valid but may be incomplete or weak, analyze it and suggest improvements with ready-to-use content.

Input: a .rune YAML file or Markdown spec section. Output: a list of actionable suggestions with proposed content.

Analysis Areas

1. Test Coverage Gaps

Check if the TESTS section adequately covers the BEHAVIOR rules.

Look for:

• BEHAVIOR rules with only 1 test (should have 2+)
• Missing boundary tests for numeric ranges
• Missing empty/null input tests
• Missing tests for the OTHERWISE clause
• Happy path tests that only cover one scenario

Example suggestion:

**Gap:** BEHAVIOR rule "WHEN percentage > 100 THEN raise error" has only 1 test with value 101.
**Suggestion:** Add a test with a more extreme value:
  -`"calculate_discount(100.0, 150) raises ValueError"`

2. Edge Case Discovery

Identify edge cases the spec author may have missed.

Common edge cases by input type (adapt null/empty representations to the target language):

Example suggestion:

**Gap:** No edge case for whitespace-only input.
**Suggestion:** Add to EDGE_CASES:
  -`"whitespace-only email ('   '): returns (False, 'Email cannot be empty')"`
And add to TESTS:
  -`"validate_email('   ')[0] == False"`

3. BEHAVIOR Ambiguity

Identify behavior rules that are vague or open to multiple interpretations.

Red flags:

• Rules without specific error messages: THEN raise error
• Rules with vague conditions: WHEN input is invalid
• Rules that use "etc." or "and so on"
• Missing OTHERWISE clause
• Conditions that could overlap (multiple rules match the same input)

Example suggestion:

**Ambiguity:** "WHEN input is invalid THEN raise error" — what makes input invalid? What error?
**Suggestion:** Replace with specific rules:
  -`WHEN input is empty THEN raise error "Input cannot be empty"`
  -`WHEN input contains non-ASCII characters THEN raise error "Input must be ASCII"`

4. CONSTRAINTS Completeness

Check if CONSTRAINTS fully describe the valid input space.

Look for:

• Parameters without any constraint
• Constraints that are vague ("must be valid")
• Missing range information for numeric parameters
• Missing format information for string parameters
• Missing size limits for collections

Example suggestion:

**Gap:** Parameter `timeout` has no constraint.
**Suggestion:** Add to CONSTRAINTS:
  -`"timeout: integer between 1 and 300 (seconds)"`

5. INTENT Clarity

Check if INTENT clearly communicates purpose.

Issues to flag:

• Implementation details (mentioning regex, algorithms, libraries)
• Too vague ("processes data")
• Missing return value description
• More than 3 sentences

6. Spec Consistency

Check internal consistency across sections.

Look for:

• EDGE_CASES that aren't reflected in BEHAVIOR
• CONSTRAINTS that imply behavior not in BEHAVIOR
• EXAMPLES that show behavior not in BEHAVIOR
• COMPLEXITY that doesn't match the apparent algorithm

Output Format

## RUNE Refinement Report: `<function_name>`
 
### Test Coverage
1.**[ADD TEST]** BEHAVIOR rule "WHEN percentage > 100..." has 1 test. Add:
   -`"calculate_discount(100.0, 200) raises ValueError"`
 
2.**[ADD TEST]** OTHERWISE clause has no dedicated test. Add:
   -`"calculate_discount(100.0, 20) == 80.0"` (if not already present)
 
### Edge Cases
3.**[ADD EDGE_CASE]** No test for zero price:
   -Edge case: `"price = 0.0: returns 0.0 regardless of percentage"`
   -Test: `"calculate_discount(0.0, 50) == 0.0"`
 
4.**[ADD EDGE_CASE]** No test for float precision:
   -Edge case: `"rounding: 10.0 * 33% = 6.70, not 6.7"`
   -Test: `"calculate_discount(10.0, 33) == 6.70"`
 
### Ambiguity
5.**[CLARIFY]** BEHAVIOR rule "WHEN coupon has expired" — expired means `expires_at < current_date` or `expires_at <= current_date`? Add to EDGE_CASES:
   -`"expires today: still valid (expires_at == current_date)"`
 
### Constraints
6.**[ADD CONSTRAINT]** Parameter `date` has no format constraint. Add:
   -`"date: ISO 8601 string (YYYY-MM-DD)"`
 
### Summary
-**Suggestions:** 6 total (2 tests, 2 edge cases, 1 clarification, 1 constraint)
-**Estimated strength improvement:** The spec goes from covering ~70% of realistic inputs to ~95%

Rules

• Only suggest improvements, never modify the spec directly
• Every suggestion must include ready-to-paste content (YAML or Markdown)
• Prioritize suggestions that prevent real bugs over stylistic improvements
• Do not suggest changes that contradict existing BEHAVIOR rules
• If the spec is already strong, say so — don't invent unnecessary suggestions
• Focus on gaps that would cause different AI tools to generate different behavior