claude-plugins

Twenty-one Claude Code plugins I use every day across a Python backend, a
React web app, a SwiftUI client and an ML pipeline: 36 skills, 18 subagents, 8
blocking and coaching hooks, LSP servers and monitors. One marketplace, shared
by every project instead of copied into each repo.

/plugin marketplace add kulykivska/claude-plugins
/plugin install pre-push-review@personal

That is the whole install. Everything here is plain files - Markdown skills,
Markdown subagents, shell hooks - so you can read exactly what a plugin does
before you enable it, and take one without the rest.

For lawyers and law students

You do not need to be a developer. Five plugins here cover the risks that
matter when a lawyer builds a site or a small tool with AI:

Let Claude set it up. Open Claude Code in your project folder (the desktop
app or the terminal; plugins do not load in claude.ai/code web sessions) and
paste this:

Set up the kulykivska/claude-plugins plugins for this project.
1. Check that `claude`, `git` and `python3` are available. If python3 is missing,
   skip guardrails and pre-push-review and tell me why.
2. Run `claude plugin marketplace add kulykivska/claude-plugins`.
3. Install each of these with `--scope project`:
   content@personal, brand@personal, seo@personal, research@personal,
   guardrails@personal, pre-push-review@personal.
4. Run `claude plugin list` and show me what is enabled.
5. Tell me to restart Claude Code so the plugins load, then give me three things
   to try: humanize my bio, legal-review my site text, fact-check one claim.

Starting a new site? The
legaltech-starter template
comes with these plugins already turned on, a business-card page and a
GitHub Pages deploy.

Start with the gate

pre-push-review reviews the diff you are about to push across five
dimensions, fixes what it finds, re-verifies, and only then lets the push
through. Not a report you skim - a working tree that changed.

Yesterday it caught three regressions in code written in that same session. The
one worth the price of the whole repository:

A response-size guard, added so a hostile feed could not OOM-kill a scheduled
job. It passed its tests, passed the linter, passed the type checker - and
broke every network request in the tool. Response event hooks on an async
httpx client are awaited; the guard was a plain function, so each request died
with TypeError: object NoneType can't be used in 'await' expression. The
tests called the guard directly and never a client, so 108 of them passed
over a tool that could not fetch anything.

The other two: a database write lock held across every network call in a batch,
and a cache file written from several threads without a lock. All three fixed
before the push, each with a test that fails without the fix.

The gate is deliberately hard to skip. It writes a one-shot marker naming the
exact commit it reviewed, and a push without that marker is refused - so
amending after a review means reviewing again.

What else is in here

Highlights; the full table is further down.

• guardrails - blocking hooks that veto destroying Fly apps, machines or
  volumes, scaling a Fly app to zero, clearing its configuration,
  DROP/TRUNCATE/unbounded DELETE through a database client (heredocs and
  -f files included), force-pushes to main in any spelling, rm -rf ~,
  kubectl delete in prod, and any commit or push carrying a real credential or
  someone's personal data. Scope and limits: guardrails/README.md.
• reviewers - four subagents that each know one stack, so a review of a
  SwiftUI diff talks about StoreKit and crashes rather than generic advice.
• sdlc - requirements to plan to implementation to QA to review, with an
  architect that designs before anyone writes code and a debugger that works
  from logs and stack traces rather than guesses.
• seo - a strategist covering technical SEO through LLM SEO: whether a page
  is citable by an AI answer, not only whether it ranks.
• coach - non-blocking nudges while you edit, which is where a reminder is
  worth something and a blocked tool call is not.
• ml - the pipeline half the reviewers cannot cover: the feature contract
  between training and serving, the multi-season gate a model change has to pass
  before it counts, and the artifact/cache steps a release actually needs.
• app-factory - one spoken idea to a submitted App Store build, including
  the two steps that stay manual because Apple requires a human.
• brand - legal-reviewer, which reads a draft before publication and
  returns clean, nuances or blocked with the offending lines rewritten.
• product-design - selling and retention design that stays honest:
  conversion reviews where every finding names the event that proves the fix,
  paywalls that preview instead of lock, return loops built on the product's
  real calendar, landing pages per audience, and microcopy without jargon. Dark
  patterns are listed as forbidden, not as options.
