Use after completing any substantive piece of work (code change, analysis, document, configuration, answer to a hard question) and BEFORE presenting it as done. Switches you from author to attacker - you try to refute your own work and only present it if it survives. Do not skip because the work "looks clean"…
Use when the user asks for a code audit, sanity check, maturity assessment, or "vibe-code check" of this repo (or a repo they point at) — e.g. "/audit", "/audit 14", "/audit security", "audit the whole repo", "how production-ready is this". Runs one, several, or all 29 best-practice topics as read-only investigations…
Use when the user says "cut a release", "cut vX.Y.Z", "ship the release", or when merged work has accumulated past the last tag and it's time to make it official. Runs the whole ritual - verify live state, bump package.json, stamp the changelog, open the cut PR, then hand the user release notes + a prefilled publish…
Use when the user says "fresh eyes", "/fresh-eyes", or is about to hand this repo to someone with no context — a Codex sprint, another agent, a new session, a contractor, a reviewer. The inverse of /INPUT — instead of ingesting outside material INTO the project, it exports verified project state OUT to a cold reader…
Use when the user says "INPUT", "/INPUT", or feeds in a block of raw material they vouch for — strategy notes, sprint output, a roadmap enhancement, a code snippet, or live coding suggestions for work in flight. Unlike /queue (one-liner capture, no analysis), INPUT is ingestion with judgment - read it all, split it…
Use whenever you are about to assert or act on a fact about a system - what a function does, what a config is set to, what is deployed, what a table contains, what a dependency's version is. Forces verification against the LIVE system before the assertion. Docs, comments, READMEs, and your own memory are treated as…
Skill "memory-hygiene" from ericlovold/sanction, covering writing: what deserves persistence, writing: how, recall: the verification rule, the maintenance habit and the honest limit.
Use before starting ANY task that involves more than one edit, file, or step - coding, refactoring, writing, configuration, migrations. Forces a short written plan (goal, unknowns, success criteria, step order) BEFORE the first change. Do not use for single-line fixes or pure questions.
Use when the user says "queue", "/queue", "add to the backlog", "capture this", or drops a thought/idea/question mid-arc that should NOT derail the current work. Appends the item to docs/BACKLOG.md with a date and moves on. With no argument, shows the open backlog. This is capture, not analysis - the point is to not…
Use BEFORE claiming any UI change works - dashboard pages, marketing pages, theme changes, new components - and whenever the user asks "did you actually look at it?". Seeds a demo org into local Postgres, boots next dev, screenshots the named pages with the preinstalled Chromium, and attaches the evidence. A visual…
Skill "ruthless-editor" from ericlovold/sanction, covering ruthless-editor: every sentence earns its place, the pass, the 30 percent test, what ruthless does not mean and the tell.
Use on every task where you will modify existing work - code, documents, configs. Fences your changes to exactly what was asked. Adjacent problems get FLAGGED, never silently fixed. Keeps diffs minimal and reviewable. Do not use it to refuse legitimate follow-through the task actually requires.
Use when the user drops market news and says "pick this up" / "what does this mean for us" - a platform launch, a protocol shift, a competitor move, a policy change. Runs the market-event playbook - verify the event at primary sources, map it onto the engine and roadmap, ship a fenced same-day slice if one exists, and…
Use when ships have outrun the public story - merged PRs with no changelog entry, roadmap "Next" items that already shipped, README claims that drifted - or on request ("truthsync", "drain the drift") and as a pre-release sweep. Diffs merged work since the last drain against the truth surfaces (changelog, roadmap…
Use whenever the user is producing communication another human will read as THEM — LinkedIn posts, outreach, emails, DMs, bios, booking-page copy, talk abstracts, personal notes. The AI coaches structure and strategy but never writes the words. Do not use for code, docs, UI copy, or anything read as the product…
Use when the user says "zoom out", "where do we stand", "what's next", or a work arc just closed (PRs merged, feature landed) and the next move is unclear. Pulls up from the trench - re-reads the live repo state, README, roadmap, and changelog - then delivers a ranked view of next best actions. Not for mid-task status…
AGENTS.md instructions for ericlovold/sanction, covering this is not the next.js you know, sanction — project context for ai sessions, what this is, commands and architecture.
Claude Code instructions for ericlovold/sanction, a project described as: Agent wallet, credential vault, and governance layer for autonomous AI agents.
The wallet an AI agent carries — mandate, budget, vault, and audit. Counterparties verify first. Runs locally from the sanction-mcp npm package. Needs 3 environment variables to run.