ds-catchup
Skill80 starsChanged 15 days agoMITView on GitHub
Give the user a short plain-language catch-up on what changed since their last message, followed by every decision still waiting on them. Use when the user returns after a long or unattended run, asks 'where are we', 'what did I miss', or types /ds-catchup.
In this repository28 other files it gives its agents.
- ds-adoptSkill
- ds-best-of-nSkill
- ds-blast-radiusSkill
- ds-blueprintSkill
- ds-context-resetSkill
- ds-design-auditSkill
- ds-designSkill
- ds-explainSkill
- ds-helpSkill
- ds-jurySkill
- ds-ledgerSkill
- ds-lessonsSkill
- ds-modeSkill
- ds-plan-loopSkill
- ds-pr-commentsSkill
- ds-principlesSkill
- ds-prSkill
- ds-readySkill
- ds-review-loopSkill
- ds-reviveSkill
- ds-sharpenSkill
- ds-shipSkill
- ds-swarmSkill
- ds-tddSkill
- ds-unslopSkill
- ds-unstickSkill
- ds-verify-loopSkill
- ds-watch-prSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Keep this turn read-only. Do not change code, start jobs or post anything.
- Distinctive: line 14
Check the current state of anything touched: tests, branches, PRs, running jobs.
- Distinctive: line 15
Write what changed in under 100 words.
- Distinctive: line 17
If nothing waits on them, say so plainly.
- Distinctive: line 25
Never invent a decision to fill the list.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
ds-catchup
Bring the user back up to speed in a minute, and hand them every call only they can make.
Steps
- Keep this turn read-only. Do not change code, start jobs or post anything.
- Collect what happened since the user's last message: your own work, subagent reports, and messages from others. Tool notifications are not user messages.
- Check the current state of anything touched: tests, branches, PRs, running jobs. Use fresh command output, not memory. Fix any number that does not match the source and say you fixed it.
- Write what changed in under 100 words. Say what it means for the user, for example "the login bug is fixed and its test passes". Leave out hashes, paths and commands unless the user needs one to act.
- List decisions waiting on the user. A decision is something only they can do: a product choice, an approval, an irreversible action, or access you lack. Include old ones still open. For each give: what it changes, the evidence, the risk, your recommendation, and "unknown" for missing facts.
- If nothing waits on them, say so plainly.
Stop when
- The catch-up and the decision list are written. One reply, no follow-up work.
Rules
- Never invent a decision to fill the list.
- Work you can still do yourself is not a decision for the user.
- Name things the way the user would, not by internal labels.
- Short sentences, no jargon.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.