This week’s tip of the week is a tool called Betterleaks.

A few months ago, I wrote about hk, a Git hook manager that can run checks like formatting, linting, and type checking before your code gets committed. One of the things I mentioned was catching leaked secrets.

Well, here’s how to actually do that.

Betterleaks is an open-source secrets scanner maintained by folks behind Gitleaks, including its original author.

GitHub can scan repositories for leaked secrets, and that’s a great safety net.

But I’d rather catch an API key or token before the commit ever leaves my machine.

Betterleaks can scan just your staged changes. For this example, I staged some source code with a fake API key and a custom detection rule so there’s no real credential involved.

$ betterleaks git . --pre-commit --staged

 + ○
   ▾
 betterleaks 1.8.1

┌─demo-api-key──○
│
│ 2 │   const apiKey = "REDACTED";
│   │                   ^^^^^^^^
│
│ attributes:
│   git.message ......
│   git.sha ..........
│   path ............. src/api.ts
│   resource ......... git.patch_content
└○

11:05PM INF scanned ~394 bytes (394 bytes) in 35.7ms
11:05PM WRN leaks found: 1

And if you’re already using hk from my previous tip, it now has Betterleaks built in. Add it as one of your hook steps:

["betterleaks"] = Builtins.betterleaks

Now secret scanning can happen automatically alongside the other checks you already run before committing.

GitHub can still be another layer of protection, but it doesn’t have to be the first place you find out you committed a secret.

Check out Betterleaks and let me know what you think!

That’s it! Short and sweet. Until the next one!

This week's tip of the week is RTK.

Coding agents run a lot of terminal commands, and those commands can produce a lot of noise.

A test suite might print hundreds of passing tests when the agent only needs to see the two that failed. git push produces progress messages that rarely matter. Logs repeat the same lines over and over.

All of that output gets added to the agent’s context window.

RTK filters and compresses terminal output before the agent reads it. It supports more than 100 commands, including Git, GitHub CLI, npm, Docker, Kubernetes, test runners, linters, and build tools.

RTK supports macOS, Linux, and Windows. Check the official installation instructions for all the available options.

I’m on macOS. Homebrew was a couple of releases behind when I installed RTK, so I used the official installer:

curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/master/install.sh | sh

Once installed, configure RTK for your preferred coding harness. For example, Claude Code has a transparent hook integration:

❯ rtk init -g --agent claude

RTK hook registered (global).

  Command:   rtk hook claude
  RTK.md:    /Users/nicktaylor/.claude/RTK.md (awareness: default)
  CLAUDE.md: @RTK.md reference added

  settings.json: hook already present
  Restart Claude Code. Test with: git status

RTK also supports Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode, Windsurf, and several others. The setup and integration method vary, so check the supported coding harnesses for the appropriate command.

You can see how much output RTK has removed by running rtk gain:

❯ rtk gain
RTK Token Savings (Global Scope)
════════════════════════════════════════════════════════════

Total commands:    29
Input tokens:      249.0M
Output tokens:     27.5K
Tokens saved:      248.9M (100.0%)
Total exec time:   10.7s (avg 369ms)
Efficiency meter: ████████████████████████ 100.0%

By Command
────────────────────────────────────────────────────────────────────────
  #  Command                   Count   Saved    Avg%    Time  Impact
────────────────────────────────────────────────────────────────────────
 1.  rtk rg                        2  248.9M  100.0%    4.4s  ██████████
 2.  rtk ls -la /Users/nic...      1     403   71.6%     4ms  ░░░░░░░░░░
 3.  rtk ls -la                    1     196   78.4%     6ms  ░░░░░░░░░░
 4.  rtk ls -la /Users/nic...      1      10   24.4%     4ms  ░░░░░░░░░░
 5.  rtk:toml jq -e .hooks...      1       0    0.0%     9ms  ░░░░░░░░░░
 6.  rtk read                      1       0    0.0%     0ms  ░░░░░░░░░░
 7.  rtk proxy which rtk           1       0    0.0%     3ms  ░░░░░░░░░░
 8.  rtk proxy sh -c strin...      1       0    0.0%    24ms  ░░░░░░░░░░
 9.  rtk proxy sh -c print...      1       0    0.0%     2ms  ░░░░░░░░░░
