Skip to content
Boris Novichkov
ResumeGitHub ↗
ENRU
All work

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.

Active
Role
Author and maintainer
Period
Apr 2026 — present
claude — /make-better
$ /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 log months 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 — flags
/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.

install
$ /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.