Today I’m excited to share a new open source project: A Claude Code skill to assess technical debt in a Ruby on Rails application. It leverages some of the libraries that we have open sourced and maintained for a long time.

Over the years, we’ve written about many of the tools we use: Skunk opens a new window for combining code quality and code coverage data, bundler-audit opens a new window for security vulnerabilities in your dependencies, libyear-bundler opens a new window for measuring dependency freshness in a Ruby application, and RubyCritic opens a new window for churn vs. complexity analysis.

The challenge? Running all these tools manually takes time and interpreting the results across multiple reports can be tedious.

What if we could automate the entire audit process and generate a comprehensive report with a single command?

In this article, I’ll show you how we built a Claude Code skill that does exactly that, in minutes!

Maintaining a Ruby on Rails application often slips down the priority list. Everything seems fine, until suddenly it isn’t. A gem update breaks a feature, a security flaw makes headlines, or your app refuses to deploy after a server upgrade. When that happens, teams scramble to find help, often at the worst possible time. This “as-needed” upgrading approach may appear cost-effective in the short term, but it leads to stress, downtime, and unpredictable expenses.

But there is a smarter path forward: fixed-cost monthly maintenance opens a new window . In this post, you’ll see why investing in a maintenance retainer is better than reactive upgrades, and how our service delivers value month after month.

When people hear the phrase “technical debt”, they often picture broken code, outdated infrastructure, or a total rewrite waiting to happen. But in our experience at Planet Argon opens a new window , technical debt usually shows up more quietly.

It’s not a crisis. It’s a pattern.

It shows up in how long it takes to make changes, how often bugs sneak in, and how hesitant developers are to touch certain parts of the codebase. And while it rarely announces itself, it always costs something — whether in time, budget, or momentum.

In this post, we’ll highlight real-world examples of how technical debt has surfaced in Rails applications we’ve worked on. These aren’t horror stories — they’re common issues we see even in well-run projects. More importantly, we’ll share some ways teams can manage debt strategically without a massive rewrite.

Many times, when looking at applications we have written or that we see around in repositories throughout the internet, we get this feeling that whatever we’re reading has a certain complexity too it. Sometimes this complexity is manegeable and expected. Sometime it’s not. Actually, very frequently, code can be difficult to understand and we usually describe such code as being overcomplicated, for example.

But it’s not just our understanding of written code that suffers. As expected, if code is more complex, it will also require more effort on the part of the computer to execute. And while efficient code might not necessarily be easy to understand, there is indeed such a possibility as code that is hard for humans to read and hard for hardware to compute.

However, in order to try to make things simpler and, especially, in order to coordinate within teams what is acceptable and what isn’t in terms of complexity, we need something that can help us measure complexity.

There are, of course, many metrics that can be used. In this article we’ll talk about cyclomatic complexity.

Managing technical debt opens a new window is a huge concern for businesses of all sizes. At FastRuby.io, we understand the challenges of maintaining a healthy codebase while continuously delivering value to your users. That’s why we’ve introduced Bonsai, our fixed-cost, monthly maintenance service opens a new window tailored to gradually alleviate technical debt. Join us as we take a deep dive into the value Bonsai brings to the table over the course of a month.

In a previous post opens a new window , we discussed the importance of assessing an application’s dependency freshness and demonstrated how you can use different tools for this purpose. One of these tools is libyears opens a new window . In this post, we’ll share the libyears calculations for several popular Ruby projects and discuss our findings with you.

Technical debt, a term coined by Ward Cunningham in the 1990s, refers to the trade-off between short-term gains and long-term consequences in the development process. In this article, we will explore what technical debt is, why it happens, why you should care about it, and discover some new tools to help you discover the technical debt in your Rails applications opens a new window .

Whether you are working in a legacy Ruby application, or a brand new application, measuring your dependency freshness score can be a positive indicator to understand whether you are staying current or gradually falling out of date.

Dependency freshness is defined as the difference between the currently used version of a dependency and the version that the system would ideally use.

In this article, I will discuss a couple of ways to keep track of how outdated or how fresh your dependencies really are.

Ever since we started offering productized Ruby and Rails upgrade services opens a new window and upgrade roadmaps opens a new window , we’ve been interested in helping as many people and companies as possible.

Unfortunately, in the past we’ve had to turn down companies who wanted to work with us but couldn’t secure the minimum monthly budget to work with our experts.

I’m pleased to announce that we’re now offering new opportunities for startups and small businesses to work alongside our team.

In this article, I will share a few new options to collaborate with our team of experts who specialize in technical debt opens a new window remediation.

At FastRuby.io, we talk a lot about software quality. It’s how we determine whether a client is a good fit for an upgrade. The less technical debt a codebase has, the easier it is to maintain, and the more likely a Rails upgrade will go smoothly. But what determines whether software is “good quality”? In this article, we will talk about what software quality is, and explain the metrics that people use when talking about how to measure it.

Churn vs. Complexity analysis is a great way to find insights about the maintainability of a project. Two of my favorite authors have written great articles about the Churn vs. Complexity graph:

• Getting Empirical about Refactoring opens a new window by Michael Feathers
• Breaking up the Beheamoth opens a new window by Sandi Metz

This two-dimensional graph can be very useful in finding the files that are the hardest to maintain in your application. In this article I will explain:

1. How you can calculate these metrics and use them in your legacy project
2. How code coverage metrics can guide your technical debt’s collection efforts

Right before my talk at RubyConf Australia opens a new window , I worked on a way to make it easy for anyone to run skunk opens a new window in their Ruby projects. In order to do that I decided to use GitHub Actions opens a new window . It’s a powerful service by GitHub and it’s quite easy to set up.

This article is about the process that I followed and how you can use it in your own application.

Two weeks ago I had the opportunity to speak at Solidus Conf 2019 opens a new window . I presented Escaping the Tar Pit opens a new window for the first time and I got to talk about a few metrics that we can use to quickly assess code quality opens a new window in any Ruby project.

In this article I’d like to talk about Skunk: A SkunkScore Calculator opens a new window ! I’ll explain why we need it, how it works, and the roadmap for this new tool.

Every time we evaluate a new project we follow a well-defined process to decide whether we take it or not. We analyze its dependencies; its code coverage; and its code quality to determine the amount of tech debt in a project. We have been using CodeClimate opens a new window to assess code quality and SimpleCov opens a new window to assess code coverage.

In my previous article I wrote about free and open source Ruby gems we can use to assess code quality opens a new window for any Ruby or Rails project. After writing that article, I found that RubyCritic opens a new window was really interesting and its community quite active, so I thought it was a good idea to add SimpleCov support to it: https://github.com/whitesmith/rubycritic/pull/319 opens a new window

As part of our Rails upgrade opens a new window business we get to evaluate a lot of codebases every month. We usually need a quick way to assess the quality of the code we get. For this we like to use CodeClimate opens a new window and SimpleCov opens a new window .

CodeClimate is free for open source projects and paid for private projects. I know that not everybody can pay for their service, so I thought it was a good idea to share some free, open source alternatives.

Here is a list of 3 tools that can help you assess the quality of your next codebase.

In this blog post I will introduce bundler-leak – A bundler plugin to find known memory leaks in your dependencies.

I had to come up with a clever title because this article is about legacy Rails opens a new window applications and I know that you might fall asleep by the third paragraph. Boooooring… You probably want to read about that new JavaScript framework that came out (I love that this sentence will always be true, it doesn’t matter when you read this)

If you have been working with Rails for a few years, you have seen your fair share of shiny new applications, well-maintained and poorly-maintained legacy applications. This post is about Legacy Rails applications