skill-arsenal

Adversarial review that breaks the self-review monoculture — three hostile personas each must find at least one issue. Picks the 3 best-fit personas from a library of 52, matched to what's being reviewed: - Code & reliability: Saboteur, Concurrency Specialist, Regression Hunter, Mutant - Security: Security Auditor, Threat Modeler, Red Teamer - Data & API: Query Planner, Contract Breaker, Chaos Engineer - UX: Accessibility Critic, First-Click Saboteur, Dark-Pattern Hunter - Content: Proofreader, Fact-Checker, Humanizer, Lost Reader Findings are deduplicated and severity-promoted when multiple personas catch the same issue. Delivers a structured BLOCK / CONCERNS / CLEAN verdict with exact citations and paste-ready comments.

Audits a codebase across many quality dimensions and produces a self-contained implementation-plan folder of ordered, verifiable tasks. Audit dimensions: - DRY/reuse and code organization - Logic errors and test quality - UX and responsive design - Spec drift (code vs. spec gaps) - Theming and accessibility Fans reading out to light agents in parallel; writes numbered task files with exact acceptance criteria so a future agent can execute each independently. Plans only — never edits source.

Research a large task and produce a mapped implementation plan a smaller model can execute without losing the big picture. Produces: 1. 00-overview.md — goal, scope, and success criteria 2. 01-map.md — parts, connections, contracts, and invariants 3. 02-roadmap.md — ordered workloads and dependency graph 4. tasks/NNN-slug.md — self-contained, map-linked task files Every task links back to the map so a context-limited executor knows what it connects to and must not break. Saves the plan outside the repo by default.

Audit a UI across six evaluation lanes, each backed by an itemized reference checklist, and produce a prioritized improvement plan with severity-rated findings (P1–P4) and before/after fixes. The six lanes: - A. Accessibility — WCAG 2.2 contrast, use-of-color, focus, target size, reflow - B. Usability — Nielsen's heuristics, error messages, slips vs. mistakes - C. Cognitive load — Hick's Law, Von Restorff, Prägnanz - D. Affordances & conventions — Norman, Jakob's Law, Apple HIG (Clarity/Deference/Depth) - E. Visual hierarchy — Refactoring UI, Gestalt - F. Color & design systems — Material Design 3 roles, design tokens, product precedent Lanes can fan out to parallel sub-agents (a fusion-style panel); findings are deduplicated and severity-promoted when multiple lanes agree. Checklists carry adversarially-verified WCAG/Nielsen thresholds and an evidence-grading rule, so blocker-severity findings rest on verified facts. Preserves the existing theme. Asks the user to decide when a principle conflicts with intentional brand choices. Produces docs/design-critique/ with a findings list, impact/effort roadmap, and explicit trade-off decisions.

Generate or update a visual style guide (docs/style-guide/) — colors, typography, spacing, components, iconography, accessibility, and voice/tone. Reverse-engineers visual DNA from code (CSS custom properties, Tailwind @theme, design token files, component variant patterns). Asks for screenshots when code can't reveal color schemes, component states, or brand identity. Produces: - docs/style-guide/00-index.md — router and visual summary - docs/style-guide/01-08-*.md — numbered spec docs (brand, color, type, spacing, components, icons, a11y, voice) - docs/style-guide/tokens.json — DTCG 2025.10 machine-readable token export Also audits existing style guides — detects drift, adds missing components, retires obsolete patterns. Never edits application code.

Reasoning amplifier — runs an adaptive panel of independent agent personas, optionally cross-examines, and a judge synthesizes one answer that beats any single pass. How it works: 1. Pick distinct personas from a library of 39 (Skeptic, Risk Scout, Innovator, Pre-Mortem Coroner, Disconfirmer, and more) 2. Dispatch panel agents in parallel (independently, no cross-talk) 3. Optionally run a cross-examination reaction pass 4. Judge verifies, deduplicates, resolves contradictions, surfaces blind spots Panel size adapts to difficulty: 2 agents for light tasks, 3 for standard, 3–5 with cross-examination for hard problems.

Generates or updates a numbered spec-document set that becomes the source of truth an agent obeys when writing code. Produces: - docs/00-index.md — router index - docs/NN-topic.md — numbered spec files (100–400 lines each) - docs/decisions/ — Architecture Decision Records (ADRs) - docs/spec-compliance-plan.md — backlog of code that doesn't match canon When code is inconsistent, picks the canonical rule by convergence (the most common implementation wins) and logs every out-of-line occurrence to the compliance plan. Detects existing specs, diffs them against the code, fixes drift. ADRs are append-only. Writes docs only — never edits application code.

