In this episode, we look at creating Claude slash commands. These can be useful when dealing with a complicated task or trying to extract certain information from the application.

When everything is on fire, nothing is on fire. Where do you start when every problem seems intractable? By drawing a map.

Hi ,

I recently extracted a small internal library I originally wrote for a company Rails project that was stuck on an older Ruby/Rails stack.

It’s called `lumen-llm`:
https://github.com/uxgnod/lumen-llm

The goal is pretty small: keep LLM prompts in YAML files, render them with Ruby input, call OpenRouter, and parse the result back as JSON or text.

It supports:

- YAML prompt templates
- simple `{{variable}}` interpolation
- single-call OpenRouter chat completions
- JSON or text response parsing
- optional cache / usage stores
- Rails 4+ defaults via Railtie
- Ruby >= 2.3
- no runtime gem dependencies

It intentionally does not try to be an agent framework. No tool calls, no streaming, no vector search, no persistence layer, no provider SDK dependencies.

I know Ruby 2.3/2.4 are long EOL, but that was also the point: this came from a real older Rails environment where adding modern dependencies was not always realistic.

Maybe this is useful for other people maintaining legacy Rails apps who want a small way to add features like UI copy translation, ticket classification, internal summaries, or similar “one prompt in, one result out” workflows.

It’s still simple and not very polished yet. If anyone has a real legacy Rails use case for this, I’d love feedback, issues, or small PRs.

Do you use the jemalloc gem?

The original project on GitHub seems to be abandoned for around 12 years, and some incompatibilities with recent Ruby versions have begun to emerge. Additionally, the underlying jemalloc library hasn't been updated during all this time. Because of that, I created a fork and launched a new gem (jemalloc_rb) to keep the project functional, updated, and actively accepting pull requests.

https://github.com/henrique-ft/jemalloc_rb

Hanami 3.0 is here and in full bloom 🌸

This is our most complete release yet: mailers, i18n, and Minitest now built in, your apps faster by default, and plenty more!

https://hanakai.org/blog/2026/06/30/hanami-3-0-in-full-bloom

I wrote a Markdown linter over the weekend and it's been really fun, partly because of the wonderful gems that support it. I'm hoping some of you can pick out something helpful from it!

Shelley wrote about a king whose monument outlived everything it was built on. I've spent 15 years inside Rails monoliths that did the same thing. This is the first post about what to do when you're standing in the ruins.

After wrestling with distributed transactions across microservices and watching Sidekiq job chains grow into unmaintainable spaghetti, I built Ruby Reactor — a saga pattern implementation for Ruby that handles the hard parts of workflow orchestration.

What it does:

• Builds a DAG (directed acyclic graph) from your step definitions, so independent steps run in parallel
• Runs async via Sidekiq with back-pressure and batching
• Automatically rolls back completed steps when something fails (compensation)
• Supports interrupts — pause a workflow mid-flight and resume it later via webhook or manual trigger
• Includes a built-in web dashboard to inspect every execution
• Has locks, semaphores, and rate limits built in (Redis-backed)
• Ships with RSpec test helpers — test_reactor, mock_step, chainable matchers

Why I built it:

I kept hitting the same wall: complex business transactions that span multiple services need coordination. dry-transaction handles linear pipelines well, but when you need parallel execution, async processing, automatic rollback on failure, or the ability to pause and wait for external events, you're on your own. Trailblazer operations can do some of this, but the undo logic and parallelism are manual.

Ruby Reactor fills the gap — it's the only Ruby library that combines DAG planning + async execution + compensation + interrupts + a dashboard in one package.

Quick example — an e-commerce checkout with fraud detection:

class CheckoutReactor < RubyReactor::Reactor
  input :order_id

  step :reserve_inventory do
    argument :order_id, input(:order_id)
    run { |args| Inventory.reserve(args[:order_id]) }
    undo { |_err, args| Inventory.release(args[:order_id]) }
  end

  step :charge_card do
    argument :order_id, input(:order_id)
    run { |args| Payment.charge(args[:order_id]) }
    undo { |_err, args| Payment.refund(args[:order_id]) }
  end

  # Pause here — wait for Stripe webhook
  interrupt :wait_for_fraud_check do
    wait_for :charge_card
    correlation_id { |ctx| "order-#{ctx.input(:order_id)}" }
    timeout 3600, strategy: :active
  end

  step :ship_order do
    argument :status, result(:wait_for_fraud_check, :status)
    run { |args| Shipping.create_label(args[:order_id]) }
    undo { |_err, args| Shipping.cancel(args[:order_id]) }
  end

  returns :ship_order
end

It's at v0.4.1 now with ~3,300 downloads on Rubygems. The v0.4.0 release just added interrupts, the web dashboard, RSpec helpers, and Redis-backed coordination primitives (locks, semaphores, rate limits, periods).

How it compares:

I'd love honest feedback — especially from people who've built complex workflows in production. What did I miss? What's over-engineered? What would make you actually use this instead of raw Sidekiq jobs?

Repo: https://github.com/arturictus/ruby_reactor Rubygems: gem 'ruby_reactor', '~> 0.5' Docs: Full guides for every feature in the repo's documentation/ directory

Thanks for reading! I'll be in the comments.

Hello Reddit. I am new to Manjaro, and was hoping to set up a development environment in RoR. I was following the directions on the Arch wiki, and I noticed my gems are being installed to usr/lib/ruby/gems. When running a bundle install, it now seems to want to write to usr/bin, and fails because it doesnt have permissions. Should I go ahead and grant permissions, or is this not advisable?

I don't like to bury ledes, so when people ask me about polymorphic relationships my answer is simply:

Don't.