b4r7x

@b4r7x source repo

58 skills
0 followers
9 hours ago last updated

▌
Nuke Think · b4r7x bundle
Use when a task needs unusually deep or careful reasoning — hard architecture decisions, root-cause analysis, ambiguous trade-offs, adjudicating conflicting findings, high-stakes irreversible choices — especially when running on a mid-tier model or as a judgment role (skeptic, spec-architect, reconciler) inside another nuke skill.

0
installs
▌
Nuke Voice · b4r7x bundle
Use when the session's prose should read like a senior engineer's writing — "nuke voice", "talk like fable", "stop sounding like an AI", "write normally" — or when output keeps failing in either direction: filler openers, restated asks, follow-up offers, narrated tool calls (too chatty), or arrow-chain telegraphese and invented codenames (over-compressed). A standing discipline until revoked, especially for models below the frontier tier. Governs how prose READS; nuke-crisp sizes answers and nuke-quiet governs hand-backs — voice stacks with both.

0
installs
▌
Nuke Design · b4r7x bundle
Use when a UI must not just pass its checklist but actually look designed — building any landing, marketing page, or visual surface after a direction is chosen, or judging a render that "passes every gate but looks generated" — "this looks AI-generated", "make it actually beautiful", a post-build design review, or any moment a score above 6/10 is about to be given to a render nobody screenshotted. Also loadable as a charter by implementer roles in nuke-creative/nuke-code/nuke-exec (build half) and by fresh critics (verification half). Triggers: "nuke design", "anti-slop design", "design pass".

0
installs
▌
Nuke Prompt · b4r7x bundle
Use when a prompt must be engineered, not improvised — "nuke prompt", "write a system prompt for…", "harden this prompt", "my agent ignores its instructions" — compiling a rough prompt idea or a misbehaving existing prompt into a production one, proven by a breaker wave before hand-off.

0
installs
▌
Nuke Review · b4r7x bundle
Use when the user wants a thorough review of a diff, branch, PR, or staged changes — "nuke review", "review this branch/PR", "review my changes" — heavier than a glance, cheaper than a full audit.

0
installs
▌
Nuke Sprint · b4r7x bundle
Use when a small task should run the whole pipeline in miniature, in one session — research (reuse first) → plan, gated by default → build → fresh review → fix — "nuke sprint", "small, but do it properly", "plan first, show me, then build", "quick task, full review". Single deliverable up to ~5 files / ~300 lines; no lower bound — invoking sprint IS the opt-in, even for a tiny change. The deliberate inverse of nuke-blitz: blitz's default is GO, sprint's default is STOP at the plan. Not for un-invoked everyday work (the constitution routes that to nuke-code) or multi-deliverable asks (nuke-spec → nuke-exec).

0
installs
▌
Nuke Verify · b4r7x bundle
Use when an implementation produced by another agent, a cheaper model, or a colleague needs verification against its spec/task/plan — "nuke verify", "verify this implementation", "check what the agent built" — and should be fixed until clean, not just reviewed.

0
installs
▌
Nuke Release · b4r7x bundle
Use when a repo, package, or plugin is about to be shipped to users — "nuke release", "is this ready to publish", "release check", "can I ship this" — verifying the things users hit first: docs that tell the truth, install paths that work, versions that agree, a build that passes from a clean checkout, nothing embarrassing in the artifact. Verdict-first, read-only.

0
installs
▌
Nuke Creative · b4r7x bundle
Use when UI work should look designed, not generated — "make it beautiful", "awwwards level", "distinctive", "premium", a landing page, hero, marketing site, portfolio, or any interface where visual quality is part of the ask — or when generated UI keeps arriving as the same centered hero, gradient-on-dark, glass cards, and default fonts. Also loadable as a charter by implementer roles touching UI files inside other nuke skills.

0
installs
▌
Nuke Code · b4r7x bundle
Use when implementing anything beyond trivial — more than one file, more than ~30 changed lines, or any change to a public API, dependency, schema, or behavior contract. THINK (done-criteria + ≥2 shapes) → BUILD (house-idiom charter) → SHIP (fresh validator + gates before "done"). Engaged automatically by the nuke constitution; "nuke code" forces it.

0
installs
▌
Nuke Deps · b4r7x bundle
Use when dependencies need a planned audit or upgrade — "nuke deps", "update dependencies", "are our deps safe/outdated", "upgrade to v5" — vulnerable, outdated, unused, or duplicated packages, upgraded in gated waves with majors isolated one at a time, never a blind bulk bump.

