In the age of AI and automation, we can definitely get some help with this. This is what my colleague Fritz suggested. We were watching Dependabot PRs pile up and figured the real pain point was that people were lacking the information they needed to merge with confidence. So I used Claude’s skill-creator to build a skill that gives me exactly that: a short summary of the changes, the risk, and a recommendation: can I merge, or do I need to look more carefully myself?

A Dependabot PR review skill

You point the skill at a Dependabot PR or at the whole repo and it gives you back the one thing the PR description never tells you: should I merge this, and if not, why not?

It works in two modes:

• Single-PR mode — paste a Dependabot PR URL and you get a full review for that one PR.
• Audit mode — ask it to “review all open dependabot PRs” and it discovers every open Dependabot PR in the repo with gh, analyzes them one by one, and produces a single triage report.

For each PR, the skill does roughly what a careful human would do, just faster and without getting bored:

1. Reads the PR diff to figure out the gem name, the old and new version, and whether the bump is patch, minor, or major.
2. Pulls the changelog between those two versions from GitHub releases, CHANGELOG.md, or RubyGems and only keeps the parts that matter: breaking changes, deprecations, security fixes, notable behaviour changes. The release-notes-style noise gets stripped out.
3. Greps the codebase to see where the gem is actually used. A bump to a gem that lives in three test files is a very different story from a bump to a gem that runs in your payment flow, and the skill calls that out.
4. Hands you a verdict in one of four buckets:
   • Merge — safe, low risk
   • Verify — looks safe but here are the specific things to check first
   • Investigate — needs human judgment, here’s why
   • Hold — there are breaking changes, you’ll need code work before merging

In audit mode you get all of that as a summary table at the top: PR number, gem, bump (7.2.4 → 8.0.10), type, age, verdict, and a “why”, sorted worklist style: Merge first, then Verify, Investigate, Hold.

What the output actually looks like

Here’s a trimmed example of what audit mode prints back into the chat for a repo with a handful of open Dependabot PRs:

Found 5 open Dependabot PRs. Analyzing each now…

| #     | Gem            | Bump            | Type     | Age | Verdict     | Why                                  |
|-------|----------------|-----------------|----------|-----|-------------|--------------------------------------|
| #9170 | rubocop        | 1.65.0 → 1.68.0 | minor    | 12d | Merge       | dev-only, no breaking changes        |
| #9168 | sidekiq        | 7.2.4 → 7.3.1   | minor    | 6d  | Verify      | check Redis 6.2+ in production       |
| #9165 | aws-sdk-s3     | 1.143 → 1.150   | minor    | 21d | Verify      | new default checksum algorithm       |
| #9159 | devise         | 4.9.3 → 4.9.4   | patch    | 3d  | Merge       | patch, safe to merge                 |
| #9142 | rails          | 7.2.4 → 8.0.10  | major    | 30d | Hold        | breaking: deprecated Active Job APIs |

And then for each PR, a per-PR section with the changelog highlights, the files in your codebase that touch that gem, and the reasoning behind the verdict so you can scan the table for the easy wins.

Posting the review back to the PR

The chat transcript is not where teams review code, so after the review is done, the skill asks if you want to post it as a comment on the PR. Nothing gets posted without an explicit yes.

The comment uses a collapsible <details> block, with the verdict and a one-line reason above the fold so a teammate scrolling the timeline can triage without expanding, and the full review tucked underneath. There’s also an invisible marker in the comment, so if you re-run the audit a week later, it can detect its own previous comments and skip PRs that already have a review instead of spamming duplicates.

Give it a try

Curious about the skill? Check it out here. If you have any improvements or feedback, please open an issue or pull request. We love feedback!

It is Week Four.

Tuesday: four commits before lunch

The 17th. Four refactor-from-retro commits before noon. Reusing API connections across commands instead of reconnecting each time. /morning filtering rules. Stale 1:1 prep dropped from the daily log. The system had been running for three weeks, and friction points had accumulated. I was working through them in fifteen-minute bursts between meetings.

