michaelshimeles/skills: Six Agent Skills and an AGENTS.md Workflow for Claude Code, Cursor, and Codex

The delivery gap these skills try to close

Coding agents write code quickly and describe it badly. A PR arrives with a confident paragraph explaining that the button now works, and the reviewer has to take that on faith. The collection in michaelshimeles/skills attacks that gap from several angles at once: a skill that records the agent driving the app and burns timestamped annotations into a video, a skill that generates a before/after image table for the PR body, and a skill that keeps pushing until a review bot stops complaining. The audience is narrow and specific. It is a team already using Claude Code, Cursor, or Codex on a shared repository, already reviewing on GitHub, GitLab, or Perforce, and already willing to let an agent open and update pull requests. Solo developers working on one branch at a time will find the worktree skill and the scope-check machinery heavier than the problem it solves. The README's own framing is a four-beat workflow: isolate, build, prove, ship. That ordering is the actual product. The individual SKILL.md files are the parts.

How a skill folder gets loaded, and what AGENTS.md adds

Each skill is a directory containing a SKILL.md with frontmatter for name and description. According to the README, Claude loads the instructions on demand when the task matches the description, and you can also call one explicitly with a slash command such as /code-structure or /evidence-driven-testing. That is the whole loading mechanism: no daemon, no plugin registry, no build step. The interesting design decision sits in the unslop skill, which is vendored from cursor/plugins and modified in two places. The maintainer dropped the disable-model-invocation: true line and rewrote the description to name the trigger (text you write or edit for a human reader) instead of upstream's blanket "any writing. Must always apply." The README states plainly that you can restore the flag if you want slash-command-only behaviour. That is a deliberate trade: auto-invocation on a narrower scope versus a skill that fires on everything. AGENTS.md is the other half. It is a template you drop into a repo and fill in with repo-specific callouts for checks, invariants, and environment. Without those filled in, the workflow has no teeth, because the agent has no idea what your test command is.

The evidence recorder is the most concrete piece

evidence-driven-testing ships a Python script, scripts/evidence.py, that runs on Python 3 and FFmpeg and exposes four commands: doctor, start, annotate, stop. The agent drives the app live through computer use, or through cua-driver when the harness has no computer-use tools, while the recorder captures the session. Each annotation is timestamped as the agent tests, then burned into evidence.mp4 when the recorder stops, and summarized into a generated report.md and manifest.json. The raw capture format is MPEG-TS, which the README calls out for a real reason: a crashed or hard-killed recorder still leaves usable footage. That is a sensible choice for a tool whose job is capturing a failure. The doctor command reports on both FFmpeg capabilities and the capture source, and the constraints are worth reading before you install anything. You need ffmpeg and ffprobe built with libx264 and the ass filter. On Linux you need X11 via DISPLAY or wlroots Wayland via wf-recorder, and the README states that GNOME and KDE are not supported. macOS needs Screen Recording permission. Windows needs any standard ffmpeg. Headless environments swap the recorder for scripted screenshots and Playwright captures, and non-UI changes are expected to produce measured numbers, output pairs, or transcript excerpts instead of video. A smoke test exists: python3 -m pytest tests/ -q runs tests/test_evidence.py against a synthetic video source.

The Greptile loop and its file-count escape hatch

greploop is vendored from greptileai/skills under MIT and iterates on a PR, MR, or shelved changelist until Greptile returns 5/5 confidence with zero unresolved comments. It triggers the review, fixes actionable comments, resolves threads, pushes, and repeats up to --max-iterations cycles, default 10. It requires Greptile installed on the repo and an authenticated gh, glab, or p4 CLI depending on your host. The sibling skill, greploop-apps, exists because of one specific failure: Greptile's plain @greptile mention refuses to review very large PRs with a "Too many files changed for review" response. The apps variant triggers the review by tagging @greptile-apps instead, and when no check run appears it falls back to polling Greptile's edited summary comment. The README notes this variant is local and derived from the same upstream, with no separate repository. Two things stand out here. First, a default of ten iterations is a lot of pushes to a branch, and each cycle spends review capacity. Second, the fallback path in greploop-apps is polling a comment, which is a weaker signal than a check run. Neither is disqualifying, but you should decide your iteration ceiling before you point this at a shared repository.

Installation, and the worktree convention

