Claude Code Plugins
A plugin marketplace that puts a coding agent to work on a real repository
Two published Claude Code plugins behind one marketplace command. make-better audits an existing codebase across nine topics and applies the fixes; feature builds every change in an isolated git worktree with its own port and lands it through a pull request. Both are configurable per project.
$ /make-better# picks the oldest subsystems, reviews each across nine topics Total: 104 findings across 5 systems. - 13 bug fixes (applied automatically) - 14 DRY refactors - 11 architecture cleanups - 13 consistency fixes - 6 efficiency wins - 16 tests added - 18 doc-sync updates - 10 completeness fixes - 3 security each system on its own branch, merged back with --no-ff. nothing pushed.Output from a real run on a medium-sized monorepo, as published in the project README.
The problem
A coding agent that can edit your repository is useful and dangerous in the same breath. The useful part is obvious. The dangerous part is that a long autonomous run produces a pile of changes with no story attached — you cannot tell which edit came from which decision, and reviewing it is worse than doing the work yourself.
Both plugins are attempts at the same answer: give the agent a harness that produces a reviewable trail by construction.
make-better
One command audits an existing codebase. It discovers the project’s subsystems, records them in a registry with a last-reviewed stamp, then picks the stalest ones and reviews each across nine built-in topics — bugs, DRY, architecture, consistency, efficiency, tests, doc sync, completeness and, optionally, security. Custom topics can be added for a project’s own conventions.
The output is not a report you have to act on. Each system gets its own
implementer branch, and the agent merges the branches back into the branch you
are on with --no-ff merge commits, deleting the branches and cleaning up the
worktrees afterwards. Lint and tests run once at the end.
Nothing is ever pushed. You read git log, and either push or
git reset --hard back to where you started. That single constraint is what
makes an unattended run safe to try.
feature
The second plugin covers the other half of the loop: building something new.
Every feature or fix gets an isolated git worktree on its own branch and its own
stable port, reachable at a readable *.localhost URL. One feature can span
several repositories at once. Each iteration lands as a pull request, and a local
admin dashboard shows every live workspace — its repos, PRs and CI status, dev
server health and logs, and a one-click command to resume that conversation.
Design decisions worth naming
- Staleness, not diffs. Reviews are scheduled by how long a subsystem has gone unreviewed, so quiet corners of the codebase get attention instead of only whatever was touched last.
- Merge commits as the unit of review. One merge per subsystem keeps an
agent’s work legible in
git logmonths later. - Unattended runs must not hang. With
--yes, ambiguous decisions take the safe default where one exists, and otherwise the system is skipped and listed under “human decision needed” — a cron job that stops to ask a question is a cron job that silently does nothing.
- /make-better
- Smart defaults — usually the three stalest systems.
- /make-better 8
- Review eight systems instead.
- /make-better flutter 4
- Four systems whose names match "flutter".
- --no-discover
- Skip discovery and go straight to review.
- --rebuild
- Force a full re-discovery of the subsystem registry first.
- --yes
- Unattended — no plan mode, no prompts, runs to completion.
The full surface is four flags and an optional subsystem filter.
$ /plugin marketplace add fivol/claude-make-better$ /plugin install make-better@make-better$ /plugin install feature@make-better▋Add the marketplace once, then install either plugin.