Keeps frontend code's structure, styling, and behavior separable so the look can swap without rewriting components. Core principles: 1. Semantic tokens named by role (--color-primary) not value (--blue-500) — all in one file 2. Model/View/Presenter layering — data/logic separate from markup 3. View components are pure functions of props — renderable in tests with no side effects To rebrand: only the token file changes. Color is never the sole signal for accessibility.

Reviews a GitHub PR for real blocking problems nobody has flagged yet — verified against the actual code before reporting. Checks for: - Correctness bugs and logic errors - Security gaps and auth issues - Broken contracts and data races - Unmet acceptance criteria from the linked ticket Reads files by ref (not checkout) to avoid corrupting local state. Returns APPROVE or REQUEST CHANGES with exact file:line citations and paste-ready comments. Never posts to GitHub on its own.

Always-on token-efficiency operating model — for every task, minimize output tokens and decide inline vs. delegate to cheaper subagents, then monitor spend and checkpoint when work reclassifies. Output thrift (every turn): - No narration or preamble — lead with the result - Terse by default; read only what the task requires - Cap the tool-call loop; never re-derive what's already done Delegation tiers: - Light (Haiku-class) — reading, grepping, listing, mechanical work - Mid (Sonnet-class) — bounded judgment and implementation - Top (Opus-class) — synthesis, cross-cutting review, high-stakes decisions The large model holds strategy and verification; mechanical work fans out to the smallest capable model. Never spend a bigger model than the job needs.

Orchestrator-driven execution of an approved implementation plan — slices the work, delegates each slice to implementer subagents, verifies against intent, and runs adversarial review rounds. Execution loop: 1. Green gate — tests, lint, and typecheck pass before review 2. Slice → delegate → verify — each slice checked against the plan's acceptance criteria 3. Adversarial review — up to 3 rounds fixing real blockers 4. Re-verify after each fix round Consumes plan-architect output directly. File-collision guard prevents parallel slices from conflicting.

Searches a curated database of standardized modern web-platform patterns before writing any browser code — so Claude uses the platform instead of heavy dependencies or ad-hoc solutions. Covers: - Layout: container queries, :has(), subgrid - Motion: View Transitions, scroll-driven animations - Performance: LCP, Core Web Vitals, INP - Platform APIs: anchor positioning, Popover API - Accessibility and forms Search first, then retrieve the full guide. Patterns default to Baseline Widely Available — safe across modern browsers.

Removes signs of AI-generated writing from text — based on Wikipedia's 'Signs of AI writing' guide. Detects and fixes: - Inflated symbolism and promotional language - Em dash overuse (zero allowed in final output) - Rule of three and -ing padding - AI vocabulary (delve, tapestry, showcase, etc.) - Passive voice and negative parallelisms Optionally voice-matches against a writing sample. Preserves specific detail, unresolved tension, and natural rhythm — the signals that make writing sound human.

Development guide for building Pinokio launcher projects — enforces a mandatory workflow and pattern-lock rules so launchers are consistent and debuggable. Mandatory before any edits: 1. Check the examples folder — never invent syntax 2. Run pre-flight and mid-task verification steps 3. Use relative paths in scripts, never absolute 4. Store captured web URLs with local.set via the example's regex capture block Supports app launchers (api/<name>) and plugin launchers (plugin/<name>). Check logs folder first when troubleshooting.

Discovers, launches, and uses Pinokio-managed apps and tools via the pterm CLI control plane. Workflow: 1. Search for the app (pterm search) 2. If not found, optionally search the registry with user approval 3. Launch and poll until ready (pterm run <ref>) 4. Use the app's HTTP API — direct call or generated client Creates a reusable skill folder with SKILL.md and client code for the app. Supports parallel launch for multiple apps. Never hardcodes paths, ports, or tokens in client files.

End-to-end workflow conductor — takes a task from raw problem to verified, reviewed completion. Workflow: 1. Interview — understand the real goal, constraints, and definition of done 2. Fusion-reasoning — fan out agents to stress-test solution approaches 3. Plan-architect — build a mapped, ordered implementation plan 4. Plan-run — execute with TDD + review-checklist guardrails on every slice 5. Completion audit — confirm every tasked item was actually done 6. Adversarial review — hostile correctness, security, and edge-case pass Three checkpoints (confirm-understanding, confirm-plan, present-verification); loops to root-cause and fix until satisfied. Also installs: fusion-reasoning, plan-advisor, plan-architect, plan-run, efficient-orchestration, build-tdd, review-checklist, review-adversarial.