10.  rtk proxy sh -c ls -l...      1       0    0.0%     7ms  ░░░░░░░░░░
────────────────────────────────────────────────────────────────────────

That result is dominated by two unusually large rg commands, so do not read it as “RTK cut my total AI usage by 100%.” RTK estimates token counts from command output, and terminal output is only one part of an agent’s context.

Still, less terminal garbage with RTK means more room for the context that matters.

That's it! Short and sweet. Until the next one!

This week’s tip of the week is Wox.

If you use Raycast on macOS or Windows, or Alfred on macOS, Wox is worth knowing about.

Wox is a free, open-source launcher for macOS, Windows, and Linux. It gives you the usual goodies like app and file search, clipboard history, calculations, plugins, and more.

I gave it a try and came away impressed.

Am I switching from Raycast? Probably not. I’ve been using Raycast for a few years now and I’m pretty deep into that workflow. I’m also perfectly happy on Raycast’s free tier.

But Raycast itself isn’t open source, and some of its additional features require a paid plan. If open source matters to you, or if I wanted that same style of launcher experience on Linux, Wox gets a lot more interesting.

And if you’re not already committed to Raycast or Alfred, I’d definitely give Wox a try before deciding which launcher to settle on.

It’s free, open source, and works across all three major desktop platforms.

Check out Wox and let me know what you think!

That’s it! Short and sweet. Until the next one!

This week's tip of the week is Mergiraf

These days, if I hit an annoying merge conflict, there's a good chance I'll just hand it off to my coding agent.

That works, but it also means I'm burning agent context on something that might not require an LLM at all.

Mergiraf is a syntax-aware merge tool. Instead of only looking at lines of text like Git does, it understands the structure of supported languages and can automatically resolve some conflicts that Git can't.

Here's a real example:

$ git merge add-retry-config
Auto-merging internal/config.go
CONFLICT (content): Merge conflict in internal/config.go
Automatic merge failed; fix conflicts and then commit the result.

$ mergiraf solve internal/config.go
WARN Cannot solve conflicts in diff2 style. Merging the original conflict sides from scratch instead.
INFO Solved all conflicts.

$ git diff --name-only --diff-filter=U
# no unresolved conflicts

Plain Git stopped at the conflict. Mergiraf reconstructed the original sides and resolved it structurally.

That's the workflow I wanted, so I also made a Mergiraf Agent Skill.

When my agent encounters a merge conflict, the skill checks for Mergiraf, installs it if necessary, and runs Mergiraf against the conflicted files first. Only the conflicts that remain get handed back to the agent for reasoning.

The principle here is bigger than this one tool: don't spend LLM tokens reasoning about something deterministic tooling can solve first.

You can install Mergiraf with Homebrew, Scoop, or Cargo. See the installation instructions.

Mergiraf won't magically solve every conflict, and you should still review what it resolves. But if it can make the conflict smaller, or eliminate it entirely, that's less work for you and less context for your coding agent.

And if you find Mergiraf useful, you can set it up as your Git merge driver so Git automatically gives it the first shot during merges, rebases, cherry-picks, and reverts.

That's it! Short and sweet. Until the next one!

This week's tip of the week is Marp.

I’m on my third talk using Marp now, and I really don’t want to go back to building presentations in a traditional slide editor.

Marp lets you build slide decks with Markdown and CSS.

That alone is useful, but the killer feature for me is how well it works with coding agents.

I’m working on my GitHub Universe talk right now, and they provided a pretty complex PowerPoint template they want speakers to use. I basically handed it to my agent and said, “make this work in Marp.”

My agent converted the PowerPoint design to Marp, pulled down the required fonts, installed what it needed, and got me to a working deck.

From that point on, the presentation is basically source code.

---
marp: true
theme: conference
---

