From qoq
QoQ "quality over quantity" toolkit for JavaScript/TypeScript projects. Three user-facing commands plus a `gate` other skills call. Use `review` to review the changes on a branch against a base branch (spelling & intention-revealing naming, unused dependencies, cognitive complexity / SOLID, copy-paste duplication, code conventions, modern TypeScript idioms, design-pattern smells). Use `refactor` to run that same analysis over a scope YOU choose — a path, a package, a directory, or the whole project — when there is no branch to diff. Use `bump packages` to safely update npm dependencies in stages (minor/patch first, then majors one major at a time with changelog research). Trigger whenever the user wants to "review my branch/diff/PR", check if changes are "ready to merge", "clean up / refactor / tidy / modernize" a file/folder/package/codebase, "reduce complexity", "remove dead dependencies", "de-duplicate", "fix naming", "apply our quality standards to <area>", or "update / upgrade / bump dependencies" / "get on the latest versions" — even if they don't name the command. Use `gate` (and have other skills call it) to check freshly produced code against the QoQ standards and auto-fix it before declaring a task done — a non-interactive quality gate over the working-tree changes that returns a PASS/FAIL verdict. Every suggestion is staged as a reviewable git patch and applied one at a time behind the project's own lint/test/build gate, so a bad change is easy to isolate and revert.
How this skill is triggered — by the user, by Claude, or both
Slash command
/qoq:qoq [review|refactor|bump packages|gate] [target][review|refactor|bump packages|gate] [target]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Applies the QoQ — _quality over quantity_ — standard to a JS/TS codebase: a few
Applies the QoQ — quality over quantity — standard to a JS/TS codebase: a few high-confidence, intention-revealing changes over a long list of nitpicks. Every suggestion is staged as a reviewable git patch and applied one at a time behind the project's own lint/test/build gate.
Two things are true for every command, so establish them before routing into
one. They are the shared engine that review, refactor, bump packages, and
gate all build on.
Confirm a clean working tree. Run git status. Most commands edit files
and revert them as their safety net, so a dirty tree gets tangled in that. If
there are uncommitted changes, point them out and ask the user to commit,
stash, or confirm stashing is fine before continuing. Exception: gate. It
is invoked precisely because a producer just wrote code, so its scope is the
dirty working tree — it does not demand a clean one and uses a git stash create snapshot as its safety net instead (see reference/gate.md).
Locate the QoQ engine. The linters and formatters (Prettier, ESLint,
Knip, JSCPD, Stylelint) and their --json digest are owned by one place —
reference/engine.md. Work out how qoq is invoked in
this project (a qoq:check / qoq:fix npm script, npx qoq, or a build-first
monorepo) and read its config, exactly as that file describes. Every command
that needs tool-backed findings (review, refactor) or a lint gate (all
three) defers to the engine rather than re-deriving flags or parsing raw
reports. If a project has no qoq set up at all, the engine documents the
fallback to the project's own ESLint/Knip/JSCPD/Prettier scripts.
Skipping these produces output that fights the project's own tools or corrupts the patch workflow's safety net.
These hold across all three commands; the command reference is the source of truth for everything specific.
.qoq/. Every command stages its patches, reports,
and digest under a single .qoq/ directory at the repo root, git-ignored for
the duration of the run (a labeled block each command adds to .gitignore and
reverts at the end) so its scratch files never show up in git status or trip
the Prettier gate. On a fully successful run the command removes .qoq/
entirely, leaving only the real code change; on an aborted run it leaves .qoq/
in place as the record of what's left.git apply-able patch in .qoq/ without touching the working tree; get the
user's sign-off; only then apply.git diff > <workspace>/<name>.patch, git restore to keep the tree clean,
then git apply --check to confirm it applies. A malformed patch is
regenerated, never forced.gate is the deliberate exception: it runs to completion without
interactive approval (its caller already authorized it), auto-applying only the
safe fixes and reporting the judgment calls as advisories rather than blocking.| Command | Description | Reference |
|---|---|---|
review | Review a branch's changes against a base branch and stage fixes as patches | reference/review.md |
refactor | Run the same analysis over a scope you choose (path/package/directory/whole project) | reference/refactor.md |
bump packages | Safely update npm dependencies in stages — minor/patch first, then majors one at a time | reference/bump.md |
gate | Non-interactive quality gate over a producer's just-written changes; returns PASS/FAIL | reference/gate.md |
gate is the integration entry point — the command another skill (or you,
mid-task) calls before declaring work done. It auto-fixes against the standards
and returns a verdict rather than running an interactive plan. See
Consuming /qoq from another skill.
The engine that every command reuses is documented separately and is not a
user-facing command: reference/engine.md (qoq CLI
discovery, the qoq --check --json run, and the compact digest from
scripts/summarize.mjs). The shared analysis worker the commands fan out to is
agents/qoq-analyzer.md.
review, refactor, bump, gate): load
its reference file and follow it. Everything after the command name is the
target (e.g. refactor packages/cli/src; gate src/foo.test.ts src/foo.ts;
bump packages → command bump, the word packages is just confirming the
noun). Setup has already run, so the command reference picks up from its own
first phase without re-doing the engine handoff.review; "clean up the auth module" →
refactor; "our deps are stale" → bump packages; "check the code I just
generated meets our standards" → gate — then load that reference.The command reference owns its own phases (scoping, analysis, presentation, execution, cleanup); this file owns only the shared setup, principles, and routing.
/qoq from another skill/qoq is meant to be a reusable quality gate that other skills fall back to
before they declare a task done. A producer skill — one that generates tests,
scaffolds a feature, writes a migration, applies a codegen step — should not call
itself finished until what it produced meets the project's QoQ standards. Rather
than each skill re-implementing "run the linters, fix the findings, refactor the
rough edges", it delegates that last mile to the gate command here.
The contract. A producer invokes the gate over the files it just changed and treats the verdict as a release gate:
gate command (/qoq gate <paths…>, or read
reference/gate.md and follow it) passing the explicit list
of files the producer created or edited. With no paths, gate infers its scope
from the working tree (git status + git diff).qoq --check + test/build gate, and lists the
judgment-heavy findings (dead-code deletion, de-duplication, pattern changes)
as advisories instead of forcing them.QoQ GATE — PASS or FAIL, the
fixes applied, the advisories left, and the validation result. PASS means
the scope meets the standards and validation is green; FAIL means
validation could not be made green or a hard standard is violated and couldn't
be auto-fixed.PASS, declare done (surface any advisories to
the user). On FAIL, do not declare done: address the reported blockers (or
hand them back to the user) and re-gate.Definition-of-done snippet — a producer skill adds a final step like this so the fallback is explicit:
Before declaring done: run
/qoq gate <the files you changed>and wait for its verdict. If it returnsFAIL, fix the reported blockers and re-run it. Only declare the task complete onPASS; pass along any advisories it reported.
This keeps one definition of "quality" — review's seven dimensions and the
engine — and lets every other skill borrow it without duplicating any of it.
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub ladamczyk-it/qoq --plugin qoq