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