# Fine-grained authorization

OAuth gets us authentication.

But what should the agent actually be allowed to do?

---

# The problem

- User can merge PRs
- Agent acts as the user
- OAuth doesn't know the difference

Now I can ask my agent to tighten a few slides, reorganize a section, add speaker notes, or change styling and it just edits the Markdown and CSS.

I tried something similar with Google Slides and browser automation before this. It was slow, inaccurate, and at one point the agent started trying to script its way around the UI.

With Marp, there’s no UI to fight.

Even if you love Keynote or PowerPoint, I think this workflow is worth trying in the agentic era. Markdown and CSS are just a much better interface for an agent to work with.

You can see my recent Commit Your Code deck running here, along with the generated PDF and PowerPoint.

I’ve also put together an open-source Marp starter kit with the local dev server and PDF/PowerPoint builds already wired up. Clone it, run it locally, and start writing slides.

That's it! Short and sweet. Until the next one!

This week's tip of the week is only-cli.

Coding agents read the web constantly, but an entire webpage can mean thousands of tokens of HTML, navigation, scripts, and other stuff the agent doesn't care about.

oc gives agents a compact, text-first way to browse instead.

Install it globally:

npm install -g @only-cli/oc

Here's a real example using this newsletter.

Say I'm asking an agent to help find my next terminal-related tip, but I want it to check what I've already covered first:

oc open https://onetipaweek.com >/dev/null
oc find "terminal"

That gave me:

4 matches for "terminal"
[37] ...Debug Network Problems Without Being a Network Expert
[40] ...Stop Babysitting Long-Running Terminal Commands
[43] ...Paste Images Into Remote AI Coding Agents

actions: do <n> | find <query> | read <n> | next | raw

The page is fetched once and saved locally. find searches that saved page without fetching it again.

If the agent wants to inspect one of those posts:

oc do 40

It gets a compact representation of the actual post:

# One Tip a Week: Stop Babysitting Long-Running Terminal Commands

This week's tip of the week is Pueue

Have you ever started a long-running command, then realized
your terminal is now its permanent babysitter?

Pueue gives you a proper task queue for shell commands.
...

The same pattern works for documentation, changelogs, project sites, blogs, and other mostly static pages.

It gets even more useful with coding agents. Install the included skill yourself, or just ask your agent to install it:

npx skills add https://github.com/only-cli/oc --skill web-browsing-cli

Installing the only-cli agent skill in my OpenClaw agent, McClaw

Now compatible agents can learn to reach for oc automatically instead of pulling whole webpages into context.

And this is where the token savings get pretty wild. Want to see them yourself?

oc --stats open https://onetipaweek.com

On the One Tip a Week archive, oc returned about 566 tokens versus roughly 196,209 tokens for the raw page HTML, about 99.7% fewer tokens.

That’s a lot less junk competing with the code, docs, and instructions your agent actually needs when using only-cli.

That's it! Short and sweet. Until the next one!

This week's tip of the week is Meetily.

AI meeting transcription is genuinely useful, but plenty of people don't want every conversation they have uploaded to a third-party server.

Meetily is a pretty nifty MIT-licensed, open-source desktop app for recording and transcribing meetings.

You can record directly in Meetily, or import an existing audio recording and have it generate a transcript and summary for you.

From there, Meetily gives you a full transcript, summary, key decisions, and action items.

Meetily in action

The part that really stands out is that Meetily is local-first.

Transcription can run locally using Whisper or Parakeet, and if you use Ollama for summaries, the whole workflow can stay on your machine.

If you prefer hosted models, it also supports providers like Claude, OpenAI, Groq, and OpenRouter.

So you get to choose whether your meeting ever leaves your computer.

Installation is straightforward on macOS and Windows from the Meetily releases page. Linux users can build it from source.

Between the polished UI, local processing, import support, and MIT license, this one is definitely worth checking out.

That's it! Short and sweet. Until the next one!

This week’s tip of the week is Trippy.

Ever had an app or service suddenly feel slow and wondered whether it was the app, your network, or something in between?