Installation is a copy or symlink into a skills directory. The README gives two forms: cp -r code-structure ~/.claude/skills/ for availability in all projects, or cp -r code-structure /path/to/project/.claude/skills/ to scope it to one repository. The before-and-after skill needs its CLI first: npm i -g @vercel/before-and-after agent-browser. The new-feature skill starts each task in an isolated Git worktree branched from origin/main so several agents can work the same repository without colliding. It covers unique task naming, a scope check against open PRs, fresh dependency installs, and cleanup after merge. The README also notes harness deltas for Claude Code and Cursor, which manage worktrees themselves, meaning the instructions change depending on which agent you run. That detail matters more than it looks: a skill that tells an agent to create a worktree will conflict with a harness that has already created one, and the deltas are the mitigation.

code-structure is the most opinionated and the least verifiable

code-structure enforces a two-layer split. Actions orchestrate domain rules, described as the why and when. A service layer centralizes reusable operational mechanics, the how. The README lists the symptoms that should send you to it: multiple workflows duplicating the same operational logic, a bug fix in one flow that does not propagate to others doing the same thing, or a feature that shares mechanics with existing ones. It ships a migration checklist for extracting shared logic and a table of anti-patterns covering god services, leaky services, and over-abstraction. This is the hardest skill in the set to judge from the outside, because its output is a judgement about your codebase rather than an artifact. There is no test, no recorder, and no generated file to inspect. The anti-pattern table is the part most likely to earn its keep, since naming over-abstraction as a failure mode is a check against the layer split being applied too eagerly. Treat this one as a review prompt, not as an enforcement mechanism.

Licence mix and the maintenance you are signing up for

The collection does not carry a single licence, and the README is explicit about each folder. before-and-after is vendored from vercel-labs/before-and-after under PolyForm Shield 1.0.0, with the licence text included in the folder. greploop is vendored from greptileai/skills under MIT, licence included. greploop-apps is a local variant derived from the same MIT source. unslop is vendored from cursor/plugins under MIT, with the body matching upstream and two frontmatter edits. PolyForm Shield is not an open source licence in the usual sense, and it is not the MIT that covers the others, so if you plan to redistribute or build a product around the before-and-after skill specifically, read the text in that folder rather than assuming the repository is uniformly permissive. The repository metadata does not list a licence for the project as a whole, and no releases were retrieved, so there is no versioned artifact to pin. Upgrades mean re-copying folders, and any local edits you made to a SKILL.md will be overwritten unless you track them. The vendored skills also drift from their upstreams over time, and nothing in the material describes a sync process.

Alternatives, and where this is the wrong tool

For the visual-proof problem, the honest alternative is Playwright's own screenshot and video output driven by a short script in your CI. The difference in approach is where the capture happens. Playwright records a deterministic browser session in a pipeline, so the same commit produces the same artifact every time. This collection records an agent driving the app live, which is more flexible for exploratory flows and interactive states, and less reproducible. If your UI changes are covered by a browser test you already trust, the recorder adds a second, fuzzier source of truth. For the review loop, the alternative is simply reading the review comments yourself, or running Greptile once and acting on the output. greploop's value is unattended iteration; its cost is up to ten push cycles and a dependency on a third-party bot's confidence score as a merge gate. The wrong-tool cases are concrete. GNOME and KDE Wayland users cannot use the recorder as documented. Teams reviewing on GitLab or Perforce need glab or p4 configured, and the Greptile requirement still applies. Anyone without the gh CLI cannot post evidence to a PR. And a repository with no CI checks or invariants to write into AGENTS.md gets a workflow template with nothing to fill in.

Editorial conclusion

Adopt this if your team already reviews PRs on GitHub with Greptile installed and you want an agent to produce recorded, timestamped proof instead of prose claims about a UI change. Skip it if you are on GNOME or KDE Wayland, if your review happens on GitLab or Perforce without the matching CLI, or if you have no interest in running a review bot in a loop up to ten times per PR. Before copying anything, run python3 scripts/evidence.py doctor to confirm ffmpeg with libx264 and the ass filter plus a supported capture source, and read the PolyForm Shield 1.0.0 text in the before-and-after folder, because that licence is not the MIT that covers the other vendored skills.

Official sources

1. Issues
2. michaelshimeles/skills on GitHub
3. README