Enforces the red → green → refactor TDD cycle for every new behavior or bug fix — no shortcuts. Cycle: 1. Red — write a failing test that expresses the desired contract 2. Green — write the minimum code to make it pass 3. Refactor — clean up duplication and naming without breaking the test Every failure must be for the right reason (not a setup error). Every implementation must be minimal — no over-engineering to anticipate future needs.

Bounded implementation-worker rules for handing work to an external reviewer (e.g. Codex) — enforces scope discipline, workspace hygiene, honest testing, and a structured handoff checklist. Key rules: - Follow the prompt exactly before expanding scope - Never modify files outside the task's scope - Never weaken tests to make a broken implementation pass - Run git status before handoff; remove scratch files Handoff always includes: changed files, tests run, pass/fail result, remaining risks, and artifacts left behind.

Pre/during/post-task quality guardrail — surfaces assumptions before coding, enforces triggered workflows during work, and runs full verification before marking done. Stages: 1. Pre-task — surface assumptions, clarify scope, read project-rules.md 2. During — run triggered workflows (schema changes, UI changes, API changes) 3. Post-task — run scripts/verify.sh; self-review before handoff Silent by default — fixes issues without listing them. Reads project-specific rules from references/project-rules.md.

Cursor task orchestrator — decomposes a task JSON into focused slices, dispatches each to Haiku subagents in parallel, adversarially reviews their output, fixes blockers, and returns a clean report. Execution loop: 1. Parse task JSON and project rules 2. Decompose into independent slices 3. Dispatch each slice to Haiku with tight context 4. Adversarially review every return (max 3 fix rounds per slice) 5. Run full verification; report pass/fail honestly You (the large model) are the orchestrator and quality gate — workers are cheap execution.

Build and incrementally maintain a persistent code map — file purposes, function contracts, call-graph edges, and end-to-end flows — so any orchestrator or agent warm-starts whole-application understanding for a few thousand tokens instead of re-reading the repo.

Bounded frontier-model critique gate — buys flow-aware review from the strongest available model at checkpoints (plan gate, merge gate) instead of paying frontier rates for the whole session.

Evaluates a task or plan and recommends which orchestrator configuration should run it: frontier model orchestrating directly, mid-tier orchestrator with frontier critique gates, or cheap-only execution.

Self-improving review checklist: every escaped defect — caught late or flagged by the user — is captured as a permanent new check in the same change, so the same class of mistake can never recur.

Systematic root-cause investigation: reproduce → localize along the code map's flows → ranked falsifiable hypotheses → fix at the divergence point → regression test proves it.

One-command feature pipeline: plan-advisor → plan-architect → [checkpoint] → plan-run (build-tdd during) → review-adversarial → review-gate → review-pr. Also installs: plan-advisor, plan-architect, plan-run, build-tdd, review-checklist, review-adversarial, review-gate, review-pr, review-ratchet, efficient-orchestration.

One-command design pipeline: design-style (canon) → design-critique (audit + North Star) → plan-architect → [checkpoint] → plan-run (build-frontend + build-web during) → re-run design-critique to measure the P1/P2 delta. Also installs: design-style, design-critique, plan-architect, plan-run, build-frontend, build-web, review-ratchet.

One-command codebase onboarding: map-specs (spec docs + ADRs + compliance plan) + map-code (JSON code map with flows and call edges), then a cross-check that the two artifacts agree. Also installs: map-specs, map-code.

One-command debt paydown: plan-advisor → plan-audit (fed the existing backlogs: spec-compliance plan, design P3/P4s, ratchet patterns) → [checkpoint: user picks the slice] → plan-run on cheap tiers → proportionate review → close the loop on compliance plan and maps. Also installs: plan-advisor, plan-audit, plan-run, build-tdd, review-adversarial, review-gate.

Remember where you left off and pick back up cleanly next session. Reads your handoff file into context at session start, and writes a human handoff + structured state snapshot + append-only log when you invoke it.

Generate and maintain a project-specific persona cast — user viewpoints derived from THIS project's code, docs, and discovery material, each carrying a reusable Review Lens (the questions that persona asks of any screen, and the red flags that make them reject it).

Authors a branch's commit message(s) and GitHub PR description from the actual diff — the text a reviewer reads, written honestly. Produces: - Imperative, why-focused commit messages (proposes squash messages for WIP piles) - A PR description: what & why, changes grouped by concern, reviewer focus points, verification steps, out-of-scope notes - The PR itself via gh (draft by default) — never merges, approves, or rewrites history Flags surprising diff content to the user instead of narrating around it. The authoring counterpart to review-pr, which critiques the result.