I’m definitely not a network expert, but Trippy makes getting some clues pretty approachable.

It combines ping and traceroute into a live terminal UI that shows the stops between your computer and a server, along with things like latency and packet loss.

Trippy has installation options for Linux, macOS, Windows, and BSD. Depending on your setup, you'll also need to configure the required privileges before running it.

Once installed, point it at a host. Let’s see what the route to GitHub looks like:

trip -u github.com

Trippy tracing github.com

Trippy continuously measures the route, so let it run for a bit and you’ll start getting useful data.

Say the first several stops are hovering around 20ms, but farther along the route that suddenly jumps to 180ms and stays high.

That’s a useful clue. The slowdown might be somewhere along the network path rather than the service you’re trying to reach.

I work on an identity-aware proxy for a living, so being able to answer “is this actually the proxy, or is the network having a bad day?” is pretty handy.

One caveat: don’t assume packet loss at a single stop means you’ve found the culprit. Some routers deprioritize this kind of diagnostic traffic. If the loss doesn’t continue through the following stops, it might not be a problem at all.

There’s plenty more you can dig into, but you don’t need to be a network guru to start getting useful information from Trippy.

If you’ve ever reached for ping while debugging something, give Trippy a try.

That’s it! Short and sweet. Until the next one!

This week’s tip of the week is Hallmark.

If you’ve been using AI to build frontends, you’ve probably noticed they can start to feel a little the same. Hallmark helps you stop shipping generic AI-generated UIs.

Hallmark is an AI skill that teaches your coding agent better design principles. Instead of settling for the same layouts and visual patterns over and over again, it encourages your AI to produce interfaces with better hierarchy, typography, spacing, and overall polish.

To put it to the test, I gave an AI the exact same prompt with and without Hallmark:

“Build a landing page for a developer tool called Logtail that helps developers search, filter, and analyze application logs. Include a hero section, a few key features, and a call to action to get started.”

Landing page generated without Hallmark

Landing page generated with Hallmark

Subjective and non-deterministic, but I prefer the Hallmark one.

Installing it takes less than a minute:

npx skills add nutlope/hallmark

Once it’s installed, it works with Claude Code, Cursor, Codex, and other Skills-compatible coding agents. You don’t need to learn a new workflow. Just keep prompting like you normally would, but with Hallmark available to your agent.

A while back I shared Impeccable, another AI skill for building better user interfaces. Hallmark and Impeccable take slightly different approaches, but I’ve found they complement each other really well.

That’s it! Short and sweet. Until the next one!

This week’s tip of the week is ZoomIt for Mac.

Windows users might already know ZoomIt from Microsoft’s Sysinternals Suite. It’s been a favorite for years, and now there’s finally a native macOS version.

If you ever find yourself saying, “Can everyone read that?” during a demo, livestream, or video call, this one’s for you.

Drawing with ZoomIt

ZoomIt for Mac lets you instantly zoom into any part of your screen while still interacting with it. You can also draw directly on your screen to highlight something without opening another app or awkwardly resizing windows.

Install it with Homebrew:

brew install --cask microsoft/sysinternalstap/zoomit

If you read my earlier tip about Snapzy, I’m still using it every day for screenshots, OCR, and recordings. ZoomIt doesn’t replace it. It fills a different niche by making live demos and screen shares easier to follow.

That’s it! Short and sweet. Until the next one!

This week's tip of the week is Pueue.

Have you ever started a long-running command, then realized your terminal is now its permanent babysitter?

Maybe it’s a build, a large download, video processing, a test suite, or some job running in your homelab. You can open another terminal, throw it into tmux, or tack on &, but then you’re managing processes instead of getting work done.

Pueue gives you a proper task queue for shell commands.

Add a few jobs:

pueue add "npm run build"
pueue add "npm test"
pueue add "yt-dlp https://example.com/video"

By default, Pueue runs them one at a time. You can see everything in the queue with:

pueue status

Need to inspect the output from a task?

pueue log 0

