/afk

name: afk
description: Works through a project while you're away, finding improvements and new ideas, building the best of them on a local branch and leaving a report for when you're back.
disable-model-invocation: true

AFK

This skill spends the time you're gone making one project better. It gathers evidence, generates ideas widely, builds the best of them on a local branch and leaves a report you can read in two minutes.

Reviewing an interface is `better-interface`, reviewing a diff is `interface-review`, exploring alternatives for one component is `variant` and stress testing one is `break`.

Hours of wide exploration

A run is meant to last hours. A run that ends after three commits and twenty minutes wasted the time the person left for it. When a batch is built and has survived **Try to reject it**, take the next idea from the list. When the list runs dry, return to **Gather evidence** for a part of the project not yet read.

This is exploration, so go wide before going deep. Read every area of the product, from its busiest pages to its settings, docs and tooling. Ideas clustered around one page or one file mean the exploration stopped early. Polishing one change past good enough costs breadth, so move on. Proving a change broke nothing is not polish, and no change skips it.

A request that names a focus changes what wide means. Given one page, one feature or a piece of work in progress, explore every angle of it and leave the rest of the product alone.

Stop only when the person's stated return time arrives or every area has been read and no evidenced idea that fits a small diff is left.

Better for the people who use it

Every idea answers one question: would someone using this product genuinely find it better? Name that person and the moment it helps them, such as a reader landing on a dead link or a visitor hunting for a post. An idea that only makes the code tidier or the agent look busy fails the test.

Rank what passes by its evidence of need. Real traffic landing on a 404 counts, and so does an error in production. So does a promise the product's copy doesn't keep, or a fix the person already shipped in a sibling project. A cost every visitor pays counts too, such as code a page ships and never runs. An idea with no evidence can still be built, but it loses every tie and its diff stays small.

Sometimes out of the box

Most nights the strongest ideas are fixes and polish. Some nights one idea should be unexpected. It might be a feature the product's own content makes possible, a new way to browse it or a tool that changes how the person works. Build one when it passes the test above and fits in a small diff. Otherwise it goes in the report with the reasoning that makes it worth trying.

A list with only safe fixes means the generating step was cut short.

Match the repository

A change should read as if the person wrote it. Before building anything, find how the repository already solves the nearest problem and copy that:

• Reuse its components, hooks and utilities. A new primitive needs a reason the existing ones can't cover.
• Use its design tokens for color, spacing, radius, type and motion. Take values from the nearest existing surface and invent none.
• Follow its file layout, naming, import style and the rules in its agent docs, including when to write comments.
• Write interface copy in the voice the product already uses, at its length and with its punctuation.
• Keep its architecture. A new state library, styling approach or data layer is an idea for the report, never something to build unattended.

When a sibling project solved the same problem, port that solution and restyle it with this repository's tokens.

Stay reversible

The person comes back to choices, not to cleanup:

• Work on a new branch named `afk/<date>` from the default branch. When the working tree holds uncommitted work, build in a separate `git worktree` and leave that work exactly as it was.
• Commit locally, one change per commit, in the repository's own commit style. Each commit applies to the default branch on its own, or the report names the commit it needs.
• Push, open pull requests, merge, deploy, post and send messages only when this request asked for it.
• Treat connected services as read-only. Read analytics, error trackers and deploy logs, and change no settings, data or integrations.
• Leave the person's own writing in their voice. Draft new copy, changelog entries or posts in the report rather than editing published prose.
• Add a dependency only when a sibling project already uses it for the same job, and name it in the report.
• Snapshot any file a test run writes to, and restore it from the snapshot afterwards.

Notes that outlive the conversation

A run of hours outlives its context, and a run that stops early should still leave something. Keep the run's notes in `.afk/<date>.md` at the root of the person's checkout. They hold every idea with its evidence and status. They also hold each decision made for the person. List `.afk/` in `.git/info/exclude` so the notes never reach a commit. Update the file after every step and write the report from it.

1. Check the tools before they leave

Find the project's dev and check commands, then use each thing the run depends on once. Start the dev server, run the checks, open a page in the browser and call each connected service. A tool that fails or waits for approval now will do the same at 3am with nobody there. Say in one message what is missing and what the run will do without it, then carry on without waiting for an answer. Done when every tool has answered or been named as missing.

2. Learn the project

Read `AGENTS.md` or `CLAUDE.md`, the README, the recent git log, open branches and pull requests and any saved memory about the person. Note the conventions they enforce, such as commit format, comment rules and component patterns. Read the CI configuration as well, since every check it runs is one