By the end of the day, I had added eight more commits. An actionability check for /context. Top 7 priorities in the daily log. A self-management outcome for my Fusion goal. Retro after retro, feeding back into the commands.

Wednesday: picking sides

Wednesday ran hard. Nine refactor commits between meetings.

I read Sally Lait’s post on semantic calendar emoji and colours. I copied her system straight into /calendar:

• 🦚 Peacock (default): 1:1s, ad-hoc work
• 🫐 Blueberry: recurring group meetings
• 🌿 Sage: pairing, workshops, active work
• 🍌 Banana: internal socials, external community
• ✏️ Graphite: transit, food

By evening, I’d refactored /evening to use Ruby instead of Python. It was a small religious war. I picked the side my team knows. The CLAUDE.md gained a preference note. This sort of thing accumulates.

Thursday: the Anytime problem

The Anytime list from Things hit 75,000 characters. That’s around 19,000 tokens. It triggered context compaction mid-session. I noticed overdue items slipping through the cracks.

I needed a filter. Not a prompt. A real script. I wrote bin/filter-anytime.

KEEP_FIELDS = %w[Title UUID Tags Area Project Deadline Notes]

items.each do |raw|
  status = raw[/^Status:\s*(.+)/, 1]
  next if status =~ /completed|canceled/

  if tags.include?("Waiting") && deadline_str
    deadline = Date.parse(deadline_str) rescue nil
    next if deadline && deadline >= today
  end

  puts raw
end

Fifty-five lines of Ruby. It runs before the agent sees the list. The filter runs on rules. It doesn’t guess. Overdue items stopped slipping.

Every session, the agent regenerates the filter. Not this time. I wrote real code. Guessing has limits.

Monday: a stretch of quiet time

A quiet Monday morning. Six refactor commits in one sitting. /calendar, /inbox, /weekly, /context. A stretch of uninterrupted time before the week’s meetings started.

That is when I realised the system had shifted. I wasn’t grinding through tasks. I was editing the system that edits my day. Maintenance, not task-grinding. The point of building a system is to make it fade into the background.

Tuesday: the cap

By the 24th, I noticed something else. My Anytime list kept growing. Each session, I added new tasks from retrospectives, meetings, and the inbox. The filter was treating the symptom. The disease was that the input exceeded the throughput.

I added a commitment cap.

Commitment cap: No more than 20 active next actions in
Things at any time across all areas (work and personal).
If /morning surfaces items that would exceed the cap,
flag it and ask what to defer before proceeding.

/morning now blocks the Top 7 until I’ve deferred enough items to sit under 20. The check is mechanical. I can’t talk it into running anyway.

What I learned

The dominant mode this week wasn’t invention. It was refactoring. Twenty-four commits out of about a hundred and forty say “from retro” or “from feedback.” The system improves by use, not by planning.

Retro-driven development. It works because the signal is cheap and the fix is small. Notice a friction point. Name it. In the next session, the command that caused the friction receives a line of new guidance. No meetings. No sprints. No planning.

The commitment cap came from one of those retros. So did bin/filter-anytime. So did Sally Lait’s colour conventions find their way into /calendar. Each started as an irritation, ended as a line in a command file, and changed how the next session ran.

Try it

Retros don’t need to be long. End each session with one. In the next session, fix what rubbed you the wrong way. The system is yours.

The original code

Our case studies page has an animated marquee of company logos — we derived that code from this tutorial on frontend.fyi. The popular approach to this pattern is to repeat the HTML a few times to create a seamless loop, but we wanted to avoid bloating the content with a leaner CSS-only approach.

Our HTML is fairly straightforward with container that controls the overflow and then a list with list items and an image for each logo.

