Workflow Planning & Development Skills

Remove unused PackageVersion entries from Directory.Packages.props files in a .NET repo using Central Package Management (CPM). Scans every .csproj, .props, and .targets file for PackageReference includes, computes which PackageVersion IDs aren't referenced anywhere, removes the unused entries with line-targeted edits that preserve formatting and comments, then verifies with dotnet restore. Use this skill whenever the user wants to clean up, prune, or remove unused entries from Directory.Packages.props, or says things like "clean up CPM", "remove unused packages from central package management", "the props file has stale entries", "prune Directory.Packages.props", or "dead packages in the central versions file" — even if they don't literally say "CPM". Trigger proactively when the user mentions Directory.Packages.props alongside cleanup, removal, dead, stale, or unused. Refuses to run on repos without a Directory.Packages.props (CPM not in use).

Make any message look AI-generated — the mirror image of the humanizer skill. Rewrites text to pile on the tells of LLM slop (em dashes, rule of three, "it's not just X, it's Y," words like delve / tapestry / testament / underscore, inflated significance, sycophantic openers, emoji bold headers) while keeping the original meaning fully intact. Has an intensity dial — subtle (the default, plausibly deniable), heavy (unmistakably AI), and unhinged (maximum slop). Use this skill whenever the user wants to make writing look AI-written, robotic, botted, or ChatGPT-flavored — phrasings like "dehumanize this," "make this look AI-generated," "make it sound like a bot wrote it," "AI-ify this," "add some slop," "give it the ChatGPT treatment," "dial up the AI," or "make this more obviously AI" — even if they never say the word "dehumanize." Mostly used for trolling and parody. If the text already looks AI-ish, dial it up rather than tone it down.

Review and consolidate Claude Code permission entries in settings.json files. Use this skill whenever the user wants to clean up, consolidate, review, audit, or prune their Claude Code permissions, or says things like "my allow list is huge", "too many permission entries", "the permissions file is a mess", "consolidate my permissions", or "look at settings.local.json". Also trigger proactively when the user mentions "permissions", "settings.local.json", "settings.json", "allow list", or complains about repeatedly approving similar commands — even if they don't literally ask to "consolidate".

Structured research-plan-implement workflow for non-trivial tasks. Researches the codebase deeply and writes findings to a persistent file, then produces an annotatable implementation plan the user can mark up with inline notes, iterates through annotation cycles until approved, builds a task breakdown, and finally implements. Use this skill whenever the user has a multi-step implementation task, feature request, refactoring, or architectural change. Suggest this workflow when you detect tasks that would benefit from upfront research and planning — multi-file changes, unfamiliar code, architectural decisions, or anything where jumping straight to code would be risky. Even if the user doesn't explicitly ask for "research" or "planning", suggest it for substantial work.

