pixxle-skills

Plugin pixxle-skills in Pixxle/skills. Commands read from the repo's manifest — 6 days ago.

Skills (31)

• architect

  Settle the caller's usage, types, signatures, and module boundaries before writing code. Grounds in the existing system, runs an arena of at least two structurally distinct sketches, implements against the synthesized sketch, and scraps it when implementation friction shows the shape is wrong. Use f

• arena

  Run N parallel candidates on one brief, each in its own git worktree, then pick a base, graft the strongest parts of the others into it, and verify the result. Use for "arena this", "throw it in the arena", a bakeoff, "get a few attempts and merge the best", a second opinion from independent attempt

• babysit

  Own the merge frontier for one PR or stack until it is merge-ready: declare a mode (drive, background, threads-only, check), watch forge checks and review threads, classify CI flakes, triage bot review skeptically, and batch fixes without merging. Use when the user asks to babysit a PR, get it green

• benchmark-checklist

  Vet a performance number before you report or act on it. Seven questions check the limiter, tuning, physical limits, errors, repeatability, end-to-end relevance, and whether the work ran at all. Use when you run a benchmark, report a speedup or regression you measured, pick a library or config on sp

• bro

  Restate the last message in plain human language, with no jargon. Use when the user types /bro, or says a reply was too dense or technical to follow.

• correct

  Finds the mistake classes agents keep repeating in a repo and makes each one impossible, preferring architecture, then types or a lint whose error names the fix, then a test, and docs last. Proves each new check fails on a real past mistake and keeps a rule-to-enforcer table in the repo's agent inst

• cortex

  Engineering agent style for concise, detailed responses, deliberate subagents, unslopped prose, simple code, and verified work. Use for /cortex or requests to work in this style.

• create-system-map

  Creates a thorough technical onboarding map of an unfamiliar repository, explaining its capabilities, APIs, architecture, data, and internal execution flows with source-backed diagrams. Uses mandatory sub-agents and tiered aggregation to cover large systems without overloading one context window. Us

• create-verification-skill

  Generate a committed, project-local verify-<app> skill that launches the app, drives it the way a user does on web, CLI, API, iOS simulator, or Android emulator, captures evidence, and seeds a feature map of what proves each feature works. Use when a repo has no scripted way to prove behavior on the

• figure-it-out

  Design and run a bespoke, auditable playbook. Frames a falsifiable definition of done, scales rigor to the stakes, runs each unit as a keep-or-revert experiment, and keeps a decision trail a human can audit later. Use when no cortex playbook fits, when the work is a large migration across many call

• grill-me

  Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

• handoff

  Persist work across agents and sessions with handoff docs, pause and resume notes, pickup from a prior trail, and an append-only decision trail that you audit against the transcript and send to a reviewer on another model family before you hand back. Use when compacting a conversation for another ag

• how

  Explain how code works today, in chat, at the level of a senior engineer onboarding onto a subsystem. Stays read-only, fans out 2 to 4 parallel explorers for a large area, then one explainer writes Overview, Key concepts, How it works, Where things live, and Gotchas. Use when the user asks "how does

• interrogate

  Adversarial review where subagents in their own git worktrees try to break a change or design, and only findings proven by a rerun command survive. Reports the restated intent, each verified finding with its command and output, and how many findings each adversary had dropped. Use when the user want

• maintain-verification-skill

  Keep a project's verify-<app> skill and its feature map honest as the app changes. Spawns one read-only source reader per feature in parallel, drives every mapped feature live in one pass, and ends clean, changed with one PR of proven corrections, or blocked. Use when the user asks to audit, refresh

• no-comments

  Pre-PR comment hygiene. Spawn a comment-sicko review of the scoped diff, delete unjustified comments, fix accepted root-cause flags in scope, and offer encodings for claimed constraints. Use before you ask for review of your own change.

• pr-comments

  Turn existing review findings into concise, human-sounding, inline-first PR comments and submit them as one GitHub review. Use after a review pass when the user wants to comment on the PR, post findings, leave inline comments, or write PR comments locally. The verdict is human-provided and never inf

• principles

  Lookup of each engineering principle, when it applies, and its file. Use when a principle may shape a decision, or when cortex loads the principles.

• prototype

  Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model

• reflect

  Mines the active session transcript for durable learnings with three parallel reviewers (judgment, tooling, divergent) and one synthesizer, sorts the proposals into Accepted, Rejected, and Backlog, and applies only the skill edits the user approves. Use when the user says reflect or /reflect, asks t

• routing-audit

  Audits a finished cortex session against the route it should have taken. Rebuilds the intended flow from the skills as they stood at that time, grades each step from the transcript as followed, only read, substituted, or skipped, and recommends skill changes that make the route hard to skip. Use aft

• shipping

  Land verified PRs safely: independent non-author verification before merge, contiguous verified run from the stack root, bottom-up land with forge-aware merge hygiene, and a thin optional note for keeping a verified queue moving. Use when the user asks to ship, land, merge, merge when ready, or veri

• swarm

  Fan out N parallel workers, drain them, and return one report. Use for /swarm, 'swarm this', or parallel coverage, races, gauntlets, and exploration. For maintainability-only, use thermo-nuclear-code-quality-review; for proving findings by running code, use interrogate.

• tdd

  Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.

• thermo-nuclear-code-quality-review

  Review a change for structural maintainability and major simplification opportunities. Use when structural quality is in scope for a change under review or a refactor, as a lane beside swarm or other review lanes, or when the user names thermo-nuclear. It reviews structure only, so a general or thor

• thermo-nuclear-refactor

  Uses structured discovery, cross-module tracing, and independent verification to find high-value refactorings across a whole codebase, drafts concrete proposals with coverage evidence, and implements only accepted proposals. Use only for full-scale refactoring of the whole system, meaning a system-w

• to-issue

  Converts an existing conversation or RFC into a proposed issue split, then drafts issues after the user approves the split. Use when the user wants one or more issues scoped for AI implementation, with clear outcomes and acceptance criteria for human review.

• unslop

  Cut AI tells and filler from any prose surface, by numbered rules that other skills cite by id. Use when you write or edit replies, PR titles and bodies, commit messages, docs, RFCs, or other session prose.

• why

  Investigate why code is shaped the way it is, from git history, PRs, and every connected evidence source, and return a cited, confidence-tiered answer. Use when the user asks why X works this way, why we picked Y, where a constant, limit, or threshold came from, whether a reason still holds, what mo

• write-a-skill

  Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill.

• write-rfc

  Converts an existing conversation into a concise RFC with explicit decisions, a proposed solution, and alternatives with comparative trade-offs. Use when the user asks to document a discussion, capture conversation outcomes, or turn an existing chat into an RFC in Simplified Technical English.

Subagents (2)

• comment-sicko

  A deranged comment-hater that savors deletion and condemns workaround code. Reviews a scoped diff and reports which comments die, which keep-list exceptions survive, and which symbols are MUST KILL reshape targets. Reports only and never edits a file. Use when the no-comments skill runs its review s

• cortex-agent

  Delegate for code-writing and helper tasks inside a cortex run. Reads the cortex and principles SKILL.md files in full before any work, so it works under the same gates as its parent, then does only the task in its brief. Use when a cortex playbook step spawns a code-writing delegate or an ad-hoc he