• ux-craft - the Apple-grade half: a motion and haptics spec with real
  spring tokens for CSS and SwiftUI, a HIG review, and a redesign
  orchestrator that always shows five or six directions and writes no product
  code before one is approved.

Taking one piece

Every plugin is a folder, and none of them depend on each other: copy one into
your own marketplace, or install only that one. Two are worth reading even if
you never install anything: pre-push-review/skills/pre-push-review/SKILL.md,
which is the whole review in about eighty lines, and
guardrails/hooks/secrets_scan.py, the credential scanner with its allowlist.

How it fits together

The picture is generated from the repository, not drawn by hand, so it cannot
drift from what is actually installed:

python3 scripts/gen_architecture.py . "PERSONAL CLAUDE CODE MARKETPLACE" \
  "ONE SOURCE OF TRUTH · EVERY PROJECT · EVERY SESSION" assets/architecture.svg
python3 scripts/render_svg.py assets/architecture.svg   # optional PNG

Interactive versions below (GitHub renders Mermaid with pan/zoom controls):

flowchart TB
    settings["~/.claude/settings.json<br/>extraKnownMarketplaces + enabledPlugins<br/>(user scope = every project)"]
    mp["personal marketplace<br/>.claude-plugin/marketplace.json"]
    settings --> mp

    subgraph workflow["Workflow skills"]
        ppr["pre-push-review<br/>fix-and-verify before push"]
        morn["morning / evening<br/>daily kickoff + wind-down"]
        sdlcS["sdlc skills:<br/>requirements · plan-task ·<br/>qa · task-review · debug"]
        flyops["fly-ops skills:<br/>deploy · fly-logs · incident"]
        mlS["ml skills:<br/>feature-change · model-eval ·<br/>ship-model"]
        appf["app-factory<br/>idea → submitted build"]
        bizS["seo-audit · social-post ·<br/>linkedin-post-writer ·<br/>humanizer · weekly-report"]
        wsS["workspace:<br/>gmail-sorter-setup · /switch"]
        pdS["product-design:<br/>conversion-review · paywall-and-pricing ·<br/>habit-loop · landing-builder · ux-copy"]
        uxS["ux-craft:<br/>delight-spec · hig-review · redesign"]
    end

    subgraph agents["Engineering subagents"]
        arch["architect<br/>(design before coding)"]
        dbg["debugger<br/>(root cause from evidence)"]
        pyr["python-reviewer<br/>(FastAPI, async, failure paths)"]
        webr["web-reviewer<br/>(React/TS, i18n, gating)"]
        swiftr["swiftui-reviewer<br/>(crashes, StoreKit, l10n)"]
        mlr["ml-reviewer<br/>(LORO gate, leakage,<br/>FEATURE_COLS sync)"]
    end

    subgraph growth["Growth & content subagents"]
        seoA["seo-strategist<br/>(keywords → LLM SEO)"]
        resA["researcher<br/>(cited, verified briefs)"]
        cwA["content-writer<br/>(LinkedIn · Threads · X · IG)"]
        rbA["report-builder<br/>(reports · decks · updates)"]
        asoA["aso-optimizer<br/>(App Store growth)"]
        gaA["growth-analyst<br/>(funnel leaks → experiment)"]
        owA["outreach-writer<br/>(pitches that get replies)"]
        fcA["fact-checker<br/>(claims verified before publishing)"]
        lrA["legal-reviewer<br/>(contract · NDA · defamation risk)"]
        crA["conversion-reviewer<br/>(ranked selling-path findings)"]
        hrA["hig-reviewer<br/>(HIG + delight checklist)"]
    end

    subgraph hooks["Hooks (automatic)"]
        guard["guardrails · BLOCKING<br/>fly destroy / DROP·TRUNCATE /<br/>force-push main / attribution /<br/>secrets+PII scan"]
        coachh["coach · non-blocking<br/>edit nudges · session banner ·<br/>failure hints · uncommitted reminder"]
        gate["pre-push gate<br/>(user-level hook, versioned in<br/>.claude/scripts/)"]
    end

    subgraph infra["Infrastructure"]
        lspP["lsp<br/>pyright · tsserver · sourcekit"]
        mon["monitors<br/>tsc-watch · dev-log errors"]
        mcpC["mcp-catalog<br/>(examples, opt-in)"]
    end

    mp --> workflow
    mp --> agents
    mp --> growth
    mp --> hooks
    mp --> infra

    sdlcS -. delegates to .-> arch
    sdlcS -. delegates to .-> dbg
    ppr -. can corroborate with .-> pyr
    ppr -. can corroborate with .-> webr
    ppr -. can corroborate with .-> swiftr
    ppr -. can corroborate with .-> mlr
    gate -- blocks git push until review --> ppr
    uxS -. audits with .-> hrA
    uxS -. audits with .-> crA
    uxS -. approved design hands off to .-> sdlcS