You can also pause the queue, resume it later, or restart a failed task:

pueue pause
pueue start
pueue restart 0

If your machine can handle more work, let multiple tasks run at once:

pueue parallel 3

Pueue runs through a background daemon. The queue isn’t tied to the terminal where you created it, so you can close the window or end an SSH session without losing your jobs. Your task history and logs are persisted too.

Pueue works on macOS, Linux, and Windows. On macOS, install it with Homebrew:

brew install pueue
brew services start pueue

You can also install it using your system package manager, download a prebuilt binary, or use Cargo:

cargo install --locked pueue
pueued -d

It’s not trying to replace cron, CI, or a heavy-duty job scheduler. It’s for those commands you start manually but don’t want to babysit manually. Give Pueue a try and let me know what you think!

That's it! Short and sweet. Until the next one!

This week's tip of the week is DuckDB.

At some point, most developers get handed a data export and need to answer one question about it.

If the file is small, you open it in a spreadsheet. If it is large or nested, you start writing a throwaway script, importing it into a database, or watching your editor reconsider its life choices.

DuckDB lets you query CSV, JSON, and Parquet files directly with SQL. There is no database server to run, schema to define, or import step required.

I recently exported all the 404 URLs from Google Search Console to figure out why Google was still crawling pages that no longer existed on my site.

Follow the installation page for Windows, macOS, or Linux. On macOS and Linux:

curl https://install.duckdb.org | sh

The installer will tell you how to add DuckDB to your PATH. Then launch it:

duckdb

Query the CSV by filename:

SELECT URL, "Last crawled"
FROM 'Table.csv'
ORDER BY "Last crawled" DESC
LIMIT 10;

I only cared about the route paths so I could search my codebase and content:

SELECT
  regexp_extract(URL, '^https?://[^/]+(/[^?]*)', 1) AS path,
  "Last crawled"
FROM 'Table.csv'
ORDER BY "Last crawled" DESC
LIMIT 10;

Extracting route paths from a Google Search Console CSV export

It does not even need to be a local file. DuckDB can also query JSON and Parquet files directly over HTTPS.

For example, I queried the live speaker data from AI Engineer Europe 2026, where I spoke this year. I expanded each speaker’s sessions and, for fun, found everyone whose name starts with nic:

SELECT
  speaker.name,
  speaker.role,
  speaker.company,
  talk.title
FROM read_json_auto(
  'https://www.ai.engineer/europe/2026/speakers.json'
) AS conference,
UNNEST(conference.speakers) AS s(speaker),
UNNEST(speaker.sessions) AS t(talk)
WHERE speaker.name ILIKE 'nic%'
ORDER BY speaker.name, talk.title;

Querying remote JSON data with DuckDB

That is the kind of task I would normally reach for jq or a quick script to handle.

Prefer a UI? Run duckdb -ui to browse data and write SQL in a local browser interface.

Running the DuckDB UI locally in a browser

That's it! Short and sweet. Until the next one!

This week's tip of the week is hk.

I've always found Git hooks useful, but I think they matter even more now that agents are writing and changing more of our code.

The more code our tools generate, the more valuable it is to automatically catch formatting issues, lint errors, broken tests, or even leaked secrets before they become commits.

The problem is that slow Git hooks are easy to resent.

You make a commit, stare at your terminal while formatting runs, then linting, then tests... and before long git commit --no-verify starts looking very tempting.

That's where hk comes in.

hk is a Git hook manager that can run independent checks like formatting, linting, and type checking in parallel when it's safe to do so, while still making sure dependent steps happen in the right order.

hk supports several installation methods across macOS, Linux, and Windows. Check out the installation docs for your platform.

Once it's installed, add its Git hooks to your repository:

hk install

I've spent a lot of time in the JavaScript and TypeScript ecosystems, so I've generally used Git hook tooling distributed as npm packages. But Git hooks are really repository infrastructure. The repository might contain Go, Rust, Python, JavaScript, or all of the above.