0
installs
▌
Nuke Docs · b4r7x bundle
Use when documentation must be checked against reality and repaired — "nuke docs", "is the README still true", "fix the docs", "docs drift" — README, docs/, setup guides, API examples. Every testable claim is verified by executing or tracing it; drifted docs are fixed, lying code is reported, never silently papered over.

0
installs
▌
Nuke Eval · b4r7x bundle
Use when a prompt, system prompt, agent instruction, or LLM-app behavior changes and must be proven, not vibed — "nuke eval", "eval this prompt", "did my prompt change help", "add evals" — or when a repo ships prompts with no eval harness at all. No prompt change is "done" without an eval run; evals themselves are proven by perturbation.

0
installs
▌
Nuke Exec · b4r7x bundle
Use when work should be executed by delegated subagents — a spec produced by nuke-audit, nuke-review, nuke-spec, or nuke-verify ("nuke exec", "execute the fix spec", "nuke fix" — its former name), or a clear task stated inline without a spec ("implement this with agents", "build this cheaply" — formerly nuke-implement). Spec in → phased execution; task in → contract first, then a single-phase execution. For the session's own hands, nuke-code applies; for judging finished work, nuke-verify.

0
installs
▌
Nuke Lean · b4r7x bundle
Use when implementation should take the shortest sound path — "no overengineering", "keep it simple", "just do what's needed", "stop gold-plating" — when generated code keeps growing guards, wrappers, options, or refactors nobody asked for, or when a diff needs desloping before hand-off ("nuke sweep", "deslop this", "clean up the diff" — the former nuke-sweep). Governs the design and the diff, NEVER the process: it removes speculation from code, not agents, workflows, or ceremonies from the ask. Also loadable as a charter by implementer roles inside other nuke skills.

0
installs
▌
Nuke Perf · b4r7x bundle
Use when something is slow, expensive, or claimed to need optimization — "nuke perf", "why is this slow", "optimize this", "make it faster" — and the change must be proven by measurement, not narrated. No optimization without a baseline number; no success claim without before/after from the same harness.

0
installs
▌
Nuke Plan · b4r7x bundle
Use when the user wants a plan they will implement THEMSELVES, ticket by ticket, in fresh sessions with cheaper or local models — "nuke plan", "plan this for me to build", "write me the tickets", "JIRA-style plan", "I'll implement it myself" — a human-readable plan folder written through an interview, handed to a second-vendor critic by hand, and closed by a verification handoff the user runs in an independent session; never executed by agents. NOT for delegated execution (nuke-spec → nuke-exec) and not for a change the session builds itself (nuke-sprint / nuke-blitz).

0
installs
▌
Nuke Spec · b4r7x bundle
Use when turning a feature request, requirement, or rough idea into an implementation-ready, self-contained spec — "nuke spec", "spec this feature", "prepare a spec for the implementer" — before handing the work to nuke-exec, a cheaper model, or another agent.

0
installs
▌
Nuke Test · b4r7x bundle
Use when a scope, change, or module needs tests designed and written — "nuke test", "write tests for this", "cover this with tests" — especially when the tests must be proven to catch real bugs, not just raise coverage numbers.

0
installs
▌
Nuke Audit · b4r7x bundle
Use when the user wants a deep multi-agent quality audit of a codebase or scope — "nuke audit", "deep audit", "full quality audit", "audit everything", "make it all SOTA". Produces a findings ledger and a phased fix spec; never edits source.

0
installs
▌
Nuke Blitz · b4r7x bundle
Use when the user wants pipeline-grade quality at conversation speed — "nuke blitz", "quick but solid", "fast: plan and go" — on a single deliverable that outgrew nuke-code's everyday scale (>~5 files or >~300 lines) but does not warrant spec → exec → verify. One session, one pass: contract → snap plan → immediate build → one fresh validator. Not for multi-deliverable asks (nuke-spec), assessment-only asks (nuke-review / nuke-audit), work meant for delegated waves (nuke-exec), or a small task the user wants gated on its plan (nuke-sprint — blitz goes, sprint stops).

0
installs
▌
Nuke Crisp · b4r7x bundle
Use when an answer, assessment, or judgment call is growing past what the question needs — option menus nobody asked for, "reach for X if" tails, hedging walls, background essays around a one-line verdict — or when the user says "just answer", "quick take", "don't overthink this", "which one, yes or no", "short answer". The inverse of nuke-think: it sizes reasoning down; think sizes it up.

