@mrciphersmith/keryx 0.3.2 → 0.3.5

package/src/gdskills/bundled/stacks/php-laravel/skills/php-laravel-code-review/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: php-laravel-code-review
+description: "Use when auditing a PHP/Laravel diff before merge for Eloquent and Blade pitfalls -- \$fillable/\$guarded mass-assignment gaps, missing eager-loaded relationships causing N+1 queries, string-interpolated DB::raw() SQL, unescaped {!! !!} Blade output, a route dropped from VerifyCsrfToken coverage, and a queued job with no idempotency guard. Not for a template review in another web framework's own view layer (use that framework's own code-review skill). Read-only, no edits."
+triggers:
+  - "review this Laravel diff for mass assignment issues"
+  - "check this Eloquent change for N+1 queries"
+  - "review this Laravel pull request for security issues"
+  - "any raw SQL string building in this PHP change"
+  - "check this Blade template for unescaped output"
+  - "review this queue job for idempotency"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# PHP / Laravel code review
+
+Read-only review of a PHP/Laravel change for framework-specific risks:
+mass assignment, N+1 queries, raw SQL interpolation, unescaped Blade
+output, missing CSRF protection, and non-idempotent queue jobs. This
+skill never edits code — it reports findings. `rules/coding-style.mdc`,
+`rules/patterns.mdc`, and `rules/security.mdc` are the rule set findings
+are checked against.
+
+## Workflow
+
+### Step 1: Scope the review
+
+1. Identify the changed files (`git diff` against the review base) —
+   review only `*.php` files in the diff (controllers, models, Form
+   Requests, jobs, migrations, Blade templates), not the whole repository.
+2. Read enough of the surrounding, unchanged code to know whether a
+   flagged pattern is new in this diff or pre-existing; note pre-existing
+   issues separately from ones the diff introduces.
+
+### Step 2: Check each changed file against the focus list
+
+**Mass assignment**
+- An Eloquent `create()`/`update()`/`fill()` call built from
+  `$request->all()`/`$request->input()` with no validation step ahead of
+  it — flag it; the fix is `$request->validated()` from a Form Request.
+- A model touched by the diff with neither `$fillable` nor `$guarded` set
+  (or `$guarded = []`) — flag as mass-assignment exposure.
+
+**N+1 queries**
+- A relationship accessed inside a loop (`foreach`, `->map()`, a Blade
+  `@foreach`) over a collection with no preceding `with()`/`load()` for
+  that relationship — flag it as a likely N+1.
+- A paginated/listing query that will be iterated for a relationship
+  display but omits `with([...])` in the query itself.
+
+**Raw SQL and injection**
+- `DB::select`/`DB::statement`/`whereRaw`/`selectRaw`/`DB::raw` with a
+  variable interpolated directly into the SQL string instead of passed as
+  a binding — flag as SQL injection risk regardless of how trusted the
+  input currently looks.
+
+**Blade output**
+- `{!! $value !!}` rendering a value that traces back to user input
+  (request data, a stored field a user can edit) without a stated
+  sanitization step — flag as an XSS risk; `{{ }}` is the default unless
+  there is a concrete reason for unescaped output.
+
+**CSRF**
+- A new POST/PUT/PATCH/DELETE route added to, or a route removed from,
+  the CSRF-exempt list (`VerifyCsrfToken`'s `$except`, or an
+  `ValidateCsrfToken` exclusion) with no stated reason — flag it as worth
+  confirming, especially for a browser-facing form route.
+
+**Queue jobs**
+- A new `ShouldQueue` job whose `handle()` performs a side effect
+  (charging a card, sending a one-time notification, creating a record)
+  with no `ShouldBeUnique`/`uniqueId()` or idempotency check — flag as a
+  duplicate-delivery risk on any at-least-once connection, which most
+  production queue configurations are.
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (mass
+assignment, N+1, injection, XSS, CSRF, duplicate side effect), and the
+fix direction — but do not apply it.
+
+```
+app/Http/Controllers/OrderController.php:24 — Order::create($request->all())
+  with no prior validation. Risk: any field in the request payload that
+  matches a fillable column can be mass-assigned. Fix direction: add a
+  StoreOrderRequest Form Request and call Order::create($request->validated()).
+```
+
+## Rules
+
+- NEVER edit code — findings and fix direction only.
+- Flag mass assignment, N+1 queries, raw SQL interpolation, unescaped
+  Blade output on user-influenced data, missing/loosened CSRF protection,
+  and non-idempotent queue jobs; do not report generic style nits already
+  covered by `Pint`/PSR-12 (those are noise here).
+- Distinguish a finding the diff introduces from a pre-existing one in
+  code the diff merely touches.
+- When a suspected N+1 is not certain from reading alone (a relationship
+  might already be eager-loaded further up the call chain), say "confirm
+  with `DB::enableQueryLog()`/a query-count assertion" rather than
+  asserting it as fact without evidence.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "The form only has a few fields, `$request->all()` is fine here" | The request payload is not bounded by the form's own fields — an attacker can add extra keys; validate and use `validated()` regardless of form size |
+| "This raw SQL is only reachable from an admin route" | Admin-only is a claim about the current deployment, not a property of the code; interpolated SQL is still injectable if that assumption ever changes |
+| "I'll just fix the mass-assignment issue myself since it's a one-line change" | This skill is read-only; report the finding and its fix direction, do not edit the file |
+| "The queue job basically never gets retried in practice" | Most production queue connections are at-least-once by design; "basically never" is not a guarantee, flag the missing idempotency guard regardless |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed `*.php` file in the diff was read, not just files named
+  in the PR description.
+- Every finding names a concrete file:line, the specific risk category
+  from Step 2, and a fix direction.
+- No source file was modified by this review.
+- Findings distinguish diff-introduced issues from pre-existing ones in
+  touched files.

