---
name: rumil-clean
description: Guided cleanup of research on a rumil question. Two modes — (a) pipeline mode wraps rumil's existing grounding/feedback clean pipelines given an evaluate call id; (b) interactive mode (default) walks a punch list conversationally, proposes each mutation, talks it through with the user, and applies accreting-only moves via the chat envelope after explicit consent. Use when rumil-review has produced a punch list and the user wants to act on it safely.
argument-hint: "<question_id> | --pipeline grounding|feedback <eval_call_id>"
---

# rumil-clean

Turns a review into applied fixes, safely. There's a fast lane and a
careful lane.

## Two modes

### Mode A — pipeline (rumil-internal)

When you already have a completed `evaluate` call on a question and
want rumil's own clean pipelines to run against its evaluation text,
this mode wraps them:

```bash
PYTHONPATH=.claude/lib uv run python -m rumil_skills.run_clean_pipeline \
    grounding <eval_call_id>

PYTHONPATH=.claude/lib uv run python -m rumil_skills.run_clean_pipeline \
    feedback <eval_call_id>
```

`grounding` runs `clean.grounding.run_grounding_feedback` — creates
source pages and grounds claims in real evidence.

`feedback` runs `clean.feedback.run_feedback_update` — applies proposed
changes from a feedback-style evaluation (new claims, new investigations,
link fixes).

Both are rumil-mediated: the actual mutations are chosen by a
rumil-internal LLM pipeline, not by you. You're just the trigger.
The run is tagged `origin=claude-code skill=rumil-clean pipeline=...`
and gets its own trace URL. Use this when you trust the rumil clean
pipeline to do the right thing and just want it to run.

**Prereq:** the user must have already run `/rumil-dispatch evaluate
<question_id>` to produce an EVALUATE call with evaluation text in its
`review_json`.

### Mode B — interactive (cc-mediated, accreting-only)

This is the conversational lane. The user typically lands here after
running `/rumil-review <question_id>` and getting back a punch list.
Your job is to walk the punch list one item at a time, proposing each
mutation, talking it through, and applying it after explicit user
consent. Strict rules:

1. **Accreting-only.** Every applied move goes through
   `apply_move.py --accreting-only`. The allowlist is: CREATE_* moves,
   non-destructive LINK_* moves, FLAG_FUNNINESS, REPORT_DUPLICATE,
   PROPOSE_CONCEPT, LOAD_PAGE. **Never** propose or apply REMOVE_LINK,
   UPDATE_EPISTEMIC, CHANGE_LINK_ROLE, or PROMOTE_CONCEPT from this
   skill — they modify or migrate existing state. If a punch-list item
   requires one of those, say so and suggest the user use the
   destructive tool manually or run the rumil-mediated clean pipeline
   instead.

2. **Talk through, then act.** Never apply a move without stating what
   you're about to do and giving the user a chance to object. Format:
   > "Proposing: `FLAG_FUNNINESS` on `be6d1a1d` (the
   > AI-governance-determines-space-allocation claim) — the headline
   > frames it as a claim but the body reads as a meta-reframe. OK to
   > apply?"

3. **Dry-run first for anything non-trivial.** For moves with complex
   payloads (links with reasoning, claims with long content), run
   `apply_move.py --dry-run` first so you can show the user what the
   validated payload looks like before committing.

4. **One move per turn.** Don't batch five mutations in a single
   response. Each move should be its own little propose-apply cycle
   so the user can stop or redirect anytime.

5. **Always gloss IDs.** When you cite a page or call, include a
   3-8 word summary in parens: `be6d1a1d (the claim about power-driven
   allocation)`. Never drop bare hex.

## Invocation

There's no single `!` block here because the skill dispatches based on
args. Parse `$ARGUMENTS` yourself:

- If the first arg is `--pipeline grounding|feedback` followed by an
  eval call id → run Mode A via `run_clean_pipeline`.
- If the first arg is a question ID → run Mode B: first load the
  question context via `gather_review_context`, then walk whatever
  punch list is already in the conversation (or ask the user for one).

If no punch list exists yet, suggest the user run `/rumil-review
<qid>` first, unless they explicitly want you to produce one here.

## What to show the user after each applied move

Just the one-line skill output:
```
⚙ cc-mediated move: <type>
• created page <short_id>
<one-line headline of result.message>
```

Plus (once per session) the envelope trace URL, so they can open the
rumil frontend to see the whole envelope Call and the moves flowing
into it.

## Escape hatches

- If the user changes their mind mid-session, stop applying and
  summarize what's been done + what's still pending from the punch
  list.
- If a proposed mutation would require destructive capability (edit
  an existing claim, remove a link, change a link role), say so and
  skip it — do not escalate to non-accreting moves. The user can
  handle those manually.
- If the user wants to switch to Mode A, just exit the conversational
  loop and fire `run_clean_pipeline` directly.