LilMGenius/paperthin

Converge an install on the full current paperthin catalog in one step: retire renamed skills, add every skill not yet installed, refresh the rest, behind one confirmation.

## Goal

Upgrade the chosen scope to the **full current catalog**, not just the originally installed subset. Show the reconciliation plan and name every new-to-user skill before confirmation; users who prefer a narrower install can decline.

## Deprecations

The rename SSOT, in release order. Append future renames here; resolve chains to their final current names. The `ssot-check` row is user-confirmed pre-v0.2.0 history, unverifiable in git after a force-push; do not invent its date or tag.

| Deprecated | Renamed to | Since |
| --- | --- | --- |
| `ssot-check` | `ssotchk` | pre-v0.2.0 history (force-pushed; user-confirmed) |
| `tasting` | `sip` | 0.6.0 |

Find where one truth lives, get approval for the consolidation plan, then collapse it into one canonical home.

## Goal

Enforce Single Source of Truth (SSOT): one fact = one home, and every other place that needs it references that home instead of copying it. References don't drift; copies do. This mutates artifacts, so it is deliberate and loss-averse.

`ssotize` starts as a read-only audit. It names the truth in scope, finds every copy, chooses the canonical home, and reports the exact consolidation plan. Only after the user approves that plan does it mutate artifacts.

Use this to **establish or repair** SSOT — messy, legacy, or freshly-scaffolded states. Once SSOT holds, don't overuse it: consolidation is a one-time repair, not ongoing upkeep. When a read-only checker and a mutating follow-up have become one inseparable workflow, fold the checker into the consolidator and keep the approval gate; splitting the reflex only makes the safer first half easier to skip.

## Workflow

1. Name the truth in scope — the specific fact, value, spec, decision, status, or definition being tracked, not the whole document.
2. Audit read-only first: enumerate every occurrence across the given artifacts and platforms.

Catch the human up at their eye level, from state, not from memory.

## Goal

`catchup` is the re-entry point for a lost human. Long agent cycles coin words, rename files, run
experiments, and make calls faster than the owner can follow. Before any next action makes sense,
the owner's mental model must be reloaded. `catchup` reads the live project state and returns a
briefing a person with zero retained context can act on. It runs before the next move gets decided:
catchup restores the map, so that decision starts from truth instead of a stale memory of it.

## Workflow

1. Read live state only: recent file mtimes, git log/diffs, plan and state docs, re0-memo notes,
   task boards. Never brief from conversation memory alone — memory is what drifted.

Find the next best action from state, not from vibes.

## Goal

`nba` is the manual re-entry point for a stalled cycle. It reads the current state and returns one action: the cheapest move that clears the binding constraint. It does not execute the action and it does not offer a menu, because a menu recreates the paralysis it exists to resolve.

## Workflow

1. Read the live cycle state: plan gates, re0-memo anti-patterns, priority notes, recent git/file changes, QA evidence, and the current workflow phase.
2. Locate the project in the cycle: FRAME, BUILD, DRIVE, RE0-MEMO, HATE, RE0-WORK, BUILD AGAIN, or SHIP.
3. Diagnose the blank-out cause: too many open threads, lost thread, unnamed blocker, closed-loop fatigue, avoidance of the hard step, or a phase that is already done.
4. Return one action: the cheapest move that clears the most. It may name the right skill for the human to fire, the external input needed, the first nail to test, or the phase transition that is already due.
5. Frame it as: where you are, next best action, why now, and done when.

Run the cycle so learning compounds and code accumulation does not masquerade as progress.

## Goal

`re0-loop` keeps a project moving through repeated turns:

```text
FRAME -> BUILD -> DRIVE -> RE0-MEMO -> HATE -> RE0-WORK -> BUILD AGAIN
```

The unit of progress is not hours, files, panels, or features. It is the count of quality-cleared templates, reusable platform modules, and anti-patterns eliminated in later cycles.

## Workflow

Turn a completed cycle into lessons the next cycle can actually use.

## Goal

`re0-memo` extracts durable learning from a work cycle without defending the artifact that produced it. A cycle can run, pass tests, and still be the wrong thing. The output is not a changelog or therapy note: it is a local, evidence-backed record of what worked, what misled the build, and what gate the next pass must clear.