The task lifecycle the pieces compose into:

flowchart LR
    R["requirements"] --> P["plan-task<br/>(+ architect)"] --> I["implement<br/>(coach nudges,<br/>guardrails veto)"] --> Q["qa"] --> T["task-review<br/>(+ reviewers)"] --> G["pre-push gate →<br/>pre-push-review"] --> D["deploy<br/>(fly-ops)"] --> M["monitor<br/>(fly-logs, incident,<br/>debugger)"]
    M -. bugs feed back .-> R
    M --> A2["announce<br/>(social-post)"] --> G2["growth-analyst<br/>reads the funnel"] -.-> R

Plugins

Cross-cutting conventions

Some rules are not one plugin's business, so they are written into every plugin
that touches the relevant stage of the work.

One engineering standard for writing and for reviewing. The engineering-standards
skill holds the whole list: architecture, failure handling, security, scalability,
performance, naming, data and migrations, analytics, tests. The coding work and the
reviewers both read it, so code is written against the same standard it is marked
against. It also fixes two things about review itself: the scope is the diff plus
the files it touches in full and their direct callers and callees, with pre-existing
findings reported in their own section; and a review is one analysis pass, one fix
pass, one verification run, rather than a find-fix-rerun loop with no natural end.

Behaviour analytics ship with the feature. Whenever a feature is added or
logic that already ships changes, the same change adds the behaviour events for
it: entering the flow, finishing it, failing it, dropping out of it. The rule
appears in new-task and plan-task (the events are part of the spec and the
plan), in architect (the design names them), in qa (the events are verified
to arrive, not just to exist in code), and in task-review, pre-push-review
and the three code reviewers, where a new flow that reports nothing is a
finding. Events reuse the project's existing taxonomy, describe mechanics the
product actually has, and never fail the flow they measure.

How I run it

~/.claude/settings.json:

{
  "extraKnownMarketplaces": {
    "personal": { "source": { "source": "directory", "path": "<this repo's absolute path>" } }
  },
  "enabledPlugins": {
    "pre-push-review@personal": true,
    "morning@personal": true,
    "...": true
  }
}

Note: the git push gate itself stays as a user-level PreToolUse hook
(~/.claude/scripts/pre-push-gate.sh), NOT in the guardrails plugin, to avoid
double-gating in repos that register an equivalent gate of their own.

Versioned user config (.claude/)

.claude/ in this repo is the versioned copy of the machine's user-level
Claude Code config:

• .claude/settings.json: copy of ~/.claude/settings.json
• .claude/scripts/pre-push-gate.sh: the push gate, generic (every project,
  every branch, no per-project exemptions); the live copy is
  ~/.claude/scripts/pre-push-gate.sh
• .claude/scripts/statusline.sh: status line script

The repo copy is the source of truth: edit here, then sync to ~/.claude
(cp .claude/scripts/* ~/.claude/scripts/). All paths are ~-based, so on a
new machine just copy .claude/settings.json + .claude/scripts/ into
~/.claude/ and clone this repo to ~/Documents/Work/Projects/AI/claude-plugins
(or update the marketplace path if it lives elsewhere).

Validate

python3 scripts/validate.py         # every plugin manifest parses and matches the marketplace
python3 scripts/test_guardrails.py --app <your-app>  # what the blocking hooks stop, and what they must not
python3 content/skills/remove-ai-marks/service/tests/test_server_security.py  # service hardening

The second one exists because a guard that cries wolf gets turned off, and a
guard that is turned off stops nothing. It covers both halves: fly apps destroy is blocked, and a README that merely mentions it is not.

Update / extend

Edit here, bump the plugin's version, restart Claude Code (local directory
marketplace: changes are picked up on reload). New plugin: folder +
.claude-plugin/plugin.json, register in .claude-plugin/marketplace.json,
enable in ~/.claude/settings.json.