If you're happy with tools like Husky, lint-staged, or maybe Vite+'s hooks support, there's no urgent reason to switch. But if your hooks are starting to feel slow, or you're working across multiple languages, hk is well worth a look.

Give it a go and let me know what you think.

That's it! Short and sweet. Until the next one!

This week's tip of the week is herdr.

If you run an AI coding agent on a remote machine, you've probably hit this annoying little problem.

You take a screenshot, copy it, switch to your SSH session, and discover you can't paste the image into Claude Code, Codex, Pi, or whatever agent you're using.

herdr's native remote mode fixes that:

herdr --remote workbox

Your local herdr client connects to a herdr session on the remote machine, bridging your clipboard, including images. If herdr isn't already installed remotely, it'll offer to install it for you.

Honestly, that feature alone sold me on it.

The rest is why I've been using herdr every day.

I mostly run it locally as the command centre for my development workflow. Some panes have local agents, others SSH into remote machines, and others run dev servers, logs, or regular terminal commands.

herdr also understands agent state, so I can see which agents are working, idle, done, or waiting for me. It can play a sound when one finishes or needs input, which means less tab-hopping to check whether anything happened.

herdr in action

Its keyboard shortcuts follow familiar tmux conventions. For example, Ctrl+B, then Q, detaches from the session. Run herdr again later, and you're back in the same live session with your panes and processes still running.

I'm no tmux expert, either. Herdr has excellent mouse support, so you can click panes, tabs, agents, and context menus while the shortcuts slowly become muscle memory.

Install herdr on macOS with Homebrew:

brew install herdr

You can also use its installer on Linux or macOS:

curl -fsSL https://herdr.dev/install.sh | sh

That's it! Short and sweet. Until the next one!

This week's tip of the week is Handy.

I started using Handy recently, and it's quickly become one of the apps I use every day. Before Handy, I was using macOS's built in dictation. It wasn't bad, but Handy has been noticeably more accurate thanks to its offline speech-to-text models like Whisper and Parakeet. After a few days, I stopped reaching for the built in dictation altogether.

I've mostly been using it for two things. The first is blogging. It's often easier to explain an idea than type it. I'll dictate a rough draft, then go back and clean it up later. The second is talking to AI coding agents. Instead of typing long prompts, I just press a shortcut, explain what I want, and press it again when I'm done.

Because Handy works at the operating system level, it doesn't matter whether I'm talking to Claude Code, ChatGPT, Goose, GitHub Copilot, or writing in VS Code, Slack, GitHub, Notion, or my browser. If I can type there, I can dictate there.

Another thing I appreciate is that everything runs locally. Your audio stays on your machine, which makes it much easier to use with work projects than cloud-based dictation services. It also supports models for languages other than English.

Handy list of text to speech models

Installing it is straightforward. You can download the app or use one of the following:

# macOS
brew install --cask handy

# Windows
winget install cjpais.Handy

Linux users can download the latest release from the project page. There are a few distro and desktop environment specific notes in the README, so I'd recommend following the official installation instructions.

I still use a keyboard for writing code, but for blog posts, documentation, AI prompts, GitHub issues, and Slack messages, I've found myself reaching for Handy more and more.

That's it! Short and sweet. Until the next one!

This week's tip of the week is ast-grep.

Have you ever needed to update code across a large codebase and immediately regretted opening the search box? Regex can get you surprisingly far, but eventually you hit the wall. Code is structured. Text search is not.

That's where ast-grep comes in. It lets you search and rewrite code based on its abstract syntax tree (AST) instead of matching raw text. It understands the structure of your code, which means you can find things that would be painful, fragile, or downright impossible with traditional search.

For example, find every console.log call:

ast-grep --pattern 'console.log($$$)'

Or find every slog.New call in a Go progam:

ast-grep --lang go --pattern 'slog.New($$$)'

Or find every React useEffect:

ast-grep --pattern 'useEffect($$$)'

You can even perform safe code transformations across an entire project. Let's say your team deprecated a function oldApi(user) and replaced it with newApi(user). Instead of manually hunting through hundreds of files, ast-grep can find every usage and even rewrite them for you.