Use `re0-memo` when the artifact is done, failed, disappointing, or ambiguous enough that the next agent needs the cycle's lessons more than its momentum.

## Workflow

1. Read the original objective, final artifact, QA evidence, user complaints, and any local planning notes.
2. Separate working assets from misleading progress: contracts, schemas, tests, services, vocabulary, and examples that earned reuse vs. UI, panels, scaffolds, or abstractions that only looked productive.
3. Generalize before recording: when feedback arrives as many specific complaints, cluster them upward into the shared pattern before writing anything down — many specifics against many items usually share one root gap. Record the root and its pattern family as the lesson; keep the specifics under it as evidence, not as lessons themselves.
4. Name each failure as an anti-pattern, not a mood.

Open `.re0/iteration/<version>-<workname>/` and write into it in the same motion, before a single line of `re0-loop`'s cycle runs.

## Goal

A cycle without a written thesis, gate list, and step plan drifts to whatever framing comes first — and a folder opened with nothing in it tells a resumed session nothing at all. `re0-plan` closes both gaps at once: the folder is never empty from the moment it's created, regardless of which weight the cycle turns out to be. It assumes the full paperthin package installed and names its sibling skills directly. It pairs with `re0-release`, which retires the folder, and `re0-memo`, which extends whatever this skill seeded instead of restarting fresh. It is not a portable planning method — the shape it writes is this repo's own convention.

## Workflow

1. Classify the cycle's weight: a fix or hardening pass with no real design surface is **lightweight**; a cycle with a direction genuinely worth arguing through is **full**.
2. Create `.re0/iteration/<version>-<workname>/` and, in the same step, write its first file — the weight decides which:
   - **lightweight** → `RETRO.local.md`: one paragraph naming the task and why it's lightweight. `re0-memo` extends this same file at the end; it never starts a fresh one. Stop here.
   - **full** → `DESIGN.local.md`: thesis, scope, and quality gates — the same content `re0-loop`'s FRAME turn expects, and enough on its own to survive a session break. When the change touches shippable surface, those gates always include an AGENTS.md/README reflection gate (see Rules). Confirm the read with `readchk`, size the tier with `modelchk`; reach for `macrothink` or another judgment skill only when the direction is genuinely contestable.
3. (full only) Write `WORKFLOW.local.md`: the numbered steps this specific cycle runs through `re0-loop`'s turn order — specific to this build, not a restatement of `re0-loop`'s generic stages.
4. (full only) Write `EVIDENCE.local.md`: the gates from `DESIGN.local.md`, listed as proof surface still to fill — the bar, not results.

Start over from what the previous cycle proved, not from what it happened to build.

## Goal

`re0-work` is a controlled restart. It keeps earned knowledge and refuses to copy forward accidental architecture. Starting from scratch is not amnesia: contracts, schemas, vocabulary, real-surface tests, quality gates, and negative corpus survive when they earned it. Scaffold, explanatory UI, debug panels, shallow generated content, and code whose only value was learning what not to do do not.

## Workflow

1. Read the current plan, any lessons or re0-memo notes, local domain notes, QA evidence, and any user complaint that triggered the restart.
2. Identify what to preserve: contracts, schemas that survived QA, quality gates, vocabulary, reusable services, real-surface tests, and negative corpus.
3. Identify what to discard: explanatory UI, debug panels, scaffold, shallow generated content, accidental abstractions, and code whose only value was learning what not to do.
4. Name the first quality gate before planning code.
5. Write a v0 skeleton plan with one complete vertical loop.
6. Build only the first loop until it clears the gate.

Read the data and propose the intent behind it, for the user to confirm.

## Goal

The result is a proposal the user only confirms, revises, or rejects — never a question. Asking makes the user compose a sentence they did not have ready; proposing lets them answer with a yes. If the turn ends with them writing that sentence anyway, the skill missed.

## Workflow

1. Read every piece of the handed-over data end to end before proposing anything.
2. State the intent you read, in one line grounded in what the data actually shows.
3. State briefly what you would do next on that intent.
4. Ask only to confirm — right, wrong, or adjust.

