pstack-claude 플러그인

• @agent-pstack-claude:comment-reviewer

  파일에 설명이 없습니다.

• @agent-pstack-claude:comment-sicko

  A deranged comment-hater that savors deletion and condemns workaround code.

• @agent-pstack-claude:poteto-agent

  Routing target for `/poteto-mode` and any request for poteto's style. Resume an existing `poteto-agent` for the conversation rather than spawning a sibling. Reads the `poteto-mode` skill's `SKILL.md` in full before any work, including its inline Principles index. Substituting `general-purpose` skips

• architect

  Settle data shapes, ownership, boundaries, and interfaces before code crosses a function/module boundary. Use for non-trivial design work.

• arena

  Spawn parallel candidate implementations for the same task, cross-judge, and graft the best parts into the winning base. Use when exploring competing designs or critical artifacts.

• automate-me

  Create a personal mode skill from recurring workflow patterns in available history. Use when the user wants their own agent style encoded.

• benchmark-checklist

  Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you run a benchmark or report a speedup or regression you measured.

• blast-radius

  Prove what a small-looking change can affect before or after editing. Use for compatibility, caller, state, schema, or behavior impact analysis.

• bro

  Restate the last technical explanation in plain human language with minimal jargon. Use when the user asks for a simpler version.

• correct

  Find the mistakes agents keep repeating in this repo and make each one impossible. Try architecture first, then types, then a lint whose error names the fix, then a test, and write docs last. Prove each check fails on a real past mistake. Repeat this each time the operator corrects you. Use for /correct.

• create-formal-verification-skill

  Generate a project-local skill that formally verifies the code where a bug costs the most and tests reach the least, in any language, with whichever verification tool fits. Use for /create-formal-verification-skill, "model-check this race", "prove this invariant", or when concurrency, retries, state machines, parsers, or unsafe code need more than tests.

• create-verification-skill

  Generate a project-local verification skill that drives the real app and captures evidence. Use when setting up automated verification for a repo.

• figure-it-out

  Design a rigorous custom playbook when no bundled playbook safely fits a large or unusual task. Use for cross-cutting ambiguous execution.

• how

  Trace how a subsystem works using code and runtime evidence. Use for architecture walkthroughs, data flow, call paths, and are-we-sure investigations.

• in-your-own-words

  Restate in your own words what you think the user's goals are and what problem they're trying to solve. Use for /in-your-own-words.

• interrogate

  Adversarially review a diff or design with independent lenses and evidence. Use before shipping contested or high-impact changes.

• ketchup

  Catch the user up on what changed in this chat since their last message, in plain words and small visuals. List every item waiting on them with what they need to decide it from the reply alone. Use for /ketchup.

• maintain-formal-verification-skill

  Bring a project's formal verification back in line with the code after the code changes: find the commits that touched verified code, update the model, harness, or properties to describe the code as it is now, rerun, and say whether each failure is drift in the verification or a bug in the code. Use for /maintain-formal-verification-skill, "is the model still true to the code", or after merges and refactors that touched verified code without rechecking it.

• maintain-verification-skill

  Repair a project verification skill whose feature map or commands drifted. Use when app behavior and verification docs no longer agree.

• make-bot-ui

  Build a small operator UI over an agent/webhook backend. Use when buttons or controls should trigger an agent workflow.

• no-comments

  Remove redundant comments, dead workaround explanations, and AI tells from code while preserving necessary constraints. Use when cleaning up code or diffs.

• poteto-help

  Guides users through pstack setup, /poteto-mode, and picking the skill, playbook, or principle for a task. Type /poteto-help with a question.

• poteto-mode

  Lauren Tan-inspired rigorous engineering mode for concise communication, deliberate decomposition, simple code, independent review when available, and runtime verification. Use for non-trivial engineering tasks or when the user asks for Poteto Mode/pstack-style rigor.

• principle-attack-the-premise

  Inventory who actually owns or exhibits the imbalance, then challenge the shared premise before writing another patch. Use when two or more fixes that share one premise have failed the same gate.

• principle-boundary-discipline

  Validate and normalize at boundaries, trust internal invariants, and keep business logic free of adapter noise. Use when at parsing, framework, process, network, storage, or user-input boundaries.

• principle-build-the-lever

  Prefer a script, codemod, generator, benchmark, or verifier that performs or proves the work repeatably over hand edits. Use when for repetitive, large, or verification-heavy work.

• principle-encode-lessons-in-structure

  Turn recurring guidance into a type, lint, test, metadata flag, generator, runtime check, or skill so the system carries the lesson. Use when when the same corrective instruction appears more than once.

• principle-exhaust-the-design-space

  Build a few materially different cheap prototypes and compare evidence before committing to one design. Use when for novel interactions or architecture with no strong precedent.

• principle-experience-first

  Optimize for the end-user experience unless the cost violates an explicit constraint. Use when product, UX, API design, or feature-scope tradeoffs arise.

• principle-explain-the-number

  Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.

• principle-fix-root-causes

  Reproduce the symptom, trace causality until one mechanism explains it, and fix that mechanism rather than compensating for downstream effects. Use when during debugging and incident repair.

• principle-foundational-thinking

  Choose the core data structures, ownership, and sequencing first so downstream logic becomes simpler. Use when before writing logic, especially when state or concurrency is involved.

• principle-guard-the-context-window

  Route bulk exploration to isolated workers or files and bring back compact evidence summaries, not raw floods. Use when when reads, logs, fan-out, or generated output threatens to dominate context.

• principle-laziness-protocol

  Bias toward deletion and the smallest change that fully solves the problem. Use when considering adding code, abstractions, dependencies, or speculative features.

• principle-make-operations-idempotent

  Design repeated execution to converge on the same correct end state rather than multiplying side effects. Use when for commands, lifecycle steps, retries, loops, or crash recovery.

• principle-migrate-callers-then-delete-legacy-apis

  Move callers to the new shape and delete the old path in the same migration wave instead of carrying a compatibility layer. Use when when replacing an internal api.

• principle-minimize-reader-load

  Reduce indirection, mutable scope, and one-caller abstractions until the causal path is easy to hold in one mind. Use when when code requires too many hops, wrappers, hidden states, or mental joins.

• principle-model-the-domain

  파일에 설명이 없습니다.

• principle-never-block-on-the-human

  Run the experiment or make the reversible best-effort change, then show the result. Ask only for genuine preference, authority, or irreversible decisions. Use when when a reversible empirical or implementation choice can be resolved with available tools.

• principle-outcome-oriented-execution

  Converge on the target architecture rather than preserving temporary compatibility states as permanent complexity. Use when during planned migrations or rewrites with explicit phases.

• principle-prove-it-works

  Verify the requested behavior against the real artifact or surface whenever possible; a proxy check only proves the proxy. Use when verifying changes, completing tasks, or claiming something is fixed.

• principle-redesign-from-first-principles

  Design the shape you would choose if the requirement had existed from day one, then migrate toward that shape. Use when when integrating a new requirement into a design that keeps fighting it.

• principle-separate-before-serializing-shared-state

  Eliminate unnecessary sharing or partition ownership before adding locks, queues, or coordination. Use when concurrency, locks, queues, shared state, or complex coordination are being considered.

+17

• SessionStartcommand

  startup|clear|compact