The real magic happens when you start creating reusable rules. Teams can use ast-grep for code migrations, enforcing conventions, detecting anti-patterns, and cleaning up large refactors.

You can install it via brew, cargo, npm and many other package managers.

If you've ever written a regex that looked like Klingon just to find a function call, ast-grep is worth a look.

That's it! Short and sweet. Until the next one!

This week's tip of the week is Lychee

You know what’s fun? Clicking a link in a README or documentation and landing on a 404. Actually, no. It’s not fun. It makes your docs feel stale, your project feel abandoned.

Lychee is a fast link checker written in Rust that can scan Markdown, HTML, reStructuredText, websites, and more. It finds broken links and email addresses before someone opens an issue with “hey, this link is dead.”

Install on macOS with Homebrew:

brew install lychee

on Windows:

winget install --id lycheeverse.lychee

on Linux:

snap install lychee

and for other Linux and other install options, see their installation docs.

Once installed, run it against a project:

lychee .

Or check specific files:

lychee README.md docs/**/*.md

Or check a website. Here it is in action on my own site:

❯ lychee https://nickyt.co
32/32 ━━━━━━━━━━━━━━━━━━━━ Finished extracting links                                                                                                        🔍 32 Total (in 4s 646ms) 🔗 28 Unique ✅ 32 OK 🚫 0 Errors 🔀 27 Redirects

Hint: Followed 27 redirects. You might want to consider replacing redirecting URLs with the resolved URLs. Use verbose mode (`-v`/`-vv`) to see redirection details.

That’s already useful locally, but the real win is putting it in continuous integration (CI) so broken links fail before they ship. Check out the official GitHub Action.

Here’s a tiny GitHub Actions example:

name: Links

on:
  repository_dispatch:
  workflow_dispatch:
  schedule:
    - cron: "00 18 * * *"

jobs:
  linkChecker:
    runs-on: ubuntu-latest
    permissions:
      issues: write # required for peter-evans/create-issue-from-file
    steps:
      - uses: actions/checkout@v5

      - name: Link Checker
        id: lychee
        uses: lycheeverse/lychee-action@v2
        with:
          fail: false

      - name: Create Issue From File
        if: steps.lychee.outputs.exit_code != 0
        uses: peter-evans/create-issue-from-file@v5
        with:
          title: Link Checker Report
          content-filepath: ./lychee/out.md
          labels: report, automated issue

You can also add a .lycheeignore file for links you know are weird, temporary, private, or blocked by some site that hates bots. The internet is held together with duct tape and redirects, so this matters.

I like this because it’s boring in the best way. It catches the stuff you probably won’t notice during a docs update, blog migration, repo cleanup, or release.

And honestly, I would rather have a robot tell me a link is broken than have a reader discover it first. Ready to add it? Drop it in your CI today.

That's it! Short and sweet. Until the next one!

This week's tip of the week is mise

If you jump between repos a lot, you probably know this dance:

“Which Node version does this use again?”
“Was this project on Python 3.11 or 3.12?”
“Where did we document the env vars?”
“Is the setup command in the README, package.json, Makefile, or someone’s brain?”

mise helps clean that up by managing project-specific runtimes, environment variables, and tasks from one config file.

Think of it like parts of asdf, pyenv, rbenv, nvm, and task runners like Make or npm scripts living under one roof, without turning your dev setup into a scavenger hunt.

Install it using the mise install docs. There are options for Homebrew, curl, package managers, and shell setup. Pick whatever install method from the buffet you prefer.

Once it’s set up, add a mise.toml to your project. Here’s a small mise.toml example:

[tools]
node = "22"
python = "3.12"

[env]
NODE_ENV = "development"
API_URL = "http://localhost:3000"

[tasks.install]
description = "Install project dependencies"
run = "npm install && pip install -r requirements.txt"

[tasks.dev]
description = "Start the app and API"
run = "npm run dev & python manage.py runserver"

[tasks.test]
description = "Run tests"
run = "npm test"

