Write and edit project docs (README/markdown) as a glossary of principles, not a mirror of the code. Use when creating or revising a README; when a doc enumerates exact scenes, scenarios, helpers, class ids, file lists, or command/flag matrices the code already holds; when trimming narrative or changelog out of a doc; or when deduplicating overlapping docs and wiring a root doc to its sub-docs.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
A doc is a glossary: it names the moving parts, says why each exists, and carries the principles a reader can't derive by grepping. The code is the source of truth for what exists right now — the doc must never race it. Before writing any line, ask the one question that governs this skill: could the reader get this faster and more reliably by reading the code? If yes, point them at the code instead of copying it in.
Keep — a reader cannot grep their way to these:
Shed — the code or its git history already holds these, so a copy only rots:
Where you're tempted to list specifics, name the folder or the single file that owns them and send the reader there — prefer a folder over a file, a source-of-truth registry over a transcribed copy. Describe a helper module by the kind of helper it holds and the rule for what belongs in it, not its current roster. One concrete touchstone is fine to ground a principle; a full inventory is the smell. "The matchups live in the table that defines them; the ids key off the class registry" stays true after the next edit — reproducing either does not.
Every fact has exactly one canonical home; every other doc links to it. Repetition across docs is a maintenance bug — copies drift and the reader can't tell which is current. A root/global doc gets a short section plus pointers to the sub-docs. When two docs explain the same thing, pick the hub and cut the other to a pointer.
Docs form a tree reachable from one root/hub doc: the hub links to each sub-doc, and a sub-doc links on to any module-level doc beneath it. Navigation flows down — a reader starts at the root and follows links in, so the whole tree is reachable from there. A doc links back up to its parent, or across to a sibling, only to reuse a fact that already lives there — an app doc pointing at the hub's deployment section instead of restating it, a boundary doc naming the sibling it defers to. That is the one-home rule doing its job. What you do not add is a rote "part of X" back-link that carries no information: it's noise, and the tree is already navigable from the root without it.
When trimming an existing doc, delete on sight: enumerations of code-discoverable items, changelog and narrative, and any sentence that restates the code. Then read what survives as a stranger with no conversation history — every remaining line should be a principle, a why, or a pointer. If a line would be just as true and just as useful as a link, make it the link.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Audit or rewrite AGENTS.md so it holds only lasting principles. Run it only when the user asks for it by name; never invoke it on your own.
The English summary is being prepared. Showing the original description.
Audit the choices an implementing agent made, not its diff — a pure decision audit that traces the session's history into a choices ledger, changes no code, and never blocks an unsupervised run. Working code still embeds architecture the user never chose; surface it because future work inherits it. Use when the user wants to review the decisions the AI made on their behalf, before merging or committing AI-implemented work, when integrating a delegated subagent's pass, or when a fix "works" but might be a point fix.
The English summary is being prepared. Showing the original description.
Audit and prioritize performance work through bounded-work and forward-progress checks. Use when asked to find performance issues, investigate freezes/500s/OOMs, review retries or polling for no-progress loops, rank a performance backlog, or implement the next simple performance fixes.
The English summary is being prepared. Showing the original description.
Audit whether tests earn their maintenance cost and which suite owns each contract. Use when pruning redundant tests, investigating implementation coupling or test-only production hooks, reviewing the value of proposed coverage, or auditing an entire subsystem. Use write-tests to implement the resulting test changes.
The English summary is being prepared. Showing the original description.
Run fast, progressive experiments to map tunable parameters and their effects. Use when optimizing code, prompts, configurations, or other artifacts against a goal or benchmark, or when a long research run needs a planned hypothesis queue, focused trials, and durable findings.
The English summary is being prepared. Showing the original description.
Shoot software UI like a film. A sequence of hero shots, each a steep, oblique, extreme close-up of the interface floating in black, with a razor-thin focal plane, a slow motivated camera drift, and UI that acts on its own, hard-cut on the action, ending on one line of copy and a still logo. Use when asked for a launch video, product film, feature trailer, teaser, promo clip, hero shot, or any "cinematic" footage of an app or UI. This skill covers camera, framing, light, and edit. It is stack-agnostic.
The English summary is being prepared. Showing the original description.