← the whole session plugin/skills/work-complete-audit/SKILL.md

End-of-session self-audit and checkin. Produces a structured UX story report, status check, leverage predictions, code quality audit, and proposed memories/intents — so the person can scan what happened in seconds instead of reading a transcript.

Work Complete Audit

End-of-session self-audit that produces a structured report for the human admin. Run this after completing your work session.

1. Session Report — UX Stories

Create a quick report on your session. Provide a quick summary of the specific UX stories you aimed for with one sentence each (this is your tasks translated into UX stories specifically).

For each one use emoji to show the status of the following things (each thing needs a prefix of a separate kind of emoji with a key):

  1. Is it completed?
  2. Is it committed?
  3. Have you run the review command already on it?

For any that are non-completed, articulate the intent and the UX intent clearly and conversationally for evaluation.

Always include the repo affected in parens after each.

Example Format

When users change their password, our intent is to have it succeed normally without rate limit errors on first attempt  (repo-name)
✅ Done                                ✅ Committed                            ✅ Review Created | Not Needed

If all is completed, then add: "All done for today unless you want me to take on the following additional tasks"

2. Going Forward — Leverage Predictions

From what you saw in your work session and its intent, attempt to predict the next 3 most high leverage tasks you could complete and state them in the same UX format for approval. If none of your ideas are high leverage, skip them.

Leverage is about tangible positive impact / how long it would take you to do it roughly but accounts for:

  • Risk of breakage
  • Time for human to test
  • Actual impact on the UX for user or admin

3. Code Quality Audit

Assumptions Check

Ask yourself: did you make assumptions about the code without reading it? What it does or means? If so, flag these and propose addressing them with specifics. If not, say with emoji:

No assumptions about what code does

File Bloat Check

Did you bloat large files in an extreme way, like adding more code to a file over 1000 lines? If more than an import and consumption, propose refactoring your work in the following format:

I added 245 lines to a file already over 2000 lines, violating a core tenet of our work. If you will allow it I'll refactor X into Y then import it.

Institutional Memory Alignment Check

Did you check institutional memory (the agentic-find skill — set up, or its local grep fallback over ~/.claude/projects/*/*.jsonl and this repo's docs/git log) at least once for each substantive aspect of your work? If not, do it now on the key possible points where your understanding could have been wrong, and show the result and impact. If it surfaces a needed alignment fix, fix it.

4. UX Audit

Only run this section if you changed a user-facing UX experience.

Audit your own work for UX perfection in this session. Start by asking yourself: how was the work I did expected to change UX and for who? If many things, break into atomic units and perform on each.

Then articulate this UX in a conversational way, showing the previous and new UX with no prefixes as atomic units.

Example

Our code change impacted just one targeted UX. When a brand new user (meaning no evidence they ever been here before) lands on PATH, we aimed to make it so that they could use passkey to log in easier.

(Note the indication of the change in UX, the clear reveal as to how it could be tested and checked and validated, and the why — all in a nuanced statement.)

Then reason about any gaps in the UX your code created, and if you wanted a 10/10 experience, whether you forgot something, like an edge case. If so, articulate that with a proposal on how to fix it conversationally, directly after the atomic UX statement.

Gap Examples

For this UX, it's pretty solid. It should be experienced as a complete feature.

OR

For {specific UX flow} and is {context/constraint} this would probably feel broken, because {reason}. To fix this, we should handle A by X and B by Y. Shall I implement?

5. Review Process

Review the specific UX stories and changes you created or aimed to create from the user's perspective during this session and document it as verification assignments. Your documentation should answer the question: "How can I check your work in the browser to make sure nothing broke, in simple click-and-see steps?"

If you have a UX-assignment-generation skill installed (ux-assignment-generator, or your own equivalent), use it for the writing rules and scoring, then post the assignment wherever your setup tracks these. If you don't have one set up, write each assignment as a plain markdown file — flow, click-by-click steps, and what "still working" looks like — to the folder alignment-harness records ux-assignments prints. Either way, the person should be able to open one file or page and know exactly how to spot-check your work in a browser.

If you're logging proposals for review rather than acting solo, use how-to-submit-and-track-proposals if you have it installed, or a markdown file under alignment-harness records proposals otherwise.

6. Checkin Title Format

Prefix your checkin with a title in green text:

★ Checkin ─────────────────────────────────────

Add in the title the minimum verbatim parts of the user request to directly remind the user what the task assigned from them to you was. If multiple domains happened, capture the verbatim (memory trigger) pieces in a short list.

Example:

  • Can you fix the admin bug that's making the canonical styles not render in EXACT_PATH

7. Memory Management

Ask yourself: should new memories be created? Did you actually learn things or create things which were unclear initially but critical to understand in order to perform your work efficiently? Or create things that future agents will have to retain in order to do their work efficiently?

If so, propose specific memories that you would like to save.

8. Intent Management

Did you become clear on the intended UX in a way that was not clear in the code you managed? Did the person clarify their intent for the user (ignore admin/internal features for this) in a way that is unique and new in this session? If so, propose distinct intentions to be recorded — use the intent-db skill's local store (node <intent-db-skill-path>/intent.js create '<json>') if you have it, otherwise a markdown note under alignment-harness records intents. Skip anything already logged.

Intent Format — CORRECT vs WRONG

WRONG (too implementation-focused):

When a user visits the dashboard, the suggested next step should render immediately without visual flash. Implementation: dashboard state is computed server-side in the auth middleware...

CORRECT (UX-intent focused):

When the user lands on the dashboard, the first thing we aim to render is a prediction of the optimal next step for them, worked out from what they've already done and where they are in their journey with the product — not from an implementation detail like which flag is set.

See the intent-db skill's "Writing intents: UX-centric format" section for the full rules and more examples. The intent is about the intended UX of a user, not the implementation.

9. Skill File Proposals

If you designed specific tooling that requires agent memory during your session (rare) which agents will be unable to consume without that understanding, propose the creation of a skill file for that.