任务收尾

wrap-up 在一个任务结束时完成收尾：校验、沉淀结论、只提交本任务的改动，最后归档当前会话。下一个任务开新会话，只靠仓库本身就能接上。

调用	触发	来源
/wrap-up [push] [keep]	仅手动	独立 Skill

为什么需要它

「一个任务一个会话」能让上下文保持干净，也更省 Token，原因见最佳实践。但会话一归档，里面的信息就不会再被读到：没写进仓库、memory 或 Issue 的结论，下一个会话不会知道。

所以收尾的重点在归档之前：确认提交范围、记下决策和后续事项。这几步每次都要做，顺序也固定，适合封装成 Skill。只做 git commit 不需要 Skill，直接说「commit」就行。

安装

npx skills add YunYouJun/ai --skill=wrap-up

使用示例

/wrap-up            # 提交但不推送，然后归档
/wrap-up push       # 提交并推送，然后归档
/wrap-up keep       # 只收尾提交，保留会话（例如还要等 Review）
/wrap-up 把放弃插件市场的原因记进 plan

执行内容

1. 划定范围：对照本次对话，把改动分为「本任务」和「无关」两类，只按路径暂存本任务的改动，不使用 git add -A；
2. 检查敏感文件：不提交 .env、密钥和本地配置；
3. 校验：代码有改动时，运行受影响范围的 lint、类型检查和测试，失败则不提交、不归档；
4. 沉淀结论：设计决策和踩坑写进仓库文档，跨任务的偏好写进 memory，未完成的事项写成 TODO、Issue 或新会话；
5. 提交：遵循仓库的提交约定，不相关的改动拆成多个 commit；只有传入 push 时才推送；
6. 归档前检查：以下情况不归档：worktree 中还有未提交改动、还有后台任务在运行、PR 正在等待 Review；
7. 汇报并归档：列出提交、沉淀内容、未处理的无关改动和后续事项，最后归档当前会话。

快速路径：工作区干净、也没有未推送的提交时，说明改动早已提交并推送，跳过第 1–3、5 步，只判断要不要沉淀结论、能不能归档，省掉空跑的检查。有改动、有未推送的提交或分支没有上游时，照常走完整流程。

不同环境的差异

• Claude Code 桌面版：通过会话管理工具归档当前会话，归档后对话结束，可以在 Archived 列表中恢复；
• CLI 与其他 Agent：没有「归档」概念，Skill 完成提交后会提示用 /clear 或新开会话。

走 PR 流程的任务，也可以在 Settings → Claude Code 中开启「PR 合并或关闭后自动归档会话」，代替手动归档。

完整指令

SKILL.md

---
name: wrap-up
description: "Wrap up the finished task in this session: verify, persist durable knowledge, commit only this session's changes, then archive the session."
argument-hint: "[push] [keep]"
disable-model-invocation: true
---

Close out the task this session worked on so the next session can start fresh from the repository alone. Anything not written to the repository, memory, or an issue is lost once the session is archived.

The arguments may contain:

- `push` — push the commits after committing
- `keep` — do everything except archive the session

Any other text is a note about what to persist or how to word the commit.

Arguments: $ARGUMENTS

## Fast path

First run `git status --short` and `git log --oneline @{u}..HEAD`. If both succeed and print nothing, everything is already committed and pushed: skip steps 1–3, 5 and 6, judge step 4 from this conversation alone, then do steps 7–9 and report `Commits: none new`. Otherwise (changes, unpushed commits, or no upstream) follow every step.

## Instructions

1. **Scope the changes.** Run `git status --short` and `git diff --stat` (plus `git diff --cached --stat` if anything is staged). Using this conversation, sort every changed path into:
   - **this task** — changes this session made for the task;
   - **unrelated** — changes that existed before the session or belong to other work.

   Stage only the paths in "this task", by name. Never `git add -A` or `git add .`. If a file mixes both, stage the relevant hunks with `git add -p` or ask. If unsure whether a change belongs to this task, ask before committing it. Leave unrelated changes untouched and list them in the report.

2. **Check for secrets.** Do not stage `.env*`, credentials, tokens, keys, or local-only config (such as `.claude/settings.local.json`). Stop and ask if one appears in "this task".

3. **Verify.** If code changed since checks last passed in this session, run the project's quick checks for the touched area (lint, typecheck, related tests). If they fail, fix them or stop and report. Do not commit or archive a broken state.

4. **Persist durable knowledge.** Ask: what would a fresh session need that is not obvious from the diff?
   - Design decisions, rejected options, and pitfalls go in the repository's own docs (follow `AGENTS.md` / `CLAUDE.md`: plan, ADR, changelog).
   - The user's preferences or corrections that apply across tasks go to memory.
   - Unfinished follow-ups go into a TODO, an issue, or a proposed new session, not just the final message.

   Skip this step when there is nothing new. Do not repeat what the commit message already says.

5. **Commit.** Follow the repository's commit conventions (Conventional Commits by default, plus any required attribution lines). Split unrelated logical changes into separate commits. Respect the repository's branch rules. If it forbids committing to the default branch, create a branch first.

6. **Push** only if the arguments contain `push` or the repository's instructions require it. Never force-push.

7. **Check whether it is safe to archive.** Do not archive, and say why, if any of these holds:
   - the session runs in a worktree that still has uncommitted changes, because archiving cleans up the worktree;
   - background tasks or side sessions started from this session are still running;
   - an open PR from this session is waiting for review or CI. Suggest keeping the session, or enabling auto-archive on PR close, instead.

8. **Report** in a few lines:

   ```
   ## Wrap-up

   Commits: <short-hash> <subject> (pushed / not pushed)
   Persisted: <docs or memory updated, or "nothing new">
   Left alone: <unrelated changed paths, or "clean">
   Follow-ups: <issue / TODO / proposed session, or "none">
   ```

9. **Archive.** Skip this step if the arguments contain `keep` or step 7 blocked it. Otherwise archive this session as the very last action. In the Claude Code desktop app, call the session archive tool with `session_id: "self"`. The conversation ends there. If the host has no such tool (CLI or other agents), say the task is closed and suggest `/clear` or starting a new session. Do not claim the session was archived.