@mrciphersmith/keryx 0.3.2 → 0.3.3

package/src/gdskills/bundled/stacks/ruby-rails/skills/ruby-rails-code-review/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: ruby-rails-code-review
+description: "Use when reviewing a Rails change for framework-specific risks -- mass assignment gaps, N+1 queries, raw SQL interpolation, raw/html_safe XSS, missing auth/authorization filters, fat controllers/models, and non-idempotent ActiveJobs. Not for a change in another web framework's own MVC layer (use that framework's own code-review skill). Read-only, no edits."
+triggers:
+  - "review this Rails diff for mass assignment issues"
+  - "check this Rails controller for N+1 queries"
+  - "review this Rails change for missing authorization"
+  - "any XSS risk from raw or html_safe in this Rails view"
+  - "review this Rails job for idempotency"
+  - "check this Rails diff for fat controller or fat model smells"
+metadata:
+  origin: authored
+  category: review
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Ruby on Rails code review
+
+Read-only review of a Rails change for framework-specific risks: mass
+assignment, N+1 queries, raw SQL, XSS via `raw`/`html_safe`, missing
+auth/authorization, fat controllers/models, and non-idempotent 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 `*.rb` files (and templates, if in scope) in the diff,
+   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**
+- A model built/updated from `params` uses `params.expect`/
+  `params.require`+`permit` with an explicit attribute list — flag
+  `Model.new(params[:model])`, `record.update(params)`, or any
+  `permit!` on user-controlled params.
+
+**N+1 queries**
+- Any loop (explicit `each`/`map`, or implicit via a view iterating a
+  collection) that calls an association method per iteration — flag it
+  when the association was not eager-loaded (`includes`/`preload`/
+  `eager_load`) before the loop.
+
+**SQL and data access**
+- Flag any `where`, `find_by_sql`, `order`, or `pluck` call built with
+  string interpolation of a value that traces back to user input,
+  instead of parameterized conditions or `sanitize_sql`.
+
+**XSS / output encoding**
+- Flag `raw(...)` or `.html_safe` applied to a value that can contain
+  user-controlled or user-influenced content — it disables ERB's
+  automatic escaping for that value.
+
+**Authentication and authorization**
+- A controller action that should require login has the app's
+  `before_action` auth filter (not accidentally excluded via
+  `skip_before_action`) — flag one that doesn't.
+- Flag an action that checks the user is logged in but never confirms
+  they're allowed to act on *this specific* record (an IDOR risk).
+
+**CSRF**
+- Flag `skip_before_action :verify_authenticity_token` or
+  `protect_from_forgery with: :null_session` added on an action
+  reachable from a standard HTML form, unless the diff itself
+  documents why (e.g. a signature-verified webhook).
+
+**Fat controllers/models**
+- A controller action with inline multi-step business logic, or a model
+  callback orchestrating unrelated side effects (email, third-party
+  call, another model's update) — flag as a candidate for extraction
+  into a service object per `rules/patterns.mdc`.
+
+**Background jobs**
+- An `ActiveJob#perform` whose side effect would be harmful if it ran
+  twice (charge, duplicate send) with no idempotency guard — flag it,
+  since most production Active Job adapters are at-least-once.
+
+### Step 3: Report
+
+For each finding: file:line, the pattern, why it matters (security
+impact, correctness, maintainability), and the fix direction — but do
+not apply it.
+
+```
+app/controllers/orders_controller.rb:18 — builds Order from raw
+  params[:order] with no strong parameters. Risk: mass assignment lets
+  any submitted key (including ones never meant to be user-settable)
+  through. Fix direction: require/permit an explicit attribute list via
+  params.expect(order: [...]) or params.require(:order).permit(...).
+```
+
+## Rules
+
+- NEVER edit code — findings and fix direction only.
+- Flag mass assignment gaps, N+1 queries, raw SQL interpolation,
+  raw/html_safe XSS risk, missing auth/authorization, disabled CSRF
+  protection, fat controller/model smells, and non-idempotent jobs; do
+  not report generic style nits already covered by `rubocop`.
+- 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 (e.g. the
+  association might already be preloaded further up the call chain),
+  say so and recommend confirming with `bullet` or the query log rather
+  than asserting it with certainty.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "This form only has a few fields, mass assignment isn't really a risk here" | Any field in the raw params hash is a risk regardless of the form's apparent size; strong parameters cost nothing and close the gap categorically |
+| "The N+1 here is only over 3-4 records in this view" | Reviews check the code path, not today's data volume — a small collection today is a large one after the feature ships and the table grows |
+| "I'll just fix the missing before_action myself since it's one line" | This skill is read-only; report the finding and its fix direction, do not edit the file |
+| "raw(user.bio) is fine, this is an internal admin tool" | User-controlled data marked pre-escaped is a genuine XSS vector regardless of who the internal audience is; flag it and let the fix direction note the sanitize option |
+
+## Verification
+
+Do not report the review done until all of the following hold:
+
+- Every changed `*.rb` 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/ruby-rails/skills/ruby-rails-code-review/evals.json

@@ -0,0 +1,71 @@
+{
+  "triggers": {
+    "positive": [
+      "Review this Rails diff for a controller action that skips authorization",
+      "Check this Rails change for a query per row in the index view",
+      "Any XSS risk from marking this user bio safe in the view?",
+      "Review this Rails pull request for a fat model with too many callbacks",
+      "Check this Rails job diff for whether it's safe to run twice",
+      "Review this Rails controller for raw params interpolated into a where clause"
+    ],
+    "negative": [
+      "Review this Go diff for goroutine leaks",
+      "Review this Django view for SQL injection",
+      "Implement the fix for the N+1 query you just found",
+      "Write a regression test for this authorization bug",
+      "Fix the rubocop offenses in this Rails file"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "mass-assignment-finding",
+      "prompt": "Review this Rails diff: a create action does Order.new(params[:order]) with no permit call. What do you find?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies Order.new(params[:order]) with no strong parameters as a mass-assignment risk, explains that any key submitted under order gets assigned rather than only intended fields, and reports a fix direction (params.expect/params.require+permit with an explicit attribute list) as a finding only -- it never actually edits or claims to have edited the code, even partially, since this skill is read-only.",
+          "pass_criteria": [
+            "Identifies Order.new(params[:order]) with no strong parameters as the problem, naming it specifically from this diff.",
+            "Explains the concrete risk: any key submitted under :order gets mass-assigned, not just the fields the form is meant to expose.",
+            "States a concrete fix direction (params.expect or params.require+permit with an explicit attribute list) purely as a finding, with no code change applied or described as applied."
+          ],
+          "fail_criteria": [
+            "Actually edits, patches, or claims to have already made even a partial or proof-of-concept code change (this skill is strictly read-only: findings and fix direction only, no edits of any size)."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: `Order.new(params[:order])` builds the model directly from the raw params hash with no `permit` call. That's a mass-assignment risk -- whatever the client submits under `order` gets assigned, not just the fields the form is supposed to expose, so an attacker or a stray client bug could set fields never meant to be user-controlled. Fix direction: require and permit an explicit attribute list, e.g. `params.expect(order: [:item_id, :quantity])` or `params.require(:order).permit(:item_id, :quantity)`, and pass that permitted hash into `Order.new` instead of the raw params. I'm reporting this as a finding rather than making the change, since this review is read-only.",
+        "known_wrong": "This is a known Rails anti-pattern so I went ahead and fixed it directly: I added `params.require(:order).permit(:item_id, :quantity)` above the `Order.new` call and updated it to use the permitted hash. The change is already in place and should be ready to merge as-is.",
+        "vague": "That params usage looks a little loose -- might be worth tightening up before this merges.",
+        "subtle_wrong": "Finding: `Order.new(params[:order])` skips strong parameters, which is worth fixing before merge. I went ahead and made a small proof-of-concept edit adding a `.permit(:item_id)` call so you can see the shape of the fix, though the rest of the form fields would still need to be added to the list before this actually works end to end."
+      }
+    },
+    {
+      "id": "authorization-vs-authentication",
+      "prompt": "Review this Rails diff: a new PATCH /orders/:id action includes before_action :authenticate_user! but doesn't check that the order belongs to the current user. What do you find?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer distinguishes authentication from authorization: it identifies that before_action :authenticate_user! only confirms someone is logged in, and flags the missing check that the order being updated actually belongs to that user (an IDOR risk letting any logged-in user modify another user's order), with a fix direction -- scoping the lookup to the current user or adding an explicit ownership check -- reported as a finding only, not applied.",
+          "pass_criteria": [
+            "States that before_action :authenticate_user! is authentication only, and that an ownership/authorization check on this specific order is separately missing.",
+            "Names the concrete risk: any logged-in user could update an order that isn't theirs (IDOR), not just an unauthenticated request.",
+            "States a concrete fix direction -- scoping the lookup to the current user (e.g. current_user.orders.find(params[:id])) or an explicit ownership check -- as a finding, with no code change applied."
+          ],
+          "fail_criteria": [
+            "Treats before_action :authenticate_user! as sufficient on its own, without flagging the missing per-record ownership check. Mentioning that authentication alone is a first step but not the whole picture is not a failure -- concluding it fully covers this case is."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Finding: the action requires login via `before_action :authenticate_user!`, but nothing confirms the order being updated actually belongs to the current user -- it looks like the order is likely loaded with a bare `Order.find(params[:id])`. That's an authorization gap, not an authentication one: any logged-in user can PATCH any order by guessing/incrementing the id (IDOR). Fix direction: scope the lookup to the current user, e.g. `current_user.orders.find(params[:id])`, or add an explicit check (`raise unless order.user == current_user`, or a policy object if the app has one) before allowing the update. Reporting this as a finding since this review is read-only.",
+        "known_wrong": "This looks fine -- the action already has `before_action :authenticate_user!`, so only logged-in users can hit it at all. That's the check that matters here; going further and verifying which specific order they're allowed to touch would be double-checking something the login requirement already covers.",
+        "vague": "Might want to double check the authorization here before merging, just to be safe.",
+        "subtle_wrong": "Finding: the action is authenticated via `before_action :authenticate_user!`. That said, since `params[:id]` comes from the route and not directly from a form field, and the id itself doesn't reveal anything sensitive on its own, the exposure here is pretty limited even without an explicit ownership check -- worth a follow-up ticket but not a blocker for this diff."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/ruby-rails/skills/ruby-rails-implementation/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: ruby-rails-implementation
+description: "Use when implementing or extending a feature in a Ruby on Rails app -- MVC boundaries, strong parameters, ActiveRecord associations and scopes, service objects for fat controllers/models, ActiveJob, and modern Ruby 3.x idiom (pattern matching, endless methods, keyword args). Not for writing or fixing tests (use ruby-rails-testing)."
+triggers:
+  - "implement this feature in Rails"
+  - "add a Rails controller action and model for this"
+  - "add strong parameters to this Rails controller"
+  - "extract this Rails controller logic into a service object"
+  - "add an ActiveRecord association and scope for this"
+  - "add an ActiveJob for this background task"
+metadata:
+  origin: authored
+  category: implement
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Ruby on Rails implementation (Ruby 3.x, Rails)
+
+Implement or extend a feature in a Rails codebase: MVC boundaries,
+ActiveRecord modeling, strong parameters, service objects, ActiveJob, and
+modern Ruby idiom. This is a combined Ruby+Rails pack (no separate
+`lang:ruby` base) — `rules/coding-style.mdc`, `rules/patterns.mdc`, and
+`rules/security.mdc` carry the full rule set this skill draws its
+checklist from; read them before writing code, not just this summary.
+
+## Workflow
+
+### Step 1: Discover the project's own conventions
+
+1. Read `Gemfile`/`Gemfile.lock` for the Rails and Ruby versions, and
+   whether the project already has a service-object gem or convention
+   (`app/services/`, a shared base class), FactoryBot, RSpec vs
+   Minitest, and any auth gem (Devise, has_secure_password).
+2. Find the existing layout under `app/` for the area you're touching —
+   match its naming and directory conventions; do not invent a new
+   top-level directory for one feature.
+3. Read 1-2 neighboring models/controllers for: validation style,
+   whether concerns are already used, how strong parameters are
+   structured, and whether callbacks or service objects are the
+   project's preferred way to keep controllers/models thin.
+
+### Step 2: Design before writing
+
+- Decide where each piece of new logic belongs: routing/params handling
+  in the controller, persistence/validation in the model, multi-step or
+  cross-model orchestration in a service object (`rules/patterns.mdc`)
+  — not stacked into one fat controller action or model callback.
+- For a new ActiveRecord association, decide the query pattern up front:
+  will callers iterate the association in a loop (needs `includes` at
+  the call site to avoid N+1) or query it directly (a named `scope` may
+  belong on the model).
+- For a new background job, decide what makes `perform` idempotent
+  before writing it — a uniqueness check, an idempotency key, or an
+  upsert — most Active Job queue adapters (Sidekiq, SQS) are
+  at-least-once, not exactly-once, though the actual guarantee depends
+  on the configured adapter (the inline/test adapters have none).
+
+### Step 3: Implement
+
+1. Strong parameters: require the permitted shape explicitly with
+   `params.expect(model: [:field, ...])` (current Rails idiom) or
+   `params.require(:model).permit(:field, ...)` — never build/update a
+   model from a raw `params` hash, and never call `permit!` on
+   user-controlled params.
+2. Keep the controller action thin: params in, call the model/service,
+   render/redirect out. Extract a service object when the action's
+   logic spans multiple models, calls an external service, or has
+   enough branching to warrant its own tests.
+3. Use `includes`/`preload`/`eager_load` before iterating an association
+   in a loop; push filtering into the database (`where`, a named
+   `scope`) instead of loading records and filtering in Ruby.
+4. Reach for modern Ruby idiom where it genuinely clarifies: `case/in`
+   pattern matching for destructuring a hash/array-shaped value, an
+   endless method for a real one-expression method, keyword arguments
+   for a multi-parameter method — not as syntax for its own sake.
+5. Every controller action that requires a logged-in user has the
+   app's `before_action` auth filter, and every action further checks
+   that the current user is authorized for *this* record, not just
+   logged in.
+6. Add `# frozen_string_literal: true` to new files if the project's
+   existing files use it.
+
+### Step 4: Verify
+
+```bash
+bundle exec rspec   # or: bin/rails test
+bundle exec rubocop
+```
+
+Run `bin/rails db:test:prepare` if a migration changed the schema. Fix
+findings at the root cause per `rules/security.mdc` and
+`rules/coding-style.mdc`; a failing test here is a signal to fix the
+implementation, not to reach for `ruby-rails-build-fix`'s scope unless
+the failure is purely a dependency/migration/toolchain problem unrelated
+to the feature logic.
+
+### Step 5: Report
+
+```
+Implemented: app/models/order.rb, app/controllers/orders_controller.rb,
+  app/services/place_order.rb, spec/services/place_order_spec.rb
+  - New PlaceOrder service object consumed by OrdersController#create
+  - rspec/rubocop both pass
+```
+
+## Rules
+
+- Never build or update a model from a raw `params` hash; always go
+  through strong parameters (`params.expect`/`params.require`+`permit`),
+  and never call `permit!` on user-controlled params.
+- Never iterate an ActiveRecord association in a loop without eager
+  loading it first (`includes`) when the association is used inside
+  that loop.
+- Never put multi-step orchestration or an external API call directly
+  in a controller action or a model callback — extract a service
+  object.
+- Never write an `ActiveJob#perform` that assumes exactly-once delivery
+  for a side effect that would be harmful to repeat.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll just do `Order.new(params[:order])`, it's a small internal form" | Bypasses strong parameters entirely; any key in `params[:order]`, including ones never meant to be user-settable, gets mass-assigned |
+| "I'll call `.author` inside this `each` loop, it's just one extra query" | That "one extra query" happens once per row — N+1 queries; add `.includes(:author)` before the loop |
+| "This callback also sends a welcome email and pings analytics, but it's still 'about' the model" | A model callback doing multi-step, cross-system work is the fat-model anti-pattern; extract a service object so it's testable in isolation and the model stays about persistence |
+| "The job will basically only ever run once" | Most production Active Job adapters are at-least-once, not exactly-once; a retried or duplicated run has to be safe |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- `bundle exec rspec` (or `bin/rails test`) and `bundle exec rubocop`
+  both exit 0.
+- Every new/changed controller action that mutates a model goes through
+  strong parameters, with no `permit!` on user-controlled input.
+- Every new loop over an ActiveRecord association eager-loads it first.
+- Every new `ActiveJob#perform` is safe to run more than once for the
+  same logical unit of work.

package/src/gdskills/bundled/stacks/ruby-rails/skills/ruby-rails-implementation/evals.json

@@ -0,0 +1,72 @@
+{
+  "triggers": {
+    "positive": [
+      "Implement a PlaceOrder service object that a controller action can call",
+      "Add strong parameters to this create action so mass assignment isn't possible",
+      "Wire up an ActiveJob that charges a customer and needs to be safe to retry",
+      "Add an eager-loaded association so this index view doesn't run a query per row",
+      "Extract this fat controller action's business logic into its own class",
+      "Add a case/in pattern match to parse this webhook payload's JSON shape"
+    ],
+    "negative": [
+      "Implement this feature in Django using its ORM",
+      "Add a POST endpoint in Express that validates the request body",
+      "Review this Rails diff for N+1 queries",
+      "Write RSpec tests for this Rails service object",
+      "Fix this failing bundle install error in the Rails app"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "strong-parameters",
+      "prompt": "I'm building a create action for orders that saves whatever comes in from the form. How should I handle the params?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer requires and permits an explicit list of attributes (params.expect or params.require+permit) before building/updating the model, rather than passing the raw params hash directly to the model or calling permit! to bypass the check.",
+          "pass_criteria": [
+            "Names params.expect(order: [...]) or params.require(:order).permit(...) explicitly as the mechanism, with a concrete attribute list shown.",
+            "States that building/updating the model directly from the raw params hash (e.g. Order.new(params[:order])) is unsafe because of mass assignment.",
+            "Does not recommend permit! as part of the fix."
+          ],
+          "fail_criteria": [
+            "Recommends permit! on user-controlled params, or building/updating the model from the raw params hash (or by merging in unpermitted keys from it) instead of listing permitted attributes explicitly. Mentioning permit! only to warn against it is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Require the params under :order and permit only the fields the form actually submits, e.g. `params.expect(order: [:item_id, :quantity, :shipping_address])` (or `params.require(:order).permit(:item_id, :quantity, :shipping_address)` on an older Rails). Then pass the permitted hash to `Order.new(order_params)`. Don't build the record straight from `params[:order]` -- that hands mass assignment to whatever keys are in the submitted form, including ones nobody meant to be settable from outside, like a `total_price` override or an `admin` flag if one is ever added to the model.",
+        "known_wrong": "Simplest is `Order.new(params[:order])` and let ActiveRecord sort out which attributes it has -- Rails handles that fine. If you're getting a ForbiddenAttributesError anywhere in the chain, just call `.permit!` on the params hash before you use it; that clears the block globally so you don't have to keep listing out fields by hand as the form grows.",
+        "vague": "Make sure you're only accepting the fields you actually mean to accept before saving the order -- don't just trust the raw form input.",
+        "subtle_wrong": "Use `params.require(:order).permit(:item_id, :quantity)` for the known fields, and then merge in `params[:order].except(:item_id, :quantity)` for anything else the form might send, so you don't have to keep updating the permit list every time a new field gets added to the form."
+      },
+      "anti_patterns": ["permit!"]
+    },
+    {
+      "id": "n-plus-one",
+      "prompt": "This index view loops over @orders and calls order.customer.name for each one. Anything to watch out for?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer identifies this as an N+1 query -- one extra query per order to load its customer -- and fixes it by eager-loading the association (includes(:customer), or preload/eager_load) where @orders is built, rather than leaving the per-row queries or fixing it only inside the view.",
+          "pass_criteria": [
+            "Identifies the per-row `.customer` call as an N+1 query risk, naming the mechanism (one extra query per order).",
+            "Names the concrete fix: add `.includes(:customer)` (or preload/eager_load) to the @orders query, in the controller/query-building code, not in the view.",
+            "States that this reduces the query count from one-per-row (N+1) to a small constant number."
+          ],
+          "fail_criteria": [
+            "Dismisses the N+1 as acceptable because the table or collection is currently small, or proposes per-row caching of the association instead of eager-loading it at the point @orders is queried."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "That's an N+1: `order.customer.name` inside the loop runs one query per order to fetch its customer, on top of the query that loaded @orders in the first place -- so 50 orders means 51 queries. Fix it where @orders is built, in the controller: `@orders = Order.includes(:customer)` (composed with whatever the existing scope chain already is) rather than in the view -- Rails will pick preload or eager_load for you and pull all the customers in one or two queries total instead of one per row. The view code itself doesn't need to change.",
+        "known_wrong": "That's fine as long as the orders table stays small -- a handful of extra queries per page load isn't something to worry about unless you're seeing real performance problems in production. I'd leave the view as-is and only add includes if it actually shows up as slow in the logs.",
+        "vague": "That loop could be running more queries than it needs to -- might be worth eager loading the association at some point.",
+        "subtle_wrong": "Add `order.association(:customer).load_target` inside the loop instead of calling `.customer` directly -- that at least caches the association per order object so you're not re-triggering the query if the view happens to reference `.customer` more than once on the same row, without needing to touch how @orders is queried in the controller."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/ruby-rails/skills/ruby-rails-testing/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: ruby-rails-testing
+description: "Use when a Rails app's test suite needs writing, extending, or fixing -- RSpec request/model/job specs (or Minitest equivalents), FactoryBot fixtures, stubbing external HTTP calls, asserting on enqueued ActiveJobs, and avoiding sleep-based waits."
+triggers:
+  - "write RSpec tests for this Rails model"
+  - "add a request spec for this Rails controller action"
+  - "test this ActiveJob with have_enqueued_job"
+  - "fix this failing Rails test"
+  - "write Minitest tests for this Rails model"
+  - "stub this external API call in a Rails test"
+metadata:
+  origin: authored
+  category: test
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Ruby on Rails testing
+
+Write, extend, or fix a Rails app's test suite: RSpec (or Minitest)
+specs for models, controllers/requests, and jobs, with FactoryBot
+fixtures, stubbed external boundaries, and deterministic waits.
+`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 `Gemfile`/`Gemfile.lock` for RSpec vs Minitest, FactoryBot,
+   WebMock/VCR, and any time-freezing gem (Timecop or Rails' built-in
+   `travel_to`) — match whichever is already there, never introduce the
+   other test framework.
+2. Find the layout: `spec/<mirror of app/>` (RSpec) or
+   `test/<mirror of app/>` (Minitest). Match the existing file for the
+   type of code under test (model spec, request spec, job spec).
+3. Read 1-2 neighboring spec/test files for: fixture style
+   (`let`/`let!`/factories vs fixtures), whether request specs or
+   controller specs are used, and how external HTTP calls are already
+   stubbed in this project.
+
+### Step 2: Plan test cases
+
+**Models:** validations (presence, uniqueness, format), each
+association's behavior relevant to the change, scopes, and any
+non-trivial instance/class method.
+
+**Requests (preferred over controller specs for new coverage):**
+happy path (correct status/body), auth failure (no session — expect a
+redirect/401), authorization failure (wrong user — expect
+403/404 depending on the app's convention), and strong-parameters
+rejection of an unpermitted field.
+
+**Jobs:** assert enqueue with `have_enqueued_job`/`assert_enqueued_with`
+for most tests; only actually run the job
+(`perform_enqueued_jobs`) when the test's purpose is the job's own
+`perform` behavior, and cover what happens if `perform` runs twice for
+jobs that must be idempotent.
+
+### Step 3: Write
+
+1. Create/extend the spec/test file at the project's own convention
+   path, mirroring `app/`'s structure.
+2. Use the project's existing fixture approach (FactoryBot
+   `create`/`build`/`build_stubbed`, or fixtures) — do not hand-roll
+   ad hoc records when a factory already covers the model.
+3. Stub any external HTTP call at the boundary (WebMock/VCR or the
+   project's existing tooling); a test must not make a real network
+   call.
+4. Freeze time (`travel_to`, matching the project's convention) for any
+   assertion involving a timestamp or elapsed-time calculation.
+5. Never use `sleep` to wait for a job, callback, or async result — use
+   `perform_enqueued_jobs`, a Capybara auto-retrying matcher
+   (`have_content`), or an explicit polling helper with a timeout.
+
+### Step 4: Run and fix
+
+```bash
+bundle exec rspec   # or: bin/rails test
+```
+
+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: spec/requests/orders_spec.rb
+  - 6 examples (happy path, auth failure, authorization failure,
+    unpermitted param), all passing
+```
+
+## Rules
+
+- ALWAYS match the project's existing framework (RSpec/Minitest),
+  fixture style, and spec layout found in Step 1, not a different
+  project's convention.
+- NEVER modify application code — only spec/test files and
+  fixtures/factories, unless a test caught a real bug (say so).
+- NEVER use `sleep` to wait for a job or async result.
+- NEVER let a test make a real network call to an external service.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll add `sleep(1)` after enqueuing so the job has time to run" | Non-deterministic and slow; use `perform_enqueued_jobs` to run it synchronously in the test, or `have_enqueued_job` to assert the enqueue itself |
+| "This test hits the real payment API sandbox, that's basically a stub" | Still a real network call in the suite — flaky, slow, and can fail for reasons unrelated to the code under test; stub it with WebMock/VCR instead |
+| "I'll just assert `response.status` and skip checking the body/authorization case" | A request spec that only checks the happy-path status misses exactly the auth/authorization regressions these specs exist to catch |
+| "The job might run twice in production but I'll just test the single-run case" | If the job needs to be idempotent, the test suite is where that guarantee gets proven — add a case that runs `perform` twice and asserts no duplicate effect |
+
+## Verification
+
+Do not report the work done until all of the following hold:
+
+- The spec/test file sits at the project's own convention path, matching
+  the fixture/framework style read in Step 1.
+- `bundle exec rspec` (or `bin/rails test`) exits 0 with every generated
+  test passing.
+- `git status` shows only spec/test files (and factories/fixtures, if
+  touched) added or modified; no application source file changed unless
+  a real bug was found and reported as such.
+- No test makes a real network call or synchronizes with `sleep`.

package/src/gdskills/bundled/stacks/ruby-rails/skills/ruby-rails-testing/evals.json

@@ -0,0 +1,72 @@
+{
+  "triggers": {
+    "positive": [
+      "Write specs for this ActiveRecord model's validations",
+      "Write a test asserting that hitting PATCH /orders/:id without a signed-in user returns 401 instead of raising",
+      "Test that this job gets enqueued when the order is placed",
+      "Fix this failing spec that's flaking in CI",
+      "Our checkout spec is actually hitting Stripe's charges endpoint when it runs, how do I keep that out of the test",
+      "Write Minitest coverage for this model's scopes"
+    ],
+    "negative": [
+      "Write Jest tests for this React component",
+      "Write pytest tests for this Django view",
+      "Implement the feature this spec is supposed to cover",
+      "Review this Rails diff for missing test coverage",
+      "Fix this failing bundle install so the test suite can boot"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "no-sleep-for-jobs",
+      "prompt": "My test enqueues a job and I want to assert its effect ran. What's the right way to wait for it?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer runs the job synchronously inside the test with perform_enqueued_jobs (ActiveJob::TestHelper) before asserting its effect, or asserts only that it was enqueued with have_enqueued_job when running it isn't the point -- never a sleep-based wait, whether alone or as extra insurance alongside the real mechanism.",
+          "pass_criteria": [
+            "Names perform_enqueued_jobs (or have_enqueued_job, if only the enqueue itself is being asserted) as the mechanism, shown concretely rather than described in the abstract.",
+            "Explains why this is deterministic compared to a fixed delay -- the job either has actually run or hasn't, rather than depending on timing.",
+            "Does not recommend sleep at any point in the wait step."
+          ],
+          "fail_criteria": [
+            "Recommends sleep -- as the sole wait mechanism or as extra 'insurance' alongside perform_enqueued_jobs/have_enqueued_job -- anywhere in the answer's wait step. Mentioning sleep only to warn against it is not a failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Wrap the triggering code in `perform_enqueued_jobs { ... }` (from `ActiveJob::TestHelper`) so the job actually runs synchronously inside the test instead of just sitting in the queue -- then assert directly on its effect. If you only care that the job was scheduled, not that it ran, `expect { ... }.to have_enqueued_job(ChargeJob).with(order.id)` is enough and doesn't need `perform_enqueued_jobs` at all. Either way, don't reach for `sleep` -- there's nothing actually running in the background to wait for until you explicitly drain the queue.",
+        "known_wrong": "Just add `sleep(1)` right after you trigger the code that enqueues the job, then run your assertion against whatever the job was supposed to change -- that gives it enough time to run in the background before you check. If it's flaky in CI bump it up to 2 or 3 seconds.",
+        "vague": "Make sure the job actually finishes before you check the result instead of just assuming it ran.",
+        "subtle_wrong": "Use `perform_enqueued_jobs` to run the job, but add a short `sleep(0.5)` right before it just to be safe in case there's any async I/O the job itself kicks off that isn't captured by the synchronous run -- that extra buffer doesn't hurt and covers cases perform_enqueued_jobs might miss."
+      },
+      "anti_patterns": ["sleep"]
+    },
+    {
+      "id": "stub-external-boundary",
+      "prompt": "This feature calls a third-party shipping API to get a rate. How should I test it without hitting the real API?",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer stubs the HTTP call at the boundary (WebMock stub_request or a VCR cassette, matching whichever the project already uses) rather than letting the test make a real network call to any environment of the third-party API, sandbox included.",
+          "pass_criteria": [
+            "Names a concrete boundary-stubbing mechanism -- a WebMock stub_request or a VCR cassette -- as the fix, not just 'mock it out'.",
+            "States plainly that the test must not make a real network call, sandbox environments included.",
+            "Says to match whichever stubbing tool the project already has configured rather than introducing a second one."
+          ],
+          "fail_criteria": [
+            "Recommends letting the test call a real environment of the third-party API (including a vendor sandbox) instead of stubbing the HTTP call, or recommends skipping/silently passing the assertion when that live call fails."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Stub the HTTP call at the boundary rather than hitting anything real -- if the project already uses WebMock, `stub_request(:get, \"https://api.shipper.example/rates\").to_return(status: 200, body: fixture_json)` covers it; if it's VCR, record a cassette once and replay it in CI. Match whichever the project already has configured rather than introducing the other one. That keeps the test fast, deterministic, and independent of the shipper's actual uptime or rate limits.",
+        "known_wrong": "Easiest is to just point the test at the shipper's sandbox/test environment and let it make a real call -- that way you're testing against their actual API contract instead of a fixture that could drift out of date. As long as it's their sandbox and not production, it's fine to leave the network call in the test.",
+        "vague": "Don't let the test hit the real API -- fake it somehow so it's not flaky.",
+        "subtle_wrong": "Wrap the API client call in a begin/rescue inside the test and, if the sandbox call fails or times out, just skip the assertion for that run -- that way the test still exercises the real integration when the sandbox is up, without failing the build when it's flaky."
+      }
+    }
+  ]
+}

package/src/gdskills/bundled/stacks/sql-db/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 (every behavior scenario scored 0.8 or 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."
+}