## Rules

Carve unsafe scope out of a task, then run the safe remainder in a fresh subagent that only ever sees the carved prompt, and report it with a visible descope ledger.

## Goal

Turn risk-adjacent work into an explicit scope decision, then execute the safe scope in a clean room. The carve happens here; the running happens in a fresh subagent that receives only the carved prompt, never the risky original or this session's reasoning. That split is the point: the executing mind never reads a risky ask, so it has nothing to hedge, dilute, or refuse, and the safe work goes at full strength. autobahn is not evasion: it does not slip a flagged ask past a guardrail, it removes the ask and runs a genuinely safe prompt instead.

## Workflow

1. **FRAME**: Read the task, inputs, and user-stated risk posture. If the user already authorized descoping, proceed. If not, produce a proposed carve, make its split explicit, and wait for approval before **RUN**: a bright-line item has no safe version, so it is non-negotiable; a gray-zone item's safe alternative trades away scope the user might want, so it is the real question. If every item is bright-line, proceed; the ledger carries the record. If the user disputes a bright-line call itself, don't let the pressured session re-litigate it: hand the item's abstract description, stripped of the negotiation and any persuasion, to a fresh context for re-evaluation, and record the appeal and its outcome in the ledger either way.
2. **CARVE**: Sweep the task and adjacent inputs for guardrail-adjacent items. For each, propose `verdict=descope`, class it bright-line or gray-zone, give one risk-free alternative, and name an archive destination per the negatives-as-corpus convention. A gray-zone item the user decides to keep stays in scope and enters the ledger as a kept-by-owner decision. Point to excluded techniques only as far as identification requires; never elaborate them.
3. **GUARD**: Distill the carve into a compact scope-guard block (absolute exclusions, allowed alternatives, and the context that authorizes what stays in scope) and fold it into the carved prompt so the run carries it verbatim. The block names each exclusion so the run cannot re-introduce it, never the original risky ask verbatim or its method. In a harness where the run shares a filesystem or a memory store with this session, the block also tells the run not to consult decision logs, notes, or transcript search over that shared state: a clean prompt does no good if the run can read the risky ask back out of something this session just wrote nearby. Instruct the run to build the safe scope at full strength, with no hedging, apology, or shrunken deliverable.
4. **RUN**: Spawn a fresh, context-clean subagent (a Task that starts with no prior context) and hand it **only** the carved prompt, never the risky original or your carve reasoning. It runs the safe scope at full strength and returns the deliverable; the executing agent never sees a risky ask, so the carve, not this session, is what lets it floor it. If risky material surfaces inside a subagent, it routes back here through **CARVE**, never improvised inline.
5. **VERIFY**: Run an adversarial pass over the returned deliverable and adjacent artifacts, checking all five failure directions: risky content elaborated, risky content silently dropped, safe work diluted or treated as excluded, stale risky material left standing nearby, and the carve itself missed or over-excluded something — re-sweep the original task from a context independent of this one and diff the result against the ledger before reporting. Cap that independent re-sweep at one pass (`N=1`), not open-ended fan-out.
6. **LEDGER**: Once the run has finished and the subagent's window is closed, report the deliverable with a descope ledger listing every carved item: its class, its verdict of descoped or kept-by-owner, the reason, the safe alternative, and the archive destination. Write the archive entry only now, not earlier — a record of the risky material sitting on disk while the run is still active undoes the isolation the carve bought. Treat exclusions as visible decisions, not gaps.

Cut a bloated artifact to its load-bearing minimum: same meaning, fewer words.

## Goal

An artifact that is correct and current can still rot a second way: it accretes. Each edit bolts a qualifier onto the nearest sentence, a rule gets restated wherever it might apply, an enumeration grows into a wall — until a reader must study what they should skim. `debloat` compresses that bloat to its load-bearing density: every claim that carries weight survives, every word that does not is cut. It is not a rewrite (`re0`), a dedup (`ssotize`), or a tell-remover (`dedash`, `detool`) — it is a density pass on prose that is otherwise fine.

## Workflow

