| name | explain-diff-html |
|---|---|
| description | Use when the user asks for a rich explanation of a code change, diff, branch, or PR. Produces HTML output. |
Please make me a rich, interactive explanation of the specified code change.
It should have these sections:
| # ## The problem | |
| # | |
| # The Honeybadger API rejects notice payloads larger than 256KB with a 413 | |
| # ("Payload Too Large") response. When that happens the error is silently | |
| # dropped and never shows up in your dashboard. Oversized payloads are usually | |
| # caused by one of a few things: | |
| # | |
| # - Long backtraces — each frame carries a snippet of surrounding source code | |
| # - A large number of breadcrumbs | |
| # - Big request payloads (params, session, CGI/env data) |
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
| { | |
| "notifier":{ | |
| "name":"honeybadger-ruby", | |
| "url":"https://github.com/honeybadger-io/honeybadger-ruby", | |
| "version":"4.5.0" | |
| }, | |
| "error":{ | |
| "class":"RuntimeError", | |
| "message":"RuntimeError: This is a runtime error, generated by the crywolf app at 2012-09-26 17:25:24 -0700", | |
| "tags":["wubba"], |
| require "ruby_llm" | |
| require "honeybadger" | |
| Honeybadger.configure do |config| | |
| config.api_key = ENV.fetch("HONEYBADGER_API_KEY") | |
| config.env = "production" | |
| config.debug = true | |
| end | |
| Honeybadger.load_plugins! |
| PROJECT_ROOT = Regexp.new(/\A\[PROJECT_ROOT\]/) | |
| Honeybadger.configure do |config| | |
| config.before_notify do |notice| | |
| location = begin | |
| Hash(notice.parsed_backtrace.find { |l| PROJECT_ROOT.match(l[:file].to_s) } || notice.parsed_backtrace.first) | |
| rescue | |
| {} | |
| end |
You can use Vector with its docker_logs source to
collect logs from your Docker containers and send them to Honeybadger Insights.
This example collects logs from all running containers:
# Put this in vector.yaml
sources:
docker:
type: "docker_logs"| --- | |
| title: ActiveJob | |
| widgets: | |
| - id: a1b2c3d4-e5f6-7890-abcd-ef1234567890 | |
| type: insights_vis | |
| grid: | |
| x: 0 | |
| "y": 0 | |
| w: 2 | |
| h: 3 |
| #!/bin/bash | |
| chmod -R go-rw /etc/honeybadger | |
| useradd --system --home /var/lib/honeybadger --shell /usr/sbin/nologin honeybadger | |
| mkdir -p /var/lib/honeybadger /var/log/honeybadger | |
| chown -R honeybadger:honeybadger /var/lib/honeybadger /var/log/honeybadger | |
| systemctl daemon-reexec | |
| systemctl daemon-reload | |
| systemctl enable honeybadger | |
| systemctl start honeybadger |
| Honeybadger.configure do |config| | |
| config.before_event do |event| | |
| event.halt! unless event.event_type == "process_action.action_controller" | |
| event.halt! unless event[:duration] > 1.0 | |
| end | |
| end |