0
installs
▌
Nuke Debug · b4r7x bundle
Use when hunting a bug, regression, failing test, flaky behavior, or unexplained output that needs root-cause analysis rather than a quick patch — "nuke debug", "find why this fails", "debug this properly".

0
installs
▌
Nuke Pilot · b4r7x bundle
Use when the user wants quality work done but has not named which ceremony — "nuke pilot", "where do I start", "make this repo good", "help me plan the cleanup", "what should I run", a broad improvement ask with no named dimension — or to resume a multi-stage itinerary started earlier. An interactive conductor: interviews the user one decision at a time, bootstraps the repo, emits an ordered itinerary of nuke commands, and drives the stage transitions. Composes ceremonies; never replaces them. NOT for a task whose ceremony is obvious (invoke it directly — the constitution routes everyday work on its own).

0
installs
▌
Nuke Quiet · b4r7x bundle
Use when the user wants work done with little or no commentary. Two grades: quiet — "no talk", "quiet", "just do it", "stop narrating" — a fixed hand-back contract and silence in between; silent — "nuke silent", "silent mode", "zero talk", "don't say anything, just do it" — the ONLY text of the whole task is the final verdict line plus the file list. Engaged for the whole session until revoked. Failures and dropped scope still get their line in both grades — honesty is never silenced.

0
installs
▌
Nuke Recon · b4r7x bundle
Use when a repo needs mapping before real work — "nuke recon", "map this repo", "get familiar with the codebase", first session in an unfamiliar project — or when other nuke skills keep re-scanning because .nuke/repo-map.md is missing or stale. Builds the shared repo map once; every ceremony consumes it for free afterwards.

0
installs
▌
Nuke Split · b4r7x bundle
Use when a spec's tasks are too big for the agents that will execute them — "nuke split", "these tasks are too large", a fix-spec whose batches overflow cheap workers, a task touching a 3000-line file — re-cutting phases, batches, and tasks to a per-tier size budget while preserving acceptance criteria and the coverage map. Never executes anything.

0
installs
▌
React Useref · b4r7x
Use when deciding between useRef and useState, implementing DOM access, storing mutable values between renders, or integrating external libraries. Covers the 4 valid cases and the useEffectEvent replacement.

0
installs
▌
Anti Slop Fix · b4r7x
Runs the anti-slop audit on source code files and automatically applies fixes for detected issues. Invokes the anti-slop analysis first, then fixes each issue in-place. Use when the user wants to clean up AI slop automatically, fix slop patterns, or asks "fix slop", "auto-fix slop", "anti-slop fix". NOT when the user only wants the report (anti-slop) and not for whole-repo remediation from an audit's findings — that is a fix-plan execution, not a slop sweep.

0
installs
▌
Audit Toolkit · b4r7x
Use when you want to audit, review, harden, ship, or remediate a codebase but are not sure which audit/review/fix skill to reach for — the single index and decision-router for the whole audit-and-fix toolkit. Triggers include "audit this", "review the codebase", "is this ready", "what audit should I run", "harden this", "find issues and fix them", "release readiness", "deep quality review", or any broad ask to assess or improve an existing project's quality, security, docs, or shippability.

0
installs
▌
React Usememo · b4r7x
Use when writing or reviewing useMemo usage in React components. Covers the 4 valid cases, when to skip it, and the practical heuristic for deciding.

0
installs
▌
Release Audit · b4r7x
Use when someone asks "is this ready to ship?", "can we release?", "pre-release check", "go/no-go", "release readiness", "ship-blockers", or wants a single readiness scorecard before tagging a version, publishing a package, deploying an app, or making a repo public — and does not want to pick individual audit skills themselves. Triggers on release gate, launch checklist, publish audit, readiness review for any repo, monorepo, library, CLI, docs site, or service.

0
installs
▌
Improve Prompt · b4r7x bundle
Transforms a rough, unpolished prompt idea into a precise, structured AI coding prompt. Automatically researches the current project context (stack, file structure, conventions, git history) before generating. This skill should be used when the user provides a vague or "dirty" prompt idea and asks to refine, improve, or rewrite it — e.g. "improve this prompt", "refine my prompt", or simply describes what they want done in rough terms. NOT when the user wants the work done or planned rather than the prompt itself — deep-plan produces the plan; just doing the task needs no prompt skill.

0
installs
▌
Sota Structure · b4r7x bundle
SOTA Structure