package/src/gdskills/bundled/stacks/php-laravel/skills/php-laravel-code-review/evals.json

@@ -0,0 +1,76 @@
+{
+  "triggers": {
+    "positive": [
+      "Can you look at this UserController@update change for fields a client shouldn't be able to touch?",
+      "This orders index page got slow after we added the customer relationship, can you spot the query issue?",
+      "We're about to ship this PR touching checkout, anything jump out before I approve it?",
+      "This report generator concatenates the date range param straight into a DB::select() call, is that safe?",
+      "Does this admin view use raw unescaped output anywhere for the comment body field?",
+      "If the queue redelivers this SendInvoiceEmail job, will the customer get charged or emailed twice?",
+      "Take a look at this controller diff and flag anything risky",
+      "Does this migration and model change look safe to merge?"
+    ],
+    "negative": [
+      "Write Pest tests covering this controller's validation rules",
+      "Implement the missing eager loading in this order listing page",
+      "Fix the composer dependency conflict blocking this build",
+      "Review this Rails controller diff for mass assignment issues",
+      "Review this Express route for SQL injection in a raw query",
+      "Review this Django view for unescaped template output"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "review-flags-raw-sql-interpolation",
+      "prompt": "Review this diff:\n\n```php\npublic function search(Request $request)\n{\n    $term = $request->input('q');\n    $results = DB::select(\"select * from products where name like '%$term%'\");\n    return view('products.search', ['results' => $results]);\n}\n```",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct review flags the interpolated $term inside the raw SQL string passed to DB::select() as a SQL injection risk, names the specific line/pattern, and gives the fix direction of using a parameter binding (e.g. DB::select('select * from products where name like ?', [\"%$term%\"])) or the query builder, without actually rewriting the code itself since this skill is read-only.",
+          "pass_criteria": [
+            "Names the DB::select(\"...$term...\") call as the specific finding, not a generic 'be careful with SQL' comment.",
+            "States the risk concretely as SQL injection (an attacker-controlled value reaching the query string unescaped).",
+            "Gives the fix direction of a parameter binding or the query builder (e.g. DB::select('...where name like ?', [...]) or Product::where('name', 'like', \"%$term%\")) without rewriting the file itself."
+          ],
+          "fail_criteria": [
+            "Says the interpolated $term is not a real risk here (e.g. because it only searches products, or because Eloquent/Laravel already escapes it automatically)."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "products.search:3 -- DB::select(\"select * from products where name like '%$term%'\") interpolates $request->input('q') directly into the raw SQL string. Risk: SQL injection -- a crafted 'q' value (e.g. `%' OR '1'='1`) breaks out of the intended LIKE clause. Fix direction: use a binding instead of interpolation, e.g. DB::select('select * from products where name like ?', [\"%{$term}%\"]), or switch to the query builder: Product::where('name', 'like', \"%{$term}%\")->get(). This is a read-only review -- I'm not applying the fix myself.",
+        "known_wrong": "This looks fine -- it's just a product search endpoint, DB::select() runs against the products table and the term is only used for a LIKE match, so there's no real injection surface here worth flagging.",
+        "vague": "Might want to double check how user input is handled in that query before merging.",
+        "subtle_wrong": "The DB::select() call is interpolating user input, but since $term only ever gets wrapped in %...% for a LIKE search and the products table has no sensitive columns, this is low-risk enough to leave as a minor note rather than a blocking finding -- worth mentioning in passing but not worth flagging as an actual SQL injection risk."
+      },
+      "anti_patterns": ["DB::select"]
+    },
+    {
+      "id": "review-flags-unescaped-blade-output",
+      "prompt": "Review this diff:\n\n```blade\n<div class=\"comment-body\">\n    {!! $comment->body !!}\n</div>\n```\n\n$comment->body is user-submitted text stored as-is when a visitor posts a comment.",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct review flags {!! $comment->body !!} as rendering unescaped, user-submitted content -- an XSS risk -- and gives the fix direction of switching to {{ $comment->body }} (escaped output) or explicitly sanitizing the value through a purifier before it reaches unescaped output, without applying the fix itself.",
+          "pass_criteria": [
+            "Names {!! $comment->body !!} as the specific finding, not a generic 'watch your Blade output' comment.",
+            "States the risk concretely as XSS, tied to $comment->body being user-submitted and stored as-is.",
+            "Gives a fix direction: switch to {{ }} escaped output, or run the value through a sanitizer/purifier before rendering it unescaped."
+          ],
+          "fail_criteria": [
+            "Says {!! !!} is fine here because the value 'is just a comment' or because Blade/Laravel already sanitizes stored content by default."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "resources/views/comments/show.blade.php -- {!! $comment->body !!} renders $comment->body unescaped. Since the prompt states this is user-submitted text stored as-is, this is an XSS risk: a comment body containing a <script> tag or an event-handler attribute would execute in every other visitor's browser who views this comment. Fix direction: switch to {{ $comment->body }} so it goes through Blade's default htmlspecialchars escaping, or, if rich-text formatting genuinely needs to be preserved, run the value through an HTML purifier at write time (or render time) before it ever reaches {!! !!}. This is a read-only review -- I'm flagging it, not editing the template.",
+        "known_wrong": "{!! $comment->body !!} looks fine -- it's just displaying a comment's text content, and Blade templates handle escaping for you automatically regardless of which syntax you use, so there's nothing to flag here.",
+        "vague": "Might be worth double-checking how comment content gets rendered before this ships.",
+        "subtle_wrong": "This uses {!! !!} for user-submitted content, which is usually a concern, but since it's scoped to a 'comment-body' div with its own CSS class and comments already go through the standard profanity filter on submission, the practical XSS risk here is low enough that it doesn't need to block this diff -- worth a passing mention but not a real finding."
+      },
+      "anti_patterns": ["{!! "]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/php-laravel/skills/php-laravel-implementation/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: php-laravel-implementation
+description: "Use when implementing or extending a feature in a PHP 8.2+ / Laravel application -- controllers, Form Request validation, Eloquent models and relationships, migrations, route-model binding, middleware, queued jobs, and service container bindings. Not for writing or fixing tests (use php-laravel-testing)."
+triggers:
+  - "add an endpoint to this Laravel controller"
+  - "implement this feature in our Laravel app"
+  - "add a new Eloquent model with a migration"
+  - "wire up validation for this form submission"
+  - "add a queued job that sends this notification"
+  - "add a new relationship between these two models"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# PHP / Laravel implementation (PHP 8.2+, Laravel 11-13)
+
+Implement or extend a feature in a Laravel application: routes,
+controllers, Form Requests, Eloquent models/migrations, jobs, and service
+container wiring. Scoped to PHP/Laravel specifically —
+`rules/coding-style.mdc`, `rules/patterns.mdc`, and `rules/security.mdc`
+carry the full stack-specific rule set this skill's checklist is built
+from; read them before writing code, not just this summary.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+1. Read `composer.json` for the `php` and `laravel/framework` version
+   constraints — do not use a language or framework feature the project's
+   own constraints predate.
+2. Find the existing layout: `app/Http/Controllers`,
+   `app/Http/Requests`, `app/Models`, `app/Actions` or `app/Services` (if
+   present), `database/migrations`, `routes/web.php`/`routes/api.php`.
+   Match it; do not invent a different layout for one change.
+3. Read 1-2 neighboring controllers/models for: whether Form Requests are
+   already used for validation, whether an action/service layer exists,
+   the project's testing framework (Pest vs PHPUnit, from
+   `tests/Pest.php` or `phpunit.xml`), and whether `Pint`/`Larastan` are
+   configured.
+
+### Step 2: Design before writing
+
+- Decide the layer for new logic: a thin controller method that
+  validates (Form Request) and delegates; the actual rule lives in a
+  model method, an action class, or a service (`rules/patterns.mdc`).
+- For a new Eloquent model: decide `$fillable` vs `$guarded` up front
+  (never leave both unset), the relationships it needs, and whether any
+  attribute needs a cast (`casts()` method, or `$casts` on an
+  unmigrated codebase).
+- For anything touching request input, plan the Form Request's
+  `rules()`/`authorize()` before writing the controller method that uses
+  it.
+- For a new queued job, decide its idempotency story
+  (`ShouldBeUnique`/`uniqueId()`, or an explicit dedupe check) before
+  writing `handle()` — most production Laravel queue connections
+  (`redis`, `sqs`, `database`) are at-least-once, but the actual
+  guarantee depends on the project's configured connection: the
+  framework's own out-of-the-box default, `sync`, runs the job inline
+  with no retry at all.
+
+### Step 3: Implement
+
+1. Add/extend the migration (`php artisan make:migration ...`) with
+   explicit column types and any needed index/foreign key — run
+   `php artisan migrate` (or the project's test-database equivalent)
+   locally to confirm it applies cleanly.
+2. Add/extend the Eloquent model: `$fillable`/`$guarded`, typed
+   relationship methods, `casts()`, scopes for reused filters.
+3. Add/extend the Form Request for validation; keep the controller method
+   itself limited to resolving the request, delegating to the model/
+   action/service, and returning a response.
+4. Register the route with route-model binding where a resource ID
+   appears in the URI, and attach any route-specific middleware with
+   `->middleware(...)`.
+5. Use constructor property promotion and `readonly` for simple DTOs/
+   value objects introduced along the way (`rules/coding-style.mdc`).
+6. Eager-load (`with()`) any relationship the new code accesses inside a
+   loop over a collection — do not introduce a new N+1.
+
+### Step 4: Verify
+
+```bash
+composer install
+./vendor/bin/phpstan analyse   # if configured (Larastan)
+php artisan test                # or ./vendor/bin/pest / ./vendor/bin/phpunit
+```
+
+Run the project's configured formatter (`./vendor/bin/pint`) if present.
+Fix findings at the root cause per `rules/security.mdc` and
+`rules/coding-style.mdc`; a failing static-analysis or test run at this
+step is a signal to fix the implementation, not to reach for
+`php-laravel-build-fix`'s scope unless the failure is purely a build/
+dependency/autoload problem unrelated to the feature logic.
+
+### Step 5: Report
+
+```
+Implemented: app/Http/Controllers/OrderController.php,
+  app/Http/Requests/StoreOrderRequest.php,
+  app/Models/Order.php, database/migrations/..._create_orders_table.php
+  - New Order model with $fillable allowlist and validated() request flow
+  - phpstan analyse and php artisan test both pass
+```
+
+## Rules
+
+- Every Eloquent model that can be mass-assigned declares `$fillable` or
+  `$guarded` explicitly — never leave both unset.
+- Build create/update calls from `$request->validated()`, never raw
+  `$request->all()`/`$request->input()`.
+- Eager-load a relationship before accessing it inside a loop over a
+  collection; a per-row relationship access with no eager load is an N+1
+  query.
+- Every queued job assumes the configured connection can redeliver it and
+  guards its side effect accordingly -- true for any at-least-once
+  connection, which is most production configurations but not `sync`.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just use `$request->all()` here, the form only has a few fields" | Bypasses validation and can mass-assign any column present in the request payload, not just the form's own fields; use `validated()` |
+| "This model is internal-only, it doesn't need `$fillable`" | "Internal-only" today does not prevent a future controller or API endpoint from mass-assigning it; declare the allowlist regardless |
+| "The relationship is only accessed for a handful of rows, eager loading is overkill" | "A handful" in a test fixture can be thousands in production; eager-load by default and only skip it with a stated reason |
+| "This job basically never gets retried, idempotency can wait" | Most production queue connections are at-least-once by design — a rare retry is still a retry, and the cost of guarding it up front is small compared to a duplicated side effect in production |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- `php artisan test` (or the project's Pest/PHPUnit command) passes.
+- The project's configured static analysis (Larastan/PHPStan), if
+  present, exits clean.
+- Every new/touched Eloquent model has `$fillable` or `$guarded` set.
+- Every new controller path that accepts user input validates through a
+  Form Request or `$request->validate([...])` before using the data.

package/src/gdskills/bundled/stacks/php-laravel/skills/php-laravel-implementation/evals.json

@@ -0,0 +1,75 @@
+{
+  "triggers": {
+    "positive": [
+      "Add a checkout endpoint that saves the order straight from the request body",
+      "Build a new model for storing customer addresses with a migration",
+      "Set up validation for this contact form controller action",
+      "Add a job that emails users when their subscription renews",
+      "Wire up route model binding for the invoice show page",
+      "Add a relationship between Author and Book and expose it on the API",
+      "Users need a way to downgrade their subscription plan mid-cycle and get a prorated credit",
+      "We need to start tracking refund requests with their own database table and model"
+    ],
+    "negative": [
+      "Write Pest tests for this Eloquent model's validation rules",
+      "Review this Laravel controller diff for N+1 queries and mass assignment",
+      "Fix this failing composer install after a dependency version bump",
+      "Add this endpoint in a Django REST framework view with a serializer",
+      "Implement this feature in a Rails controller using ActiveRecord",
+      "Add a new Express route handler backed by a Sequelize model"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "mass-assignment-validated-input",
+      "prompt": "I'm adding a controller method that creates an Order from the incoming request. How should I build it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer validates the incoming request through a Form Request (or $request->validate([...])) and builds the Eloquent create call from the validated array (e.g. Order::create($request->validated())), not from $request->all()/$request->input(), and states that the Order model itself declares $fillable or $guarded so mass assignment is bounded even if an unexpected field reaches the create call.",
+          "pass_criteria": [
+            "Shows the concrete create call built from the validated data (e.g. Order::create($request->validated())), not just says 'validate the input'.",
+            "States that the Order model declares $fillable or $guarded explicitly.",
+            "Uses a Form Request class or $request->validate([...]) to produce the validated array, named concretely rather than left implicit."
+          ],
+          "fail_criteria": [
+            "Recommends passing $request->all() or $request->input() (with no validated()/allowlist step) directly into Order::create() or a mass-update call. Mentioning $request->all() only to warn against using it this way is not a failure -- only recommending it as the actual approach is."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Create a StoreOrderRequest Form Request with the rules() the order needs (customer_id required/exists, line item shape, etc.), then in the controller call Order::create($request->validated()) -- never Order::create($request->all()). Validating first catches malformed input before it reaches the database, and passing only the validated() subset means an attacker can't smuggle an extra field into the payload that happens to match a column name. On top of that, make sure the Order model itself declares protected $fillable = ['customer_id', 'total', 'status', ...] (or $guarded, if that's the project's convention) so mass assignment stays bounded to those columns even if the validated array ever grows to include something it shouldn't.",
+        "known_wrong": "Keep it simple: in the controller, just do Order::create($request->all()) -- Eloquent's mass assignment protection via $fillable already guards which columns can be written, so there's no need for a separate Form Request or validated() step for something like this. If a required field is missing, the database's NOT NULL constraint will catch it and throw anyway.",
+        "vague": "Make sure you validate the incoming data properly before creating the order, and don't just trust whatever the client sends.",
+        "subtle_wrong": "Add inline validation with $request->validate(['customer_id' => 'required|exists:customers,id', 'total' => 'required|numeric']) at the top of the controller method so the required fields are confirmed present and well-typed, then create the order with Order::create($request->all()) since the validation call already confirmed the request looks right -- that way you get the safety of validation without needing to thread a separate validated() array through, and the model's $fillable list still bounds which columns can actually be written."
+      },
+      "anti_patterns": ["$request->all()"]
+    },
+    {
+      "id": "eager-load-relationship",
+      "prompt": "I'm adding a page that lists orders and shows each order's customer name. What should I watch out for when I write the loop?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer eager-loads the customer relationship (Order::with('customer')->get(), or ->load('customer') on an already-fetched collection) before the loop that reads $order->customer->name for each row, rather than letting each iteration lazily trigger its own query -- an N+1 query pattern that scales with the number of orders shown.",
+          "pass_criteria": [
+            "Shows the concrete eager-load call (with('customer') on the query, or ->load('customer') on the collection) before/around the loop, not just says 'watch out for N+1'.",
+            "Explains that accessing $order->customer inside the loop with no eager load issues one additional query per order."
+          ],
+          "fail_criteria": [
+            "States or implies that accessing $order->customer inside the loop with no eager load is fine because Eloquent's lazy loading 'only runs one query overall' or is otherwise not a real concern for this case."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Fetch the orders with the relationship eager-loaded up front: Order::with('customer')->get() (or, if you already have an $orders collection from elsewhere, $orders->load('customer') before the loop). Then the loop that does foreach ($orders as $order) { echo $order->customer->name; } only issues two queries total -- one for the orders, one batched query for all their customers -- instead of one query per order. Accessing $order->customer inside the loop with no eager load is the classic N+1: Eloquent lazily fires a fresh query the first time each order's customer is touched, so a 200-row order list turns into 201 queries.",
+        "known_wrong": "You can just loop over the orders and read $order->customer->name directly -- foreach ($orders as $order) { echo $order->customer->name; }. This won't cause any N+1 issue since each customer lookup is a fast, indexed primary-key query, and Eloquent only loads what's actually accessed, which keeps things efficient for a page that's not showing thousands of rows.",
+        "vague": "Be careful about how you access the relationship in the loop so it doesn't end up being slow.",
+        "subtle_wrong": "Fetch the orders with their line items eager-loaded, Order::with('items')->get(), since that's usually the more expensive relationship to compute per row, and then loop with foreach ($orders as $order) { echo $order->customer->name; }. Eager-loading items up front avoids the main N+1 risk on this page; the customer lookup per row is cheap enough on its own that it doesn't need the same treatment."
+      },
+      "anti_patterns": ["N+1"]
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/php-laravel/skills/php-laravel-testing/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: php-laravel-testing
+description: "Use when a Laravel application's test suite needs writing, extending, or fixing -- Pest or PHPUnit feature/unit tests, model factories, RefreshDatabase, HTTP testing helpers, and Queue/Mail/Event/Http fakes."
+triggers:
+  - "write a Pest test for this controller"
+  - "add feature tests for this API endpoint"
+  - "fix this failing PHPUnit test"
+  - "add a factory and test coverage for this model"
+  - "write tests that assert this job gets queued"
+  - "test this form's validation errors"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# PHP / Laravel testing (Pest / PHPUnit)
+
+Write, extend, or fix a Laravel application's test suite: Pest or PHPUnit
+feature/unit tests, model factories, database isolation, HTTP assertions,
+and framework fakes. `rules/testing.mdc` carries the full rule set this
+skill's checklist is built from — read it, not just this summary, before
+writing tests.
+
+## Workflow
+
+### Step 1: Discover the project's test conventions
+
+1. Check whether the project uses Pest (`tests/Pest.php` present) or
+   PHPUnit (test classes extending `Tests\TestCase`); match whichever is
+   already in use, do not introduce the other framework into an existing
+   suite.
+2. Find the layout: `tests/Feature` for anything touching the framework
+   (routes, database, queue, auth), `tests/Unit` for an isolated class.
+   Match it for the code under test.
+3. Read 1-2 neighboring test files for: factory usage patterns,
+   `RefreshDatabase`/`DatabaseTransactions` usage, whether fakes
+   (`Queue::fake()`, `Mail::fake()`) are already the project's norm, and
+   naming style.
+
+### Step 2: Plan test cases
+
+**Feature tests (HTTP):** happy path, validation failures
+(`assertInvalid`), authorization failures (`assertForbidden`/
+`assertUnauthorized`), not-found cases (`assertNotFound`).
+
+**Model/unit tests:** relationships resolve to the right type, casts
+produce the right PHP type, scopes filter correctly, computed
+accessors/mutators behave at their boundaries (empty/zero/null inputs).
+
+**Jobs/events/mail:** dispatched with the right arguments
+(`Queue::fake()` + `Queue::assertPushed(...)`), not that they actually
+ran — assert on the fake, don't let a test send real mail or hit a real
+queue/HTTP endpoint.
+
+### Step 3: Write
+
+1. Create/extend the test file at the project's own convention path
+   (Pest script or PHPUnit class, matching Step 1).
+2. Use model factories (`Model::factory()->create([...])`) for test data;
+   override only the fields the test cares about.
+3. Apply `RefreshDatabase` (or the project's existing trait) on any test
+   touching the database.
+4. Use `actingAs($user)` for authenticated routes; use a factory-built
+   user with the right role/permissions rather than mocking auth
+   internals.
+5. Fake external effects (`Queue::fake()`, `Mail::fake()`, `Event::fake()`,
+   `Http::fake([...])`, `Storage::fake('disk')`) instead of letting a
+   test perform a real side effect.
+6. Never wait on an async/queued effect with `sleep()`; assert against
+   the fake, or dispatch/handle the job synchronously in the test.
+
+### Step 4: Run and fix
+
+```bash
+php artisan test
+# or: ./vendor/bin/pest    /    ./vendor/bin/phpunit
+```
+
+Fix failing tests (max 3 iterations) — fix the test, not the source under
+test, unless the test itself has correctly caught a real bug (say so in
+the report rather than silently changing production code).
+
+### Step 5: Report
+
+```
+Generated: tests/Feature/OrderControllerTest.php
+  - 6 cases: happy path, validation failure, unauthorized, N+1-safe listing
+  - php artisan test passes
+```
+
+## Rules
+
+- ALWAYS match the project's existing framework (Pest vs PHPUnit) and
+  factory/fixture conventions found in Step 1, not a different project's
+  style.
+- NEVER modify source code — only test files and factories.
+- NEVER let a test send a real email, dispatch to a real queue connection,
+  or make a real outbound HTTP call — fake it.
+- NEVER use `sleep()` to wait for a queued job or async effect.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add a short `sleep(1)` so the queued job has time to run" | Non-deterministic and slow; use `Queue::fake()` and assert what was pushed, or run the job handler directly in the test |
+| "This test keeps failing on validation, I'll just assert the response isn't a 500" | Loses the actual signal — assert the specific status (`assertInvalid`, `assertForbidden`) the endpoint should return, not just "didn't crash" |
+| "I'll call the controller method directly instead of hitting the route" | Skips routing, middleware, and validation the real request path goes through — use the HTTP testing helpers (`$this->postJson(...)`) for a feature test |
+| "Let's just call the real Mailgun sandbox in this test, it's fast enough" | Introduces network flakiness and an external dependency into the suite; `Mail::fake()` asserts the same intent without a real send |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The test file sits at the project's own convention path (Pest or
+  PHPUnit), matching the style read in Step 1.
+- `php artisan test` (or the project's Pest/PHPUnit command) exits 0 with
+  every generated test passing.
+- `git status` shows only test files and factories added or modified; no
+  source file under test changed.
+- Every external side effect (mail, queue, outbound HTTP, storage) in a
+  new test is faked, not real.

package/src/gdskills/bundled/stacks/php-laravel/skills/php-laravel-testing/evals.json

@@ -0,0 +1,74 @@
+{
+  "triggers": {
+    "positive": [
+      "How do I cover the happy path for OrderController@update with Pest?",
+      "The /api/subscriptions endpoint has zero coverage, can you add tests for both success and failure?",
+      "InvoiceTest started failing with a missing column error after I added tax_rate to the migration",
+      "The RefundRequest model I just created has no factory yet and no tests",
+      "How do I verify the ShipmentNotification job actually dispatches when an order flips to shipped?",
+      "Does the checkout form request properly reject submissions missing the shipping_address field?",
+      "Add test coverage for the subscription renewal email job",
+      "Write a test that checks an unauthenticated user gets redirected from this route"
+    ],
+    "negative": [
+      "Implement the subscription renewal job itself, not its tests",
+      "Review this Laravel diff for missing eager loading and validation gaps",
+      "Fix this composer autoload error after adding a new namespace",
+      "Write Jest tests for this React checkout form",
+      "Write RSpec tests for this Rails model",
+      "Add pytest coverage for this Django view"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "no-sleep-queue-fake",
+      "prompt": "I want to test that shipping an order dispatches a SendShippingNotification job. How should I write that test?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer uses Queue::fake() before the action under test, performs the action, then asserts with Queue::assertPushed(SendShippingNotification::class, ...) -- checking the job's own arguments, not just that some job of that class was pushed -- rather than letting a real job run and waiting on it with sleep() or a polling delay.",
+          "pass_criteria": [
+            "Calls Queue::fake() before triggering the shipping action.",
+            "Asserts with Queue::assertPushed(SendShippingNotification::class, ...) after the action, shown concretely rather than described in the abstract.",
+            "Checks something about the pushed job's own state (e.g. the order it was built with), not merely that a job of that class was pushed at all."
+          ],
+          "fail_criteria": [
+            "Recommends letting the job actually run against a real queue connection and waiting for it with sleep() or a fixed delay before asserting its effect. Mentioning sleep() only to warn against it is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Call Queue::fake() at the top of the test, then perform the action that ships the order (e.g. hit the ship endpoint or call the service method), then assert with Queue::assertPushed(SendShippingNotification::class, function ($job) use ($order) { return $job->order->is($order); }); -- that checks not just that some SendShippingNotification was pushed, but that it was built for this specific order. Queue::fake() swaps the queue connection for an in-memory recorder, so nothing actually dispatches to a real worker and the assertion is instant and deterministic.",
+        "known_wrong": "Just let the job run for real against the queue connection configured for tests, then after triggering the shipping action add sleep(2) before checking that a notification record exists in the database -- that gives the queue worker enough time to pick up and process the job in the background, which is closer to how it behaves in production than faking it.",
+        "vague": "Make sure the job actually gets dispatched when the order ships and check that it happened.",
+        "subtle_wrong": "Call Queue::fake() before the action, run the shipping action, then assert Queue::assertPushed(SendShippingNotification::class) with no callback -- that confirms a job of the right class was queued. If the test is occasionally flaky in CI because the dispatch happens on a slightly different tick, add a short sleep(1) right after Queue::fake() before triggering the action, just to make sure the fake is fully wired up first."
+      },
+      "anti_patterns": ["sleep("]
+    },
+    {
+      "id": "feature-test-real-route",
+      "prompt": "I need to test that submitting this order form with a missing customer_id returns a validation error. What's the right way to write that test?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer drives the test through the actual HTTP route (e.g. $this->post('/orders', [...]) or postJson for an API test) with customer_id omitted, then asserts the validation failure with assertInvalid(['customer_id']) or an equivalent response-level assertion, rather than instantiating the controller class directly and calling its method in isolation, which bypasses routing, middleware, and the framework's own request validation pipeline.",
+          "pass_criteria": [
+            "Drives the test through the real route (e.g. $this->post(...)/$this->postJson(...) against the actual URI), not a directly instantiated controller.",
+            "Omits customer_id from the submitted payload and asserts the validation failure concretely (e.g. assertInvalid(['customer_id']) or assertSessionHasErrors(['customer_id'])), not just 'checks for an error'."
+          ],
+          "fail_criteria": [
+            "Instantiates the controller class directly (e.g. new OrderController()) and calls its method with a manually built request object instead of going through the actual route."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Use the HTTP testing helper to hit the real route with customer_id left out of the payload: $response = $this->post('/orders', ['total' => 100]); then assert $response->assertInvalid(['customer_id']); (or assertSessionHasErrors(['customer_id']) for a traditional web form). Going through $this->post(...) exercises the actual route, the web/api middleware group, and the Form Request's own validation -- the same path a real browser submission takes -- so the test proves the endpoint itself rejects the bad input, not just that some validation rule object would.",
+        "known_wrong": "Instantiate the controller directly and call its store method with a Request built by hand: $controller = new OrderController(); $request = Request::create('/orders', 'POST', ['total' => 100]); $controller->store($request); -- that's more direct than going through the HTTP kernel and avoids the overhead of dispatching a full request.",
+        "vague": "Submit the form without a customer_id and check that it comes back with a validation error.",
+        "subtle_wrong": "Skip the HTTP layer and test the Form Request's rules() directly: instantiate StoreOrderRequest, call its rules() method, and assert the returned array contains a 'required' rule for customer_id. That confirms the validation rule is defined correctly without the overhead of dispatching a full HTTP request through routing and middleware."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/ruby-rails/agent-refs.json

@@ -0,0 +1,4 @@
+{
+  "agents": [],
+  "note": "honest gate (DeepSeek deepseek-chat runner+judge, strictness high, trials 10, flow 337) ran and failed for all four skills -- trigger accuracy, not behavior content, though three of the eight behavior scenarios scored below 1.0 on this run: ruby-rails-build-fix's no-rubocop-disable-suppression scored 0.4 (below the 0.8 pack floor on its own), ruby-rails-testing's no-sleep-for-jobs scored 0.8, and stub-external-boundary scored 0.9; the other five scenarios scored 1.0. No generated pair ships; pack stays stability: experimental. See governance/eval.json for the recorded reports and W1-stack-catalog.md's Wave 4 batch 5 implementation notes for the diagnosis."
+}