AGENT SKILL

durable-compact

Write the session's state to a handoff file, then print a focused /compact command and a resume prompt.

License 许可
MIT
所属仓库
esond/skills
最近更新
2026-11-07
Stars
★ 0
Forks
0

01 前言 Front Matter

name
durable-compact
metadata
{ "internal": true }
description
Write the session's state to a handoff file, then print a focused /compact command and a resume prompt.
disable-model-invocation
true

02 资源文件 1

03 SKILL.md 正文

Durable compact

/compact keeps a lossy summary. This skill writes a handoff first: a file a cold reader can resume from, holding what the summary tends to drop. The cold reader is you after compaction, with a summary you didn't write and no memory of why anything happened. You can't run /compact yourself; the user does, with the line you print.

The whole run happens in context that compaction is about to fold away, so keep it cheap: one file write, at most one question, one short reply.

Step 1: Draft the handoff

Write it from what is already in your context. You hold the full session, so you write it yourself; a fresh subagent sees none of the conversation.

Path: handoffs/<project>/<YYYY-MM-DD-HHmm>-<topic-slug>.md under the Claude config dir (${CLAUDE_CONFIG_DIR:-$HOME/.claude}), resolved to an absolute path. <project> is the basename of the git root of the session's primary working directory, or of that directory outside a repo. Get the timestamp from the shell rather than guessing it. Then write handoffs/.pending/<session id> holding only the handoff's absolute path, where the session id is $CLAUDE_CODE_SESSION_ID read from the shell; the compact hook loads the handoff for that session only. In the same shell call, delete files in handoffs/.pending older than 30 minutes: pointers left by /clear or a closed session, which no compaction will consume.

Fill these sections, omitting any that would be empty:

  • Goal: what the user is trying to achieve, in their words where you have them. Include the reason behind it if they gave one.
  • State: what is done and verified, what is in progress, what is untouched. Say how each "done" was verified.
  • Decisions: each choice made, why, and the options rejected. A rejected option with its reason stops the next session from proposing it again.
  • User corrections and preferences: every time the user corrected you or stated how they want things done this session, quoted verbatim.
  • Hard-won facts: things learned by effort that the repo doesn't record: tool or API behavior, gotchas, commands that work, dead ends and why they failed.
  • Open threads: questions waiting on the user, things you were about to check, known problems not yet fixed.
  • Next step: the single concrete action to take on resume.
  • Pointers: exact identifiers: absolute file paths, branch names, PR/issue numbers, URLs, IDs, commands. Copy them, never paraphrase them.

Point to what lives on disk (code, git history, docs) instead of restating it; the handoff carries what exists only in this conversation. Prefer a dense line over a paragraph.

Done when a reader with only this file and the repo could take the next step without asking what anything means.

Step 2: One check with the user

While drafting, note the borderline items: things you weren't sure deserved a place, or facts you inferred rather than saw. With two or more, ask one AskUserQuestion (multiSelect): "Which of these should the handoff keep?" with up to four of them as options. With fewer, ask a single-select "Anything else the handoff should keep?" with "No, it's complete" and, if there is one, "Keep <the borderline item>" as options. Either way the built-in "Other" box is where the user adds what you missed. Apply the answers to the file.

In the same AskUserQuestion call, check for the compact hook. It is already active when this skill came from the behavior plugin, which ships it: <base dir>/../../hooks/hooks.json exists and names load-handoff.sh. Otherwise search the user settings file (settings.json in the Claude config dir) and the project's .claude/settings.json and .claude/settings.local.json for load-handoff.sh. If the entry that names it has no matcher, set it to "compact" so the hook runs only after compaction. If it's in none of them, add a second question offering to install it: it loads the handoff into context automatically after every compaction that follows this skill, so the resume prompt becomes unnecessary. On yes, add this entry to the hooks.SessionStart array, keeping everything else in the file intact, with the script's absolute path from this skill's base directory:

{
  "matcher": "compact",
  "hooks": [{ "type": "command", "command": "sh \"<base dir>/scripts/load-handoff.sh\"", "timeout": 5 }]
}

A hook added mid-session may not be active until the user reviews it in /hooks or restarts, so the resume prompt still matters this time.

Step 3: Print the commands

Reply with the handoff path, then two fenced blocks:

  1. The compact command, with focus instructions naming the goal, the next step, and the handoff path, so the summary itself keeps the pointer:

    /compact Keep: <goal in a few words>; next step <next step>; full state in <absolute handoff path>
    
  2. The resume prompt to paste after compaction:

    Resume from the handoff at <absolute handoff path>. Read it in full before acting; where it and the compaction summary disagree, the handoff wins. Then <next step>.
    

Add one line saying the resume prompt works after /clear too, which drops the summary for a cleaner start. If the hook was already installed, say the handoff loads on its own after /compact, and the resume prompt is the fallback if it doesn't show up.

04 同仓库更多 Skills

esond
esond/skills

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.

★ 0
esond
esond/skills

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.

邮件与沟通
★ 0
esond
esond/skills

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.

开发工程师
★ 0
esond
esond/skills

sync-core-docs

Create or audit a repo's README.md, AGENTS.md/CLAUDE.md, and REVIEW.md docs.

★ 0
esond
esond/skills

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.

设计师视觉设计Skill与智能体开发
★ 0
esond
esond/skills

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.

★ 0