Skip to content
AI & Agents
Skill

/sip

After you create or change an artifact or skill, taste-test it with our own skills instead of trusting your in-session judgment — recursive self-improvement, made automatic. Use right after writing or editing anything, before calling it done, committing, or handing it off.

BOOST
From plugin
paperthin
1.1k28 skills
Install
$ npx -y skills add LilMGenius/paperthin --skill sip --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/sip

Context preview

The summary Claude sees to decide when to auto-load this skill.

After you create or change an artifact or skill, taste-test it with our own skills instead of trusting your in-session judgment — recursive self-improvement, made automatic. Use right after writing or editing anything, before calling it done, committing, or handing it off.

SKILL.md

sip.SKILL.md
name: sip
description: "After you create or change an artifact or skill, taste-test it with our own skills instead of trusting your in-session judgment — recursive self-improvement, made automatic. Use right after writing or editing anything, before calling it done, committing, or handing it off."

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. 7. Apply the findings here, then serve it.

Rules

  • Trigger on your OWN output, right after making it — that's when bias is highest and a check is cheapest.
  • Use the skills; don't re-implement them — `shower` for clarity, `factchk`/`mandela` for truth, `ssotize` for SSOT, `detool` for portability claims, `re0` for cleanup. `sip` orchestrates and routes findings back to the author session to fix; the skills do the work.
  • Skip what plainly doesn't apply, or any check whose skill isn't installed — run only what's present. `factchk`/`mandela` fire only when there is a claim or an eval; `detool` fires only when the artifact claims portability, tool-neutrality, stack-agnostic durability, or cross-agent reuse; a one-line prose tweak may need only a consistency check. Say what you skipped and why.
  • Stop at the artifact — `sip` never touches git or makes commits.
  • Chain only model-invoked skills; a user-invoked skill (marked `disable-model-invocation`) is a human's to fire deliberately, so `sip` must not call one.

Verification

Before finishing:

1. The change was actually run through the relevant skills, not eyeballed. 2. Findings were applied (or consciously deferred with a stated reason). 3. The artifact actually changed as a result (a diff exists), or every skipped skill has a stated reason.

Read more
Ships withpaperthin

Turning old engineering wisdom into reflexes your agent reaches for on its own. On any agent | Claude Code, Codex, OpenCode, Antigravity, Copilot, Cursor, Grok-Build, Pi, Hermes, OpenClaw, etc.

Get the whole plugin
Stats
1,130
Stars
113
Forks
Active
Maintenance
JavaScript
Language
MIT
License
7d ago
Last commit
3mo ago
Created
16h ago
Added

Repo: LilMGenius/paperthin

Other skills on paperthin.