quangtran88

Use when the user provides an OpenAPI or Swagger spec and asks to find security issues, pentest the API, audit endpoints for OWASP API Top 10, or check for BOLA, BFLA, mass assignment, injection, or SSRF vulnerabilities in a running HTTP API

Use when the user wants to capture a brainstormed idea, feature, or solution into a durable backlog/spec doc under docs/backlog — a human-facing reference that combines context, chosen solution, key decisions (ADR-lite), scope, acceptance criteria, and optional feature/integration/contract/use-case/handoff modules. Drafts the whole doc autonomously from the current conversation and persists docs/backlog/<slug>.md; asks the user only when blocked or a decision genuinely needs their input. NOT a low-level implementation plan (that is superpowers:writing-plans / x-do).

Use when the user reports a bug, error, test failure, or unexpected behavior — routes through investigation, hypothesis testing, and verified fix with structured evidence collection

Use when the user wants to apply a visual design system to a project, references a specific brand's style (Linear-like, Stripe-like, Claude-like), asks for a DESIGN.md, or describes aesthetic intent (warm editorial, dark minimal, stark futuristic) for AI UI generation

Use when the user asks to build, implement, fix, or execute a plan — detects context (existing plan, new feature, bug, quick task, visual input) and routes through brainstorming, planning, debugging, or execution workflows

Use when the user wants a complex input (file, function, directory, PRD, plan, spec, URL, pasted prose, or vague feature name) explained step by step in a comprehension-gated walkthrough — produces a persistent .x-guide/<slug>/GUIDE.md with full TOC and walks the user one part at a time, supports resume across sessions

Use BEFORE implementation when AI has produced a plan, spec, design doc, PRD, or code-bearing proposal and you want a senior-engineer architect-review pass — walks the user through the decisions, tradeoffs, assumptions, blind spots, shape mismatches, and future-debt AI silently embedded. Surfaces "what AI did, what it picked over alternatives, what it took on, and what gets harder later" one item at a time with confirm / modify / reject / skip gates. Hard-blocks code-level details so the human stays at architectural direction.

Use when the user wants end-to-end QA testing for a feature, branch, or PR — scans the project for entry points, generates a TEST_PLAN.md with edge cases, launches the service in an isolated container, and dispatches test runners (cheap agy for simple HTTP cases, claude for complex flows). Profile-driven: `init` once, then `run` repeatedly.

Install a battle-tested multi-agent dev-squad configuration onto a new Multica project (installer, NOT a generator). Use when the user wants to set up, provision, bootstrap, or install a Multica dev squad on a repo — drives phases P0-P7 with hard gates.

Use when reviewing a diff for cross-file coherence, coupling, or abstraction-boundary regressions — the architecture lens. Supplies precise vocabulary (depth/seam/locality), the deletion test, the adapter-count seam rule, and a code-graph-first caller-impact recipe with a graph-free fallback. Do not use for writing code, style policing, or other reviewers' lenses.

Use when {{QA_SEAT_NAME}} must drive a real browser against the target repo's web surface ({{UI_SURFACE}}) with the playwright MCP — supplies hybrid DOM+screenshot grounding, the tiered-locator order, a self-heal loop that ESCALATES instead of weakening assertions, a step cap, and the headless no-clarifying-question contract. Do NOT use for native-channel rendering (that is un-automatable), for API/contract testing (qa.md HTTP oracles), or for scenario-shape / non-determinism metrics (your eager QA scenario contract + eval-harness own those).

Use while implementing a sub-issue at a judgment point — a repeatedly failing build/test, a needed dependency, a wrong-looking AC (HALT vs push through), or metabolizing the three-panel review. Not for reviewing others' code or spec/planning.

Use when reviewing a diff that changes control flow, a state machine, auth/permission checks, async or concurrent code, or input boundaries, and you need exhaustive enumeration of unhandled paths. A method (mechanical path-walk), not an attitude. Do not use for writing code or for style/quality opinions.

Use in non-deterministic testing — Mode-2 real-model or Mode-3 real-platform — when exact-string asserts would flake. Supplies the determinism split (mock = assert exact, real-model = assert a predicate over k runs), pass@k vs pass^k reliability metrics, the grader taxonomy (code / model / human), and baseline-SHA regression framing. Do not use for deterministic mock-LLM scenarios (assert exactly) or for scenario generation (your eager QA scenario contract owns that).

Use when reviewing a diff that touches LLM prompt construction, tool/function-calling, RAG/retrieval, rendering of model output, AI credentials, or any path where model or tool output flows onward — the LLM-gateway attack class. Supplies the sink patterns and severity/FP rules for that lens. Do not use for generic web vulns the base review already covers, or for writing code.

Use when a sub-issue adds or changes an MCP tool/server surface — the agent-centric tool-design rules plus the Zod-strict validation and tool-annotation checklist. Always defer current @modelcontextprotocol/sdk signatures to context7 (don't trust memory). Do not use for non-MCP code, or for merely consuming an existing MCP tool.

Interactively run a git contribution audit for the user. Use when someone asks "who contributed most" across a company's/team's repos, wants a contribution or activity audit, a per-month/quarter contributor breakdown, a code-review/pull-request/issue breakdown, or a shareable contributor leaderboard. This skill DRIVES the setup — it checks prerequisites (GitHub CLI auth), interviews the user for scope (which orgs/users/repos), the ranking metric, noise filters, and output, then clones, dedups identities, and produces a single self-contained HTML report covering both git churn AND (from the GitHub API) pull-request / code-review / review-comment / issue activity — so reviewers who write little code still show up. Do NOT expect the user to run commands themselves; you run the pipeline for them.

Generate a personalized, self-mentoring learning repo (a "dojo") for any topic the user wants to master — coding or not. Interviews the learner, deep-researches and curates the best materials, synthesizes a module-based curriculum with a roadmap, then scaffolds a git repo whose AGENTS.md turns any coding agent into a persistent mentor with daily check-ins, teach-back gates, spaced repetition, confidence calibration, and progress tracking. Use when the user asks to build a dojo, learning repo, curriculum, roadmap, or mentor repo for a topic, or commits to mastering a topic long-term ("build me a dojo for X", "teach me X long-term") — not for one-off questions about a topic.