plugins

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 when asked for a deep audit, deep analysis, production-readiness review, architecture assessment, or prioritized recommendations across a whole codebase or subsystem — orchestrates parallel reader agents with adversarial verification and publishes findings to docs/deep-analysis/

Turn the work just done into VETTED lessons that survive across sessions and projects — harvest the session's decisions/errors, draft candidate lessons, refute them adversarially, and promote only the survivors into taskmanager memories. The self-improvement loop, gated so a false lesson can never silently change how the suite works. Trigger: end of a substantial piece of work / a wrap-up moment, or when asked to capture lessons learned.

Manage project memories - constraints, decisions, conventions with conflict detection and resolution

Manage tasks, state, and memories - parse PRDs into hierarchical tasks with dependencies and complexity

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.

The suite's risk-sized front door: given a request, name the right top-level PIPELINE (which existing entry points, in what order) by scope and risk — analysis, trivial change, bug fix, feature/high-risk, or codebase health. Advisory; it routes the pipeline only and never sizes verification depth (the brain's job). Trigger: a "which pipeline / where do I start / what process for this / route this" question, or an ambiguous ask whose right path is unclear.

A durable, disposable home for in-flight thinking that overflows a single context window — layered scratch → (optional) blackboard → (optional) conclusions under thoughts/<task-slug>/, refuted by the existing adversarial-verify and drained into durable truth (scribe / deep-analysis) when it settles. Trigger: ONLY when one task won't fit in one context (multi-session work, or a deep-work/deep-analysis run whose shared board must survive the window). Below that bar, think in-context.

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.

Use whenever you make or discover a decision, fix a non-trivial error, change architecture or what the system does, or defer something undecided — and before acting on any task. The canonical contract for how docs/ works: docs/ is the single source of truth (read it first, write it after), its truth is typed and verified, and stale docs are always a defect. Adopted by every plugin, command, and agent that reads or writes project state.

Use whenever a change needs a system-design decision — architecture, system design, data model, module/service boundaries, interface/API contracts, scalability/scale, or an ADR. The canonical discipline for designing systems: architecture is tradeoffs, engineered, never over-engineered. Right-size the present, place clean seams for likely futures with explicit extraction triggers, decide the irreversibles now and defer the reversible, elicit real scale/risk case-by-case, and trace every choice to the PRD. Writes its output into docs/architecture/ + docs/adr/ per scribe's documentation contract.

Use at the start of any multi-step task and during exploration — before reading files, searching, or re-checking completed work, especially when tempted to read whole files, re-verify known facts, or run independent lookups one at a time.

Use when writing or editing code in an existing codebase — before adding comments, docstrings, try/catch blocks, validation, logging, or TODOs the surrounding file doesn't have, and before explaining your style choices in the reply.

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

Use when implementing any change in existing code — when tempted to clean up nearby code, add unrequested validation or options, fix something "arguably in scope", or when the diff is growing past what was asked.