wrap

name	wrap
description	Wrap up the current session by reflecting on what was learned and identifying skills, rules, or hooks that should be created or updated. Use at end of session, before switching contexts, or when Q says "wrap up", "let's stop", or /wrap.

Session Wrap-Up

End a session by reflecting on what happened and identifying anything that should be persisted as a skill, rule, or hook — at the user or project level.

Steps

1. Session Review

Scan the conversation for:

Signal	What it means
Q corrected a behavior	A rule might prevent the mistake next time
A multi-step workflow was performed	A skill could automate it
A pattern was repeated across files	A hook or rule could enforce it
Q expressed a preference	A rule should encode it
A tool was used in a non-obvious way	A skill could capture the recipe
Something was done manually that could be automated	A hook could fire automatically
A project-specific convention was discovered	A project-level rule should document it

2. Classify Candidates

For each candidate identified, determine:

What type?

• Rule — A behavioral directive (do this, don't do that, prefer X over Y)
• Skill — A reusable multi-step workflow triggered by a slash command
• Hook — An automatic action triggered by a lifecycle event or tool use

What scope?

• User-level (~/.claude/rules/ or ~/.claude/skills/) — Applies to ALL projects
• Project-level (.claude/rules/ or .claude/skills/) — Applies to THIS repo only

Decision criteria:

Is this specific to THIS project?
├─ Yes → Project-level (.claude/)
└─ No (applies everywhere)
   └─ User-level (~/.claude/)

3. Present Findings

Report to Q in this format:

## Session Reflection

### Candidates Identified

1. **[Rule/Skill/Hook]** — [brief description]
   - Scope: [user/project]
   - Trigger: [what prompted this — correction, pattern, preference]
   - Location: [exact file path where it would go]

2. ...

### No Changes Needed
[If nothing was identified, say so — not every session produces learnings]

### Journal Entry
[If the project has .claude/journal.md, note any decisions/insights worth logging]

4. Get Approval

Wait for Q to confirm which candidates to act on. Do NOT create files without approval.

5. Execute Approved Changes

For approved items:

• Rules: Create or update the rule file with clear, concise directives
• Skills: Create or update the SKILL.md with proper frontmatter and steps
• Hooks: Propose the hook configuration for settings.json (Q adds it)
• Journal: Append entry to .claude/journal.md

6. Create Handoff

Write a brief handoff summary:

## Session Wrap-Up — [Date]

### Completed
- [x] What was accomplished

### Persisted
- [Type]: [file path] — [what was added/changed]

### Open Items
- [ ] Anything left unfinished

### Next Session
- Recommended starting point

What NOT to Persist

• Trivial observations with no behavioral impact
• One-off debugging steps
• Things already covered by existing rules
• Preferences Q has already encoded in CLAUDE.md
• Context that only matters for this session

Examples

Correction → Rule: Q said "don't use WebSearch, use mgrep" → Already a rule in ~/.claude/rules/search.md. But if it weren't, this is exactly the kind of thing that becomes a user-level rule.

Repeated workflow → Skill: Ran 8 review agents, collected reports, synthesized → Already the review-to-disk skill. If it weren't, this is a skill candidate.

Project convention → Project rule: "This project uses Commander.js with lazy-loaded commands" → .claude/rules/cli-patterns.md in the project.

No findings:

## Session Reflection

No new skills, rules, or hooks identified. The session was straightforward
and existing configuration handled everything well.

### Journal Entry
Logged architecture decision about lazy-loading to .claude/journal.md.