precise-alloyprecise-alloy/ritus/skills/wrap-up/SKILL.md

wrap-up

Skill1 starsChanged 4 months agoMITView on GitHub

Use after pr-review returns an Approve verdict to promote exploration entries, verify doc updates, and report final status. TRIGGER - invoke only after pr-review approves.

We split this skill into the rules it gives an agent

13 rules. 0 are common, 11 are distinctive, and 2 are very specific to this project.

0
Common
Most of the 55 edited versions we read keep these.
11
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Core principle: No loose ends - verify every step completed before declaring done.
line 9
Distinctive:
After pr-review returns an Approve verdict.
line 13
Distinctive:
When starting wrap-up, create this TODO - every item below, verbatim (never a single item named after the skill) - and mark items done as …
line 16
Very specific:
Read docs/tasks/{branch-slug}/exploration.md.
line 29
Distinctive:
Append-only: - never modify existing doc content.
line 40
Distinctive:
If an entry is questionable or you're unsure about placement, hold it and ask the user.
line 41
Distinctive:
After all entries are promoted, delete the exploration log.
line 42
Distinctive:
If the exploration log doesn't exist or is empty, skip this step.
line 43
Very specific:
Read each task file in docs/tasks/{branch-slug}/.
line 47
Distinctive:
If all doc updates are confirmed, mark this step done.
line 53
Distinctive:
Never skip promotion when the exploration log has entries - unpromoted exploration entries are lost knowledge.
line 82
Distinctive:
Never modify existing doc content when promoting - append only.
line 83
Distinctive:
If doc updates are missing, report them - do not apply them yourself.
line 84

“Common” is measured: kept by at least 6 in 10 of the 55 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Wrap-up

Core principle: No loose ends - verify every step completed before declaring done.

When to use

After pr-review returns an Approve verdict. If pr-review has not run or the verdict is not Approve, stop and instruct the user to run pr-review first. This is the post-implementation cleanup skill - it ensures cleanup happens instead of being forgotten, then hands off to comprehension (the chain terminal) for a final understanding check before the human commits.

When starting wrap-up, create this TODO - every item below, verbatim (never a single item named after the skill) - and mark items done as you complete them:

TODO:

- [ ] Promote exploration.md entries to target docs
- [ ] Verify DOC UPDATE sections from task files were fulfilled
- [ ] Report final status to user
- [ ] Hand off to comprehension (invoke comprehension)

Step 1: Promote exploration entries

Read docs/tasks/{branch-slug}/exploration.md. For each flagged entry, promote to the target doc:

Flag	Target doc
`[CODE_CONVENTIONS]`	`docs/CODE_CONVENTIONS.md`
`[ARCHITECTURE]`	`docs/ARCHITECTURE.md`
`[LESSONS]`	`docs/LESSONS.md`
`[DECISIONS]`	`docs/DECISIONS.md`
`[NONE]`	Not promoted - deleted with the log

Rules:

Append-only - never modify existing doc content.
If an entry is questionable or you're unsure about placement, hold it and ask the user.
After all entries are promoted, delete the exploration log.
If the exploration log doesn't exist or is empty, skip this step.

Step 2: Verify doc updates

Read each task file in docs/tasks/{branch-slug}/. For STANDARD/EPIC tasks with a DOC UPDATE section:

Extract the target docs and expected updates.
Grep the target docs to confirm the updates were applied.
Flag any missing doc updates.

If all doc updates are confirmed, mark this step done. If any are missing, report them.

Step 3: Report final status

Report to the user:

## Wrap-up complete

### Exploration entries promoted
- [CODE_CONVENTIONS] <entry> → docs/CODE_CONVENTIONS.md
- [LESSONS] <entry> → docs/LESSONS.md
  (or: no entries to promote)

### Doc updates verified
- ✅ docs/ARCHITECTURE.md - updated per task 001
- ❌ docs/DECISIONS.md - missing update from task 002
  (or: all doc updates confirmed)

### Address-feedback rounds
- Round 1: <N> comments addressed (<commit-hash>)
  (or: no address-feedback rounds in this workflow)