1. Pin the artifact and read it end to end; note in one line what each section must convey — the load-bearing content that has to survive.
2. Find the bloat, not the content: padding that adds length but not meaning; a qualifier or parenthetical the sentence holds without; a fused sentence carrying three ideas; a wall of enumeration where a rule plus a short list would do; a point restated within reach of itself; litigation-history (why-we-decided-it) where the rule alone suffices.
3. Compress in place: cut the padding, split the fused sentence or drop its dead clause, collapse the wall, keep a repeated point once. Move nothing to another artifact and re-derive nothing.
4. Preserve every load-bearing claim — a rule, fact, constraint, or example that carries weight. If cutting a word would lose one, keep the word.
5. When the bloat is really duplication across artifacts, or the content has drifted stale, stop and name it: hand duplication to `ssotize` and drift to `re0`. `debloat` only tightens.
6. Re-read cold and cut again — the first pass always leaves some.

Remove em-dashes and the dashes standing in for them from the scope the user names, one occurrence at a time, while leaving hyphens, ranges, and deliberate marks alone.

## Goal

Replace each em-dash that should not remain with the mark or wording its clause actually needs. Target any dash doing an em-dash's job, whatever its exact character: U+2014 and its longer or repurposed look-alikes all read the same on the page. The user owns the scope: a passage, field, file, selection, or tree. Do not widen it without asking.

## Workflow

1. **FIND**: Take the exact scope from the user and locate every dash doing an em-dash's job in it, judged by the role it plays in the sentence, not its codepoint: any mark that sets off an aside, an appositive, an abrupt turn, or a missing conjunction. The em-dash (U+2014) is the common one; the horizontal bar (U+2015) and the two- and three-em dashes (U+2E3A, U+2E3B) read the same and count. The en-dash (U+2013) is the boundary case: it counts when it joins clauses where an em-dash would fit, but stays when it spans a range's endpoints, numeric or not (`1990–2020`, the `London–Paris` route). A dash doing a non-em job (a hyphen, a minus, a range) stays. Surface anything genuinely ambiguous as a judgment call rather than changing it blindly.
2. **REPLACE per role**: Choose per occurrence by grammatical role:
   - *Parenthetical aside*: commas or parentheses when the dashed material can be lifted out of the sentence.
   - *Appositive*: a colon or comma when the dashed material renames, defines, or expands the noun before it.
   - *Abrupt turn*: a full stop, semicolon, or comma when the dash marks a pivot, interruption, or restart.
   - *False-conjunction break*: rewrite the sentence when the dash stands in for a missing "and", "but", "because", "so", or another real connective.

Remove incidental tool coupling from artifacts that claim to outlive the stack that wrote them.

## Goal

A durable artifact should stay true and actionable when the agent, harness, operating system, vendor, model, or toolchain changes. `detool` finds stack-specific nouns in portable content and rewrites them to the underlying mechanism without deleting the action they enabled.

The point is portability, not vagueness. A reader should still know what to inspect, run, measure, compare, or verify after the rewrite.

## Workflow

1. Read the target artifact end to end.
2. **Role before edit**: classify the whole artifact, or each section if mixed, as durable/portable content, provenance/operational record, or a claim about a named tool.
3. Sweep durable content for incidental coupling: harness paths, vendor CLIs and flags, model or product brands used as mechanisms, tool-specific environment variables, quotas, UI steps, cache homes, session files, and version-pinned behavior stated as timeless truth.
4. **Mechanism not euphemism**: replace each durable-content hit with the neutral mechanism that preserves the action. If neutral wording would lose the action, keep the concrete detail as an example of the mechanism instead of pretending it generalizes.

Check what's asserted as real against reality — in both directions — before it ships.

## Goal

The author's "plausible / absurd / novel" is the least reliable line in any artifact. Human priors fail **both ways** — they exclude the real (desert frogs exist) and normalize the impossible (weightless crates). `factchk` scans claims presented as reality-grounded, verifies each against external sources in both directions, and fixes or flags. Its scope is a claim about *the world* — whether what's asserted as real is real — not the soundness of a validation or the survival of a whole plan.

## Workflow

