个人作者
Eric Sondergard
Serial pragmatist. Check out my other repos at @hexagram-solutions!
- Skills
- 17
- 仓库
- 1
- 职业覆盖
- 4
- 场景覆盖
- 5
- Stars
- ★ 0
Eric Sondergard 的 Skills 17
work-item-voice
Write or edit the user's issues in their own voice, in any work tracker — Jira, Linear, GitHub Issues, Azure DevOps. Covers features (new behavior), tasks (work that needs doing), and bugs (behavior that does not match expectation). Load this whenever the deliverable is an issue body, whether they say "file a bug", "write a ticket", "draft a story", "create an issue for this", "turn this into a Jira", "write this up in Linear", or paste a thread and ask for an issue out of it. Load it too whenever text goes into an issue that already exists — "record this in the issue", "add what we found to the ticket", "note this on the card", "update the one about refunds", or naming an issue by its key and asking for a fact to go in it — and when writing or updating one is a step inside a larger task. Features get behavior-driven framing with no implementation prescribed, and bugs get expected versus actual. Not for a comment on an issue, which is a conversation turn.
conversational-voice
Write the user's side of a conversation with another person, in the user's own voice: Slack messages and replies, DMs, email, PR and code-review comments, Linear or Jira comments, and any other turn in an exchange that goes out under the user's name. Load this whenever the deliverable is a message a human will read as written by the user, whether they say "draft a Slack message", "reply to this", "how should I word this", "tell the team", "ask them about X", "send a note to", or just paste a thread and ask what to say back. Load it too when tightening, shortening, or sanity-checking a message they already wrote, and when a message is one step of a larger task. The register is direct and informal, the way they'd talk to a friend or acquaintance, with the answer up front for a reader who skims. Not for something the user authors rather than sends — an issue body, a PR description, a commit message — even though a person reads those too.
sync-core-repo-docs
Create or audit a repo's three core doc files — README.md, the agent instructions file (AGENTS.md or CLAUDE.md), and REVIEW.md — in that dependency order. If a file is missing, generate it from the 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; AGENTS.md captures coding guidance for the agent (delegating to /init or claude-md-improver); REVIEW.md holds guidance for code reviewers, human or automated, without duplicating AGENTS.md. Target files with --readme, --claude, and --review, or run all three. 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", "write an AGENTS.md", "audit our docs", or "get this repo ready for contributors" — even when only one file is named. Prefer it over claude-md-improver when README or REVIEW are also in scope.
sync-core-docs
Create or audit a repo's README.md, AGENTS.md/CLAUDE.md, and REVIEW.md docs.
righting-software-system-design
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.
reorganize-branch-commits
Reorganize the commits on a non-default git branch into a clean, logical history by rewriting the branch — `git reset` + re-commit by default, `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, back the branch up, then rewrite history. 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.
pr-review-resolver
Address outstanding review feedback on a GitHub pull request: unresolved review threads, submitted review bodies, and general PR comments. Triages each critically, fixes what it agrees with, and pushes back on the rest. Use whenever the user wants to address, fix, resolve, or work through PR review comments or feedback, even if they just say "handle the PR comments", "fix what the reviewers said", or "go through the PR", or pastes a PR URL and asks you to act on the feedback there.
inline-review
Find and address inline code-review comments left in the code, marked with the `rev:` prefix (e.g. `// rev:`, `# rev:`, `-- rev:`). These are a manual code review done inline instead of on GitHub — each comment is a question, suggestion, concern, or change request about the nearby code. Use this skill whenever the user asks you to address, handle, resolve, go through, or respond to their inline review comments, rev comments, or `rev:` comments — even when phrased tersely, like "address my rev comments", "handle the reviews", "go through the rev: notes", "I left some inline comments", "respond to my review", or just "address these" right after leaving such comments. Trigger whenever the request references `rev:` comments in the code.
clean-unused-cpm-packages
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).
diataxis
Router for documentation work under the Diátaxis methodology. Use whenever the user wants to write, add to, expand, reorganize, or audit documentation — "write docs for X", "document this feature", "add a page about", "improve our README", "does this doc work", "audit our docs", "--audit" — or mentions Diátaxis, the compass, or a documentation type when no single type skill is the obvious match. Applies the compass (action or cognition? acquisition or application?) to classify the reader's need, then hands off to diataxis-tutorial, diataxis-how-to, diataxis-reference, or diataxis-explanation. When the user points at existing docs or supplies paths, assume the work is adding to or expanding those articles. With --audit, runs an improvement pass instead: classify each unit, run the matching type's drift checklist, and propose relocations and splits that fit the docs to the model without rewriting their substance. Prefer this router over a type skill whenever the type isn't already certain.
diataxis-tutorial
Write, expand, or audit a tutorial — learning-oriented documentation in the Diátaxis sense: a lesson that takes a beginner through a guided, hands-on experience to build skill and confidence, where the artifact produced along the way is not the point. Use whenever the user wants a "getting started" guide, onboarding walkthrough, "first steps with X", intro lesson, learning exercise, workshop material, or asks to "teach someone" a tool, API, or codebase by doing — even if they never say "tutorial". Also loaded by the `diataxis` router when the compass points to action + acquisition: the reader will *do* something in order to *learn*. If the reader is an already-competent practitioner trying to get a real job done, that's `diataxis-how-to` instead; when the type is in doubt or mixed, consult the `diataxis` skill first.
diataxis-reference
Write, expand, or audit reference documentation — information-oriented technical description in the Diátaxis sense: austere, accurate, consistent facts about the machinery, consulted while working. Use whenever the user wants API docs, a configuration or parameter listing, CLI or command documentation, an options table, schema or data-model docs, error-code catalogs, environment-variable docs, or any "document what X is / what settings exist" request — even if they never say "reference". Also loaded by the `diataxis` router when the compass points to cognition + application: the reader needs *facts to consult* while *getting work done*. If the content is mostly why-and-context discussion, that's `diataxis-explanation`; if it directs the reader's actions step by step, that's `diataxis-how-to`. When the type is in doubt or mixed, consult the `diataxis` skill first.
diataxis-how-to
Write, expand, or audit a how-to guide — goal-oriented documentation in the Diátaxis sense: directions that help an already-competent reader accomplish a specific real-world task. Use whenever the user wants a "how to X" doc, a runbook, playbook, recipe, troubleshooting guide, setup/configuration/ migration/deployment/integration instructions, or step-by-step directions for practitioners — even if they never say "how-to guide". Also loaded by the `diataxis` router when the compass points to action + application: the reader will *do* something to *get work done*. If the reader is a beginner who needs to learn by doing in a safe setting, that's `diataxis-tutorial` instead; if the content mostly enumerates options and facts, that's `diataxis-reference`. When the type is in doubt or mixed, consult the `diataxis` skill first.
diataxis-explanation
Write, expand, or audit explanation — understanding-oriented documentation in the Diátaxis sense: discursive discussion that deepens the reader's grasp of a topic, read away from the work itself. Use whenever the user wants an architecture overview, design-rationale or "why did we build it this way" doc, concept guide, background or theory piece, ADR-style context, a "philosophy of X" or "about X" article, or asks to capture the reasoning behind a decision — even if they never say "explanation". Also loaded by the `diataxis` router when the compass points to cognition + acquisition: the reader wants to *understand*, as *study*. If the content is facts to consult mid-work, that's `diataxis-reference`; if it directs a task, that's `diataxis-how-to`. When the type is in doubt or mixed, consult the `diataxis` skill first.
de-slop
Deep-strip the tells of AI writing (claudisms) from a draft while keeping its meaning and the writer's voice intact. Sweeps the draft against the living claudisms banlist at claudisms.ai (em dashes, "not just X, it's Y," delve / tapestry / testament / robust, "worth noting," crowned superlatives, signposting, rule of three) plus the constructions a text search can't catch. Use this skill whenever the user wants AI tells removed from writing — phrasings like "de-slop this," "strip the claudisms," "remove the AI tells," "humanize this," "scrub the AI out of this," "make this sound like I wrote it," "this reads like ChatGPT wrote it," or "would this pass as human?" — even if they never say "de-slop." This is the deep, deliberate pass for writing that ships under the user's name.
bro
Restate the last message in plain human language, with no jargon.
durable-compact
Write the session's state to a handoff file, then print a focused /compact command and a resume prompt.