TrevorEdris

Identify and remove AI slop from code comments, documentation, and prose. Use when cleaning up AI-generated output, reviewing for AI tells, or improving signal-to-noise ratio in any text.

Design review for front-end code changes using Playwright for live browser testing. Covers visual hierarchy, accessibility (WCAG AA+), responsive design, and interaction patterns. Use when reviewing UI/UX changes before merge.

Adversarial code review that assumes the worst. Finds failure modes, race conditions, blast radius, and edge cases that optimistic reviewers miss. Use when you want brutal honesty about code resilience.

Perform thorough code review on a PR using the Pragmatic Quality framework. Integrates with Jira to validate implementation matches ticket requirements. Use when reviewing pull requests or providing PR feedback.

Validate implementation plans for completeness, specificity, and actionability. Catches vague language, missing sections, and untestable outcomes.

Interactive PRD creation and iteration for non-technical users. Use this skill whenever the user wants to define product requirements, write a PRD, spec out a feature, describe what to build, or says "what should we build", "write requirements", "create a PRD", "define the product". Also use when updating an existing PRD based on stakeholder or engineering feedback. Guides through structured requirement definition using plain-language facilitation prompts with discovery questions upfront. Auto-validates with /prd-validator after completion.

Translates an approved PRD into a unified ROADMAP.md with phased feature descriptions and implementation checklists. Use this skill whenever an engineer receives a PRD and needs to break it into phases, when the user asks "how do I turn this PRD into a plan", "create a roadmap from requirements", or "decompose this into milestones". Gates on PRD validation — refuses to proceed if the PRD hasn't passed /prd-validator.

Validates PRD.md files for structural completeness, specificity, and actionability before handoff to engineering. Use this skill whenever a PRD exists and needs quality review, before handing requirements to engineers, when the user asks "is this PRD ready" or "validate my requirements", or automatically after /prd-author completes. Checks for required sections, acceptance criteria, scope boundaries, vague language, and requirement ID consistency. Supports --draft mode for work-in-progress PRDs.

Use when creating, editing, reviewing, or rendering software architecture or flow diagrams — C4 diagrams (system context, container, component, deployment, dynamic), sequence diagrams, request-flow visuals, or any Mermaid authoring where the rendered output must be readable. Also use when a Mermaid diagram renders with overlapping labels, parse errors, or a single-column layout, or when the user asks to "diagram the architecture", "draw the request flow", "map the sequences", or wants LucidChart-quality output from Mermaid.

Use when about to create a feature, build a component, add functionality, modify behavior, or start any new work — or when the user asks how should we, what approach, which way, explore options, design X, or spec this out. Triggers before any code, scaffold, or implementation skill runs.

Use when one request spans multiple domains (e.g. code + tests + docs + security + diagrams), has independent workstreams that could run concurrently, or is too large for a single agent in one pass — symptoms include "do all of X, Y, and Z", a multi-part review, or a task that would obviously thrash one agent's context

Use when defining product requirements, writing or updating a PRD, spec'ing out a feature, or deciding what to build — or when the user says write requirements, create a PRD, define the product, what should we build, or hands over stakeholder/engineering feedback to fold into an existing PRD. Especially for non-technical users translating a conversation into structured requirements.

Use when you want brutal, worst-case review of code resilience -- failure modes, race conditions, blast radius, and edge cases optimistic reviewers miss.

Use when reviewing code or a PR for high-confidence, real-exploitation security vulnerabilities (>80% confidence threshold, low false positives).

Use when saving or restoring agent context across sessions -- the user asks to save state, create a handoff, or pause, or the context window nears capacity; or to resume with load handoff, resume from, or continue where we left off.

Use when reviewing a pull request or diff, giving PR feedback, validating an implementation against a Jira ticket or spec, after completing a feature or task, before merging to main, or whenever you need a fresh set of eyes on changes before they ship

NASA Power of 10 Rule 1 — Restrict control flow to simple constructs (no goto, setjmp/longjmp, recursion). Severity: blocker.

NASA Power of 10 Rule 2 — Every loop must have a statically determinable upper bound. Severity: blocker.

NASA Power of 10 Rule 3 — No dynamic memory allocation after initialization. Severity: blocker.

NASA Power of 10 Rule 4 — Functions ≤60 lines (one printed page). Severity: high.

NASA Power of 10 Rule 5 — Average ≥2 runtime assertions per function. Severity: high.

NASA Power of 10 Rule 6 — Declare data at smallest possible scope. Severity: medium.

NASA Power of 10 Rule 7 — Check every non-void return value; validate every parameter. Severity: blocker.

NASA Power of 10 Rule 8 — Limit preprocessor + metaprogramming (no recursive macros, no reflection-for-control-flow). Severity: high.

Show your Pokemon companion or reroll for a new one. Displays braille sprite art with shiny rainbow rendering. Triggered by: pokemon, pocket monster, roll pokemon, my pokemon, what pokemon am I, reroll, new pokemon, swap pokemon.