1. Scan for **reality-grounded assertions** — anything leaning on "this is plausible / realistic / absurd / novel / impossible because X," including the claim you are *about to write*, not only those already on the page.
2. Verify each against **external sources** (web search, open references) in **both directions**: could the "absurd" be real? could the "obvious" or "novel" be false or long-established? If you cannot reach a source, **flag — never assert from intuition**.
3. **Fix or flag:** a mechanically-clear error (a wrong date, a misattributed source, a falsified number) → correct it with a cited source; a judgment call (a contested or interpretive claim) → surface it, don't silently rewrite.
4. Report each claim, its verdict, the source, and — for a failed claim — which direction it failed.

## Rules

Press a decision you just made until you can explain it, or the gap where you can't is named.

## Goal

The moment after a choice is when understanding is cheapest to fake: you can restate an option fluently without having earned the reasons behind it, and by the time that gap matters the decision is load-bearing elsewhere. The Feynman test catches it — if you can't explain a thing plainly, you don't yet understand it. So no one hands you the rationale; a fresh critic that never made the decision presses for what you can't actually explain, and a shallow answer draws a narrower question instead of a pass. The result is a decision you can now explain under real pressure, or an honest flag that you can't yet.

## Workflow

1. **Trigger**: fire right after a decision is made — typically just after options were laid out with no argument for any, and one was picked.
2. **Restate, don't justify**: state the decision neutrally. Do not supply the reasoning behind it, and do not let the user borrow reasoning that was never actually given.
3. **Isolate the critic**: hand the decision — not any reasoning — to a fresh, context-free sub-session that never watched the decision get made. Have it press for gaps: what a skeptical outsider would ask, what is assumed but unstated, what would have to be true for the choice to hold.
4. **Return one gap at a time**: give the user the sharpest unresolved gap and ask them to explain it in their own words. Never batch gaps into a checklist.
5. **Judge the explanation**: if the answer actually resolves the gap, close it and move on. If it restates the question, deflects, or leans on authority ("the agent suggested it") instead of reasoning, do not accept it.
6. **Narrow, don't repeat**: on a shallow answer, don't ask the same question again — narrow to the exact part that stayed vague and ask that. Keep narrowing each round; never widen back to a generic "are you sure?"

Refuse to be nice to the plan — return the one objection that could kill it and the cheapest shot that proves it matters.

## Goal

`hate` asks "what would someone who wants this to fail attack first?" (validity). It attacks the *whole* plan — not one fact or one line, but the load-bearing structure — and collapses the attack to a single root. The highest-value output is never a checklist — it's one objection plus the cheaper experiment hiding inside the elaborate plan.

## Workflow

1. Pin the **load-bearing assumption(s)** — what must hold for the whole thing to stand.
2. Attack on whatever axes apply — the general ones first: **a load-bearing fact** that may be false, **confabulation** (a post-hoc story treated as ground truth), **analogy-mistaken-for-isomorphism** (structure assumed to transfer across domains where it doesn't), **future-tense suture** (the argument leans on a result that doesn't exist yet), and the sharpest — **cites a principle but implements its opposite**; and for empirical / research plans, **leakage** (no external ground-truth enters the validation independently) and **statistical power / family-wise α** (a true hypothesis auto-failing from uncorrected tests; a near-zero-power condition that rubber-stamps regardless of truth).
3. Collapse the findings to the **single root** objection — the one whose failure makes the others moot.
4. Find the **first nail** — the cheapest falsification of the load-bearing assumption: the check (in time / cost / sample) that could kill it *before* the expensive program runs.
5. Return `{ root, first_nail }` — not a list.

Step back from the session's chosen path and ask several fresh reads what the current direction might be missing.

## Goal

`macrothink` checks the live decision or direction in hand, not the artifact that describes it. It is for moments when the session may have inherited a framing from examples, wording, prior turns, or a first plausible answer.

The product is a spread of independent reads. Divergence is the signal. Convergence is reassurance, never proof.

## Workflow

This skill is not model-invoked automatically. When a user explicitly invokes it, the invoked run may create the bounded fresh sub-sessions below; they are read-only inputs to this pass, not separate authority to change the plan.

