mcpField
S
sip

sip

github.com/lilmgeniusAgent workflows1.4k1.3k installsUpdated 4w ago
Repository

About sip

sip is a skill that routes newly created or changed artifacts through relevant repository skills before they are handed off. It selects checks by artifact type and claims, then returns findings for the author to apply; it does not touch git or commit.

Key features

  1. 01Triggers checks after artifact changes
  2. 02Routes clarity and truth checks
  3. 03Audits repository consistency
  4. 04Checks portability claims when applicable
  5. 05Applies findings before handoff

Use cases

  1. 01Reviewing a newly written skill before release
  2. 02Checking a changed document for factual claims
  3. 03Validating an experiment definition before handoff

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/lilmgenius/paperthin --skill sip

After installing, type/sipin Claude Code to confirm it loaded.

Details

From the project README

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.

Comments

Markdown supported