跳到正文
cccskills
免费在 GitHub 公开

honeybadger-debugging

Investigate and fix a specific Honeybadger exception in the Bike Index app — pull the fault, read its backtrace, find the offending code, write the fix. Trigger whenever a request names one Honeybadger error: a pasted fault URL (`app.honeybadger.io/projects/…/faults/…`), a fault ID, an error class plus "in production" (`Vips::Error`, `NoMethodError in AfterStolenRecordSaveJob`), or phrasings like "fix this Honeybadger error", "why is this erroring in prod", "what's causing this exception", "look at this HB fault". Use `bin/binx_hb` for fault and notice detail; it is the only Honeybadger reader this repo uses. Not for a broad production health sweep across many sources, and not for reading raw log files (that's production-log-inspection).

中文简介正在准备中。当前显示原文说明。

bikeindex/bike_index星标 308(GitHub 308 + cccskills 0)

实测评分 未实测

查看安装方法

包含的文件（1）

  • SKILL.md4.5 KB

SKILL.md（原文）

安装前可以查看交给 AI 代理的指令内容。

Fixing a Honeybadger exception

Pull the fault with bin/binx_hb

Run it from the repo root. Two modes matter here: fault for the summary, notice for the backtrace.

bin/binx_hb fault  https://app.honeybadger.io/projects/35931/faults/133010748
bin/binx_hb notice backend/133010748

Both take a pasted fault URL or <project>/<fault_id>, where project is backend, frontend, or csp. Each prints raw: tmp/hb-…json on its last line — answer follow-up questions with jq against that file rather than fetching again.

It reads HONEYBADGER_PERSONAL_AUTH_TOKEN from .env.development. Without it the command exits saying so — get a new token at honeybadger.io/users/edit and ask the user to set it. Don't fall back to the honeybadger MCP server — it can't redirect a notice to a file, so a 130 KB backtrace lands whole in context. Aggregates are covered too — binx_hb faults, trend and counts.

Read the notice in this order

  1. message and params — the failing input is usually right here. For a job, params holds the Sidekiq hash and args names the record to reproduce against.
  2. App frames — the default listing, deepest first. The top frame is where it raised, the bottom is the entry point. [PROJECT_ROOT] is the repo root.
  3. --all-frames — when the raise is inside a gem and you need the call path that reached it.
  4. deploy — the revision live when it fired. A fault created minutes after that deploy makes git show <revision> the first place to look.

One notice is almost always enough; repeat notices of a fault are near-identical. Pass --limit N only when you suspect the occurrences genuinely differ — a browser-specific frontend error, or params that vary between failures.

Then fix it

Decide which kind of fault it is first — the two need different work.

Deterministic — a bug reachable from the input

  • Reproduce from args/params before changing code — bundle exec rails runner against the dev database is usually enough.
  • A decoder error isn't proof the file is bad. Production's libvips and libheif are Ubuntu's packages (.cloud66/deploy_hooks.yml), older than Homebrew's — download the stored file and decode it locally before treating it as corrupt. The "bad seek" in fault 134271942 read as truncation, and was a valid iPhone HEIC that libheif 1.17 couldn't parse.
  • Cover the fix with a spec; the rspec-testing skill has the house style.
  • Check whether the same pattern exists elsewhere. Errno::ENOENT in one image job usually means every image job shares the bug.

Transient — a 5xx or timeout from S3/R2, the image CDN, another service

Don't try to reproduce it. The tell is a burst of notices inside a few seconds and then nothing, with a message naming the provider rather than your code.

  • Check the job's retry setting first. config/honeybadger.yml sets sidekiq.attempt_threshold, which only drops the first failure of a retryable job — retry: false reports every blip, and ScheduledJob defaults to it.
  • A retry only silences a blip shorter than Sidekiq's first backoff, 15 + rand(10) seconds. Check the notice timestamps against that.
  • Check what a mid-operation failure leaves behind — retrying doesn't help work that isn't idempotent. ActiveStorage::Blob#purge destroys the row before deleting the file, so a failed delete orphans the file for good.
  • Find prior occurrences by error class, not job name. Honeybadger's q doesn't match the component field, and a renamed component splits the history.

Don't resolve, ignore, or comment on the fault in Honeybadger — marking it fixed is the user's call once the fix ships.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护，适用 Google 的隐私权政策和服务条款。

同一仓库的技能

admin-data-api

免费

Read live production data from Bike Index through the admin OAuth token — Sidekiq and PgHero status, and the user-submitted bug reports — the same data as the cookie-gated dashboards, but agent-friendly JSON. Trigger when the user asks about production queue depth, job backlog, retries/dead jobs, running Sidekiq processes, or Postgres health (slow/blocked queries, index usage, unused/invalid indexes, connection counts, table/db sizes, vacuum/transaction-id danger) — and wants the *live* answer from production rather than logs or Honeybadger. Also trigger for anything about bug reports users have emailed in: what's been reported, searching/filtering them by status, tag or membership, or tagging one / linking it to the PR that fixes it. Also trigger when a request returns 401/expired and the AdminData token needs refreshing/re-authorizing. Not for reading log files (use production-log-inspection) or aggregated exception triage (bin/binx_hb).

中文简介正在准备中。当前显示原文说明。

bikeindex/bike_index3082026年10月29日 更新

fixing-flaky-failures

免费

How to fix a test that fails intermittently in Bike Index — one that passes locally but fails on CI, fails on one shard, passes on re-run, or is already tagged `:flaky`. **Read this before touching any spec that is failing intermittently, and before adding, raising, or relying on a `flaky:` tag or a `wait:` bump.** Trigger on a CI failure the user calls flaky, unreliable, intermittent, "green locally", "passes on retry", "fix CI", or a pasted `gh run`/Actions URL whose failure isn't reproducible; also whenever you catch yourself about to delete, skip, loosen, or retry an assertion to make a red build go green. **Equally: any spec that fails intermittently while you verify your own work** — deciding whether your change caused a flake, or whether to ship past one, is this skill's problem too, and it arrives with no CI run, no `:flaky` tag, and nobody but you calling it flaky.

中文简介正在准备中。当前显示原文说明。

bikeindex/bike_index3082026年10月29日 更新

frontend-conventions

免费

Bike Index's frontend conventions — Tailwind class prefixing (`tw:`), the standard `twinput`/`twlabel`/`twlink` form/link classes, the `number_display` helper for numbers, `Counts` for site-wide figures (bikes registered, recoveries, organizations), the UI component library rule (every button is `UI::Button`/`UI::ButtonLink`, every typeahead/autocomplete is `UI::Forms::Combobox`, every FAQ is `UI::Accordion`, never hand-rolled markup), that **helpers are deprecated — render a view component taking full keyword arguments instead of adding or extending one**, ViewComponent rules (when to write a partial instead, keyword arguments, instance variables, `helpers.` prefix in templates), and `UI::Time::Component` for every date/time. Trigger when adding or modifying views (`.html.erb`), view components, Stimulus controllers, Tailwind classes, image or icon files under `app/assets/images` (which usually already exist), or any frontend code that touches styling or interactivity — including admin screens, whose unlayered legacy CSS inverts several of these rules. Stimulus.js is the JavaScript framework; SCSS and CoffeeScript files exist but are deprecated.

中文简介正在准备中。当前显示原文说明。

bikeindex/bike_index3082026年10月29日 更新

frontend-screenshots

免费

Capture desktop+mobile screenshots of Bike Index pages from the local `bin/dev` server via Playwright MCP, with a seeded-user identity gate that keeps PII out of uploaded images. Use whenever a task needs screenshots of local pages — PR documentation, bug repros, before/after comparisons across branches, design review, demos — including mid-interaction states like an open dropdown, a modal showing, a form mid-fill, or a hover. Use it even when the user just says "grab a screenshot" or "show me what this looks like" without naming Playwright. For a component that only renders under an env var / feature flag / hard-to-reach state (e.g. the review-app banner), screenshot its ViewComponent/Lookbook preview URL instead of a full page. **Also read the filename rule here before any `mcp__playwright__browser_take_screenshot` call**, including a one-off capture of some other site — it's what keeps PNGs out of the working tree.

中文简介正在准备中。当前显示原文说明。

bikeindex/bike_index3082026年10月29日 更新

github-pr-images

免费

Embed a local image file into an existing GitHub PR — either in the PR body or as a comment. Trigger when a request pairs a local image (screenshot, .png/.jpg, CleanShot capture, before/after) with an existing PR (by #number, URL, branch name, or "the open PR"), regardless of verb — attach, embed, add, put, post, drop, show, document. Also covers visually documenting test runs, bug repros, UI states, or CI failures on an existing PR. Uploads through `gh`'s `--attach` flag — except in the Claude Code web sandbox, which has no `gh` and hosts images through the PR branch's history instead. It also owns the PR's one `## Screenshots` comment — finding, creating, editing and verifying it — so other workflows (the `pr` skill's screenshot phase) hand it a composed body that references local image paths, and it posts it.

中文简介正在准备中。当前显示原文说明。

bikeindex/bike_index3082026年10月29日 更新

integration-testing

免费

Bike Index conventions for browser specs (`type: :system, :js`) — **drive every step through the real UI** (no FactoryBot or `execute_script` shortcuts to skip what a user would do), every example pays a browser boot cost so bias toward fewer, denser examples that walk through state via clicks, prefer named-element matchers over CSS selectors, and combine same-setup work into one `it` even when scenarios feel independent. **Consult this skill any time you create or modify a `:js, type: :system` spec** — that includes everything under `spec/integration/` AND component system specs at `spec/components/**/*_system_spec.rb`. Read alongside the `rspec-testing` skill for the project's general `context`/`let` style.

中文简介正在准备中。当前显示原文说明。

bikeindex/bike_index3082026年10月29日 更新

查看 bikeindex 的全部技能

报告此技能的问题