Stoica-Mihai
UserCurated Claude Code plugin marketplace — OpenSpec extensions and autonomous development workflows
Categories
Indexed Skills (15)
opsx-exttask-queue
Use when the user wants new code written or new behavior added that naturally splits into multiple independent changes — "add X and Y and Z", "build the whole auth system", "migrate the service", or "do this task" when the scope clearly spans several discrete pieces. Orchestrates structured codebase exploration, change queue planning, isolated worktree execution per change, and spec verification. Prefer `opsx-ext:task` for single-change requests that don't need a queue or isolated worktrees. Skip for questions, explanations, bug fixes, single-line patches, console.log debugging, version bumps, and /opsx command runs.
opsx-exttask
Use when the user wants new code written or new behavior added — "add X", "build X", "implement X", "create X", "migrate X", or "do this task". Drives a single OpenSpec change end-to-end — explore, plan, self-review, implement, test, verify — as one deterministic workflow, then hands back for review and commit. Prefer `opsx-ext:task-queue` when the request clearly splits into multiple independent changes that benefit from isolated worktrees. Skip for questions, explanations, bug fixes, single-line patches, console.log debugging, version bumps, and /opsx command runs.
tdd
Test-Driven Development workflow. Use when the user asks to work test-first, says "tdd", "/tdd", "write tests first", "red green refactor", "test-driven", or explicitly wants failing tests before implementation. Also trigger when the user says "add tests for X then implement" or "start with a test". Do NOT trigger on general coding requests that don't mention test-first intent.
adversarial-testing
Design and run adversarial tests against a system — inputs chosen to break it rather than to confirm it works. Covers three layers under one method: classical software with no decidable test oracle (metamorphic relations, differential testing, coverage-guided and stateful fuzzing, mutation testing), AI and language-model systems (direct and indirect prompt injection, multi-turn escalation, agentic tool abuse, attack success rate measurement), and the tool layer that automates both (PyRIT, garak, promptfoo, DeepEval, DeepTeam). Produces a scoped test plan, a generated attack corpus, measured results against a baseline, and a triaged findings report. Slash-command only — run it with /adversarial-testing on a target you are authorized to test.
commit
Handles git commits with concise, list-style messages and no co-author trailers. Use this skill whenever the user asks to commit, says "commit", "/commit", "commit this", "save my changes", or any variation of requesting a git commit. This skill MUST be used for every commit operation — it overrides the default commit behavior.
code-audit-deep
Line-level code audit skill. Surfaces concrete, actionable findings — perf hotspots, error-handling correctness bugs, durability / ordering bugs, memory-shape problems, function-level complexity, semantic coupling, concurrency-primitive scope mistakes, and unenforced or unfalsifiable invariants (gates that cannot reach the violation, assertions that cannot fail, rules that live only in a comment) — that file-level architectural analysis cannot see. Language-agnostic. **This skill owns the word "hotspots" when the user wants line-level findings inside files** — phrasings like "what are the hotspots", "where are the hotspots in X", "find hotspots in this file", "show me the hotspots", "any hotspots in commit.rs?" all trigger this skill; prefer this over `architectural-hotspots` whenever the user is pointing at code and asking what's wrong with it, rather than asking which files in the repo are structurally suspect. Also trigger on "audit this", "review this code", "audit X", "review X", "find bugs in X", "what'
architectural-hotspots
Surfaces architectural hotspots in a codebase — high-coupling hub files, tangled high-fan-out modules, oversized god modules, and dependency cycles. Use this skill when the user asks where to refactor, which files are architecturally problematic, which modules are most tightly coupled, where the tech debt is concentrated, what should be split up, or how the dependency structure of a project looks. Also trigger on phrases like "find hotspots in this repo", "coupling problems", "god classes", "circular dependencies", "refactor candidates", or "which files do too much" — even if the user does not say the word "architecture". Do NOT trigger for runtime *performance* hotspots — "why is my app slow", "profile this", CPU/memory bottlenecks — this skill sees structure, not execution; for static perf findings use `code-audit-deep`, for real measurements suggest a profiler. This skill is **scope: whole repository**. If the user is pointing at a specific file or asking what is wrong *inside* a file ("hotspots in commit.
code-smells
Whole-repository design-smell review — detects *wrong engineering* by name: feature envy, data clumps, primitive obsession, shotgun surgery, divergent change, speculative generality, message chains, temporal coupling, flag arguments, global/mutable data, dead code, repeated switches that want to be polymorphism — every confirmed smell from the Fowler/Beck catalog and beyond, each mapped to a specific catalog refactoring (Extract Class, Move Function, Introduce Parameter Object, Replace Conditional with Polymorphism, …). Report-first; applies the approved refactorings only when invoked with `--fix`. Use whenever the user invokes /smells, says "code smells", "design smells", "bad design", "wrong engineering", "spaghetti code", "is this well engineered", "maintainability review", "why is this codebase hard to change", "what refactorings does this need", or asks for a Fowler-style review — even if they never say the word "smell". Boundaries: bug / perf / durability findings inside named files belong to `code-audi
dry-principle
Enforces DRY (Don't Repeat Yourself) thinking across all programming tasks — writing new code, reviewing code, fixing bugs, refactoring, editing config, schemas, tests, and documentation. Use this skill for ANY coding or programming-related task: feature implementation, bug fixes, code review, refactoring, writing tests, editing configuration, database schema changes, build system modifications, or documentation updates. This skill should trigger whenever Claude is about to write, modify, or review code or code-adjacent files. Even if the user doesn't mention "DRY" or "duplication", this skill applies to all software engineering work.
fact-check
Enforces evidence-based reasoning for any task that involves making factual claims about a codebase — debugging, bug fixing, code investigation, code modification, AND explaining what code does, answering "where is X" / "what does Y do" / "is this safe", or summarizing behavior. Use this skill whenever the user asks to fix a bug, investigate an issue, modify existing code, trace a problem, debug behavior, refactor, change, update code, or explain/locate/audit any part of the codebase. This skill ensures Claude gathers real evidence from source code, docs, git history, and runtime behavior before making any claim — never guessing, never paraphrasing comments as fact, never relying on training memory. Even if the task seems straightforward, use this skill to guarantee that every claim and recommendation is grounded in verified facts.
futurism-design
Apply the Futurism Design System — a Paper-Futurist web aesthetic (bold italic display type, a single red accent, square corners, solid offset shadows, and fast directional motion) with paired light and dark themes. Use this skill whenever the user asks to build, style, or restyle any web UI — a page, component, landing hero, dashboard, form, or full app — AND wants it to follow the Futurism look, OR invokes /futurism-design, OR references "futurism", "futurist", "paper futurism", "the red/cream design", or "our design system" in this repo. Trigger it even when the user only says "make a page" or "build a component" in a project that has adopted this system, so the output stays on-brand instead of defaulting to generic styling. This is an explicit, web-only design language — do not use it for terminal/CLI output.
compare-screenshots
Compare two screenshots and report every visual difference between them. Use this skill whenever the user gives you two image files (before/after, expected/actual, v1/v2, baseline/candidate) and wants to know what changed, spot the differences, diff two UI states, do visual-regression checking, or confirm two screens look identical. Triggers on "compare these screenshots", "what's different between these two images", "diff these UIs", "did the layout change", "spot the difference", "/compare-screenshots", or any before/after image pair. The skill first checks the pair is similar enough to be worth comparing, then produces a similarity percentage, a third image with the changed regions boxed in red, and a written rundown of what actually changed in each region.
smoke-test
Designs and scaffolds smoke-test suites (build-verification tests) for web services, APIs, and software systems. Use this skill whenever the user asks to "add smoke tests", "set up build verification", "write a fast test that proves the deploy isn't broken", "what should my smoke tests cover", "wire smoke tests into CI", or anything else about catching catastrophic failures before downstream testing. Also trigger on "BVT / BAT", "intake testing", "sanity vs smoke", "build acceptance". The skill detects the project's stack (Python/FastAPI, Node/Express, Go net/http, Rust/axum, etc.), proposes a focused 5-10 check suite following the API-first, <2-minute, idempotent discipline, and emits a runnable scaffold in the right framework — with `TODO` markers for environment-specific values like base URL and auth tokens. Even if the user has not explicitly said "smoke", trigger when they ask for a "fast CI gate", "deploy-readiness check", "is-the-build-up test", "happy-path coverage", or describe symptoms like "we keep
skill-builder
Create new skills, modify and improve existing skills, and measure skill performance with **unbiased blind evaluations**. Drop-in replacement for `skill-creator` that fixes its central design flaw — the same agent writing the skill also writing the tests, which lets implementation knowledge contaminate prompt selection. `skill-builder` delegates eval authoring to a blind subagent that sees only the skill's name + description, never the SKILL.md body, scripts, or fixtures. Use whenever the user wants to create, modify, or benchmark a skill, or optimize a skill's description for triggering accuracy.
backend-reversing
Reverse-engineer a game or software backend from its compiled client and reconstruct an authoritative server emulator. Use this whenever the user is reversing a client-server protocol, analyzing netcode or packet formats, decompiling a Unity / Unreal / Godot client to recover its network structures, decoding captured Protobuf / FlatBuffers / gRPC / TLV payloads, analyzing a Diffie-Hellman / RSA / ECDHE handshake, or standing up a private or emulated server for a defunct, offline, or owned game. Trigger on phrases like "reverse engineer the server", "emulate the backend", "private server", "figure out the packet format", "decode this protocol", "what serialization is this", "map the game's API", "il2cpp dump", "recover the .proto", or "the client talks to a server I no longer have". Scope is AUTHORIZED work only — game preservation, security research on software you own or are cleared to test, interoperability, and CTF. It pairs every offensive finding with the matching server-side hardening, so it doubles as
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.