Automated multi-model variant of plan-repl: a coordinator fans token-heavy research out to parallel Sonnet subagents (via the Workflow tool), synthesizes an implementation plan on the session model, then a Fable arbiter grills the plan over bounded rounds (three by default, extendable by explicit request when you're in the loop) until it has no substantive objections — replacing plan-repl's human > NOTE: loop with a cheap→mid→expensive model cascade. Explicit-only: invoke via the /esond:plan-repl-auto command or by name. Do NOT auto-suggest or fire it on general planning/refactor requests — plan-repl is the default; use this ONLY when the user explicitly asks for plan-repl-auto or the automated multi-model plan cascade. Flags: --implement (run end-to-end and autonomously with no human checkpoints, then fan Sonnet subagents to build the plan) and --arbiter (arbiter, default Fable).

Experimental HTML variant of plan-repl. Same research → plan → annotate → implement workflow, but each phase produces an interactive HTML page instead of a markdown file — with an in-browser annotation widget that exports notes back to a JSON file Claude reads on the next turn. Use this skill whenever the user explicitly asks for the HTML version of plan-repl, wants to prototype or evaluate the HTML output format, says things like "let's try the HTML plan thing", "use plan-repl-html", "render the plan as HTML", "I want the experimental HTML workflow", "do the plan thing but in HTML", "annotate this in the browser instead of in markdown", or references Thariq's "HTML is the new markdown" post in the context of planning. Do NOT auto-suggest this for general planning tasks — plan-repl is the default; plan-repl-html is an opt-in experiment. Trigger only when the user has explicitly asked for the HTML variant.

Resume an in-progress plan-repl task from its persisted files. Reads tasks/{task-name}/research.md, plan.md, and todo.md, cross-references them against the current branch's git state to figure out where the previous session actually left off, then continues from that phase. Use this skill whenever the user wants to pick a plan-repl task back up — even if they phrase it as "resume the X task", "continue where we left off", "I cleared my context, let's keep going", "pick up the webhook-retries task", "what were we doing on X", or just "let's continue X" with a name that matches a directory under tasks/. The two main scenarios: (1) the user cleared their context mid-workflow because research and planning bloated the conversation and wants a fresh slate without losing the work on disk, and (2) the user is returning to a task in a new session after exiting earlier. Trigger proactively when the user references a task name that exists under tasks/ and hasn't been part of the current conversation yet.

Address outstanding review comments on a GitHub pull request. Fetches all unresolved review threads and general PR comments, assesses each for validity, then either fixes the code, commits, replies with the commit hash, and resolves the thread, or — when declining — replies with justification and leaves the thread for the reviewer to resolve. Use this skill whenever the user wants to address, fix, resolve, or work through PR review comments or feedback — even if they just say something like "handle the PR comments", "address the review feedback", "fix what the reviewers said", or "go through the PR". Also trigger when the user pastes a PR URL and asks you to act on the feedback there.

Reorganize the commits on a non-default git branch into a clean, logical history by rewriting the branch — git reset + re-commit by default, scripted git rebase -i when commit boundaries already align. Propose groupings based on the actual work done (features, refactors, tests, fixes, docs), get explicit user approval, then rewrite history while re-signing commits and running hooks. Use this skill whenever the user wants to tidy up, clean up, reorganize, restructure, squash, or curate commits on a feature branch — even if they phrase it as "my branch is a mess", "squash this down", "combine these commits", "fix up the commit log before I open a PR", or "make the commits presentable for review". Trigger proactively when the user is about to open or push a PR and the branch has scrappy/WIP/"fix" commits to collapse. Refuses to operate on default or release-shaped branches (main, master, develop, trunk, production, release, or the repo default) — a feature-branch-only tool.

Opt-in, collaborative system-design workflow based on Juval Löwy's iDesign methodology in Righting Software. Conducts a multi-phase interview (framing → use cases → volatility analysis → components → call-chain validation → report) that surfaces unknown-unknowns and produces a written recommendation at decompositions/{system-name}/report.md. Run only when the user explicitly invites this workflow — not for general architecture questions, lightweight design conversations, or quick "where should X live?" questions. Valid triggers: the user names the skill directly, references Righting Software / Juval Löwy / iDesign / "The Method" / volatility-based decomposition and asks to run a full session, asks for a "deep" or "structured" or "Löwy-style" system design session, or accepts a prior suggestion to run it. Wait for an explicit yes before entering Phase 0. The skill is interrogative — a back-and-forth interview that challenges each volatility candidate and proposes ones the user hasn't considered.

Retroactively sign unsigned commits on the current git branch that were authored by the current git user. Use this skill whenever the user mentions signing previously-unsigned commits, fixing commit signatures, re-signing commits that were made without GPG/SSH signing, or any phrase like "sign my commits", "these commits aren't signed", "fix the signatures on this branch", "I need to sign the commits from earlier", or "clean up the unsigned commits". A common trigger scenario: Claude Code ran autonomously, hit a signing-key-locked error (e.g. 1Password locked, SSH agent missing, GPG passphrase timeout), fell back to -c commit.gpgsign=false to keep making progress, and now the user is back at the keyboard and wants to sign those commits. Trigger this skill proactively when you see unsigned commits on the current branch and the user starts talking about signing or signatures — don't wait for a literal "please sign".

Create or audit a repo's three core doc files — README.md, CLAUDE.md, and REVIEW.md — in that dependency order. If a file is missing, generate it from the actual codebase; if it exists, audit it against the current code and apply targeted fixes after confirmation. README.md gets a developer from clone to running the project; CLAUDE.md captures coding guidance for Claude (delegating to /init or the claude-md-improver skill); REVIEW.md holds reviewer-facing guidance for automated code review agents without duplicating CLAUDE.md. Target files with --readme, --claude, and --review, or run all three by default. Use whenever the user wants to set up, bootstrap, scaffold, refresh, audit, update, or sync a repo's docs, or says things like "create a README", "is my README still accurate", "write a CLAUDE.md", "audit our docs", or "get this repo ready for contributors" — even if they name only one of the three files. Prefer it over claude-md-improver alone when README or REVIEW are also in scope.

DEPRECATED — superseded by righting-software-system-design, a more faithful and complete implementation of Juval Löwy's iDesign methodology from Righting Software. Do not invoke this skill for new decomposition sessions. The only valid trigger is when the user explicitly asks to continue an in-progress decomposition they started with this specific skill before its deprecation (e.g., "let's pick up the volatility-decomposition session I started", "continue my old decomposition", or names this skill by its exact slug volatility-decomposition). For everything else — including all references to iDesign, Juval Löwy, Righting Software, "The Method", volatility-based decomposition, axes of change, Manager/Engine/Access/Accessor/Utility terminology, architectural ambiguity, "how should I break this up?", monolith extraction, microservices design, or unknown-unknowns — defer to righting-software-system-design.