> ledger at .ratchet/ledger.jsonl, the accepted complexity mark, and every upgrade trigger. Use when the user says "ratchet ledger", "/ratchet-ledger", "what did we defer", "show the complexity trend", "what shortcuts are in here", or asks whether the codebase is getting simpler or more complex over time. Reports real recorded numbers only, never estimates.
npx skills add https://github.com/0xwilliamortiz/ratchet --skill ratchet-ledger
Three sections. Real numbers only.
Read .ratchet/ledger.jsonl, one JSON object per finished session. Report
the last ten: date, mode, lines added, new dependencies, findings by tag, and
the repository line count at the end of that session.
Show the direction plainly. If the line count has risen for three sessions in
a row, say so.
If the file is missing, say the ratchet is not initialised for this repository
and that mkdir .ratchet turns it on. Do not invent a trend.
Read .ratchet/mark.json, the accepted high water mark. Compare it to the
repository now.
Below or equal to the mark: At the mark. Above it: report the gap and the
reason recorded on the mark, then ask whether to bring it down or accept a
new mark with a written reason.
grep -rnE '(#|//|--) ?ratchet:' . --exclude-dir=node_modules --exclude-dir=.git
One row per hit, grouped by file:
<file>:<line> <what was simplified>. ceiling: <the limit>. upgrade: <the trigger>.
The convention is ratchet: <ceiling>, <upgrade path>, so both fields come
straight out of the comment. Any marker with no upgrade trigger gets tagged
no-trigger, those are the ones that rot silently.
End with <N> shortcuts, <M> with no trigger.
Every number here is read from a file or counted from the tree. Never report
what a session "saved": the version that was not written was never written,
so there is nothing to subtract from. The trend and the shortcut count are
the real figures, and they are enough.
Reports only. Changes nothing unless asked to write the report to a file.
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
Take 0xwilliamortiz/ratchet-ledger from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.