1. Name the current direction: the decision the session is about to keep building on.
2. Strip the prompt to the underlying problem: goal, constraints, and known facts. Remove the session's own examples, suggested answer, preferred naming, and framing-specific wording.

Audit a validation for leakage: does outside ground-truth actually enter, or is everyone confirming a result no one independently produced?

## Goal

The name is the **Mandela Effect** — a whole population *confidently remembers* something that never independently happened; a leaky validation is the same shape. Walk the 8 patterns below. `mandela` checks one thing: whether a *validation* is independent, or whether the designer, model, and scorer are only confirming each other.

## Workflow

1. Identify the validation (eval / metric / experiment / holdout / "how we'll know"). Name its **components** — what plays model, scorer, designer, dataset.
2. Ask the **core question**: does external ground-truth enter *independently*?
3. Test the validation against all **8 patterns** below (some apply only to certain components — a human subject, a scorer); report only the ones that fire, each by name.
4. Give the independent-ground-truth fix for each hit.

## The 8 leakage patterns

Size the run before you spend it: how strong a model, and how hard it should think.

`modelchk` is read-only and advisory. From one assessment it sizes the two dials that set a model's per-run cognitive spend — capability tier and reasoning effort. It does not choose, route, switch, pin, spawn, set, or require any concrete model or level.

## Goal

From a single risk-and-complexity read, recommend two coordinates.

**Capability tier** — the cheapest sufficient class of mind:

- `fast` for local, mechanical, reversible work with cheap, complete verification.
- `standard` for ordinary repo-grounded reasoning, multi-step drafting, normal coding, and conventional documentation or skill work.
- `frontier` for architecture, high ambiguity, safety/security/privacy/data-loss risk, release-critical review, cross-domain scope, or work where one wrong assumption wastes a large run.

Refresh the target artifact as if it were the first clean version.

## Goal

The result must be lighter, more current, and more accurate than the input. It should not read like a changelog, cleanup note, or patch over an older draft.

## Workflow

1. Identify the target artifact from the user's request or the active context.
2. Read the target artifact end to end before editing.
3. Check nearby artifacts that must stay aligned with it.
4. Remove scaffolding residue, stale deltas, duplicated process noise, deprecated information, and over-specific history.
5. Fold durable lessons into the place they should have lived from the start.
6. Rewrite instead of appending when appending would preserve noise.

Rewrite a finished commit message so the log hands off on its own — in the author's own voice, not an imposed one.

## Goal

Repeated amends and momentum commits leave a message bloated, stale, or padded with trivia. `re0-git` rewrites the message into a clean version that lets a fresh session continue from `git log` alone, without reading the diff. It refines what the author already writes. Only the message moves — and timestamps, per the date rule below; the tree never changes.

It is **user-invoked** — run it once you've decided to commit. A commit-cleanup tool in the agent's reach would bias it toward committing when it shouldn't.

## Workflow

1. Scope the target — usually `HEAD`, sometimes a short unpushed range.
2. Read the change (`git show --stat`, `git diff`) and any documented commit rules. Then sample nearby non-target messages: start with 10, stop earlier if the convention is obvious, or expand only until the convention is clear.
3. Resolve mixed logs in this order: documented project rules, nearby commits touching the same area, then same-author commits within that convention. Do not average incompatible styles or let one author's habits override the repo.
4. Rewrite the message to the **commit-economy** (below): keep only durable handoff facts, fold supporting edits into the change they serve, and cut anything the diff or tag already proves. Give trivia no bullet of its own.

Land a contribution fairly: credit preserved, the maintainer's changes legible, accepted on the record.

## Goal

A contribution is a gift with a permanent carrying cost, and a review either honors both or fails one. `re0-merge` walks whoever reviews — any collaborator or maintainer, not just the author — through accepting a pull request the way this suite does: judged against the thesis, landed with the author's authorship intact, the maintainer's own edits kept as separate commits, and closed with an approval and a credit rather than a silent rejection.

## Workflow