Now when someone opens the repo, they can run:

mise install # install runtimes, e.f. Node 22, Python 3.12
mise run install # install task
mise run dev

For a simple Node app, I’d probably keep using npm run dev. No need to add another layer just for the vibes. The win with mise is that the right Node version, Python version, and env vars are already loaded before that command runs.

The task runner side is more useful when a repo crosses ecosystems, or when you want consistent commands across projects. One repo might use npm run dev, another pnpm dev, another cargo run, but your muscle memory can stay mise run dev.

One honest caveat: mise configs can run commands, so treat a new mise.toml like you would a shell script from a repo you just cloned. Read it before trusting it.

Even if you are happy with asdf, direnv, nvm, or a pile of npm scripts, mise is worth a look if your projects keep needing “just one more setup step.”

That's it! Short and sweet. Until the next one!

This week's tip of the week is Kondo.

Do you have a folder full of old coding projects that you swear you’re going to come back to? Same. The problem is that those projects are usually dragging around a bunch of stuff you do not need anymore: dependencies, build artifacts, caches, compiled output, etc.

Kondo helps clean that up. This is not just “delete node_modules again.” à la rimraf or rm -rf. Kondo supports 20+ project types across different stacks, which makes it a nice cleanup tool for anyone with a messy ~/code, ~/dev, or ~/projects folder.

It scans your projects and finds dependency and build artifact folders that can usually be regenerated later. Think node_modules, Rust target, build folders, Composer vendor, CMake artifacts, and a bunch more.

Install it with Homebrew:

brew install kondo

Or with Cargo (you’ll need rust installed):

cargo install kondo

Then point it at a folder:

kondo ~/code

Kondo will scan your projects and prompt you before deleting anything. This is basically rm -rf with a nicer workflow and prompts. That is useful, but it also means you should review what it wants to delete before smashing yes like you’re accepting cookie banners.

A good first run is somewhere scoped:

❯ kondo ./mcterm
/Users/nicktaylor/dev/oss/mcterm/McTermCore Swift project (3 months ago)
  └─ .build (804.2MiB)
  └─ .swiftpm (345.0B)
  delete above artifact directories? ([y]es, [n]o, [a]ll, [q]uit): y
Projects cleaned: 1/1, Bytes deleted: 804.2MiB / 804.2MiB

If you have a pile of cloned repos, abandoned experiments, or conference demo apps sitting around, this is an easy way to claw back space without manually spelunking through every folder.

I’ve written about Mole before, which is also in the disk cleanup world (macOS only), but Kondo is more focused on cleaning dependency and build artifacts from code projects specifically, so it earns its own spot.

That's it! Short and sweet. Until the next one!

This week's tip of the week is Socket Firewall Free.

I’ve been using Socket’s GitHub app in my OSS projects, but for some reason, I wasn’t using Socket’s firewall locally.

Sébastien Lorber, who runs the excellent React newsletter This Week In React (subscribe if you live in React), shared his local setup for this. It’s worth sharing beyond the React ecosystem because npm supply chain attacks keep getting worse.

The setup is simple:

npm install -g sfw

# add these to your shell profile
alias npm="sfw npm"
alias npx="sfw npx"
alias pnpm="sfw pnpm"
alias yarn="sfw yarn"
alias bun="sfw bun"

Now your package manager commands run through Socket Firewall first.

So instead of blindly running npm install, npx some-random-cli, or pnpm add whatever, Socket Firewall Free can block known malware before it hits your machine.

Socket Firewall Free in action

Socket Firewall Free is free, as the name implies, for both open source and commercial use, which makes it an easy win for local development machines.

As I mentioned, they also offer a GitHub integration and team features for CI/CD workflows.

This is a no-brainer to set up locally.

That's it! Short and sweet. Until the next one!

Update 2026-06-01 11:04am: Thanks for this heads up from one of our subscribers. Telemetry is not configurable. Socket Firewall Free collects anonymous telemetry. Socket Firewall Enterprise allows you to configure telemetry collection.