Mechanises the closing routine we've been doing manually every session in the loyalty pre-launch walkthrough: update the persistent memory file + the go-live readiness proposal with today's progress, run mkdocs strict + architecture validation, commit and push the doc changes, then print a concise recap with next-session carry-over. Skill triggers on phrases like "call it a night", "save memory and docs", "wrap up", etc. when the session has been on the loyalty walkthrough. SKILL.md documents exact file paths, section templates, commit message shape, target remote (gitea), and the edge cases (TPL-016 noise from another agent's in-flight work, architecture errors blocking push, mkdocs strict failures). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5.8 KiB
name, description
| name | description |
|---|---|
| loyalty-wrap | End-of-day session wrap for the loyalty pre-launch E2E walkthrough. Use when the user says any of "call it a night", "wrap up", "save memory and docs", "let's pause for today", "end of session", or similar phrasing — and the session has been working on the loyalty Tests 1-8 (or related loyalty pre-launch fixes). Updates the persistent memory file + the go-live readiness proposal with today's progress, runs mkdocs strict + architecture validation, commits and pushes the doc changes, then prints a concise recap with next-session carry-over. |
Loyalty walkthrough — end-of-day wrap
A repeatable routine for closing out a session on the loyalty pre-launch E2E walkthrough. Every session in this thread has the same shape: do work → user says "call it a night" → record progress in two places → ship the doc changes → print a recap. This skill mechanises that.
When to invoke
Trigger phrases (non-exhaustive): "call it a night", "save memory and docs", "wrap up", "let's pause for today", "end of session", "save where we are", "goodnight let's commit".
If the user invokes this when the session has not been on the loyalty walkthrough (e.g. they were doing unrelated work), confirm before proceeding — the skill is loyalty-specific.
Files touched
| Path | Purpose |
|---|---|
~/.claude/projects/-home-samir-Documents-PycharmProjects-letzshop-product-import/memory/project_loyalty_e2e_walkthrough.md |
Persistent memory file — auto-loaded next session |
docs/proposals/loyalty-go-live-readiness.md |
In-repo proposal doc — same content but framed for the team / future readers |
Steps
1. Update memory
Edit the memory file: insert a new dated section above the line that currently reads ## Current state — paused end of day YYYY-MM-DD, and also update that line's date to today.
Section template:
## YYYY-MM-DD — <one-line headline of what got done>
### <Brief block per Test that progressed, or per bug found / fixed>
Body covering: what surfaced, root cause, commit hash + commit subject. If multiple commits, list each with `\`abc12345\` <subject>`.
### <Any investigations that didn't ship code yet>
Body covering: what was found, what's queued. Include file:line citations.
The memory file's last section heading is always ## Current state — paused end of day YYYY-MM-DD. Rename it to today's date so the file's most-recent timestamp tracks.
2. Update the proposal
Edit docs/proposals/loyalty-go-live-readiness.md: insert a new section above the ## Status board heading using a similar dated template. The proposal entries skew slightly more formal (team-readable) but cover the same factual ground. Always include:
- Tests that progressed (with status board delta)
- Commits with hashes + subjects
- Carry-over for next session
3. Verify the docs build clean
Per the user's global rule (~/.claude/CLAUDE.md): always run mkdocs after doc changes AND always run architecture validation. Run them in parallel via two run_in_background: true Bash tool calls:
mkdocs build --strict 2>&1 | tail -6
pre-commit run validate-architecture --all-files 2>&1 | tail -5
Both must pass. mkdocs failures usually mean a broken nav entry or a doc that doesn't exist; architecture warnings are OK (16 pre-existing baseline; 126 if another agent's TPL-016 work is in flight — treat as expected unless the count jumped further).
4. Commit + push
Stage ONLY docs/proposals/loyalty-go-live-readiness.md — never -A. The memory file is at ~/.claude/... and isn't part of the repo (don't try to add it).
Commit message template:
docs(loyalty): record YYYY-MM-DD <one-line headline>
<2-4 sentence body covering the day's work — Tests progressed, bugs
fixed with commit hashes, investigations/scopes recorded, what's
carrying over to next session.>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Push to the gitea remote (not origin — that's the Synology backup; prod pulls from gitea):
git push gitea master
5. Recap to the user
End the turn with a tight summary:
- Today's shipped commits (
hash+ one-line subject for each) - What's complete (which Tests; which bugs are now resolved)
- The carry-over list for next session (mirrors the memory file's "Carry over" subsection)
- Sign-off: "Just say
resumetomorrow and I'll pick up at . Goodnight 🌙"
Edge cases
- Nothing shipped today (only investigation, no commits): still record the investigation in memory + proposal, still run mkdocs + architecture, but the commit message body should reflect that no code shipped, only docs.
- The other agent's
TPL-016warning count keeps climbing: this is expected — that agent is actively addressing the rule. As long as none of the new warnings are in files this session touched, ignore. - Architecture validation fails (errors, not warnings): do NOT push docs. Surface the error to the user and ask whether to fix or skip the wrap.
- mkdocs strict build fails: same — do not push, surface the failure first. Usually a broken nav reference to a deleted page or a malformed cross-link.
- Branch isn't
master: confirm with the user before pushing. The walkthrough has only ever used master. - gitea push fails (auth, network): tell the user to push manually; don't retry blindly.
What the skill explicitly does NOT do
- Does not commit code changes. The day's code commits (cooldown fixes, template edits, etc.) should already be in by the time wrap is invoked. The wrap commit is docs-only.
- Does not run the test suite. The work-in-progress commits earlier in the session would have triggered pre-commit hooks already.
- Does not update the global
~/.claude/CLAUDE.mdor other user-level files. - Does not advance the walkthrough (no test execution, no new fixes) — only records what already happened.