1. **Gate before landing.** An additive contribution is declined by default; the burden is on the addition to show the suite is worse without it, not on you to justify a no. Judge each PR alone, never as a batch: a bug-fix subtracts a defect and is the easy yes; new tooling earns a place only if it mechanizes a rule already enforced by hand; a new skill lands only if it closes a real gap no existing one covers. A well-reasoned decline is a shipped outcome, not a failure.
2. **Cold-read it first.** Read the contribution end to end with fresh eyes (a `shower` pass when installed) before deciding; a name or claim that reads clean to its author may not to a stranger.
3. **Verify, do not re-fix.** Where the author already pushed a fix, prove it with a throwaway regression case rather than rewriting it; the credit for the fix is theirs.
4. **Approve as you accept, then land on a `land/pr-<n>` branch** (a range only for a genuine multi-PR batch). Submit the approving review the moment you decide to accept, before the land — it is a verdict on the contributor's code, not a receipt for a release, and giving it now (not bundled with the later close) is what keeps a closed-not-merged PR reading as accepted. Then accept each contributor commit with its authorship preserved (you become the committer; clean the message with `re0-git`), add every maintainer change as its own separate commit so the credit split stays legible, and fast-forward into `main`.
5. **Complete a new skill, don't merge it raw.** Get the name right (a plain real word or tight compression, no opaque coinage), the invocation right (model- vs user-invoked), and the home right; then register it on every roster surface (`plugin.json`, the README Index in root and every localized copy, `re0-upgrade`'s Current catalog, `scripts/catalog.cjs`) so no drift-guard trips.
6. **After the release the contribution shipped in confirms, close the PR with the comment.** Close it in the same motion as a comment that credits and explains — never a silent close, and never before the release lands. The approval from step 4 already records it as accepted; this step only closes and explains.

Run this repo's shipping and releasing checklist on a pending change, then tag and publish once confirmed.

## Goal

Make "prepare and ship a release" a single deliberate command instead of re-deriving the shipping and releasing checklist by hand every time. It runs `sip` when installed, applies commit-economy directly, and never auto-fires another user-invoked skill. It treats "commit" and "tag + push" as two separately-staked moments: a commit stays local and reversible, tag + push is the one step that goes public.

## Workflow

1. Confirm shipping readiness against the pending diff — every applicable item from AGENTS.md's Shipping checklist except the version bump and the `sip` run, which are steps 2 and 3 here:
   - any new or changed `SKILL.md` has the right shape (frontmatter `name`+`description`, `disable-model-invocation` only if user-invoked, body sections Goal/Workflow/Rules/Verification);
   - the README and every localized copy under `docs/readme/` list it accurately, with the right invocation column and in the roster's logical order — the same order held across `plugin.json`, `scripts/catalog.cjs`, and `re0-upgrade`'s catalog, kept in lockstep with `reorder`; the README's Problem removes-list and Fixes narrative include it only if it carries the thesis (most skills earn neither — both are curated);
   - `plugin.json` registers its path;
   - any rename appends an old -> new row to `re0-upgrade`'s deprecations checklist, in release order;
   - shared cross-skill rules (edit-safety, negatives-as-corpus, commit-economy) stay coherent across every copy that carries them.

Check the read before acting: did you understand the instruction correctly enough to spend the work?

## Goal

`readchk` catches misread instructions before they become coherent work against the wrong target. It verifies a claim about the requester's intent against available context: the current message, session history, project memory, files on disk, and established conventions.

This is not `factchk`: the question is what was meant, not whether a world claim is true.

## Workflow

1. Recognize the signal: a long or multi-part instruction, ambiguous scope or referents, deliberately flexible wording, or stakes high enough that a wrong guess would cost real work.
2. Restate the instruction internally in different words. Do not copy the user's wording back to yourself and treat that as understanding.
3. Cross-check the restatement against available context. Look for contradictions, missing antecedents, or two plausible readings that context cannot choose between.
4. If context resolves the read, proceed silently. Do not ask the requester to confirm what the available context already answered.

Put a listing back into an order that carries meaning, moving items only.

## Goal

A listing's order is information: kin sit together, and the sequence follows one axis a reader can feel. Order drifts — items get appended where they were written, not where they belong — until the sequence tells the reader nothing. `reorder` realigns the set under a single, nameable principle so the order reads as intentional again. It is fast and single-purpose: it moves items, and changes nothing else.

## Workflow

