Session closer

Skill fbsmna-coder/karpathy-pro-max/skills/session-closer

Stop Claude Code from hallucinating — Karpathy-grade discipline in 8 skills

Install

npx -y skills add fbsmna-coder/karpathy-pro-max --skill session-closer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

End every work session with an honest status report — what shipped, what didn't, what's blocked. Use at the end of any non-trivial work session to prevent silent loss of context, false claims of completion, and undocumented blockers.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.3 KB, as published. Nobody here has run it

Session Closer

Sessions end. Context is lost. The user comes back tomorrow and asks "where were we?" — and if the agent did not leave an honest status, the answer is reconstructed from chat scrollback and is usually wrong.

This skill enforces a structured end-of-session report that tells the truth.

When to apply

End of any session where ≥1 file was edited or ≥1 non-trivial decision was made.
Before context is cleared / compacted.
When the user says "stop," "let's wrap up," "сессия завершена," or similar.
When you hit a blocker and cannot proceed without input.

The report format

Use this structure exactly. The headers matter — they make the report scannable on return.

## Session Close — YYYY-MM-DD HH:MM

### Shipped
- <thing 1>: <verification — test passed, deployed to X, screenshot at Y>
- <thing 2>: ...

### Not Shipped (started but not done)
- <thing>: <where it stands, what's left, file paths>

### Blocked
- <thing>: <what's needed to unblock — credential, decision, external response>

### Unclear / Open Questions
- <question that came up that you did not resolve>

### Files Changed
- path/to/file.py — <one-line summary of change>
- path/to/other.md — <...>

### Next Session — Recommended First Action
<one specific thing to start with, with enough context that future-you doesn't need to re-derive it>

Anti-sugarcoating rules

These are non-negotiable. Violating them is the most common failure of session-end reports.

Do not claim completion for partial work. "Mostly done, just needs testing" goes in Not Shipped, not Shipped.
Do not omit the Blocked section because it's empty for you. If you hit a blocker, name it. The user needs to know so they can unblock.
Do not phrase failures as victories. "Discovered that the API doesn't support X" is a finding, not a deliverable. List it under Unclear / Open Questions or Blocked.
Do not list aspirational tasks under Shipped. Only what is verified done.
No "I'll do X next session" promises. Recommend a first action; do not commit to a future state.

Persist the report

If the project uses a sessions log (sessions.md, daily/YYYY-MM-DD.md, etc.), append the report to it. Do not just emit it as chat output that scrolls away.

If no sessions log exists, ask the user once: "Should I start a sessions.md to track these?" If yes, create it and append. If no, emit to chat and let the user decide what to keep.

Example — wrong vs. right

Wrong:

"Session complete. Implemented the user dashboard, fixed the auth bug, and started on the notification system. All good!"

Right:

## Session Close — 2026-04-15 22:30

### Shipped
- User dashboard route: deployed to staging, smoke test passed (curl /dashboard returns 200, renders 4 widgets).
- Auth bug #142: test `test_session_expiry_grace` was failing, now passes. Deployed to staging.

### Not Shipped (started but not done)
- Notification system: created skeleton in `app/notifications/`, model defined, no handlers yet, no tests. Approx 30% complete.

### Blocked
- Production deploy of dashboard: waiting on DNS change for `dashboard.example.com` (asked DevOps 2h ago, no response).

### Unclear / Open Questions
- Notification preferences: should they be per-channel or global? Current skeleton assumes global; user mentioned per-channel earlier — needs decision.

### Files Changed
- app/routes/dashboard.py — new route
- app/auth/session.py — fixed grace period off-by-one
- app/notifications/__init__.py, models.py — new skeleton
- tests/test_session.py — added regression test

### Next Session — Recommended First Action
Decide notification preference scope (per-channel vs global), then continue notification handlers. Skeleton is in `app/notifications/`, model has placeholders for both options.

Why this matters

Without honest session reports, context erodes. The user trusts that "shipped" things shipped. They build on top of partial work that the agent claimed was done. The bug is found in production. Trust collapses. Fix the report, fix the trust.