magfrump
@magfrump
Public Skills
code-review
by magfrump
Orchestrate a comprehensive code review by coordinating code-fact-check and code critic agents (security-reviewer, performance-reviewer, api-consistency-reviewer) in parallel, with optional contextual critics (architecture-review, test-strategy, tech-debt-triage, dependency-upgrade, ui-visual-review) auto-selected based on the diff. Follows a 3-stage pipeline: code fact-check → critic agents → synthesis. Produces a freeform chat summary plus a structured code review rubric with red/amber/green status tracking. Use this skill when the user asks to "review this code", "review this PR", "review my changes", "review this diff", "full code review", "run all critics", "code review this branch", or wants a multi-perspective review of code changes. Default to this orchestrator whenever a PR is being prepared, opened, or evaluated — it composes security, performance, API consistency, and (when triggered) architecture into a single pass. Also use when the user asks for two or more of those concerns together. For a deliberately narrow review on a single concern (just security, just performance), invoke the standalone critic skill directly instead.
code-fact-check
by magfrump
Verify checkable claims in code comments, docstrings, commit messages, and project documentation against actual code behavior. This is the code analog of the prose fact-check skill: where fact-check checks essay claims against the world via web search, code-fact-check checks code claims against the codebase via direct file reading — and, when a claim's subject is executable in the review sandbox, by actually running it. For every claim about what code does, how it performs, or how it's structured, search the codebase for evidence and report findings with calibrated confidence. Produces a structured Markdown report. Use this skill when the user asks to "verify the comments", "check the docs against the code", "audit documentation accuracy", "are the docstrings still accurate", "do the comments match the code", or when upstream orchestration (e.g., the code-review skill) requests a code verification pass. Also trigger when reviewing or onboarding to a codebase and the comments or docstrings look stale, drifted, or contradict the surrounding implementation — running this skill before further work surfaces documentation rot that would otherwise mislead later changes.
security-reviewer
by magfrump
Review code changes for security vulnerabilities using structured cognitive moves that go beyond what static analysis tools catch. This is not a linter — it focuses on design-level security flaws, trust boundary violations, implicit assumptions about input safety, and patterns that create exploitable conditions. Produces a structured Markdown critique of code diffs. Use this skill when the user asks to "review for security", "check for vulnerabilities", "security audit this PR", "what could an attacker do with this", or "is this safe". Also trigger when code touches authentication, authorization, input handling, cryptography, file I/O, network calls, or serialization. Also trigger when the diff includes changes to dependency manifests (package.json, requirements.txt, go.mod, Cargo.toml, pyproject.toml, Gemfile, pom.xml, build.gradle, etc.) or their lockfiles. NOTE: This skill can be invoked standalone or by a code-review orchestrator. If a code-fact-check report is provided, use it as your foundation for understanding what the code actually does and do not re-verify documented behavior.
dependency-upgrade
by magfrump
Evaluate a dependency upgrade by reviewing the changelog, identifying breaking changes, assessing migration effort, and producing a go/no-go recommendation with a concrete migration plan. Use this skill when the user asks "should we upgrade X", "what changed in X v2", "is this upgrade safe", "review this dependency bump", "review this dep bump PR", "is bumping X v1 to v2 risky", or when Dependabot or Renovate opens a PR that needs human judgment. Also trigger when a dependency has a known security advisory or CVE, is approaching end-of-life, or when a transitive dep is forcing a version bump. Can evaluate a single upgrade or compare alternatives (e.g., "should we upgrade X or switch to a different library"). When in doubt and the work involves a dependency manifest change (package.json, go.mod, requirements.txt, Cargo.toml, Gemfile, pyproject.toml, etc.), prefer running this skill over skipping it. NOTE: This skill can be invoked standalone or by a code-review orchestrator. If a code-fact-check report is provided, it is the sole source of execution results: consume its verdicts and cite its claim ids for any command-outcome statement (audit, install, test, grep) and do not run or re-assert command outcomes yourself.
performance-reviewer
by magfrump
Review code changes for performance problems using structured cognitive moves that go beyond what profilers and benchmarks catch. This is not about micro-optimization — it focuses on algorithmic complexity issues, hidden N+1 patterns, unnecessary work in hot paths, resource lifecycle problems, and scaling bottlenecks that only appear under load. Produces a structured Markdown critique of code diffs. Use this skill when the user asks to "review for performance", "perf review", "will this scale", "check for bottlenecks", "is this efficient", "what happens under load", "find the N+1", or "hot path analysis". Also trigger when code touches database queries, ORM calls, loops over collections, caching, pagination, batch operations, request handling paths, background workers, or any code in a measured hot path. This is the performance critic — for security flaws use security-reviewer; for interface design use api-consistency-reviewer; for module/dependency structure use architecture-review. NOTE: This skill can be invoked standalone or by a code-review orchestrator. If a code-fact-check report is provided, use it as your foundation for understanding what the code actually does and do not re-verify documented behavior.
arithmetic-eval
by magfrump
Validate and evaluate math using python3 to prevent hallucinated calculations. Two modes: (1) bare arithmetic (numbers + operators only) via a safe AST evaluator — no shell interpolation, no eval; (2) scientific computing (imports, scripts, dataframes) gated by a machine-enforced static checker over an approved-modules allowlist for scipy, numpy, pandas, sympy, statistics, etc., then run under OS confinement. Use whenever performing, verifying, or double-checking ANY calculation, including: intermediate math inside a fact-check ("does 2.3M / 41 ≈ 56k?"), cost estimates ("$0.003 × 1.2M tokens"), unit conversions, percentage changes, t-tests, p-values, confidence intervals, CSV/JSON aggregations, regression coefficients, and sanity checks in code review. Default to using this skill — mental math is the exception, not the rule. Trigger phrases: "compute", "calculate", "what's X% of Y", "how many", "verify this number", "check the math", "is this right", or any expression with operators (+, -, , /, %, *) on non-trivial operands.
yglesias-critique
by magfrump
Critique a draft that proposes a mechanism — any intervention where the author wants something to happen — using the cognitive methods and reasoning patterns of Matt Yglesias. This is the right critic for proposals of any kind: a software design, a research tool, a community norm, a curriculum change, an organizational shift, a fundraising plan, or a government policy. Yglesias's distinctive moves operate on proposed mechanisms generally: agree-with-the-goal-demolish-the-mechanism, find the one boring lever nobody's pulling, follow the money/effort through the system, check whether the proposal survives an adoption cycle, run the "10 million people" scale test, swap in the implementation org chart, identify the cost-disease trap, and find the popular version. Government policy is a special case, not the full scope. This is the DEFAULT critic whenever a draft pairs a goal with a proposed mechanism and the user wants pragmatic pushback on whether the mechanism actually achieves the goal. Trigger phrases: "would this actually work", "give me the pragmatic critique", "what's the boring lever", "is the mechanism the right one", "am I being realistic here", "poke holes in this proposal", "would this policy actually work", "what's the supply-side take", "follow the money on this", "what's the 10-million -people test", "what's the popular version", "would this survive an election cycle", "is this proposal implementable". Produces a structured Markdown critique. Distinct from cowen-critique (which stress-tests argument rigor — is the reasoning sound) and ai-personas-critique (which dispatches multiple orthogonal lenses): this skill applies a single, consistent mechanism-feasibility lens — does the proposed intervention actually achieve the stated goal at the scale and through the institutions the author has in mind. NOTE: This skill is typically invoked by the draft-review orchestrator, which provides a pre-built fact-check report. If a fact-check report is provided, use it as your factual foundation and do not redo basic fact verification.
business-plan-critique-market-sizing
by magfrump
Critically review a business-plan-shaped draft (founder pitch, investor deck narrative, go-to-market strategy doc, fundraising memo, product strategy brief, market-entry analysis, or similar) using a focused set of market-sizing lenses: TAM definition and derivation, SAM (addressable-segment) realism, SOM (capturable-share) achievability, market timing, and comparable-company benchmarks. This skill exists because many early-stage plans pass moat and unit-economics scrutiny but quietly fail on the market story — TAM is computed top-down from a category report that doesn't match the actual product, the addressable segment is defined so loosely it includes customers who would never buy, the captured share implied by the revenue plan exceeds what comparable companies have achieved at comparable stage, the "why now" rests on a trend that's been true for a decade, or the comp-set benchmarks have been cherry-picked to support the model. Use this skill whenever a draft proposes a business or product strategy and the author wants pressure on whether the market is large enough, addressable enough, capturable enough, and timed right. Also trigger when the draft quotes a TAM, SAM, SOM, market-growth rate, addressable-customer count, capturable share, "why now" thesis, or comparable-company revenue/share figure the author wants pressure-tested. Trigger phrases: "is the market real", "review my TAM", "is the TAM defensible", "TAM/SAM/SOM critique", "market-sizing review", "is the market big enough", "stress-test the market story", "why-now critique", "market timing review", "is the addressable segment realistic", "are the comparable benchmarks right", "is the captured share achievable", "review the market opportunity", "critique the addressable market", "did I size this market right". Produces a structured Markdown critique with a known section layout (TAM Definition, SAM Realism, SOM Achievability, Market Timing, Comparable Benchmarks, Factual Foundation, Overall Assessment). Scope is intentionally narrow: moat/distribution and unit-economics critiques are explicitly deferred to sibling skills (business-plan-critique-moat and business-plan-critique-unit-economics) so this skill stays focused on the market story. This skill is also distinct from cowen-critique, which applies general argument-rigor moves to any prose argument and may incidentally pressure a market claim ("if this market is so large, why isn't there a $1B incumbent already?") but does not systematically check TAM derivation, segment definition, capturable share, market timing, or comp-set benchmarks. If the draft's biggest weakness is general argument structure rather than market sizing specifically, route to cowen-critique instead. NOTE: This skill is typically invoked by the draft-review orchestrator, which provides a pre-built fact-check report. If a fact-check report is provided, use it as your factual foundation and do not redo basic fact verification.
ui-visual-review
by magfrump
Review and fix visual/layout issues in UI code — cross-resolution compatibility, scrollability, overflow handling, sizing, affordance, focus order, and 3D viewport rendering. Triggers on ANY visible UI element, not just CSS: TSX/JSX, Vue, Svelte, Tailwind, CSS-in-JS, Unity/C# UI components (Button, Toggle, Selectable subclasses), SwiftUI views, native mobile layouts, and 3D rendering surfaces (three.js, react-three-fiber, Babylon, model-viewer, Unity WebGL, Unreal Pixel Streaming, .glb/.gltf). Validates recommendations against accessibility standards (WCAG 2.2), NNGroup usability research, and platform UI guidance. Use this skill when the user reports visual elements that are cut off, overlapping, invisible at certain resolutions, or otherwise broken across screen sizes. Also trigger on any of: "fix the layout", "make this responsive", "review the UI", "check visual elements", "audit the CSS", "review the layout", "check the UI", "fix the styling", "responsive design review", "is this responsive", "does this work on mobile", "layout review", or when a diff touches any file containing rendered UI — including TSX/JSX, CSS, SCSS, Tailwind class strings, Unity C# UI scripts, or 3D scene setup. Produces concrete code fixes plus a structured report of findings. NOTE: This skill can be invoked standalone or by a code-review orchestrator. If a code-fact-check report is provided, use it as your foundation for understanding what the code actually does and do not re-verify documented behavior.
self-eval
by magfrump
Evaluate a single skill or workflow against the project's evaluation rubric (docs/evaluation-rubric.md). Auto-scores five structural dimensions (testability investment, trigger clarity, overlap and redundancy, test coverage, pipeline readiness) as Strong/Adequate/Weak with justification. Flags the four judgment-dependent dimensions (counterfactual gap, user-specific fit, failure mode gracefulness, condition for value) with structured prompts so a human reviewer can finish the assessment efficiently. Produces a structured Markdown report at docs/reviews/self-eval-{target}.md with a Key Questions list. Use this skill whenever the user asks to "evaluate this skill", "assess this workflow", "run the rubric on X", "self-eval", "score this skill", or "how does X hold up against the rubric". Also trigger automatically before merging a new or substantially modified skill or workflow (pre-merge gate), during periodic reassessment of existing tools when conditions have changed (pipeline built/abandoned, usage shifted), and as part of the PR-prep review-fix loop when the diff touches skills/ or workflows/. When in doubt, run it — under-triggering here means skills ship without rubric assessment.
cowen-critique
by magfrump
Critically review a draft (blog post, essay, article, op-ed, research note, or similar written piece) using the cognitive methods and reasoning patterns of economist Tyler Cowen. This goes beyond applying his known conclusions — it encodes how he actually breaks down arguments, the specific intellectual moves he makes (boring-explanation-first, invert-the-thesis, revealed preferences, market signals, cross-domain analogy, sub-claim decomposition, contingent assumptions, calibrated uncertainty), and the habits of mind that distinguish his analysis. Produces a structured Markdown critique. This is the DEFAULT critic for substantive intellectual feedback on a written argument — reach for it whenever a draft makes a claim that could be wrong and the user wants more than proofreading. Trigger phrases: "review this draft", "critique this", "pressure-test this", "poke holes in this", "what am I missing", "is this argument solid", "challenge my thinking", "play devil's advocate", "stress-test the argument", "give me a Cowen-style review", "what would an economist say about this", "is the reasoning sound", "where is this weak". Distinct from yglesias-critique (which targets proposed mechanisms — does the intervention achieve the goal) and ai-personas-critique (which dispatches multiple orthogonal lenses): this skill applies a single, consistent economist's lens focused on argument rigor and revealed-vs-stated reasoning. NOTE: This skill is typically invoked by the draft-review orchestrator, which provides a pre-built fact-check report. If a fact-check report is provided, use it as your factual foundation and do not redo basic fact verification.
business-plan-critique-unit-economics
by magfrump
Critically review a business-plan-shaped draft (founder pitch, investor deck narrative, go-to-market strategy doc, fundraising memo, product strategy brief, financial model, or similar) using a focused set of unit-economics lenses: CAC, LTV, contribution margin, payback period, and gross-margin trajectory. This skill exists because many early-stage plans look defensible on the moat and market story but quietly fail on the math — the per-customer economics either never work or only work at a scale the business can't reach. Use this skill whenever a draft proposes a business or product strategy and the author wants pressure on whether the unit economics actually compound. Also trigger when the draft quotes CAC, LTV, LTV/CAC ratio, churn, retention, gross margin, contribution margin, payback period, NRR/GRR, or any per-customer profitability figure the author wants pressure-tested. Trigger phrases: "do the unit economics work", "review my CAC/LTV", "critique the financial model", "is this fundable on the numbers", "stress-test the margins", "payback period feedback", "contribution margin critique", "unit economics review", "is the LTV real", "are these margins defensible", "check the per-customer math", "review the CAC assumptions", "what's wrong with my unit economics". Produces a structured Markdown critique with a known section layout (CAC, LTV, Contribution Margin, Payback Period, Gross-Margin Trajectory, Factual Foundation, Overall Assessment). Scope is intentionally narrow: moat/distribution and market-sizing critiques are explicitly deferred to sibling skills (business-plan-critique-moat and the future business-plan-critique-market-sizing) so this skill stays focused on the per-customer math. NOTE: This skill is typically invoked by the draft-review orchestrator, which provides a pre-built fact-check report. If a fact-check report is provided, use it as your factual foundation and do not redo basic fact verification.
tech-debt-triage
by magfrump
Evaluate a piece of tech debt and produce a structured assessment: what it costs to carry, what it costs to fix, when it becomes urgent, and where it ranks relative to other work. Use this skill when the user asks "should we fix this", "is this worth refactoring", "how bad is this tech debt", "prioritize these cleanup tasks", "what's the highest-ROI cleanup", or when scoping a cleanup sprint, refactor week, or backlog grooming pass. Also trigger when code review surfaces something that works but is fragile, overly complex, or blocking future work; when a developer complains that a module is "painful" or "we should rewrite this"; when planning capacity and deciding whether to spend it on debt versus features; or when a postmortem identifies underlying debt as a contributor. Can evaluate a single item or compare multiple debt items using the matrix-analysis pattern. Prefer running this skill over giving an ad-hoc opinion whenever the question is "is fixing this worth it" — the structured carry/fix/urgency framing changes the answer often enough to be worth the small overhead.
draft-review
by magfrump
Orchestrate a comprehensive review of a written draft (blog post, essay, op-ed, policy memo, investor deck, fundraising memo, founder pitch, go-to-market doc, or any prose argument) by coordinating fact-checking and critic agents. Runs a 3-stage pipeline: fact-check → critic agents in parallel → synthesis into a freeform chat summary plus a structured verification rubric with red/amber/green status tracking. Auto-selects from available critics (cowen-critique, yglesias-critique, ai-personas-critique, business-plan-critique-moat, business-plan-critique-unit-economics) based on draft topic. Supports ensemble mode for higher confidence through convergence analysis. Use this skill whenever the user wants a thorough review of a draft that combines fact-checking with substantive critique. Trigger phrases: "review this draft", "give me feedback on this", "fact-check and critique this", "review my essay/post/memo/pitch/deck", "what am I missing", "multiple perspectives on this piece", "stress-test this argument". For reviewing a single concern (just fact-check, just one critic lens), use the standalone skill instead. For code review, use code-review.
matrix-analysis
by magfrump
Orchestrate a structured evaluation of multiple items across multiple criteria by dispatching parallel sub-agents — one per criterion — that each score all items along their assigned dimension. Compiles results into a comparison matrix, surfaces tradeoffs, and synthesizes an overall recommendation. Use this skill whenever the user is choosing among 2+ named alternatives along 2+ named dimensions — comparing options, evaluating alternatives, ranking candidates, or making a structured decision across multiple dimensions. Trigger phrases: "compare these options", "evaluate X vs Y vs Z", "which of these is best", "pros and cons matrix", "decision matrix", "trade-off analysis", "score these against criteria", "tabulate the options", "side-by-side comparison". Works with any combination of items and criteria: design alternatives, libraries, vendors, architectures, approaches, tools, or any other set of comparable options. Also trigger as a sub-procedure of divergent-design when the candidate set is wide enough that a scoring matrix would clarify the choice, or when an RPI plan needs to choose among 3+ approaches. Prefer this skill over an ad-hoc pros/cons list whenever the decision crosses 2+ items and 2+ criteria — the parallel sub-agent dispatch produces more consistent calibration than a single agent reasoning about everything at once.
business-plan-critique-moat
by magfrump
Critically review a business-plan-shaped draft (founder pitch, investor deck narrative, go-to-market strategy doc, fundraising memo, product strategy brief, or similar) using a focused set of moat-and-distribution lenses: moat type, distribution channel, switching cost, network effect, and competitive response. This skill exists because the most common reason early-stage plans fail is not market timing or product quality — it's that the named moat isn't structurally durable, the distribution channel can't scale, or the competitive response defeats the thesis once it works. Use this skill whenever a draft proposes a business or product strategy and the author wants pressure on whether the durable advantage is real, OR whenever a draft names a moat, network effect, switching cost, distribution channel, or competitive positioning claim. Trigger phrases: "review my business plan", "critique this pitch", "is this defensible", "is this durable", "what's the moat", "moat review", "moat-and-distribution critique", "stress-test the strategy", "would this survive competition", "competitive response analysis", "fundraising deck review", "GTM critique", "go-to-market feedback", "review the distribution strategy", "pressure-test the network effect". Produces a structured Markdown critique. Scope is intentionally narrow: market-sizing and unit-economics critiques are explicitly deferred to sibling skills (business-plan-critique-unit-economics and a future market-sizing critic) so this skill stays focused on durable advantage. If the draft is primarily about CAC/LTV/payback/margin math, route to the unit-economics sibling instead. NOTE: This skill is typically invoked by the draft-review orchestrator, which provides a pre-built fact-check report. If a fact-check report is provided, use it as your factual foundation and do not redo basic fact verification.
test-strategy
by magfrump
Given a feature, module, or change, recommend what kinds of tests to write, where to put them, and what to prioritize. Analyzes the code's risk profile, existing test patterns, and architecture to produce a concrete testing plan — not generic advice, but specific test cases mapped to specific files, with each recommendation traceable to a named gap in the code. Use this skill when the user asks "what tests should I write", "how should I test this", "what's missing from our test coverage", "what's the test plan", "scope the verification", or "where are the coverage gaps". Also trigger at the end of an RPI planning phase to populate the plan's test specification section, when a feature is implemented but has no tests, when reviewing a PR that lacks tests, or when the user is unsure whether unit, integration, or end-to-end tests are appropriate. Output is a structured Markdown plan with named gaps (G1, G2, ...) and recommended tests that cite which gaps they close.
architecture-review
by magfrump
Review code changes for structural integrity — SOLID principle violations, dependency direction problems, module boundary breaches, and coupling issues. This is not a code review for implementation quality (security, performance, API consistency) — it focuses on whether a change maintains or improves the system's architectural health. Produces a structured Markdown critique of code diffs. Invoke this skill ONLY when the diff changes one or more of: (1) module structure (new modules, renames, moves, package/directory layout), (2) public APIs (new or changed exported types, functions, or interfaces; abstract classes/protocols), (3) data models (schemas, DTOs, persisted contracts, message formats consumers depend on), or (4) cross-cutting concerns (dependency injection wiring, middleware, auth/authz pipelines, logging/tracing setup, caching layers, error-handling pipelines). SKIP this skill when the diff only modifies implementation inside an existing module without touching its public surface — internal refactors, bug fixes, perf tweaks, test additions, doc updates, and dependency-version bumps alone are out of scope. Use this skill when the user asks to "review the architecture", "check dependencies", "is this well-structured", "review module boundaries", "SOLID review", "coupling analysis", or "dependency direction check". NOTE: This skill can be invoked standalone or by a code-review orchestrator. If a code-fact-check report is provided, use it as your foundation for understanding what the code actually does and do not re-verify documented behavior.
what-if-analysis
by magfrump
Perform a structured prospective consequence analysis of a proposed change — a plan, design, migration, refactor, policy, or any artifact that proposes doing something different from the status quo. This skill systematically explores "what if this assumption is wrong?" and "what would need to be true for this to fail?" It traces second-order effects, maps hidden couplings, and stress-tests the highest-confidence assumptions. Differentiated from critique skills (cowen-critique, yglesias-critique) which evaluate whether an argument is good — this skill evaluates what happens if the argument is wrong, and what the consequences are even if it's right. Use this skill when the user asks things like "what could go wrong with this", "stress-test this plan", "what am I not seeing", "what are the risks", "what are the second-order effects", "what breaks if we're wrong", "what assumptions is this making", or "what if this assumption doesn't hold". Also trigger when the user is about to make a significant, hard-to-reverse change and wants to understand the consequence space before committing, or when invoked as a sub-procedure of divergent-design to stress-test top candidates before a decision is finalized. Distinct from pre-mortem: that skill operates retrospectively (assume failure has already happened → write the narrative of why), while this skill operates prospectively (the plan is on the table → map the consequence space around it). Trigger phrases that name a failure as already having happened — "pre-mortem this", "imagine 6 months later and this failed", "write the failure story", "tell me why this failed" — route to pre-mortem, not here. The two skills compose: run what-if first to map the territory, then pre-mortem to walk the specific failure paths through it. NOTE: This skill can optionally receive upstream reports (fact-check, critique) but does not require them. If critique reports are provided, use them to identify which assumptions the critics didn't examine — that's where this skill adds the most value.
fact-check
by magfrump
Perform rigorous journalistic fact-checking on a draft (blog post, essay, article, policy piece, or any prose with checkable assertions). This is not a critique or review — it's a neutral verification pass, like a newspaper's fact-checking desk. For every checkable claim in the draft, search for evidence, assess accuracy, and report findings with calibrated confidence. Produces a structured Markdown report that can be consumed by human readers or passed to downstream critic agents. Use this skill whenever the user asks to "fact-check this", "verify the numbers", "check the claims", "source-check", "is this true", "did this actually happen", "make sure the facts are right", "verify this draft", or any phrasing that asks for factual verification rather than judgment. Also trigger when upstream orchestration (e.g., the draft-review skill) requests a fact-check pass before running critic agents — the orchestrator will supply a goal preamble.
design-space-situating
by magfrump
Place a proposed design decision onto eight orthogonal dimensions of design technique (locus of authority, orientation in time, search/compose/emerge, modeling target, reversibility, formality, social structure, legibility) and produce a structured situating record that names what kind of decision this actually is. Use this skill when the user asks "what kind of decision is this", "situate this decision", "where does this sit in the design space", "frame this before we choose", "frame this before we diverge", "what kind of problem is this", or "are we even framing this right". Also trigger proactively as a sub-procedure when divergent-design surfaces contradictory constraints that no candidate can satisfy, when DD's compatibility matrix has no green cell, or when RPI research turns up a decision touching authority, time, reversibility, formality, social structure, or legibility in ways the user has not named. Contradictory constraints almost always signal a misframed problem rather than a genuine tradeoff — run this skill before treating it as a tradeoff. The output record becomes input to DD's diagnosis step (problem statement) or RPI's plan step (decision framing); it is a frame, not a decision. Lean toward invoking this skill when in doubt — a 5-minute framing pass routinely saves hours of misdirected design work.
api-consistency-reviewer
by magfrump
Review code changes for API design consistency across the surfaces that consumers actually bind to: HTTP/REST endpoints, gRPC services, GraphQL schemas, SDK methods, exported library functions, CLI commands and flags, configuration schemas, event payloads, and any other interface that internal or external callers depend on. Catches the bugs and usability problems that come from APIs evolving inconsistently — mixed naming conventions (snake_case vs camelCase, get vs fetch, plural vs singular), inconsistent error response formats, breaking changes disguised as additions, divergent pagination/filtering patterns, request/response field asymmetries, and interfaces that quietly violate the expectations the rest of the codebase has already established. Produces a structured Markdown critique of code diffs with a name-pattern audit that compares every new public name against its closest existing neighbors. Use this skill when the user asks to "check API consistency", "review the interface", "does this match our conventions", "will this break clients", "is this a good API", "audit endpoint naming", "check the SDK surface", or "compare to sibling endpoints". Also trigger whenever a diff adds or modifies a public endpoint, exported function/method/class, SDK method, CLI command or flag, config field, event schema, or any consumer-facing contract — even when the user did not explicitly ask for an API review. Distinct from architecture-review (which evaluates SOLID, dependency direction, and module boundaries) and security-reviewer (which evaluates trust boundaries and exploitability) — this skill evaluates whether the new surface matches the conventions consumers have already learned. NOTE: This skill can be invoked standalone or by a code-review orchestrator. If a code-fact-check report is provided, use it as your foundation for understanding what the code actually does and do not re-verify documented behavior.
pre-mortem
by magfrump
Conduct a Klein-style pre-mortem on a proposed change by assuming the change has already shipped and already failed, then writing concrete retrospective failure narratives that explain why. The cognitive shift is from advocate mode ("how do we make this work?") to detective mode ("the project failed — what does the post-incident review say?"). Produces 3–5 specific failure stories, each with a named root cause, an ordered chain of consequences, and an observable outcome, calibrated for plausibility and severity. Use this skill when the user says "imagine this has already failed", "pre-mortem the launch", "pre-mortem this", "it's six months later and this didn't work — what happened", "write the failure post-mortem before we ship", "give me the failure stories", "tell me the story of why this failed", or "what does the incident report say if this goes wrong". Also trigger when a team has converged too quickly on a plan and needs to confront concrete ways it could go wrong, or when a high-stakes, hard-to-reverse change is about to be committed and the user wants the failure narratives before the decision is locked. Distinct from what-if-analysis: that skill operates prospectively (proposal → "what could go wrong from here?" — load-bearing assumptions, second-order effects, coupling map, reversibility gradient); this skill operates retrospectively (failure already happened → "tell the story of why"). The trigger test at invocation time is mechanical: if the user's framing is "this has failed — why?" use pre-mortem; if the framing is "this is the plan — what could go wrong?" use what-if-analysis. The two skills compose for high-stakes changes — run what-if-analysis first to map the consequence space, then this skill to convert the most worrying parts of that map into concrete failure narratives the team can plan mitigations against.
divergent-design
by magfrump
Route a tradeoff-bearing design decision into the divergent-design workflow (diverge → diagnose → match → decide) instead of open-ended brainstorming. Use this skill the moment a creative task resolves to choosing among competing approaches that carry tradeoffs — building a feature, structuring a module, or selecting a library where more than one option is viable. Trigger phrasings (same surface brainstorming would catch): "which approach", "compare options", "compare approaches", "evaluate alternatives", "weigh alternatives", "X vs Y", "should we use X or Y", "pick between", "choose between", "decide between", "what are the options", "multiple approaches", "design choice", "design decision", "tradeoff", "trade-offs", "pros and cons", "library selection", "tool selection", "architecture". This skill SUPERSEDES open-ended brainstorming whenever the task is a decision among 3+ tradeoff-bearing options: if you can name 3+ viable options that differ on a tradeoff axis, route here for the structured candidate/matrix presentation. Mechanical trigger test: can you name 3+ viable options that differ on a tradeoff axis? Yes → this skill. (If the solution space is genuinely open-ended with no competing options yet, brainstorming still applies.) This is a thin router — it hands off to workflows/divergent-design.md, which holds the full process; it does not duplicate it.