1. Pin the listing and its items — the ordered set in focus.
2. Name the principle that makes the order carry the most meaning: workflow or lifecycle sequence, dependency, grouping by kind, severity, frequency, or plain alphabetical. If the set already has a latent order, surface and finish it rather than imposing a new one.
3. Cluster kin adjacent, then sequence the clusters by that one principle.
4. Move items into the new order in place. Reword nothing; add and remove nothing.
5. If the same set is mirrored elsewhere — a translated copy, a second surface — apply the identical order to each.

Step out of the session and let a clean mind read it: does the artifact stand on its own?

## Goal

A long session quietly accumulates context you can't un-see, so you lose the ability to judge whether your work reads clearly to a first-timer — you no longer know what you left unsaid (the unknown-unknowns). The fix is a literally fresh brain: a separate sub-session that never saw this conversation cold-reads the artifact in focus and reports where a clean reader would stall. A smoke test for comprehension and handoff. This skill diagnoses; the fixing happens back in the main session.

## Workflow

1. Pin the scope: the artifact (or set) currently in focus. If "in focus" is ambiguous, confirm with the user or take the artifact just produced or under discussion. Privately note, in one line, what it is meant to be and who it is for — your yardstick for step 4; the reviewer never sees it.
2. Launch a **fresh sub-session** (a subagent / Task — it starts context-free). Hand it the artifact's **contents** (inline, or a copy), not a repo path, and tell it not to open the project's README, docs, or neighboring files that would spoil the cold read. Give it nothing about your intent or reasoning.
3. Have it cold-read blind and report, from the artifact alone:
   - what it takes the artifact to be, do, and expect;
   - what is unclear, ambiguous, or assumed-but-unstated;
   - what it would need to act confidently, and what it had to guess.

Taste your own cooking: the moment you finish making something, check it with the very skills this repo ships before you serve it.

## Goal

A reminder buried in docs ("remember to verify") won't reliably fire in a fresh session. `sip` makes the recursive self-improvement loop a triggered habit: right after any create or change, run our own skills on the result — the clean checks and the true ones — so quality doesn't ride on the author's biased in-session judgment.

## Workflow

1. Spot the trigger: you just created or changed an artifact or skill and are about to call it done, commit, or hand it off.
2. **Cold-read it** — run `shower` on the artifact (fresh-eyes comprehension / handoff check).
3. **Verify it's true** — if the artifact asserts a reality-grounded claim, run `factchk`; if it defines an eval, metric, or experiment, run `mandela`. Skip when it has neither.
4. **Check consistency** — run `ssotize` in audit mode across the repo for anything the change duplicated or contradicted; execute its consolidation plan only after approval.
5. **Detool portability claims** — run `detool` only when the artifact claims portability, tool-neutrality, stack-agnostic durability, or cross-agent reuse. Skip when it is provenance, operational notes, a tool-targeted runbook, or does not claim portability.
6. **Tidy** — `re0` the changed docs so the result reads as a clean v0, not a patch over a draft.

Split one artifact across independent lenses and return where they converge and where they don't.

## Goal

The result is a picture of where the lenses agree, where they disagree, and the smallest question that would resolve the disagreement. Not a checklist, and never an average — averaging the lenses is the failure this skill exists to prevent.

## Workflow

1. Read the artifact end to end before choosing the lenses.
2. Choose one lens per genuinely distinct failure mode — correctness, security, readability, cost, adversarial-user, and the like. Two candidate lenses that share a failure mode are one lens, not two. In practice this lands between **2 and 5**: below 2 there is nothing to converge, and past 5 you are almost always padding with lenses that overlap. There is no default count — the artifact's distinct failure modes set it.
3. Through each lens, produce a one-line verdict — pass, fail, or unclear — with its single most load-bearing reason. No hedging list; if a reason isn't load-bearing, drop it.
4. Compare the verdicts and group them: full agreement, agreement for different reasons, disagreement.
5. Where there is disagreement, name the single next question whose answer would move it into agreement or a clean split with owners. That question is the output, not the individual verdicts.
6. Where every lens agrees, return the shared verdict with the reasons that were load-bearing for at least two lenses.