/rulph

name: rulph
description: |
  Iterative rubric-based evaluation and self-improvement loop. Builds a scoring rubric interactively,
  evaluates an artifact with multiple models in parallel (Codex, Gemini, Claude), then autonomously
  improves the artifact one criterion at a time until a score threshold is met or circuit breaker fires.
  "/rulph", "rubric evaluate", "rubric score", "multi-model evaluate",
  "score and improve", "evaluate and iterate", "grade this",
  "루브릭 루프", "채점 루프", "자율 개선", "개선 루프", "루브릭 평가"
allowed-tools:
  - Read
  - Grep
  - Glob
  - Bash
  - Write
  - AskUserQuestion
  - Agent
validate_prompt: |
  Must contain all 4 Phases (Rubric Building, Evaluation, Improvement Loop, Completion).
  Must include 3-step rubric building interaction with per-criterion floor setting.
  Must include Agent-based parallel multi-model scoring with AVAILABLE/SKIPPED/DEGRADED states.
  Must include pass check with both threshold AND floor (AND-gate).
  Must include circuit breaker logic.
  Must include state file write for Stop hook integration.

rulph

Iterative self-improvement skill driven by a user-defined rubric. Builds a scoring rubric interactively, evaluates an artifact with multiple models in parallel, then loops autonomously — improving one criterion at a time — until the score meets the threshold or the circuit breaker fires. No user interaction after Phase 1.

---

Phase 1: Rubric Building

Build an evaluation rubric through a 3-step interactive process before any scoring begins.

**User interaction**: Use the `AskUserQuestion` tool for all user-facing questions in this skill. This ensures the UI renders properly and waits for real user input.

Step 1 — Criteria Collection

Use `AskUserQuestion` to ask what they are evaluating and what criteria matter. Suggest common categories (code quality, writing quality, system design) but let them describe freely.

After the user responds, parse:

• **Target**: the artifact or output being evaluated (file path, text block, or description)
• **Criteria**: the named dimensions to score (extract from free text or selection)

Require a minimum of 2 criteria. If fewer than 2 are given, prompt again: > "Please provide at least 2 criteria so we can triangulate quality. What else matters?"

**Rubric Validation** — before proceeding, check each criterion:

• Warn on criteria that are not LLM-evaluable (e.g., "is it beautiful", "feels right", "gut check")

> "Warning: '[criterion]' is hard to score objectively. Consider rewording to something measurable, e.g., 'visual hierarchy is clear and consistent'."

• Block on purely subjective criteria only if the user cannot clarify after one prompt.

Step 2 — Rubric Draft Presentation

Generate a rubric draft based on the collected criteria. Assign equal weights by default.

**Checklist Decomposition (default)**: Break each criterion into 5–10 yes/no sub-items. Score is computed as `(checked / total) × 100`. This eliminates evaluator interpretation variance.

Present the draft as a table with sub-items:

## Draft Rubric

| # | Criterion       | Weight | Sub-items (yes/no each)                                    |
|---|-----------------|--------|------------------------------------------------------------|
| 1 | [criterion]     | 25%    | □ [sub-item-1] · □ [sub-item-2] · □ [sub-item-3]          |
|   |                 |        | □ [sub-item-4] · □ [sub-item-5]                            |
|   |                 |        | score = (checked / 5) × 100                                |
| 2 | [criterion]     | 25%    | □ [sub-item-1] · □ [sub-item-2] · □ [sub-item-3]          |
|   |                 |        | □ [sub-item-4] · □ [sub-item-5] · □ [sub-item-6]          |
|   |                 |        | score = (checked / 6) × 100                                |

**Sub-item design rules**:

• Each sub-item must be **binary observable** — answerable with yes or no by reading the artifact
• Avoid subjective sub-items ("code is clean") — reword to observable ("all functions have explicit return types")
• Order sub-items from basic (easy to pass) to advanced (hard to pass)
• Unchecked sub-items automatically become improvement targets in Phase 3

**Qualitative fallback**: If a criterion genuinely cannot be decomposed into sub-items (e.g., "writing tone"), use level-based anchors instead:

| # | Criterion       | Weight | Scoring Guidance (0–100)                                   |
|---|-----------------|--------|------------------------------------------------------------|
| N | [criterion]     | 25%    | 0=absent · 25=minimal · 50=partial · 75=good · 100=full   |

Level-based anchors must have **5 levels** (0/25/50/75/100) with one concrete observable indicator per level. 3-level anchors (0/50/80) are too coarse.

Each criterion gets:

• A 0–100 scoring range
• Either checklist sub-items (preferred) or 5-level anchors with observable indicators

Then use `AskUserQuestion` to confirm or modify (accept, adjust weights, edit criteria, or start over). Loop until the user accepts.

**Weight validation**: After any adjustment, verify `sum(weights) == 100%` (±1% tolerance for rounding). If invalid, prompt: > "Weights must sum to 100%. Current sum: [X]%. Please redistribute." Re-present the rubric table until weights are valid.

Step 3 — Threshold & Floor Setting

Use `AskUserQuestion` to ask two things:

1. **Overall threshold** (0–100): what overall score the artifact should reach before stopping. Suggest 70/80/90 as options. Default is 70 if the user doesn't specify.

2. **Per-criterion floor** (0–100): the minimum score that EACH individual criterion must meet, regardless of overall score. Suggest 50/60 as options. Default is 60 if the user doesn't specify. Set to 0 to disable.

**Why floor matters**: Without a floor, strong criteria can mask weak ones (e.g., overall 80 passes threshold 70, but one criterion scores 50). The floor ensures every dimension meets a minimum bar.

Rubric