Post-deploy runtime verification: proves a shipped change actually works in the running environment, not just that the pipeline went green. The pass: - Rollback criteria written BEFORE looking — no rationalizing sick numbers - Confirm the deployed version actually contains the change - Baseline health: endpoints, error rate, latency vs. pre-deploy - Smoke the changed behavior itself with runnable, repeatable probes - Blast-radius scan: new log signatures, consumers of changed contracts Verdict: HEALTHY / DEGRADED / ROLL BACK with evidence. Probes only — never redeploys, restarts, or rolls back on its own.

Dedicated security audit producing a severity-ranked findings report with exact citations, attack narratives, and concrete fixes. Eight-dimension sweep: - Dependencies / known CVEs (reachability-checked) - Authentication and authorization (incl. IDOR) - Input validation and injection (SQL/command/template/path) - SSRF and outbound trust - Secrets in code, config, and logs - Crypto misuse and data protection - Insecure configuration and defaults Fans dimensions out to parallel agents; every lead is verified against real code before it becomes a finding. Report-only — proof-of-concept never goes beyond harmless reads.

Authors backlog-ready user stories from a feature idea or rough notes — the value statement plus testable acceptance criteria. Each story: - As a <role> / I want <goal> / so that <benefit>, with real persona lenses when map-personas output exists - 3–7 Given/When/Then criteria, edge and failure paths included, every Then observable - Explicit out-of-scope, honest S/M/L size, open questions instead of invented requirements Slices vertically per INVEST; stays solution-free. Requirements only — implementation is plan-architect's job, with the story as its feature statement.

One-command debugging pipeline: debug-root-cause → [checkpoint: confirm the diagnosis] → build-tdd (regression test proves the fix) → review-adversarial → review-gate when configured → ratchet the escape. One checkpoint at the confirmed root cause — a wrong diagnosis reviewed and shipped is the expensive failure mode. Never declares fixed without the repro flipping from fail to pass; artifacts (repro command, causal chain, test, verdicts) hand forward between stages. Also installs: debug-root-cause, build-tdd, review-adversarial, review-ratchet, efficient-orchestration.

Dedicated performance audit producing a severity-ranked findings report with measured or estimated impact, exact citations, and concrete fixes. Seven-dimension sweep: - Query & N+1 hotspots (round-trips counted per flow) - Algorithmic complexity on realistic n - Hot paths (per-request expensive work) - Memory and allocation pressure - Frontend bundle size and Core Web Vitals (LCP/INP/CLS) - Caching gaps (and caches with no invalidation story) - Blocking I/O and concurrency Fans dimensions out to parallel agents; every impact figure is labeled measured or estimated — never an estimate dressed as a measurement. Report-only.

Authors user-facing release notes and CHANGELOG entries from merged PRs and commit history — the release as its users experience it. Produces: - Keep a Changelog buckets: Added / Changed / Fixed / Deprecated / Removed / Security - Entries translated from engineering-speak to user effect, each linking its PR(s) - Breaking changes in a first-class section with migration notes (what breaks, who's affected, before → after) - Prepends to CHANGELOG.md or drafts the GitHub Release body, matching the repo's house style Derived from merged history only — never from memory of the work. Never tags or publishes the release itself.

Authors and maintains a team-facing project wiki / knowledge base for contributors and maintainers: architecture overviews, how-tos, runbooks, onboarding guides, and FAQ. Each page type gets its own skeleton: - Architecture overview — components, flows, why it's shaped this way (links ADRs, never restates them) - How-to — one task, exact commands, verification at the end - Runbook — symptom → diagnosis → remediation → escalation, written for 3 a.m. - Onboarding — day-one to first-PR path - FAQ — real questions actually asked Sources accurate content from map-specs and map-code artifacts when present; every code claim carries a pointer. Explanation and procedure — the specs remain the law.

Authors end-user documentation and training material tailored by audience tier — the same feature documented at the right depth for general users, power users, and developers. Persona-driven flow: - Uses the project's map-personas cast (docs/personas/) as reader definitions when one exists, mapping personas onto tiers and editing against each persona's Review Lens - Offers to run map-personas first when no cast exists - Falls back to the three standard tiers standalone Output: per-tier documents, tier labeled — quickstarts and task guides for general users, advanced workflows and automation for power users, runnable API/integration examples for developers. Grounded in the actual product; no tier bleed, no invented behavior.