mwguerra

Analyze, test, and prepare apps for production with Pest and Playwright testing

This skill should be used when encountering errors during development, when the user mentions an error, when debugging issues, or when asked to "fix an error", "debug this", "why is this failing", "solve this error". Provides intelligent error recognition, solution lookup from past errors, and error logging for future reference.

This skill should be used when the user asks to "manage notes", "update vault", "add to obsidian", "document in vault", "search my notes", "find related notes", or when working with Obsidian vault files. Also triggers when discussing knowledge management, note organization, or when Claude Code auto-captures commits, tasks, or component creation.

This skill should be used when conducting PRD interviews, creating product requirements documents, planning new features, documenting bug fixes, or when using commands like "/prd-builder:prd", "/prd-builder:feature", "/prd-builder:bugfix", or "/prd-builder:refine". Provides comprehensive interview frameworks and question templates for building thorough PRDs.

Execute complete user flow testing with Playwright MCP, testing end-to-end journeys through the application

Systematically test all pages for errors, functionality, and proper rendering using Playwright MCP

Execute comprehensive role-based E2E testing with Playwright, testing all user flows for each role

Orchestrate app launch preparation - SEO, screenshots, personas, ads, articles, landing pages

Use when asked to implement, build, add, fix, refactor, or change anything in a codebase — vague asks included. Tier-driven phases: intake, investigate, plan, build, verify, deliver. Entry point: /implement.

The map-reduce + blackboard pipeline that lets a small-context model digest inputs far beyond one attention window — a codebase, a long document, a corpus, a multi-part idea — and state only evidence-anchored, citation-checked conclusions. Use when / Trigger: executing or resuming an analyst run (/analyst:digest, /analyst:resume, /analyst:show), or any analysis input exceeds one 200-line chunk.

Use whenever a change needs a system-design decision — architecture, system design, data model, module/service boundaries, interface/API contracts, scale, or an ADR. The canonical discipline for designing systems: tradeoffs made explicit, the design sized to the 15 elicited context fields, one-way doors found by a five-flag checklist (one ADR each), every component earning its place through a two-cell subtraction walk, and every "start simple" seam carrying a concrete extraction trigger. Executed as checkpointed run steps (references/phase-*.md) that write into docs/architecture/ + docs/adr/ per scribe's documentation contract.

Stay focused on the project with the task in hand; recall another project's knowledge ONLY when the task actually needs it. When a task requires changing a shared dependency you own (a local composer/npm package in another repo), make the change IN that owning repo — commit, push, retag — then update and re-verify the consumer. Trigger: an edit is about to land inside a dependency directory, or a task can't be done without touching a package you maintain elsewhere.

Use when asked for a deep audit, production-readiness review, architecture review, or prioritized recommendations across a codebase or subsystem — orchestrates parallel reader agents with adversarial verification and publishes findings to docs/deep-analysis/

Run a large, multi-place task as a checkpointed state machine over the runs store — plan, adversarial plan review, wave-by-wave execution, synthesis — one step per invocation, resumable after any interruption. Trigger: cross-file refactor, data migration, large feature build, multi-source research — work that cannot finish in one pass. Manual invocation: /deep-work.

Use before ending any turn that used tools or produced a deliverable — when tempted to ask "Want me to…?", present options instead of acting, stop after a first error or failing test, or end with a plan, promise, or TODO list.

Use when writing any user-facing reply — answers, status updates, summaries, or final reports — especially after multi-step work, when tempted to show process, add headers to a short answer, open by classifying the question, or open with praise.

Run a large, multi-place, uncertain task to completion via "plan → adversarial review → serial execute → synthesize & verify." Trigger: cross-file refactor, data migration, large feature build, system audit, deep research — tasks that can't be done in one pass and touch many places. Manual invocation: /deep-work.

Use when asked to implement, build, add, fix, refactor, or change anything non-trivial in a codebase — especially vague asks ("do that", "make it work") that need clarification, planning, and verified delivery with tests and commits

Opinionated CORE Laravel 13 + Pest 4 conventions, applied by default on any Laravel project — artisan-first file creation, Eloquent/migration/queue/ scheduler patterns, fail-closed multi-tenancy, parallel-safe tests, and a "verified before done" bar. Composes with (never duplicates) maestro's stack-agnostic discipline. Use when / Trigger: editing or creating anything in a Laravel codebase — models, migrations, factories, jobs, scheduled commands, Filament resources, or Pest tests; whenever you reach for a file generator, design a schema/relationship, write a queued job or a tenant-scoped query, or are about to call a Laravel task "done."

Use before ending any turn that used tools or produced a deliverable — when tempted to ask "Want me to…?", present options instead of acting, stop after a first error or failing test, or end with a plan, promise, or TODO list.

Use before claiming anything works, is fixed, is done, or passes; before status updates on changes you haven't run; before agreeing with someone else's claim about your work; and before state-changing commands like restarts, deletes, or config edits.

The discipline behind maestro:regression — prove a change didn't break existing work by running the suite, an adversarial bounded blast-radius probe against documented architecture contracts, and honest coverage, then emit a verdict taskmanager's done-gate enforces. Trigger: a change is about to be marked done / committed and you must confirm it didn't regress existing behavior or violate a documented boundary.

The house rules for building Filament v5 panels — schema layout, navigation grouping, relation managers, save-redirects, delete placement, the user-menu profile/settings page, native authentication + optional authenticator-app (TOTP) 2FA, and no public registration. Opinionated, prescriptive, and grounded in real Filament 5.6 source so every namespace and method is correct. Trigger: load whenever editing Laravel/Filament code — creating or changing a Filament Resource, form/table schema, page (Create/Edit/List), RelationManager, or PanelProvider; wiring panel auth/2FA; or scaffolding admin UI with `make:filament-*`.

Take a conclusion, code, fix, or design you just produced and spawn an independent agent to adversarially re-check it — assuming it likely missed something, with the job of finding holes rather than affirming. Trigger: you just reached an important conclusion/fix/design and want to confirm before delivering, or you changed a high-risk core. Manual invocation: /adversarial-verify.

Use for any task or question involving Livewire. Activate if user mentions Livewire, wire: directives, or Livewire-specific concepts like wire:model, wire:click, wire:sort, or islands, invoke this skill. Covers building new components, debugging reactivity issues, real-time form validation, drag-and-drop, loading states, migrating from Livewire 3 to 4, converting component formats (SFC/MFC/class-based), and performance optimization. Do not use for non-Livewire reactive UI (React, Vue, Alpine-only, Inertia.js) or standard Laravel forms without Livewire.