0
installs
▌
Humanize Readme · b4r7x bundle
Rewrites a README.md to remove AI slop — buzzwords, generic openers, fake enthusiasm, and formulaic structure — replacing it with direct, honest, human-sounding writing. This skill should be used when the user wants to humanize a README, remove AI-generated writing patterns, make documentation sound less like ChatGPT wrote it, or asks to "humanize readme", "make it sound human", "remove AI slop from the docs". NOT for factual drift (whether the README's claims are still true — that is a docs-accuracy audit) and not for source code slop (anti-slop).

0
installs
▌
React Useeffect · b4r7x
Use when writing, reviewing, or debugging useEffect in React. Covers the 6 valid use cases, 7 anti-patterns, dependency pitfalls, and the decision tree for whether you actually need an effect.

0
installs
▌
Convergence Loop · b4r7x
Use when orchestrating a large multi-agent audit, review, sweep, or migration that must converge rather than finish in one pass — whole-repo quality audits, release or handoff readiness checks, security surface audits, jargon sweeps, docs reviews, or any long subagent fan-out at risk of usage limits, crashes, or lost context mid-run. Triggers include "run to convergence", "multi-round audit", "resumable audit", "batch the auditors", "keep auditing until dry".

0
installs
▌
React Usecontext · b4r7x
Use when working with React Context — deciding whether to use it, optimizing context value to prevent re-renders, or implementing compound components. Covers context value memoization, alternatives, and the compound components pattern.

0
installs
▌
Handoff Readiness · b4r7x
Use when judging whether a publishable or reusable artifact — npm package, library, SDK, component kit, CLI binary, copy-paste/shadcn-style registry, or template — is ready to hand to real external users. Triggers include "is this publishable", "release ready", "handoff readiness", "can users actually install this", "audit package exports/types/peerDependencies", "pre-publish check", first public release, registry installability, or broken-consumer-import doubts.

0
installs
▌
React Usecallback · b4r7x
Use when writing or reviewing useCallback usage in React components. Covers React Compiler impact, when useCallback is justified, and the most common mistake (useCallback without memo).

0
installs
▌
React Senior Guide · b4r7x
Use when writing or reviewing any React code as a comprehensive reference. Routes to 9 specialized React skills covering hooks, patterns, anti-patterns, and custom-hook authoring — load the matched skill, don't just read this table. Includes cross-cutting principles and an AI code review checklist.

0
installs
▌
React Anti Patterns · b4r7x
Use when reviewing React code — especially AI-generated code — to catch common anti-patterns. Covers 18 anti-patterns with detection difficulty, including stale closures, state mutation, useEffect abuse, and boolean explosion.

0
installs
▌
React Hook Authoring · b4r7x bundle
Use when writing, reviewing, or designing custom React hooks for component libraries. Covers memoization decisions, consumer DX, controlled/uncontrolled patterns, and function stability. Prevents overengineering — start simple, add complexity only when profiler demands it. This skill should be used when building hooks that other developers will consume.

0
installs
▌
Docs Deploy Readiness · b4r7x
Use when a documentation or content site needs a pre-deploy audit — someone asks "are the docs ready to ship", requests a docs review, coverage gap check, stub/orphan page hunt, docs-vs-code accuracy verification, SEO/meta/OG/canonical/sitemap/robots/llms.txt check, 404 or search validation, or a clean-environment docs build check before going public. Any stack (SSG, SSR, MDX, static export). For the artifact being documented, use handoff-readiness instead.

0
installs
▌
Nextjs Supabase Guard · b4r7x
Use after writing or modifying code in a Next.js + Supabase project, before committing, or when reviewing such a PR — "validate the stack", "full-stack guard", "check the supabase integration". Orchestrates code-quality, react-guard, nextjs-guard, and Supabase-specific skills through a phased workflow. NOT for projects without Supabase (nextjs-guard) or without Next.js (react-guard).

0
installs
▌
React Design Patterns · b4r7x
Use when choosing a React component pattern — custom hooks, control props, compound components, headless components, render props, container/presentational, or other architectural patterns. Includes 13 patterns with decision guide and 2025 popularity ranking.

0
installs
▌
Security Surface Audit · b4r7x
Use when auditing what an existing project exposes to attackers — a loopback/localhost dev or control server, public web app or API, CLI that spawns processes, published library, static site with CI/CD deploy pipeline, or desktop-embedded server. Triggers include "security audit", "attack surface", "threat model", "is this safe to ship", DNS rebinding / CORS / CSRF / Host-header exposure questions, secrets-at-rest review, or supply-chain posture checks before release or handoff.

0
installs
▌
React Hook Authoring Fix · b4r7x
Audits custom React hooks for overengineering, memoization issues, consumer DX problems, and known antipatterns, then applies fixes. Use when the user wants to audit hooks, fix hook patterns, clean up memoization, or asks "audit hooks", "fix hooks", "check my hooks". Applies the react-hook-authoring principles.

0
installs
▌
Expo Bulletproof Structure · b4r7x
Bulletproof Expo project structure pattern for React Native apps. Enforces thin routing layer, feature-based modules, dependency direction rules, and Expo Router conventions. Use when creating files, scaffolding features, or making architectural decisions in any Expo/React Native project.

0
installs
▌
Test Behavior Not Implementation · b4r7x
Testing philosophy based on Kent C. Dodds' Testing Trophy and TkDodo's testing principles. Enforces behavior-based testing, mocking discipline, accessible queries, and the "fewer better tests" principle. Use when writing, reviewing, or auditing tests in any TypeScript/React project. Triggers on test files, test commands, or mentions of testing strategy.

0
installs
▌
Anti Slop · b4r7x bundle
Audits source code files for AI-generated slop patterns — unnecessary comments, over-engineering, defensive over-coding, AI voice markers, dead code, type workarounds, and verbose patterns. Outputs a structured report with line references and severity. Use when the user wants to find AI slop in specific files, find unnecessary comments, detect over-engineering, or asks "check for slop", "anti-slop", "review for AI patterns". NOT for whole-repo quality audits (that is code-audit's job — or audit-toolkit when unsure which audit fits) and not for prose/README style (humanize-readme).

0
installs
▌
Deep Plan · b4r7x bundle
Takes a rough, unpolished prompt idea and autonomously turns it into an implementation plan. Researches the project deeply, asks clarifying questions, generates a precise internal prompt, then executes it to produce a structured plan with todos. Designed for plan mode. Use when the user gives a vague feature request, rough idea, or "dirty" prompt and wants a ready-to-execute implementation plan — e.g. "plan this", "deep plan", "turn this into a plan". NOT for debugging an existing bug (root-cause it instead), not for a task so small the plan would be longer than the change, and not when the user only wants the refined prompt without a plan (improve-prompt).

0
installs
▌
Code Audit · b4r7x
Comprehensive codebase quality audit using parallel agents. Checks DRY, SRP, anti-slop, naming, file organization, type safety, error handling, patterns, dead code, architecture, and reusability. Produces findings report + fix plan for multi-agent execution. Use when the user wants to audit code quality, review architecture, check for smells, or says "code audit", "quality check", "review codebase". NOT for a slop-only pass on named files (anti-slop) and not when the user is unsure which audit fits (audit-toolkit routes).

0
installs
▌
Jargon Leak · b4r7x
Jargon Leak

0
installs
▌
React Guard · b4r7x
Use after writing or modifying React components (.tsx/.jsx), before committing React changes, or when reviewing a React PR — "validate the React code", "react guard", "check these components". Loads the React review skills and runs a BLOCKER/WARNING/INFO checklist over the changed files. Works standalone, no Next.js required. NOT for designing new hooks or choosing patterns — route through react-senior-guide for that.

0
installs
▌
Code Quality · b4r7x
Reference of universal code quality principles — DRY, KISS, YAGNI, SRP — with anti-pattern tables. Load it as the quality bar ALONGSIDE a review, audit, or guard (code-audit, react-guard, and the other guards load it); framework-agnostic. NOT an entry point — it has no workflow of its own, so for "audit this" reach for code-audit or audit-toolkit instead.

0
installs
▌
Human Commit · b4r7x
Generates human-like git commit messages based on staged or unstaged changes. Reads git diff, analyzes what changed, and outputs 3 natural commit message options that sound like they were written by a developer — not AI. This skill should be used when the user wants a commit message, asks "what should I write for commit", "generate commit message", "human like commit", or just asks for help committing. NOT for changelogs, release notes, or PR descriptions — it writes commit subjects only.

0
installs
▌
Nextjs Guard · b4r7x
Use after writing or modifying Next.js App Router code, before committing, or when reviewing a Next.js PR — "validate the Next.js code", "nextjs guard", "check the app router changes". Loads the Next.js skill set plus react-guard and validates routing, RSC boundaries, and data patterns. NOT for plain React without Next.js (react-guard alone) and not for the full-stack Supabase pipeline (nextjs-supabase-guard).

0
installs

58 published skills