critique

agent-skills

Skills I wrote and use, in the open Agent Skills format: a folder with a SKILL.md that any compatible agent can load.

How the repo and its eval harness fit together: ARCHITECTURE.md.

guided-tour

Gets a person up to speed on an unfamiliar product or console. Not a video, not a docs page: the actual product, with someone riding along.

Most agent tooling is built to finish a task alone. This one is built to stop.

A person learns a UI by touching it, so the tour is a loop of point, explain, try it, wait:

• One stop per turn. Each stop names the control, says what real job it does, gives one small read-only task, and ends the turn. The user explores and asks questions for as long as they like.
• A spotlight, not a screenshot. scripts/spotlight.js outlines the control and tags it with the stop number. It reaches into same-origin iframes and open shadow roots, restores the page's own styles when cleared, and never clicks or types.
• The agent points, the user acts. Anything that creates, changes, deletes, sends or costs money is the user's click, after the agent has said what it does and what it bills. Sign-in, consent screens and cookie banners are always theirs.
• Live page over docs, docs over memory. Admin consoles get redesigned often, so the outline is checked against the vendor's current docs and then against what is on screen.
• Somewhere safe to practise. references/practice-environments.md lists where to find a safe sandbox for each kind of tool, and tells the agent to quote the vendor's current terms instead of recalling them.

It needs an agent with browser tools that can read the open page and run JavaScript in it.

claude-tui-study-buddy

guided-tour for the terminal. The same idea, a different surface: the agent stops and the user does the work.

• The user types every command. In Claude Code a line starting with ! runs in the session's shell, so the agent sees the output without running anything itself.
• Goals, not commands. Each task says what to make happen. Hints climb a ladder: which tool, then which flag, then the full command only when asked for.
• Two safety lines, agreed first. A real service or repository used as the practice subject is read-only. Anything that changes state happens in a throwaway folder.
• A quiz from memory, graded honestly. One question per turn, no leading, and a confident wrong answer is wrong.
• A rating that rests on the record. The agent keeps a tally of what was done unaided, hinted or shown, and recommends a self-rating from that: not inflated, not undersold. The result is appended to the study guide.

It needs a terminal agent where the user can run a command inside the session and the output lands in the conversation.

todo-list

One page holds the lists. The user edits it by hand; the agent edits the same data from chat ("put sponges on my hardware store list", "I'm out of milk"). The page redraws live either way.

• The agent writes data, never the page. Changes go through the page's database, so nothing the user typed on the page is ever overwritten by a republish.
• Every change is undoable. scripts/writes.py builds each write together with its history entry, and each delete with a snapshot, so the page's Restore button works for the agent's changes too. Writes are pinned to the version that was read, so an edit made on the page a second earlier is not lost.
• It asks when it should and acts when it can. A list that plainly does not exist gets made. A name that might mean an existing list ("home depot" when there is a "Hardware" list) gets a question. An item never lands on a list the user did not name.
• No duplicates. Asking for something already on the list says so. Asking for something already checked off unchecks it.
• Due dates with real reminders. An item can have a due date, set from chat or by tapping it on the page; the page shows it and marks it overdue. The page cannot notify anyone, so the reminder is a calendar event with pop-ups a day and an hour before. The page makes that event itself, through the viewer's own Google Calendar connector, the moment a date is set, moved or removed on it; the agent does the same for changes made from chat. scripts/reminders.py compares the items with their events and prints the calendar calls that are missing, which is how a date changed on the page gets its reminder moved the next time the agent reads the list.

It needs Claude's Artifact tools, which host the page and its database.

sum and critique

Both are small on purpose. What they add over a capable agent with no skill is consistency: the same shape and the same rules every time.

sum writes for a reader that starts cold and takes every line as fact. Its rules are the ones that bite in practice: report what was observed ("14 passed, 1 failed, not re-run" instead of "tests pass"), carry every loose end including the ones that were not this session's focus, keep conditions attached to their steps, use absolute dates, and keep secrets out.

critique asks for evidence behind every finding (a quote or a file and line), scales to what happened so a clean session gets a short answer, and reports without fixing: the user decides what is worth acting on.

Using them together

I use the pair to move to a fresh session when the context window fills up:

1. /critique while the whole session is still in view. The agent reviews its own work and proposes fixes and rules.
2. "Yes, fix it." The fixes land in this session, where the agent still has the context to make them.
3. /sum once the work is in its best state. The handoff describes the fixed version, not the flawed one. It comes back as a single code block.
4. Copy the block with the code block's copy button.
5. New session. Paste it as the first message and carry on.

The order matters. A summary written before the critique hands the next session problems it has no context to find.

Evals

sum and critique each ship with three recorded sessions in skills/<name>/evals/: a transcript, the project folder that session was working in, and a list of plain-language expectations. todo-list ships with six seeded databases and is run against a local stand-in for the Artifact tools ([scripts/mock_artifacts.py](