<div class="horizontally-scrolling-logos">
  <ul class="horizontally-scrolling-logos__list">
    <li class="horizontally-scrolling-logos__item">
      <img
        src="images/vimeo.png"
        alt="vimeo logo"
        class="horizontally-scrolling-logos__image"
        loading="lazy"
      >
    </li>
    <li class="horizontally-scrolling-logos__item">
      <img
        src="images/merck.png"
        alt="Merck logo"
        class="horizontally-scrolling-logos__image"
        loading="lazy"
      >
    </li>
    <li class="horizontally-scrolling-logos__item">
      <img
        src="images/planned-parentood.png"
        alt="Planned Parenthood logo"
        class="horizontally-scrolling-logos__image"
        loading="lazy"
      >
    </li>
    <li class="horizontally-scrolling-logos__item">
      <img
        src="images/hbr.png"
        alt="Harvard Business Review logo"
        class="horizontally-scrolling-logos__image"
        loading="lazy"
      >
    </li>
    <li class="horizontally-scrolling-logos__item">
      <img
        src="images/moma.png"
        alt="MOMA logo"
        class="horizontally-scrolling-logos__image"
        loading="lazy"
      >
    </li>
  </ul>
</div>

The CSS leverages a lot of custom properties to note the animation speed, the number of logos in the list, etc. All of these go in to calculate the track width and position of each logo in the marquee.

.horizontally-scrolling-logos {
  --spacing--medium: 1.5rem;
  --speed: 25s;
  --numItems: 5;
  --single-slide-speed: calc(var(--speed) / var(--numItems));
  --item-width: 20rem;
  --item-gap: var(--spacing--medium);
  --item-width-plus-gap: calc(var(--item-width) + var(--item-gap));
  --track-width: calc(var(--item-width-plus-gap) * calc(var(--numItems)));

  overflow: hidden;

  &:hover .horizontally-scrolling-logos__item {
    animation-play-state: paused;
  }
}

.horizontally-scrolling-logos__list {
  align-items: center;
  container-type: inline-size;
  display: grid;
  gap: var(--spacing--medium);
  grid-template-columns: var(--track-width) [track] 0 [resting];
  width: max-content;

  @media screen and (prefers-reduced-motion: reduce) {
    display: flex;
    flex-wrap: wrap;
    justify-content: center;
    width: auto;
  }
}

.horizontally-scrolling-logos__item {
  animation: marquee var(--speed) linear infinite var(--direction, forwards);
  animation-delay: calc(
    var(--single-slide-speed) * var(--item-position) * -1
  );
  grid-area: resting;
  width: var(--item-width);

  &:nth-child(1) {
    --item-position: 1;
  }
  &:nth-child(2) {
    --item-position: 2;
  }
  &:nth-child(3) {
    --item-position: 3;
  }
  &:nth-child(4) {
    --item-position: 4;
  }
  &:nth-child(5) {
    --item-position: 5;
  }

  @media screen and (prefers-reduced-motion: reduce) {
    animation: none;
    display: flex;
    justify-content: center;
  }
}

@keyframes marquee {
  to {
    transform: translateX(calc(-100cqw - 100%));
  }
}

And what it looks like all together:

Reducing our code with functions

We can reduce the verbosity of this in one spot in particular: where we are defining the position of each child element.

Right now we’re using --item-position to relay the index of the child and set a staggered animation delay on each logo, which creates the marquee effect. We can remove all those nth-child declarations with a sibling-index() function in lieu of --item-position:

.horizontally-scrolling-logos__item {
  animation: marquee var(--speed) linear infinite var(--direction, forwards);
  animation-delay: calc(
-    var(--single-slide-speed) * var(--item-position) * -1
+    var(--single-slide-speed) * sibling-index() * -1
  );
  grid-area: resting;
  width: var(--item-width);

-  &:nth-child(1) {
-    --item-position: 1;
-  }
-  &:nth-child(2) {
-    --item-position: 2;
-  }
-  &:nth-child(3) {
-    --item-position: 3;
-  }
-  &:nth-child(4) {
-    --item-position: 4;
-  }
-  &:nth-child(5) {
-    --item-position: 5;
-  }

  @media screen and (prefers-reduced-motion: reduce) {
    animation: none;
    display: flex;
    justify-content: center;
  }
}