### Next steps
- Comprehension check (`invoke comprehension`) - a final understanding pass before you commit

Hard rules

Never skip promotion when the exploration log has entries - unpromoted exploration entries are lost knowledge.
Never modify existing doc content when promoting - append only.
If doc updates are missing, report them - do not apply them yourself. The execute-task subagent owns implementation.

Handoff

Report: final status (exploration promoted, doc updates verified, address-feedback rounds).
TODO update: invoke comprehension - the terminal comprehension check before the human commits.

Download now (ZIP)

Other versions60 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 60
rohitg00/pro-workflow★ 2.9ksame name
anthropics/launch-your-agent★ 1ksame name
ianlkl11234s/mini-taiwan-pulse★ 537same name
aspi6246/Claude-Code-Skills-for-Academics★ 153same name
PaulRBerg/agent-skills★ 104same name
KerberosClaw/kc_ai_skills★ 79same name
jonathanmalkin/jules★ 65same name
simoncorry/foundry★ 39same name
alxyrgin/health-os★ 38same name
mshadmanrahman/claude-for-designers★ 32same name
50 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use refine, doctor and 5 more.
Other files people use alongside this one.
- AlexPEClubSkill
  refine
  Always use when the user wants to discuss an exsiting feature or specification. Open an existing feature spec to improve, extend, or fundamentally challenge it. Pass the feature ID as argument (e.g. /refine PROJ-2).
  Also in 3 projects that use this
- MicrosoftSkill
  doctor
  Diagnose an Amplifier CLI environment through the CLI doctor agent. USE WHEN a user requests CLI runtime, settings or missing-capability inspection. DO NOT USE for project bugs or other hosts.
  Also in 4 projects that use this
- austintgriffithSkill
  orchestration
  Use when a Scaffold-ETH 2 build leaves localhost: planning the launch order, deploying and verifying contracts on a live network, standing up a fork of a real chain to rehearse a deploy, or fixing a contract bug that is already onchain. Not for running the app or a demo against that fork (`/frontend-playbook`).
  Also in 3 projects that use this
- SentrySkill
  spec
  Produce a verified spec — problem, desired outcome, and acceptance criteria — before building. Use when given a GitHub/Linear issue link, when starting from a fuzzy in-conversation idea, or asked to "figure out what to do" / "scope this" / "what should I build" — whenever the *what* isn't yet pinned down. Grills the ambiguities, checks the premise against the code, and produces acceptance criteria you sign off on — then hands to design-first.
  Also in 4 projects that use this
- seikaikyoSkill
  interview-me
  需求不明時的意圖萃取訪談：一次一題、每題附上自己的猜測、聽出「真正想要 vs 覺得應該要」，直到能預測使用者反應（約 95% 信心）才動工。適用：需求缺少對象 / 動機 / 成功標準 / 約束，或使用者點名「訪談我」「先確認一下」「我們確定嗎」。明確自足的指示、純資訊查詢、機械性操作不適用。
  Also in 3 projects that use this
- GoogleSkill
  grill-me
  A relentless interview to sharpen a plan or design.
  Also in 10 projects that use this
In this repository21 other files it gives its agents.
- address-feedbackSkill
- brainstormSkill
- code-conventionsSkill
- comprehensionSkill
- debugSkill
- definition-of-doneSkill
- execute-taskSkill
- migrate-docsSkill
- pr-reviewSkill
- repo-scanSkill
- requirement-analysisSkill
- securitySkill
- setupSkill
- start-ritusSkill
- syncSkill
- task-generationSkill
- tddSkill
- testing-policySkill
- ticket-reviewSkill
- triageSkill
- verify-taskSkill

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

What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free

13 rules. 0 are common, 11 are distinctive, and 2 are very specific to this project.

Wrap-up

When to use

Step 1: Promote exploration entries

Step 2: Verify doc updates

Step 3: Report final status

Hard rules

Handoff

Word for word · 0

Edited · 0

Wrote their own version · 60

refine

doctor

orchestration

spec

interview-me

grill-me

Does it work?

No reviews yet

Your trail

Now do this for your own.