The --single-slide-speed calculates the overall speed of the animation divided by the number of children (–numItems). We can use sibling-count() here to replace --numItems. And we’ll need to move that calculation to be within the .horizontally-scrolling-logos__item to be able to count the siblings.

.horizontally-scrolling-logos__item {
+  --single-slide-speed: calc(var(--speed) / sibling-count());

  animation: marquee var(--speed) linear infinite var(--direction, forwards);
  animation-delay: calc(
    var(--single-slide-speed) * sibling-index() * -1
  );
  grid-area: resting;
  width: var(--item-width);

  @media screen and (prefers-reduced-motion: reduce) {
    animation: none;
    display: flex;
    justify-content: center;
  }
}

And that’s it! A small change overall, but an impactful one!

An annoying caveat

In a perfect world, we’d completely replace --numItems with sibling-count() so our CSS doesn’t have to manually track the number of logos in our marquee. But, in this current implementation, we need the parent element to use that to define the track width, not the children. Perhaps one day, we’ll have a function like children-count() to allow for more dynamic data in our CSS.

Another approach is to offload it onto Javascript by counting the siblings and setting the custom property inline. Our goal here, however, is to keep as much in the CSS as possible, and the tradeoff doesn’t seem worthwhile in this case.

And of course, there are a handful of other approaches to this web pattern that other people have solved in a variety of ways that would require us to rethink this architecture entirely. But we’re here for a quick and easy win.

A quick word on motion

You may have also noticed a declaration block in the code defining a reduced motion layout. This has nothing to do with sibling-index() or sibling-count() but feels worth mentioning (and has been a topic of discussion within our team). While we can do very fun things with animation in CSS, it’s still important to respect user preferences. Our scroll animation turns into static side-by-side images when that preference is reduced motion.

We could improve the code even more, by implementing an opt-in rather than an opt-out preference query.

.horizontally-scrolling-logos__list {
  align-items: center;
  display: flex;
  flex-wrap: wrap;
  justify-content: center;
  width: auto;
  container-type: inline-size;
  display: grid;
  gap: var(--spacing--medium);
  grid-template-columns: var(--track-width) [track] 0 [resting];
  width: max-content;

  @media screen and (prefers-reduced-motion: no-preference) {
    container-type: inline-size;
    display: grid;
    gap: var(--spacing--medium);
    grid-template-columns: var(--track-width) [track] 0 [resting];
    width: max-content;
  }
}

.horizontally-scrolling-logos__item {
  --single-slide-speed: calc(var(--speed) / sibling-count());

  animation: none;
  display: flex;
  justify-content: center;

  @media screen and (prefers-reduced-motion: no-preference) {
    animation: marquee var(--speed) linear infinite var(--direction, forwards);
    animation-delay: calc(
      var(--single-slide-speed) * sibling-index() * -1
    );
    grid-area: resting;
    width: var(--item-width);
  }
}

All of this is to say: small changes like this add up. Replacing repetitive selectors with functions like sibling-index() and sibling-count() makes the code easier to read and maintain, and a little more resilient to change.

It’s also a glimpse at where CSS is headed. As more logic moves into the language itself, we can rely less on JavaScript for things like layout and interactivity. That shift doesn’t always come in big, flashy features, but in small utilities that quietly reduce verbosity.

This particular change won’t revolutionize your codebase. But it does make things a bit simpler, and that’s usually a good trade.

And if the pace of new CSS features is any indication, we’ll have plenty more opportunities like this soon.

The trigger was simple. I ran /inbox and spotted the pattern. Every time: fetch the item, decide what to do, place it somewhere, move on. The first version of the command automated that loop:

# Inbox Command

Process the Things inbox one item at a time, newest first.

## Instructions

### Step 1: Load Context

Fetch in parallel:

1. Call `mcp__things__get_inbox` to get all inbox items
1. Call `mcp__things__get_projects` to get project names

Sort inbox items newest first (by creation date).

If the inbox is empty, report "Inbox is empty" and stop.

### Step 2: Present the Next Item

For each inbox item, present:

- Title
- Age
- Tags (if any)
- Notes (truncated if long)
- Related project (fuzzy-match title against project names)

Then wait for the user to say what they want to do.

Within thirty minutes, that command went through three revisions. The loop version advanced on its own. I changed it to single-item mode because I wanted control. Then I added reading detection: if the notes contain a URL, fetch the page title and suggest a tag. I created three commits, three lessons about how I process information.

The one-day command

The same morning, I created /reply for Slack DMs. It standardised the flow: find the user, open the DM, fetch the history, draft the reply, and send.

It lasted twenty-four hours.

By Wednesday, I had split it into /dm for direct messages and /thread for channel thread replies. Both shared a patterns file that held the common steps:

# DM Command

Send a direct message on Slack to $ARGUMENTS.

Follow shared patterns from
`.claude/commands/slack-patterns.md`.

## Instructions

### Step 1: Setup and Find User

1. **Rube Session Setup** (see `slack-patterns.md`)
1. **Find User** (see `slack-patterns.md`)

### Step 2: Open DM and Fetch History

1. Use `SLACK_OPEN_DM` with the user's ID
1. **Fetch History** on the DM channel
   (see `slack-patterns.md`)

The split happened because DMs and threads are different conversations. A DM is private, one-to-one, with full history. A thread is public, anchored to a specific message, with context that the whole channel can see. The same “reply” verb hid two different communication patterns.

The communication stack

That refactoring revealed something. Each command I built that week mapped to a communication channel:

• /dm — Slack direct messages
• /thread — Slack channel threads
• /slack — new channel messages
• /email — Gmail replies and composition
• /hub — reading saved Hub pages
• /draft — anything else (LinkedIn, talking points, Hub replies)

Six commands. Six ways I talk to people at work. The /draft command became the catch-all for channels without an API:

# Draft Command

Draft a reply or message for any context. Does not send.

Use this for LinkedIn messages, in-person talking points,
Hub replies, or any situation where `/dm`, `/thread`, and
`/email` don't apply.

## Pattern: Voice

Blend the user's natural tone with DHH and Nicholas Lezard:

- Direct and opinionated, but not abrasive
- Concise sentences that carry weight
- Avoid corporate filler
- Match the formality of the channel

The voice pattern is the part I did not expect to matter. I had assumed Claude would write in a generic assistant tone. Instead, by defining a voice, every draft came back in a register I recognised as mine. Not perfect. Close enough to edit rather than rewrite.

Plan mode and command boundaries

Not everything went well. On Tuesday, I hit a bug where plan mode leaked between commands. When I ran /waiting, it accumulated a state that bled into /retro. That broke both commands.

The fix took two commits and a revert. The first attempt added “Never use EnterPlanMode” to every command. That was wrong. The real fix was removing the auto-advance loop from /waiting. Each command invocation stayed self-contained. Commands are not functions. They are conversations. And conversations should end clean.

What I learned

Building these commands showed me something. My job as a director is communication:

• Write messages
• Respond to threads
• Follow up on waiting items
• Process my inbox
• Draft replies
• Read Hub posts

The actual management decisions happen in the gaps between those conversations.

The system I built in the first two weeks gave me structure: routines, meeting sync, and project files. This week gave me flow. The difference is that structure tells you what to do. Flow tells you how to do it without thinking about the mechanics.

I am not faster. I am less distracted. Each command removes one decision about where to go and what to type. That compounds over a day of fifty small conversations.

Try it yourself

Pick one communication pattern you repeat daily. Write a command for it. Not a script. A conversation. Define the steps, the voice, the context. Then run it and see what breaks. The breaking is where the learning is.