Claude on ¬ just serendipity 🍀

drskill: lint claude skills

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 28 Jul 2026 19:09:34 +0200

♠ I found drskill through Drew Breunig’s post about managing an agent’s loadout.

Problem statement: lint skills bundled in a Claude Code plugin with drskill.

Running it through uvx is easy enough:

% uvx drskill scan --detailed
drskill scan — 3 harnesses (10 more empty), 9 skills
...
0 errors, 5 warnings (5 new) · token counts are approximate

But none of this repository’s 11 skills appeared. The known limitation explains why:

Claude Code skills bundled inside plugins are not scanned yet.

I projected the plugin’s skill directory into the plain .claude/skills layout that drskill understands via Justfile:

# Check skills with drskill
doctor:
    #!/usr/bin/env bash
    set -euo pipefail
    tmp=$(mktemp -d)
    trap 'trash "$tmp"' EXIT
    mkdir -p "$tmp/project/.claude/skills" "$tmp/home"
    for skill in "$PWD"/plugins/thiagowfx/skills/*; do
      ln -s "$skill" "$tmp/project/.claude/skills/$(basename "$skill")"
    done
    uv_cache=$(uv cache dir)
    cd "$tmp/project"
    HOME="$tmp/home" UV_CACHE_DIR="$uv_cache" uvx drskill scan --ci --harness claude-code

The temporary HOME excludes unrelated global skills. Reusing uv’s cache avoids redownloading drskill there. --ci makes warnings fail the recipe.

The first isolated scan found four warnings:

drskill scan — 1 harness, 11 skills

WARNINGS
  [e91d] new frontmatter-angle-brackets: 'bloggify' ...
  [a551] new frontmatter-angle-brackets: 'gha' ...
  [6335] new frontmatter-angle-brackets: 'new-apkbuild' ...
  [206e] new missing-activation: 2 skills never say when to use them ...

0 errors, 4 warnings (4 new) · token counts are approximate
exit=2

The fixes were small: remove angle brackets from argument-hint values and add explicit activation conditions to catchup and handoff:

-argument-hint: "<url>"
+argument-hint: "url"

-description: Create portable handoff document for another agent or harness to continue current work.
+description: Create a portable handoff document for another agent or harness to continue current work. Use when the user asks for a handoff, continuation brief, or context transfer.

Now the repository has its own linter:

% just doctor
drskill scan — 1 harness, 11 skills

No findings.
0 errors, 0 warnings · token counts are approximate

Restoring <url> temporarily made just doctor exit 2 again, so future warnings will break the check. I should add it to CI at some point.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #claude #coding #dev

claude code: replace a hand-rolled loop with /goal

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 16 Jul 2026 13:44:25 +0200

♠ Previously.

Problem statement: one of my skills, /pr-pass, was a hand-rolled loop — push, poll CI, fix a failure, re-push, repeat, bail after five iterations.

It works quite well, and it’s one of my most used skills.

That said, recently Claude Code shipped /goal (in v2.1.139), which is exactly that loop, packaging it as a primitive. So the skill was reimplementing something the harness now does natively.

In fact, most harnesses ship /goal natively these days.

We shall refactor!

/goal sets a completion condition. After each turn a fast model checks whether it holds; if not, Claude starts another turn on its own. It auto-clears once the condition is met. From the docs:

The /goal command sets a completion condition and Claude keeps working toward it without you prompting each step. After each turn, a small fast model checks whether the condition holds. If not, Claude starts another turn instead of returning control to you.

That deletes three things the old skill hand-built: the Monitor poll waiting on CI state, the “go back to Step 1” loop, and the max-5-iterations guard. The guard becomes a clause in the condition itself:

/goal every check on this PR has passed (gh pr checks shows no FAILURE
and no PENDING), or stop after 5 turns

One catch worth knowing before reaching for /goal: the evaluator (tester?) is a fresh model that only reads the transcript. It does not run gh or read files.

It does not call tools, so it can only judge what Claude has already surfaced in the conversation.

So the condition has to be something Claude’s own output demonstrates. The skill now says to paste the gh pr checks result into the reply every turn, so the evaluator has a CI state to judge against. Otherwise the goal would have never resolved thus it would have looped forever.

Another gotcha: /goal doesn’t touch permissions. Each turn’s git push still prompts unless paired it with auto mode.

The lesson generalizes past this one skill: whenever the harness grows a primitive, the custom code that predates it becomes technical debt. /loop, Stop hooks, and /goal now cover most of the “keep going until X” constructs I used previously.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #claude #coding #dev

when Gen AI cites docs that don't exist

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 16 Jul 2026 12:34:22 +0200

♠ Today in AGI: two Claude agents, same annotation, opposite answers.

I had a PR touching an ArgoCD PostSync hook. Ordering hooks within a phase needs an annotation, so I asked; Claude Code (Opus 4.8) and Claude in GitHub disagreed:

Claude Code: argocd.argoproj.io/hook-weight does not exist.
Claude in GitHub: it does exist.

Both stated it flatly. So I pushed the GitHub agent, and it doubled down — citing documentation(!):

This claim is incorrect. argocd.argoproj.io/hook-weight is a documented ArgoCD annotation for controlling hook execution order within a phase. From the ArgoCD resource hooks documentation:

Citing non-existent docs is the clanker equivalent of pulling rank.

Confident. Sourced. Wrong. The actual annotation for ordering is argocd.argoproj.io/sync-wave:

They are defined by the argocd.argoproj.io/sync-wave annotation. The value is an integer that defines the ordering.

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "5"

There is no hook-weight. The “documentation” it quoted from doesn’t say what it says it says.

Eventually it folded:

You are correct, and I apologize for the confident but incorrect claim in round 3.

Round 3. It took three rounds and a fabricated citation before the model conceded. The failure mode isn’t the hallucination — it’s the escalation to """docs""" as authority to defend it.

Same model family, same question, one right and one wrong. Verify against the upstream source, not against the more confident agent.

Human-in-the-loop is still very much needed, folks.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #claude #dev #kubernetes

★ claude code: ship your skills as a plugin marketplace

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 25 Jun 2026 20:40:02 +0200

♠ Problem statement: my Claude Code skills lived in my .dotfiles, usable only on the machine that cloned them. I wanted them to be installable anywhere with one command, so that (for example) my teammates could easily adopt them.

Claude Code reads skills from a marketplace, which is essentially a git repo with a manifest. So I turned github.com/thiagowfx/skills into one. The layout:

.claude-plugin/marketplace.json    # marketplace manifest
plugins/thiagowfx/                 # one plugin
  .claude-plugin/plugin.json       # plugin manifest
  skills/<name>/SKILL.md           # one dir per skill (auto-discovered)

The marketplace lists plugins; a plugin bundles skills. I have one plugin holding all ten. I do not find it necessary to have multiple plug-ins at this point. marketplace.json points at it with a relative source:

{
  "name": "thiagowfx",
  "owner": { "name": "Thiago Perrotta", "url": "https://github.com/thiagowfx" },
  "plugins": [
    {
      "name": "thiagowfx",
      "source": "./plugins/thiagowfx",
      "description": "Thiago's personal Gen-AI / Claude Code skills."
    }
  ]
}

The plugin manifest is just metadata — there’s no need to enumerate skills. Anything under skills/<name>/SKILL.md is discovered automatically:

{
  "name": "thiagowfx",
  "version": "0.2.2",
  "license": "MIT"
}

The docs are explicit about why I keep that version:

Setting version means users only receive updates when you change this field, so bump it on every release. If you omit version and host this marketplace in git, every commit automatically counts as a new version.

I’ll go with version pinning for now.

Install from any machine:

/plugin marketplace add thiagowfx/skills
/plugin install thiagowfx@thiagowfx

/plugin marketplace update thiagowfx pulls future changes.

Outside Claude:

claude plugins update thiagowfx@thiagowfx

The whole thing — manifests, nine seeded skills, README, license — was scaffolded by Claude Code itself, which felt appropriately recursive: one of the skills I was packaging interviews me about a plan before any code gets written, so it grilled me about how to package the skills. Quite meta, eh?

Next up: point the dotfiles at the repo so there’s a single source of truth.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bestof #claude #coding #dev

★ caveman: talk like caveman, save tokens

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 25 Jun 2026 01:30:43 +0200

♠ Long Claude Code sessions eat a lot of context, fast. Each response injects tokens into the context window: prose-heavy replies burn through it faster than terse ones ($$).

caveman is a Claude Code plugin that switches the model into a compressed communication style: drops articles, filler words, and pleasantries while keeping full technical accuracy. Claims ~75% token reduction per response.

Installation:

% /plugin marketplace add JuliusBrussee/caveman
Successfully added marketplace: caveman
% /plugin install caveman@caveman
✓ Installed caveman. Run /reload-plugins to apply.

After /reload-plugins, manually activate with /caveman. Manually deactivate it by saying “normal mode” or “caveman off”.

A session-start hook fires automatically on the next session, effectively auto-enabling it (M-x caveman-mode emacs vibes).

It ships three modes (lite, full, ultra) and three subagent presets (cavecrew-investigator, cavecrew-builder, cavecrew-reviewer). I don’t care. This is unnecessary bloat. An irony, for a plug-in intended to mitigate bloat.

The out-of-the-box installation is enough; tweaks are not necessary. The defaults are sensible.

In practice: responses are punchy. The model still reasons correctly; it just stops narrating. No “Sure, I’d be happy to help with that.” Just the answer.

~~You’re absolutely right.~~ no more!?

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bestof #claude #dev

bloggify

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 09 Jun 2026 16:50:11 +0200

♠ I’ve been drawing a line for ages here. My AI usage policy, quoting Derek Sivers:

I have never ever used AI to generate text in place of my “voice”. […] nothing claiming to be written by me is written by an AI.

Likewise, I said. Then in “new blog post via Claude Code” I held the line one more time: the LLM orchestrates the publishing, but “everything is still my own text, my own words. The LLM is not writing the prose.”

The line moved. Slightly. I wrote a /bloggify skill whose entire job is to draft a post in my own style / voice:

---
name: bloggify
description: Draft a blog post for perrotta.dev in the existing house style.
argument-hint: "<topic or what you want to write about>"
---

Write a blog post about `$ARGUMENTS` for the perrotta.dev blog.

The trick is that the style is already written down. The repo has a STYLE.md — derived by reading my own old posts — and the skill just points at it:

The repo owns the style. Read STYLE.md and CLAUDE.md first — they are the source of truth for voice, structure, frontmatter, and conventions.

It scaffolds with just new, follows the rules I’d already codified (minimal frontmatter, bold problem statement, code carries the weight, no “In this post I will…”), lints with prek, and hands back a draft. It does not commit.

So: is this still my own words?

Mostly. The skill forbids invented examples — it has to use real commands, real output, the real artifact. The structure is mine, written down a year ago. The voice is mine, learned from my old posts. The prose is the machine’s impression of me, and I edit it until it sounds like me again.

The line didn’t disappear. It just got blurrier.

I (still) commit to reading the entire post, paragraph by paragraph, and making manual changes to it to better match my style.

As of today, it’s not clear to me whether this approach will stick.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #claude #dev #meta

Claude Enterprise: plan usage

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 26 May 2026 13:11:11 +0200

♠ When enrolled in a Claude Enterprise plan, /usage (or /cost) are useless.

Instead, head over to https://claude.ai/settings/usage to assess your usage limits.

Usage limits normally reset at the beginning of the month.

Your plan admin can increase your usage limits manually ~~if you ask it nicely~~ when warranted.

— § —

Reply via email

#ai #claude #dev

Grill me

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 25 May 2026 14:55:10 +0200

♠ Matt Pocock (via Sebastian de Deyne):

This is an intro to the /grill-me skill, separate from my video on my top 5 skills. It’s the most flexible skill I’ve ever created, and one I use outside of coding too.

Here is the skill in all its glory:
---
name: grill-me
description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
---

Interview me relentlessly about every aspect of this plan until
we reach a shared understanding. Walk down each branch of the design
tree resolving dependencies between decisions one by one.

If a question can be answered by exploring the codebase, explore
the codebase instead.

For each question, provide your recommended answer.
This skill is incredibly short — just a few lines that pack a powerful punch.

This skill is very useful for brainstorming. I have adopted it as well.

— § —

Reply via email

#ai #claude #dev

prove_it: verification hooks for Claude Code

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 21 May 2026 19:10:09 +0200

♠ Problem statement: Claude Code likes to declare “done” without running tests. Said no overconfident LLM ever.

prove_it by Justin Searls is a config-driven hook framework that intercepts Claude’s lifecycle events (SessionStart, PreToolUse, Stop) and runs whatever tasks you configure — tests, linters, AI reviewers — blocking the Stop until they pass.

I like this concept in spirit.

Installation:

% brew install searlsco/tap/prove_it
% prove_it install                    # one-time, registers global hooks at ~/.claude/
% cd <git repo> && prove_it init      # per-repo config + script stubs + git hooks; comparable to `pre-commit install`
% prove_it doctor                     # comparable to `brew doctor`

I (finally!) tried it today and concluded that it’s not for me.

That said, I really like the ideas that Justin developed there. I’ll look into adopting some of them into my global CLAUDE.md.

See the README.md for documentation.

— § —

Reply via email

#ai #claude #dev

llm: Anthropic Claude plugin

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 21 May 2026 16:33:51 +0200

♠ Simon Willison’s llm CLI ships with OpenAI models out of the box. Anthropic Claude support lives in a separate plugin, llm-anthropic.

% llm plugins
[]

Install it:

% llm install llm-anthropic
...
Successfully installed anthropic-0.103.1 docstring-parser-0.18.0 llm-anthropic-0.25

Verify:

% llm plugins
[
  {
    "name": "llm-anthropic",
    "hooks": [
      "register_models"
    ],
    "version": "0.25"
  }
]

Claude models are now registered:

% llm models | grep -i anthropic
Anthropic Messages: anthropic/claude-opus-4-7 (aliases: claude-opus-4.7)
Anthropic Messages: anthropic/claude-sonnet-4-6 (aliases: claude-sonnet-4.6)
Anthropic Messages: anthropic/claude-haiku-4-5-20251001 (aliases: claude-haiku-4.5)
[...]

Set the API key:

% llm keys set anthropic

And prompt away:

% llm -m claude-haiku-4.5 "hello"
Hello! How can I assist you today?

— § —

Reply via email

#ai #claude #dev

★ Personal CLAUDE.md

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 20 May 2026 14:20:44 +0200

♠ I asked Claude Opus 4.7 to generate a global CLAUDE.md for my tone & style based on historical usage for 12+ months. The result¹ was added to my thiagowfx/.dotfiles repo, cross-posted here for ease of reference and future preservation.

I expect this file to evolve over time. Updates won’t be republished here; the dotfiles repo is the source of truth.

# Global CLAUDE.md

Personal preferences that apply across every project. Project-specific facts live in each repo's own CLAUDE.md.

## Tone

- Terse. Action-oriented. No lectures, no preamble, no trailing summaries, no
  political correctness.
- Don't invent sections, headings, or boilerplate I didn't request. Match the
  shape of what I asked for.
- Number multi-part questions (1/2/3) so I can answer inline.
- When disambiguating, focus on one topic at a time.
- If I reply "yes", "go on", "a)", "do it", or similar — that's full
  authorization. Don't re-confirm.

## Keep moving

- If my reply is "hello?", "so?", "are you still there?" — you stalled. Don't
  wait for trivial confirmation; pick the reasonable default and continue.
- After a sandbox lift ("try again", "I lifted your sandbox") — retry the exact
  same command. Don't restart reasoning.
- Don't pause to summarize what you just did before doing the next step.

## Don't over-engineer

- Bug fixes don't need surrounding refactors. One-shot operations don't need
  helpers.
- If you add a flag (`--force`, `--recursive`, etc.), be ready to justify it.
  Don't cargo-cult.
- Prefer the simplest thing that works. I'll ask for more if I want more. Keep
  it simple.

## Destructive ops

- Never `rm`. Use `trash` (or the equivalent move-to-trash).
- For destructive ops on shared state (S3 objects, branches, DB rows): make a
  backup first, then delete only what matches, then confirm. Phrase:
  *backup → filter → delete*.
- Never force-push to `master`/`main`. Never skip hooks (`--no-verify`) unless I
  explicitly ask.

## Tooling defaults

- **Pre-commit**: prefer `prek` over `pre-commit`. Run
  `prek run --all-files`. When configuring hooks, prefer self-contained/pinned
  deps over relying on system binaries.
- **Polling**: never `sleep` in a loop. Use the `Monitor` tool with an `until`
  condition, or `run_in_background` and wait for the notification.
- **`gh pr checks`**: `--watch` and `--json` are mutually exclusive. Don't
  combine them.
- **Editor**: vim (preferred) and Zed. Don't suggest VSCode-specific workflows.

## Worktrees and PRs

- Default to worktrees for parallel work. Path convention:
  `~/<org>/<repo>/.worktrees/<topic>/`. If I say "work here please: `<path>`",
  `cd` there and proceed. Use the `wt` tool to manage worktrees.
- Branch prefix: `thiagowfx/<topic>`.
- Slash commands I lean on: `/commit`, `/commit-and-send-pr`, `/send-pr`,
  `/pr-pass`, `/gha`, `/grill-me`. If I chain a task with one of these ("do X,
  then /commit-and-send-pr foo"), treat the slash command as the final step —
  invoke it, don't paraphrase.
- "commit what you changed (only). DO NOT push" means exactly that: stage only
  the files you touched this turn, commit, stop.
- For non-trivial PRs, include a Mermaid diagram in the description when it
  helps. Beware of string escaping issues.
- After any meaningful change to an open PR, update the PR description
  (`gh pr edit`) so it reflects the current state. Don't let the title/body
  drift from what the branch actually does.

## Drift and reconciliation

- When code and live state disagree, the default is **update the code to match
  the live state**, not the reverse. Don't propose `terraform import`
  reshuffles unless I ask.

Colophon #

How did I do this?

% cd ~/.claude && claude
% help me craft my (global) CLAUDE.md, based on past interactions

That’s it! No fancy prompt. Direct and succinct.

I performed a few manual tweaks. The end result was quite decent (to my taste). ↩︎

— § —

Reply via email

#ai #bestof #claude #dev #meta #pkm #serenity

claude: /powerup

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 04 May 2026 10:44:47 -0400

♠ Previously.

Run /powerup within Claude Code:

 ▐▛███▜▌   Claude Code v2.1.126
▝▜█████▛▘  Sonnet 4.6 · Claude Enterprise
  ▘▘ ▝▝    /Users/thiago.perrotta

❯ /powerup
───────────────────────────────────────────────────────────────────────────────
  Power-ups 5/10 unlocked ████████

  Each power-up teaches one thing Claude Code can do that most people miss. Open
  one, read it, try it, mark it done.

    ✔ Talk to your codebase    @ files, line refs
    ✔ Steer with modes         shift+tab, plan, auto
    ✔ Undo anything            /rewind, Esc-Esc
    ◯ Run in the background    tasks, /tasks
    ◯ Teach Claude your rules  CLAUDE.md, /memory
  ❯ ✔ Extend with tools        MCP, /mcp
    ◯ Automate your workflow   skills, hooks
    ◯ Multiply yourself        subagents, /agents
    ◯ Code from anywhere       /remote-control, /teleport
    ✔ Dial the model           /model, /effort

  ↑↓ to select · Enter to open · Esc to close

This is a clever and unobtrusive way to teach usage tips and tricks to developers, I like it!

— § —

Reply via email

#ai #claude #dev

Large context windows

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 29 Apr 2026 17:49:48 +0200

♠ Claude Code status bar in a lovely Wednesday:

mongodb (git:thiagowfx/atlas-mongo-promote-aws-peering ⎇ mongodb) [Opus 4.7 (1M context)] [██░░░ 406k/1000k 50%] $40.53 sid:{session ID}

It feels good to be able to use more than 200k tokens in a single session.

— § —

Reply via email

#ai #claude #dev

claude: recap

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 24 Apr 2026 00:52:56 +0200

♠ Now that frontier models from Anthropic have context windows of up to 1M tokens, I constantly find myself forgetting what each session is about whenever I have 4+ terminal tabs open.

I know, I could simply name sessions, but I often don’t.

Can we throw AI at the issue? Of course, Gen AI solves problems generated by AI (pun intended).

There’s this built-in ~~command~~ skill: /recap:

Generate a one-line session recap now

200K+ tokens later, /recap is my hope to remind me of what I was doing the day before.

— § —

Reply via email

#ai #claude #dev

claude, claudey, claudeyy

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 18 Apr 2026 23:40:02 +0200

♠ My current workflow:

`claude` #

Pure claude code. Straight from homebrew: brew install claude-code.

`claudey` #

% which claudey
claudey: aliased to cco --allow-oauth-refresh --add-dir ~/.cache --add-dir ~/.aws/cli/cache --add-dir ~/.aws/sso/cache --add-dir ~/.azure --add-dir ~/.terraform.d/plugin-cache --add-dir ~/go --add-dir ~/Library/Keychains

Previously: cco.

`claudeyy` #

% which claudeyy
claudeyy: aliased to claude --allow-dangerously-skip-permissions

Living dangerously!

I’m satisfied with claudey most of the time.

— § —

Reply via email

#ai #claude #dev

★ anki: flashcard generation with claude code

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 15 Apr 2026 16:09:12 +0200

♠ Previously.

I started to use Claude Code to generate flashcards for my (new) Tech Deck via AnkiConnect, covering books and topics I’m studying for to consolidate my SWE-SRE knowledge.

The workflow: I tell Claude which book or topic to cover, it researches their key concepts, checks my existing cards (notes) for potential overlap, and batch-adds new ones via the AnkiConnect HTTP API:

def anki_request(action, **params):
    payload = json.dumps({"action": action, "version": 6, "params": params})
    req = urllib.request.Request("http://localhost:8765", data=payload.encode(), method="POST")
    with urllib.request.urlopen(req) as resp:
        return json.loads(resp.read())["result"]

notes = [
    {
        "deckName": "Tech 💻",
        "modelName": "Basic",
        "fields": {
            "Front": "DDIA: <b>LSM-Trees vs B-Trees</b> — how do they differ?",
            "Back": "..."  # HTML-formatted answer
        },
        "tags": ["ddia"],
    },
    # ... more notes
]

anki_request("addNotes", notes=notes)

In a sample session, topics covered:

Topic	Cards	Tag
SRE (Google)	50	`sre`
System Design	40	`system-design`
LeetCode / Python	41	`python`
Kubernetes	20	`kubernetes`
Production-Ready Microservices (Susan Fowler)	28	`microservices`
DDIA (Martin Kleppmann)	25	`ddia`
Building Microservices (Newman)	16	`microservices`
Fundamentals of Software Architecture (Richards & Ford)	25	`software-architecture`
Kubernetes advanced	25	`kubernetes`
Networking	17	`networking`
Linux / Systems Performance	16	`linux`
Python stdlib	23	`python`
Total	~326

For each book, Claude searched the web for chapter summaries and key concepts, cross-referenced my existing cards to avoid duplication, then created a Python script to push cards through AnkiConnect’s addNotes action.

Cards match the existing format: Basic note type, HTML formatting (<b>, <br>, <code>, •), one tag per topic.

Example card (front):

DDIA: Sloppy quorums and hinted handoff — what are they?

Example card (back):

In a standard quorum (w + r > n), writes/reads must reach specific replicas. Problem: during a network partition, the designated replicas may be unreachable. Strict quorum would reject the write → reduced availability. Sloppy quorum: Accept writes on any reachable nodes, even if they aren’t the designated replicas (…)

The whole process took about an hour. Doing it by hand would have taken days.

I am excited to evolve this workflow. The next step is going to be to refactor my thousands of language cards and notes.

— § —

Reply via email

#ai #bestof #claude #dev #pkm

claude: /simplify

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 12 Apr 2026 10:18:17 +0200

♠ Previously.

My all-time favorite bundled skill for code reviewing in Claude Code: /simplify.

As per the official docs:

/simplify   Review changed code for reuse, quality, and efficiency, then fix any issues found. (bundled)

A sample run:

  Running 3 agents… (ctrl+o to expand)
   ├─ Code reuse review · 38 tool uses · 42.1k tokens
   │  ⎿  Read: modules/remote-access-ips/main.tf
   ├─ Code quality review · 17 tool uses · 29.8k tokens
   │  ⎿  Searching for 7 patterns, reading 10 files…
   └─ Efficiency review · 0 tool uses
      ⎿  Done
     (ctrl+b to run in background)

It is effective, not very opinionated (which is good in this context!), and non-intrusive.

And it surely burns a good share of tokens.

I’m interested in exploring ways to automate this skill invocation as part of every PR.

— § —

Reply via email

#ai #claude #dev

★ claude code: naming sessions

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 12 Apr 2026 10:06:51 +0200

♠ Previously.

Problem statement: claude --resume accepts a session ID (UUID), but UUIDs are not human-friendly.

% claude --resume 92884e7a-422a-4e2a-9fbc-dc0a2e85380b

I can’t remember that at all, and even copy-and-paste is error-prone in this context (e.g. missing the first or last character in the UUID).

There are a few ways to turn this into a nicer developer experience.

Start a session with a name:

% claude --name "golden-ami-deploy-servers"

Realistically, though, that’s hard to remember. Also, oftentimes you’ll start a session without knowing upfront what you’ll work on.

Rename mid-session with /rename:

/rename golden-ami-deploy-servers

Better! The name can be adjusted on-the-fly. It resembles tmux in this aspect.

Or: just /rename with no argument will auto-generate a name from the conversation history. Fancy. That will burn a few more tokens though.

And now, back to the original problem:

Resume by name:

% claude --resume "golden-ami-deploy-servers"

The interactive picker (claude --resume with no argument) also displays session names, making it easy to find what you’re looking for.

You can also invoke /resume mid-session.

— § —

Reply via email

#ai #bestof #claude #dev

cco: OAuth refresh fix

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 12 Apr 2026 07:35:32 +0200

♠ Previously.

Problem statement: cco is not able to autonomously refresh the OAuth token used by claude.

The manual workaround is to run an one-off unsandboxed claude, and then get back to cco afterwards.

Why?

Run /doctor within cco and compare its output with /doctor within an unsandbox claude code session. The culprit:

Warning: macOS Keychain is not writable (security: SecKeychainItemCreateFromContent (<default>): UNIX[Operation not permitted];
  add-generic-password: returned 100001). Console login will fail to save your API key.
  Fix: Run: security unlock-keychain ~/Library/Keychains/login.keychain-db — if that doesn't fix it, your login keychain password may
  be out of sync with your account password: open Keychain Access, select the 'login' keychain, then Edit → Change Password for
  Keychain 'login'.

So now I am passing --add-dir ~/Library/Keychains to cco, and the warning is finally gone!

commit 5c111a7caffb4e6b3dc4d678d4fc1bd6c8296ae5
Author: Thiago Perrotta <{redacted}>
Date:   Sun Apr 12 07:34:53 2026 +0200

    cco: add key chain dir, via /doctor

diff --git profile/.profile.d/alias.sh profile/.profile.d/alias.sh
index 0f5018c..80d7b60 100644
--- profile/.profile.d/alias.sh
+++ profile/.profile.d/alias.sh
@@ -51,7 +51,7 @@ fi

 if command -v claude >/dev/null 2>&1; then
 	if command -v cco >/dev/null 2>&1; then
-		alias claudey="cco --allow-oauth-refresh --add-dir ~/.cache --add-dir ~/.aws/cli/cache --add-dir ~/.aws/sso/cache --add-dir ~/.azure --add-dir ~/.terraform.d/plugin-cache --add-dir ~/go"
+		alias claudey="cco --allow-oauth-refresh --add-dir ~/.cache --add-dir ~/.aws/cli/cache --add-dir ~/.aws/sso/cache --add-dir ~/.azure --add-dir ~/.terraform.d/plugin-cache --add-dir ~/go --add-dir ~/Library/Keychains"
 	fi
 	alias claudeyy="claude --allow-dangerously-skip-permissions"
 fi

— § —

Reply via email

#ai #claude #dev #security

claude code: kitty keyboard protocol garbage

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 25 Mar 2026 14:15:27 +0100

♠ Upon quitting Claude Code, pressing C-c in the terminal produces garbage like this instead of the expected ^C:

❯ 0;5u9;5u0;5uc9;5u9;5u9;5u9;5u9;5u

Something similar happens with C-a, C-e, C-l, etc. I am using zsh.

What’s happening #

Claude Code enables the kitty keyboard protocol (“CSI u mode”) for enhanced key input handling. Whenever the program exits cleanly, it restores the terminal to its original state. However, if the cleanup doesn’t fully complete (crash, SIGKILL, etc.), the terminal remains in CSI u mode.

In this mode, keypresses are sent as escape sequences rather than being interpreted by the shell. For example, Ctrl-C sends \e[99;5u (keycode 99 = c, modifier 5 = Ctrl) instead of being interpreted as SIGINT. Multiple rapid keypresses concatenate into the garbled output above.

Fix #

Reset the terminal:

reset

Or, more targeted — disable CSI u mode explicitly:

printf '\e[<u'

…though no one can remember this. reset is standard and simple, though it could be easily confused with clear.

Prevention #

Add a precmd hook to ~/.zshrc so the protocol is disabled before every prompt:

precmd() { printf '\e[<u' 2>/dev/null }

For bash, use PROMPT_COMMAND instead:

PROMPT_COMMAND='printf "\e[<u" 2>/dev/null'

This is a no-op when the terminal is already in normal mode, so there’s no downside to having it always run.

This is what Claude says, but I’d rather not clutter my precmd due to Claude. For now, I am happy to run reset manually when needed.

I suspect this is well-known but they have many open bugs in their GitHub issue tracker, I couldn’t pinpoint it to a specific issue.

Update: well, someone reported it just 5 minutes ago at the time of this post.

— § —

Reply via email

#ai #claude #dev

cco: additionalDirectories

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 18 Mar 2026 17:31:13 +0100

♠ Previously.

Problem statement: passing --add-dir flags to cco in a shell alias doesn’t scale well as the number of directories increases.

I had this alias:

alias claudey="cco --allow-oauth-refresh --add-dir ~/.cache --add-dir ~/.aws/cli/cache --add-dir ~/.aws/sso/cache --add-dir ~/.azure --add-dir ~/.terraform.d/plugin-cache"

cco now supports reading additionalDirectories from .claude/settings.local.json, inside the permissions object:

{
  "permissions": {
    "additionalDirectories": [
      "~/.cache",
      "~/.aws/cli/cache",
      "~/.aws/sso/cache",
      "~/.azure",
      "~/.terraform.d/plugin-cache"
    ]
  }
}

…since PR #44.

The alias then becomes:

alias claudey="cco --allow-oauth-refresh"

The directories are now project-specific, checked into each repo’s .claude/settings.local.json. Much cleaner.

I wish it would support the global ~/.claude/settings.json too, but it doesn’t.

— § —

Reply via email

#ai #claude #dev #security

claude: srt: sandbox runtime

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 04 Mar 2026 12:27:42 +0100

♠ Previously: cco.

cco handles filesystem isolation but not networking — srt adds network isolation.

Disclaimer: This post was adapted from a slides presentation I recently created for an AI hackathon. Its prose resembles a quick-reference manual.

`srt`: sandbox-runtime #

srt is Anthropic’s open-source sandbox runtime. It is process agnostic and it uses OS-native primitives — Seatbelt on macOS, bubblewrap on Linux — no container overhead, just like cco.

Run a command inside the sandbox (“hello world”):

% npx @anthropic-ai/sandbox-runtime <command>

Or you might as well install it so that it is easily invokable as srt¹:

% npm install -g @anthropic-ai/sandbox-runtime

-g is for global (=not local).

Network restrictions in action:

% srt "curl anthropic.com"
<html>...</html>                  # allowed

% srt "curl example.com"
Connection blocked by network allowlist  # blocked

Filesystem restrictions in action:

% srt "cat README.md"
# Anthropic Sandb...               # current dir allowed

% srt "cat ~/.ssh/id_rsa"
cat: Operation not permitted        # blocked

The sandbox configuration lives globally in ~/.srt-settings.json:

{
  "network": {
    "allowedDomains": ["github.com", "registry.npmjs.org"],
    "deniedDomains": []
  },
  "filesystem": {
    "denyRead": ["~/.ssh", "~/.aws/credentials"],
    "allowWrite": ["."],
    "denyWrite": [".env", "config/production.json"]
  }
}

It is secure by default — everything is blocked unless explicitly allowed. Separate controls for filesystem reads, writes, and network domains.

native `/sandbox` #

Since v1.0.29, Claude Code ships with native sandboxing — powered by srt under the hood. Enable it with the /sandbox command. Zero setup on macOS.

Two modes:

Auto-allow: sandboxed commands run without prompts; unsandboxable commands fall back to the regular permission flow.
Regular: all commands still require approval, but sandbox boundaries are enforced. The most strict.

In the first mode, you will see the following pattern quite often:

⏺ Bash(gh api user --jq .login)
  ⎿  Error: Exit code 71
     sandbox-exec: sandbox_apply: Operation not permitted

     sandbox-exec: sandbox_apply: Operation not permitted

⏺ Sandbox restriction on gh. Let me retry outside the sandbox.

⏺ Bash(gh api user --jq .login)
  ⎿  thiagowfx

Anthropic reports ~84% fewer permission prompts with auto-allow mode.

~/.claude/settings.json:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": true,
    "allowedDomains": ["registry.npmjs.org", "api.github.com"],
    "excludedCommands": ["docker"],
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build", "~/.cache"]
    }
  }
}

autoAllowBashIfSandboxed — sandboxed commands run without prompts
excludedCommands — tools that always run outside the sandbox (e.g. Docker)
allowUnsandboxedCommands — escape hatch for commands that fail inside the sandbox (still requires approval)
filesystem.allowWrite — grant subprocess write access to paths outside the working directory

When to use what?

cco: quick filesystem-only sandbox, zero config, IDE agnostic
srt: standalone sandbox for any process (not only Claude Code) with network isolation
/sandbox: native Claude Code integration, fewest prompts, recommended for daily use

I’ve been daily driving cco + the native /sandbox. It encompasses the best of all worlds.

srt reminds me of the popular subtitles extension format for videos. Also, I constantly makee typos by typing str instead. ↩︎

— § —

Reply via email

#ai #claude #dev #security

★ claude: add session ID to status bar

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 02 Mar 2026 11:18:19 +0100

♠ Desired outcome:

❯ claude

 ▐▛███▜▌   Claude Code v2.1.63
▝▜█████▛▘  Opus 4.6 · Claude Team
  ▘▘ ▝▝    ~/.dotfiles

──────────────────────────────────────────────────────────
❯
──────────────────────────────────────────────────────────
  .dotfiles (git:master*) [Opus 4.6] [█░░░░] $0.00 sid:9afc33ee-610d-47cc-8bde-1a52d1b22832

The status bar displays the current:

git repository we’re on
git branch
model name
context window usage (%)
session cost (in USD)
session ID

I recently added the last two items, and the post title reflects that.

The session cost is helpful as a pat on the shoulder to remind you of how expensive Anthropic models are. If you want to put a cap on the session, --max-budget-usd could be helpful:

--max-budget-usd <amount>		Maximum dollar amount to spend on API calls (only works with --print)

The session ID is, by itself, useless. It is just a boring UUID, auto-generated whenever a new session is started.

That said, the session ID can become powerful when you start to treat sessions as first-class citizens (e.g. like how Amp Code does to threads).

Use cases #

Use case #1: resume a previous session.

claude [-r | --resume] <uuid>

-r, --resume [value]		Resume a conversation by session ID, or open interactive picker with optional search term

This is useful whenever you know in advance you’ll need to close your terminal (e.g. to restart your computer for system upgrades).

Use case #2: multiple divergent explorations.

claude --fork-session [-r | --resume | -c | --continue] <uuid>

--fork-session				 When resuming, create a new session ID instead of reusing the original (use with --resume or --continue)

Whenever you reach a point of ambiguity when vibe coding, you may want to explore multiple paths. --fork-session creates new sessions from an existing context window (session ID), allowing you to preserve your original session context.

Use case #3: refer to other sessions.

Sample prompt:

let's continue work from sid:484b8360-b5ee-4a47-9137-f45c00ff2dc0

this foo path is too slow, make it faster by activating the infinite
improbability module

The config #

The resulting diff:

thiago.perrotta ~/.dotfiles git:master
❯ git --no-pager show 0f94082
commit 0f9408223c60dcda980c18787d3d0c1519428c30
Author: Thiago Perrotta <{redacted}>
Date:   Fri Feb 27 16:56:57 2026 +0100

    claude: status bar: add session ID, add cost

diff --git claude/.claude/statusline.sh claude/.claude/statusline.sh
old mode 100644
new mode 100755
index 785b5f3..f43527a
--- claude/.claude/statusline.sh
+++ claude/.claude/statusline.sh
@@ -5,8 +5,10 @@ input=$(cat)

 # Extract information from JSON
 model_name=$(echo "$input" | jq -r '.model.display_name')
+session_id=$(echo "$input" | jq -r '.session_id')
 current_dir=$(echo "$input" | jq -r '.workspace.current_dir')
 output_style=$(echo "$input" | jq -r '.output_style.name')
+cost=$(echo "$input" | jq -r '.cost.total_cost_usd')

 # Get current working directory basename
 dir_name=$(basename "$current_dir")
@@ -87,5 +89,15 @@ if [[ -n "$context_info" ]]; then
     status_parts+=("$context_info")
 fi

+# Add cost
+if [[ -n "$cost" && "$cost" != "null" ]]; then
+    status_parts+=("$(printf '$%.2f' "$cost")")
+fi
+
+# Add session ID
+if [[ -n "$session_id" && "$session_id" != "null" ]]; then
+    status_parts+=("sid:$session_id")
+fi
+
 # Join parts with spaces and print
 printf "%s" "$(IFS=' '; echo "${status_parts[*]}")"

The full status line config. I’ll inline it here for completeness:

#!/bin/bash

# Read JSON input from stdin
input=$(cat)

# Extract information from JSON
model_name=$(echo "$input" | jq -r '.model.display_name')
session_id=$(echo "$input" | jq -r '.session_id')
current_dir=$(echo "$input" | jq -r '.workspace.current_dir')
output_style=$(echo "$input" | jq -r '.output_style.name')
cost=$(echo "$input" | jq -r '.cost.total_cost_usd')

# Get current working directory basename
dir_name=$(basename "$current_dir")

# Get git information if in a git repository
git_info=""
if git rev-parse --git-dir > /dev/null 2>&1; then
    branch=$(git branch --show-current 2>/dev/null)
    if [[ -n "$branch" ]]; then
        # Check for uncommitted changes
        if ! git diff --quiet 2>/dev/null || ! git diff --cached --quiet 2>/dev/null; then
            dirty="*"
        else
            dirty=""
        fi

        # Check if in a linked worktree (not the main worktree)
        worktree_info=""
        git_dir=$(cd "$(git rev-parse --git-dir 2>/dev/null)" && pwd)
        git_common_dir=$(cd "$(git rev-parse --git-common-dir 2>/dev/null)" && pwd)
        if [[ "$git_dir" != "$git_common_dir" ]]; then
            # We're in a linked worktree - show its name
            worktree_path=$(git rev-parse --show-toplevel 2>/dev/null)
            worktree_name=$(basename "$worktree_path")
            worktree_info=" ⎇ $worktree_name"
        fi

        git_info="(git:$branch$worktree_info$dirty)"
    fi
fi

# Calculate context window usage (relative to auto-compact threshold ~80%)
context_info=""
usage=$(echo "$input" | jq '.context_window.current_usage')
if [ "$usage" != "null" ]; then
    # Include output_tokens for accurate context measurement
    current=$(echo "$usage" | jq '.input_tokens + .output_tokens + .cache_creation_input_tokens + .cache_read_input_tokens')
    size=$(echo "$input" | jq '.context_window.context_window_size')

    # Auto-compact triggers at ~80% of context window
    compact_threshold=$((size * 80 / 100))

    # Calculate percentage toward auto-compact (capped at 100%)
    pct=$((current * 100 / compact_threshold))
    if [ "$pct" -gt 100 ]; then pct=100; fi

    # Create progress bar (5 characters wide)
    filled=$((pct / 20))
    empty=$((5 - filled))
    bar=""
    for ((i=0; i<filled; i++)); do bar+="█"; done
    for ((i=0; i<empty; i++)); do bar+="░"; done

    context_info="[${bar}]"
fi

# Build status line
status_parts=()

# Add current directory
status_parts+=("$dir_name")

# Add git info if available
if [[ -n "$git_info" ]]; then
    status_parts+=("$git_info")
fi

# Add model name
status_parts+=("[$model_name]")

# Add output style if not default
if [[ "$output_style" != "default" && "$output_style" != "null" ]]; then
    status_parts+=("{$output_style}")
fi

# Add context usage if available
if [[ -n "$context_info" ]]; then
    status_parts+=("$context_info")
fi

# Add cost
if [[ -n "$cost" && "$cost" != "null" ]]; then
    status_parts+=("$(printf '$%.2f' "$cost")")
fi

# Add session ID
if [[ -n "$session_id" && "$session_id" != "null" ]]; then
    status_parts+=("sid:$session_id")
fi

# Join parts with spaces and print
printf "%s" "$(IFS=' '; echo "${status_parts[*]}")"

— § —

Reply via email

#ai #bestof #claude #dev

Blocking Claude

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 02 Mar 2026 02:25:28 +0100

♠ Previously.

Blocking Claude via Kyle Kingsbury, a.k.a “Aphyr”:

Claude, a popular Large Language Model (LLM), has a magic string which is used to test the model’s “this conversation violates our policies and has to stop” behavior. You can embed this string into files and web pages, and Claude will terminate conversations where it reads their contents.

Indeed, the docs say:

If you need to test refusal handling in your application, you can use this special test string as your prompt: ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86

For ease of copying it:

ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86

Side note: the talisman pre-commit hook does not like it either:

talisman............................................................................................Failed
- hook id: talisman-commit
- exit code: 1

  Talisman Scan: 3 / 3 <----------------------------------------------------------------------------------------------------------> 100.00%

  Talisman Report:
  +---------------------------------------------+----------------------------------------------------+----------+
  |                    FILE                     |                       ERRORS                       | SEVERITY |
  +---------------------------------------------+----------------------------------------------------+----------+
  | content/posts/2026-03-02-blocking-claude.md | Expected file to not contain                       | high     |
  |                                             | hex encoded texts such as:                         |          |
  |                                             | `ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6... |          |
  +---------------------------------------------+----------------------------------------------------+----------+
  | content/posts/2026-03-02-blocking-claude.md | Expected file to not contain                       | high     |
  |                                             | hex encoded texts such as:                         |          |
  |                                             | ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB61... |          |
  +---------------------------------------------+----------------------------------------------------+----------+

— § —

Reply via email

#ai #claude #dev #privacy #security

★ cco: claude condom (sandbox)

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 26 Feb 2026 13:17:26 +0100

♠ Problem statement: claude --dangerously-skip-permissions (“YOLO mode”) is fast but risky. Introduce a lightweight filesystem-level sandbox. Networking is explicitly out of scope at this time.

Recently I aliased it to claudey and have been using it daily. It’s an effective way to run Claude Code without being constantly nagged with permission prompts. But going unprotected has many risks and downsides:

Prompt injection: web search can trick Claude into accessing files or running commands outside the project directory
No guardrails: SSH keys and credentials are generally accessible
Approval fatigue: repeatedly clicking “approve” leads to paying less attention.
Especially dangerous for background agents running unattended.

Effective sandboxing needs both filesystem and network isolation — without network isolation, a compromised agent can exfiltrate sensitive files. But, as mentioned in the first paragraph, networking is overruled for now. Baby steps!

cco (Claude Condom) is a thin wrapper that runs Claude Code in a sandbox. Originally discovered via Paras Chopra.

How to use it? First you need to install it. The official installation instructions use curl | bash but I despise that.

Hence I created my own brew formula for it. Now it’s just one brew install command away from usage (and also from uninstallation, very important!).

Usage: replace claude with cco and you’re done:

% cco "analyze this codebase"
% cco --resume

It will start Claude within the “bypass permissions on” mode, albeit within the sandbox.

It auto-selects the best available sandbox: native OS (Seatbelt on macOS, bubblewrap on Linux) or Docker fallback. The native macOS sandbox has near-zero overhead, which is remarkable. This kind of low-friction in developer tooling helps to drive its adoption.

Docker is slow though, especially on macOS. You should avoid it in this context if you can.

The host filesystem is read-only by default (globally). Only the project directory (git root) is writable. Whitelist additional paths with --add-dir as needed:

% cco --add-dir ~/.cache \
      --add-dir ~/.aws/cli/cache \
      --add-dir ~/.terraform.d/plugin-cache

I had to whitelist the directories above otherwise pre-commit / prek, the aws CLI and terraform would fail sporadically.

--safe hides $HOME entirely; only whitelisted paths are visible.

--deny-path blocks specific sensitive paths.

All Claude Code flags (--resume, --model, etc.) pass through transparently.

Why cco?

it’s zero-config
its startup has pretty much zero overhead
it’s IDE agnostic
it just works™

Why not cco?

It does not handle networking. srt is more suitable as an additional step.

I updated my claudey alias:

alias cco="cco --allow-oauth-refresh --add-dir ~/.cache --add-dir ~/.aws/cli/cache --add-dir ~/.terraform.d/plugin-cache"

Update(2026-03-02): ~/.aws/sso/cache is also needed for the AWS CLI.

--allow-oauth-refresh is necessary, or else:

⎿  API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth token has expired. Please obtain a new token or refresh your
     existing token."},"request_id":"req_{redacted}"} · Please run /login

…my login credentials would expire roughly once every day. Re-authenticating every day is quite annoying.

This is properly documented:

Credential file access: The credentials JSON is mounted read-only by default, so Claude cannot update tokens unless --allow-oauth-refresh is explicitly enabled.

— § —

Reply via email

#ai #bestof #claude #dev #security

★ Gimme subagents

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 23 Feb 2026 10:57:55 +0100

♠ Scenario: we’re test-driving the adoption of a Terrateam feature called stacks. The specifics aren’t relevant here.

In a typical agentic LLM session with Claude Code¹, the feature was drafted (planned) and then subsequently implemented.

Following that comes the important part: testing! As part of the testing process I tend to resonate with Thorsten Ball:

Most of the time, when I work with Amp, I know in advance (a) what I want the resulting code to do and (b) how I will test that it does exactly that.

Once Amp declares it’s done writing code, I test. And what I mean is that I “test”, in every possible meaning of the word. The goal is to make sure the code actually does what it’s supposed to do. That can mean: asking Amp to run the unit tests, asking it to manually test in a browser, asking it to run a command, or check the data in the database, run the curl. With every tool I have — Amp, code, my hands and eyes — I test the happy path, the teary path, the edge cases. I make sure to test with existing data, no data, real data, fake data. I think about what might be different in production and how I could test that. Sometimes I ask Amp itself how I can manually verify what it just did and ask it to walk me through the testing.

How exactly I test very much depends on what I’m testing. Not all functionality and code have the same blast radius. Some sit at the heart of a system, some are peripheral. Adjust accordingly.

But once I’ve tested something and compared how it works with my mental model of how it’s supposed to work, then the code, I find, becomes less important.

Yes, I’ll do spot-checks to make sure it isn’t completely insane (less and less of a problem with these new models). I also go through my mental list of always-check-these things like (a) where and how is the data stored (b) will this box us in and prevent future changes (c) security (d) does it touch functionality I hadn’t considered. Sometimes that can take a while, other times there’s barely anything to do.

…hence I surely prompt the LLM to suggest me how to test the feature:

⏺ Here's how to test the stacks feature:

  1. Validate the config syntax

  just check-terrateam-tags

  This confirms all projects referenced in .terrateam/config.yml have valid tags, including the new corp-network-check tags.

  2. Verify tag assignments are correct

  Check that the right projects land in each stack:

  # Foundation layer projects
  just list-projects-by-tag network
  just list-projects-by-tag terraform-secrets
  just list-projects-by-tag atlas

  # Compute layer projects
  just list-projects-by-tag eks
  just list-projects-by-tag corp-network-check

  # Services layer (future)
  just list-projects-by-tag service-identity

  Confirm that every cluster project falls into exactly one of the three stacks.

  3. Validate the config file itself

  just validate-terrateam-config   # if this recipe exists
  # or simply:
  yamllint .terrateam/config.yml   # basic YAML syntax check

  4. Test on a real PR (the real test)

  Stacks are a Terrateam server-side feature — the ordering logic runs in Terrateam's CI, not locally. The only real end-to-end test is:

  [...]

For the sake of preserving the context window of my current session, I employ the following technique:

❯ 1) OK (in a subagent)
  2) OK (in a subagent, in parallel)
  3) OK (in a subagent, in parallel)

  let's do these first. Prompt me before going to 4

⏺ 3 agents finished (ctrl+o to expand)
   ├─ Bash (Check terrateam tags validation) · 1 tool use · 13.3k tokens
   │  ⎿  Done
   ├─ Task (Verify tag assignments per stack) · 17 tool uses · 32.3k tokens
   │  ⎿  Done
   └─ Bash (Validate terrateam config YAML) · 7 tool uses · 16.5k tokens
      ⎿  Done

And that works exactly as you would expect it to.

⏺ All three checks passed:

  1. Tag validation (just check-terrateam-tags)

  All {redacted – number of projects} standalone projects are properly tagged.

  2. Stack tag assignment verification

  ┌─────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │                  Check                  │                                                    Result                                                    │
  ├─────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Cluster projects missing from all stacks│ None — all {redacted – number of projects} cluster projects are covered                                      │
  ├─────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Cluster projects in multiple stacks     │ None — tag sets are disjoint                                                                                 │
  ├─────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Non-cluster projects in stacks          │ 10 projects (6 terraform-secrets, 1 opsgenie, 3 atlas) — all in cluster-foundation, expected/harmless per ADR│
  ├─────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Placeholder tags (not yet in use)       │ deploy, rds, service-identity — cluster-services stack is currently empty                                    │
  └─────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  3. Config validation

  - yamllint: passed (zero warnings/errors)
  - just check: all checks passed (AWS profiles, terrateam tags, AWS provider tags)

  Everything looks good locally. Ready for step 4 (push branch, open PR, test Terrateam's stack ordering on a real PR) whenever you want to proceed.

In prose: consider using subagents (i) to preserve your context window, and (ii) to speed up testing by running them in parallel.

One disadvantage: I’d avoid using subagents in this manner whenever the testing procedures aren’t clearly well-defined and scoped (for example, whenever they are ambiguous or uncertain). Why? Because I’d rather have full control in these complex scenarios, by having the ability to manually steer the LLM in real-time. With subagents you have limited ability to do so.

Last but not least: subagents are not an exclusive feature of Claude Code:

Pi has a couple of extensions that add subagents capabilities to it. Example (untested)
And so does OpenCode.
I am a bit surprised to find out that Codex does not support them yet. Or does it?

Should I stop linking to their website? At this point, every Software Engineer has heard of Claude Code at least once, right? ↩︎

— § —

Reply via email

#ai #bestof #claude #dev

★ New APKBUILD: LLM edition

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 18 Feb 2026 11:23:05 +0100

♠ Problem statement: package prek for Alpine Linux.

prek is a modern replacement for pre-commit, covered (many times) in this blog¹.

Previously.

It’s already a breeze to create APKBUILDs. I’ve been doing so for ages.

Now, in 2026, with agentic LLMs, it’s even more so!

I can be more useful to the Alpine Linux community by increasing my efficiency as a package maintainer.

Yesterday I used Amp Free in smart mode (Opus 4.6) to scaffold the APKBUILD for prek, using the AUR PKGBUILD as a baseline. Prompt:

write an APKBUILD for prek, inspired by https://aur.archlinux.org/packages/prek

once written, copy it to knol (ssh knol)
aports dir: ~/workspace/aports (in knol)

The result:

# Maintainer: Thiago Perrotta <{redacted}>
pkgname=pre
pkgver=0.3.3
pkgrel=0
pkgdesc="Better pre-commit, re-engineered in Rust"
url="https://github.com/j178/prek"
arch="all"
license="MIT"
makedepends="cargo cargo-auditable"
subpackages="
	$pkgname-bash-completion
	$pkgname-fish-completion
	$pkgname-zsh-completion
	$pkgname-doc
	"
source="$pkgname-$pkgver.tar.gz::https://github.com/j178/prek/archive/v$pkgver.tar.gz"
options="net" # fetch dependencies

prepare() {
	default_prepare
	cargo fetch --target="$CTARGET" --locked
}

build() {
	cargo auditable build --release --frozen

	target/release/prek util generate-shell-completion bash > $pkgname.bash
	target/release/prek util generate-shell-completion fish > $pkgname.fish
	target/release/prek util generate-shell-completion zsh > $pkgname.zsh
}

check() {
	cargo test --frozen
	cargo test --frozen -- --skip cache_gc_keeps_local_hook_env --skip cache_gc_removes_unreferenced_entries
}

package() {
	install -Dm755 target/release/$pkgname -t "$pkgdir"/usr/bin/

	install -Dm644 $pkgname.bash "$pkgdir"/usr/share/bash-completion/completions/$pkgname
	install -Dm644 $pkgname.fish "$pkgdir"/usr/share/fish/vendor_completions.d/$pkgname.fish
	install -Dm644 $pkgname.zsh "$pkgdir"/usr/share/zsh/site-functions/_$pkgname

	install -Dm644 LICENSE -t "$pkgdir"/usr/share/licenses/$pkgname/
	install -Dm644 README.md -t "$pkgdir"/usr/share/doc/$pkgname/
}

sha512sums="
87f5b5905d0c95b7f55a789eb00b463bb987c5fc981d83500f34a41b8e9ea2e4a0ac9d45a0c3a029a7957de33f5ade866c396c399252eb4a7a9e09e32e270b99  prek-0.3.3.tar.gz
"

This was a great initial attempt, but tests failed:

Stopped on the first failure. Run `cargo insta test` to run all snapshots.
thread 'cache_gc_removes_unreferenced_entries' (15179) panicked at /builds/thiagowfx/aports/testing/prek/tmp/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/insta-1.46.3/src/runtime.rs:719:13:
snapshot assertion for 'cache_gc_removes_unreferenced_entries-2' failed in line 234
failures:
    cache_gc_keeps_local_hook_env
    cache_gc_removes_unreferenced_entries

A follow-up edit yielded this diff:

@@ -30,7 +30,7 @@ build() {
}

check() {
-	cargo test --frozen
+	cargo test --frozen -- --skip cache_gc_keeps_local_hook_env --skip cache_gc_removes_unreferenced_entries
}

package() {

…but that caused more failures. Then I got interrupted and the night ended.

Today, I continued with Claude Code.

Original prompt to claudey² using Opus 4.6:

we’re packaging prek for alpine linux (APKBUILD)

we’re using https://aur.archlinux.org/packages/prek as reference

we have access to an alpine system in knol (ssh knol)

the aports tree lives in ~/workspace/aports in knol

we’re already in the right branch, the prek APKBUILD lives in testing/prek within knol

the problem is that the test is failing in our MR pipeline: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/97666

sample job: https://gitlab.alpinelinux.org/thiagowfx/aports/-/jobs/2223963 (raw log: https://gitlab.alpinelinux.org/thiagowfx/aports/-/jobs/2223963/raw)

fix the APKBUILD!

I think it’s a missing checkdep

A couple of burned tokens later:

APKBUILD updated. Here’s what changed:

Added checkdepends=“bash python3”:

python3 — prek’s pygrep language handler uses uv to find a Python interpreter. Without system Python, uv python find fails, causing all 11 pygrep tests to fail. Also needed for the windows_script_run test which uses a #!/usr/bin/env python3 shebang.

bash — the script tests use #!/usr/bin/env bash shebangs, and Alpine doesn’t ship bash by default (only busybox ash).

Added –skip for language integration tests needing unavailable runtimes:

docker — needs Docker daemon (also covers docker_image via substring match)

julia — Julia not available in Alpine

lua:: — Lua interpreter not available

haskell — GHC/cabal not available

node:: — Node.js/npm not available

ruby:: — Ruby not available

rust:: — Rust toolchain tests (rustup) not available

swift:: — Swift not available

bun:: — Bun not available

The unit tests (282) plus other integration suites (auto_update, builtin_hooks, cache, hook_impl, identify, install) still run fully. You can commit and push to re-trigger the pipeline.

That’s spot on. Here’s the diff:

🧙 thiago@knol ~/workspace/aports/testing/prek git:prek
❯ git --no-pager show
commit 8f702c5f1ee1b6d153a4f957c309f2badd452d31 (HEAD -> prek)
Author: Thiago Perrotta <{redacted}>
Date:   Wed Feb 18 05:30:14 2026 -0500

    skip language integration tests

diff --git testing/prek/APKBUILD testing/prek/APKBUILD
index 5e134457bc..d6080fa977 100644
--- testing/prek/APKBUILD
+++ testing/prek/APKBUILD
@@ -7,6 +7,7 @@ url="https://github.com/j178/prek"
 arch="all"
 license="MIT"
 makedepends="cargo cargo-auditable"
+checkdepends="bash python3"
 subpackages="
 	$pkgname-bash-completion
 	$pkgname-fish-completion
@@ -30,7 +31,18 @@ build() {
 }

 check() {
-	cargo test --frozen -- --skip cache_gc_keeps_local_hook_env --skip cache_gc_removes_unreferenced_entries
+	cargo test --frozen -- \
+		--skip cache_gc_keeps_local_hook_env \
+		--skip cache_gc_removes_unreferenced_entries \
+		--skip "docker" \
+		--skip "julia" \
+		--skip "lua::" \
+		--skip "haskell" \
+		--skip "node::" \
+		--skip "ruby::" \
+		--skip "rust::" \
+		--skip "swift::" \
+		--skip "bun::"
 }

 package() {

I had to continue with a few more follow-ups though. Eventually, that led to Merge Request (MR) !97666:

# Maintainer: Thiago Perrotta <{redacted}>
pkgname=prek
pkgver=0.3.3
pkgrel=0
pkgdesc="Better pre-commit, re-engineered in Rust"
url="https://github.com/j178/prek"
arch="all"
license="MIT"
makedepends="cargo cargo-auditable"
subpackages="
	$pkgname-bash-completion
	$pkgname-fish-completion
	$pkgname-zsh-completion
	$pkgname-doc
	"
source="$pkgname-$pkgver.tar.gz::https://github.com/j178/prek/archive/v$pkgver.tar.gz"
options="net" # fetch dependencies

prepare() {
	default_prepare
	cargo fetch --target="$CTARGET" --locked
}

build() {
	cargo auditable build --release --frozen

	target/release/prek util generate-shell-completion bash > $pkgname.bash
	target/release/prek util generate-shell-completion fish > $pkgname.fish
	target/release/prek util generate-shell-completion zsh > $pkgname.zsh
}

check() {
	cargo test --frozen --lib
}

package() {
	install -Dm755 target/release/$pkgname -t "$pkgdir"/usr/bin/

	install -Dm644 $pkgname.bash "$pkgdir"/usr/share/bash-completion/completions/$pkgname
	install -Dm644 $pkgname.fish "$pkgdir"/usr/share/fish/vendor_completions.d/$pkgname.fish
	install -Dm644 $pkgname.zsh "$pkgdir"/usr/share/zsh/site-functions/_$pkgname

	install -Dm644 LICENSE -t "$pkgdir"/usr/share/licenses/$pkgname/
	install -Dm644 README.md -t "$pkgdir"/usr/share/doc/$pkgname/
}

sha512sums="
87f5b5905d0c95b7f55a789eb00b463bb987c5fc981d83500f34a41b8e9ea2e4a0ac9d45a0c3a029a7957de33f5ade866c396c399252eb4a7a9e09e32e270b99  prek-0.3.3.tar.gz
"

…wherein all tests pass.

I can’t compile prek on my little alpine linux VPS (1GB RAM). Apparently Rust is a monster that requires a lot of RAM for compiling and linking software with hundreds of dependencies.

I tested it by grabbing the built .apk package from the GitLab pipeline from my MR:

⏺ x86_64 passed. Let's grab the artifact and install it:

⏺ Bash(ssh knol "curl -L -o /tmp/prek-x86_64.zip
      'https://gitlab.alpinelinux.org/api/v4/projects/3998/jobs/2224483/artifacts' && cd /tmp && unzip -o
      prek-x86_64.zip &&…)
  ⎿    % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                      Dload  Upload  Total   Spent   Left   Speed
       0      0   0      0   0      0      0      0                              0100  3.51M 100  3.
     … +19 lines (ctrl+o to expand)

⏺ Bash(ssh knol "sudo apk add --allow-untrusted /tmp/packages/testing/x86_64/prek-0.3.3-r0.apk && prek
      --version")
  ⎿  (1/1) Installing prek (0.3.3-r0)
     Executing busybox-1.37.0-r31.trigger
     OK: 1257.5 MiB in 579 packages
     prek 0.3.3

⏺ Installed and working. prek 0.3.3 on knol. All 8 completed architectures passed (riscv64 is still
  building).

The LLM tries to use sudo instead of doas, which is not correct on Alpine Linux.

It works anyway because I have the doas-sudo-shim package installed:

% sudo -h
Usage:
  sudo (-i | -s) [-n] [-u <user>] [<command> [--] [<args>...]]
  sudo [-ins] [-u <user>] <command> [--] [<args>...]
  sudo [-h]

Execute a command as another user using doas(1).

This is not the original sudo, but the doas shim for sudo. It supports only
a subset of the sudo options (both short and long) that have an equivalent in
doas, plus option -i (--login). Refer to sudo(1) for more information.

If you need some sudo features that are not supported in doas, replace
package 'doas-sudo-shim' with 'sudo': apk add sudo !doas-sudo-shim.

Please report bugs at <https://github.com/jirutka/doas-sudo-shim/issues>.

Expect a post about prek soon. ↩︎
alias claudey=claude --dangerously-skip-permissions, with no annoying confirmation prompts ↩︎

— § —

Reply via email

#ai #alpine-linux #bestof #claude #dev

★ new blog post via Claude Code

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 13 Feb 2026 21:54:26 +0000

♠ It’s 2026. Blogging to my static website from a laptop, with vim and markdown, with hugo build and git commit / git push is old-school.

I can instead create blog posts via the Claude Code app. It already has access to my git repository. It knows how to clone it, commit to it, test it (when needed) and push it to GitHub.

If you can read this, it means this experiment worked flawlessly.

And, you see, everything is still my own text, my own words. The LLM is not writing the prose. It’s merely orchestrating the act of publishing it.

Will this lower my barrier to blogging more often?

— § —

Reply via email

#ai #bestof #claude #dev #meta #selfhosted

Claude Code: always be 'verbose'

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 12 Feb 2026 13:37:25 +0100

♠ Problem statement: Claude Code responses have been getting shorter lately.

There’s been discussion on HN and a blog post about Claude Code being “dumbed down” with increasingly terse outputs.

Before:

After:

Simply add "outputStyle": "verbose" to your .claude/settings.json to restore the original behavior:

diff --git claude/.claude/settings.json claude/.claude/settings.json
index 13a58d2..7f59e73 100644
--- claude/.claude/settings.json
+++ claude/.claude/settings.json
@@ -95,5 +95,6 @@
     "lua-lsp@claude-plugins-official": true,
     "gopls-lsp@claude-plugins-official": true
   },
-  "alwaysThinkingEnabled": true
+  "alwaysThinkingEnabled": true,
+  "outputStyle": "verbose"
 }

“Verbose” is misleading in this context.

It sounds like -vvv and a firehose of logs and agent thinking traces filling your terminal screen, but it is not.

As per Boris from the Claude Code team, in the aforementioned HN thread:

To be clear: we re-purposed verbose mode to do exactly what you are asking for. We kept the name “verbose mode”, but the behavior is what you want, without the other verbose output.

This is a comment for this reply:

I don’t want verbose mode. I want Claude to tell me what it’s reading in the first 3 seconds, so I can switch gears without fear it’s going to the wrong part of the codebase. By saying that my use case requires verbose mode, you’re saying that I need to see massive levels of babysitting-level output (even if less massive than before) to be able to do this.

I find it a collective humanity waste of time that a thread like this gathers 600+ comments.

But it’s just another day of a poor UX decision for power users. You address it with a workaround, and then life moves on.

— § —

Reply via email

#ai #claude #dev

Claude Code: swarm mode (agent teams)

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 09 Feb 2026 18:14:01 +0100

♠ Goodness.

Who asked for a feature to burn tokens?

Orchestrate teams of Claude Code sessions:

Coordinate multiple Claude Code instances working together as a team, with shared tasks, inter-agent messaging, and centralized management.

Demo running in the git repository of this blog:


 ▐▛███▜▌   Claude Code v2.1.37
▝▜█████▛▘  Opus 4.6 · Claude Team
  ▘▘ ▝▝    ~/Workspace/perrotta.dev

❯ swarm mode to analyze my blog

⏺ I'll set up a team of agents to analyze your blog from multiple angles in parallel.

⏺ Now let me spawn 4 agents to work in parallel on each analysis task.

⏺ 4 agents launched (ctrl+o to expand)
   ├─ @content-analyst (Explore)
   │  ⎿  Analyze blog content and trends (shift+↑ to manage)
   ├─ @tech-analyst (Explore)
   │  ⎿  Analyze Hugo technical setup (shift+↑ to manage)
   ├─ @structure-analyst (Explore)
   │  ⎿  Analyze site structure and linking (shift+↑ to manage)
   └─ @quality-analyst (Explore)
      ⎿  Analyze code quality and practices (shift+↑ to manage)

⏺ 4 analysis agents are now running in parallel:
  ┌───────────────────┬─────────────────────────────────────────┬─────────┐
  │       Agent       │               Focus Area                │ Status  │
  ├───────────────────┼─────────────────────────────────────────┼─────────┤
  │ content-analyst   │ Posts, topics, tags, writing trends     │ Running │
  ├───────────────────┼─────────────────────────────────────────┼─────────┤
  │ tech-analyst      │ Hugo config, layouts, shortcodes, theme │ Running │
  ├───────────────────┼─────────────────────────────────────────┼─────────┤
  │ structure-analyst │ Internal linking, assets, navigation    │ Running │
  ├───────────────────┼─────────────────────────────────────────┼─────────┤
  │ quality-analyst   │ Templates, CSS/JS, code quality         │ Running │
  └───────────────────┴─────────────────────────────────────────┴─────────┘
  I'll compile the results as they come in.

✢ Analyzing Hugo technical setup… (2m 0s · 0 tokens)

    ╒═ team-lead · shift + ↑/↓ to select
    ├─ @content-analyst: Running Get recent and oldest posts with metadata… · 19 tool uses · 34.3k tokens
    ├─ @quality-analyst: Reading 5 files… · 24 tool uses · 70.6k tokens
    ├─ @structure-analyst: Reading 5 files… · 26 tool uses · 38.5k tokens
    └─ @tech-analyst: Searching for 2 patterns, reading 3 files… · 73 tool uses · 95.9k tokens

Lesson learned: start Claude in YOLO mode:

% which claudey
claudey: aliased to claude --dangerously-skip-permissions

Some folks are starting to suggest to alias this invocation to cc, but I find it to be poor taste. cc is the C compiler.

…otherwise you’ll be nagged to death with permissions prompts from multiple agents. Decision fatigue is real, folks.

@tech-analyst❯ Complete Hugo technical setup analysis

⏺ Great, the tech analyst has finished. Let me update its task and wait for the others.

⏺ Excellent analysis from the tech analyst. Waiting on the other 3 agents to finish their analysis...


⏺ The tech analyst is idle now — its work is already captured. Waiting on content, structure, and quality
  analysts to report back.


⏺ Still waiting on the other 3 agents (content, structure, quality) to complete their analysis...


@quality-analyst❯ Complete code quality analysis report

⏺ Quality analyst is done too. Let me update its task.

⏺ 2 of 4 analyses complete. Still waiting on content-analyst and structure-analyst...


⏺ Waiting on content-analyst and structure-analyst to finish...


⏺ Still waiting on the last 2 agents...


⏺ Waiting for content-analyst and structure-analyst to complete their reports.


@content-analyst❯ Complete blog content analysis: 1041 posts, trends, tags, topics

⏺ Content analyst is done with a thorough report. Let me update its task.

⏺ 3 of 4 complete. Just waiting on structure-analyst now...


⏺ Waiting on structure-analyst to finish the last report...


⏺ Still waiting on the structure-analyst...


@structure-analyst❯ Complete site structure analysis report

⏺ All 4 agents have reported back! Let me update the last task and shut down the team.

✻ Baked for 5m 17s

⏺ ---
  Blog Analysis: perrotta.dev

  Here's the consolidated analysis from all 4 agents.

  At a Glance
  ┌──────────────────────┬─────────────────────┐
  │        Metric        │        Value        │
  ├──────────────────────┼─────────────────────┤
  │ Total posts          │ 1,041               │
  ├──────────────────────┼─────────────────────┤
  │ First post           │ Sep 2014            │
  ├──────────────────────┼─────────────────────┤
  │ Unique tags          │ 27                  │
  ├──────────────────────┼─────────────────────┤
  │ Top tag              │ dev (902 posts)     │
  ├──────────────────────┼─────────────────────┤
  │ Median post length   │ 44 lines            │
  ├──────────────────────┼─────────────────────┤
  │ Internal cross-links │ 207 (bidirectional) │
  ├──────────────────────┼─────────────────────┤
  │ Graph nodes/edges    │ 1,039 / 213         │
  ├──────────────────────┼─────────────────────┤
  │ Template files       │ 33                  │
  ├──────────────────────┼─────────────────────┤
  │ Pre-commit hooks     │ ~40                 │
  ├──────────────────────┼─────────────────────┤
  │ External theme       │ None (fully custom) │
  └──────────────────────┴─────────────────────┘
  ---
  Content Profile

  Growth trajectory is dramatic — from 1 post in 2014 and a 5-year hiatus (2017-2021) to 598 posts in 2025
  and 153 already in Feb 2026. The coding section (LeetCode, ByteByteGo, AoC) drives the volume surge, with
   batch publishing days hitting 43 posts in a single day.

  Two distinct voices: 87% of posts are tagged dev (technical), while 19% are tagged serenity
  (philosophical, short reflections — some just 9 lines). The bestof tag (148 posts, 14%) provides a
  curated recommendation layer.

  Top topics: LeetCode solutions (201), serenity reflections (194), bestof picks (148), AI/LLM (50), git
  (48), privacy (43), macOS (41), Kubernetes (35).

  Writing style: Overwhelmingly short-form (median 44 lines, longest 367). Text-only — only 3 posts contain
   images.

  ---
  Technical Architecture

  Fully custom Hugo setup — no external theme, all 33 templates in layouts/. Catppuccin color scheme
  (Latte/Mocha) with modern CSS (light-dark(), view transitions, prefers-reduced-motion). All CSS inlined
  (~1200 lines), JS deferred and fingerprinted.

  Standout features for a static site:
  - Client-side full-text search with lazy-loaded JSON index
  - D3.js interactive force-directed graph (full site + per-post mini-graphs)
  - Precomputed backlinks, related posts, and "Previously" chains (via Python script)
  - Keyboard navigation (j/k, arrows, f for fullscreen)
  - IndieWeb microformats (h-card, h-entry, h-feed)
  - Multiple output formats: HTML, RSS, Markdown, OPML, llms.txt, JSON
  - Multilingual (EN/PT) with conditional language switcher

  Build pipeline is robust: Justfile with 19 recipes, Python precomputation step, and the most thorough
  pre-commit setup I've seen for a personal blog (40 hooks covering formatting, security, content quality,
  and Hugo-specific validation).

  ---
  Site Structure

  External links heavily favor GitHub (517), LeetCode (204), Wikipedia (84), and StackOverflow (45).
  Internal cross-referencing centers on the Advent of Code hub post (28 inbound links).

  SEO is comprehensive: JSON-LD, OpenGraph, Twitter Cards, canonical URLs, custom robots.txt blocking AI
  crawlers, sitemap pinging, llms.txt.

  Privacy-first: No analytics, no cookies, no ads, no tracking. Email-based replies. EXIF stripping on
  images.

  ---
  Strengths

  1. Performance — Inlined CSS, deferred JS, lazy loading, no external fonts, 512KB Club green team member
  2. Automation — 40 pre-commit hooks enforce quality, formatting, security, and Hugo-specific rules
  automatically
  3. Rich features — Search, graph, backlinks, related posts, keyboard nav, fullscreen — all on a static
  site
  4. Privacy — Zero tracking, no third-party dependencies for core functionality
  5. Content curation — bestof tagging and disciplined taxonomy (only 27 tags for 1,041 posts)

  Potential Improvements

  1. D3.js weight — d3.v7.min.js (~270KB) loads on every post page for the mini-graph; could be lazy-loaded
  2. Inline styles in templates — Several partials use inline style attributes instead of CSS classes
  3. Chroma CSS always inlined — ~78 syntax highlighting rules load even on pages without code blocks
  4. Hugo CI version drift — Deploy uses 0.152.2, prek uses 0.140.0, local is 0.155.3
  5. Portuguese content — Only 8 PT posts despite multilingual setup; could be expanded or streamlined

✻ Cooked for 36s


⏺ All 4 agents have shut down. Let me clean up the team.

⏺ 4 teammates shut down gracefully

⏺ Team cleaned up. The full analysis is in my summary above — let me know if you'd like to dig deeper into
  any specific area, or if you want actionable recommendations on any of the improvement areas identified.

Lesson learned: launch tmux before activating the swarm.

You’ll be able to see in multiple tmux panes at a glance all agents working simultaneously. This feature is supported out-of-the-box.

— § —

Reply via email

#ai #claude #dev #meta

You are absolutely right!

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 09 Feb 2026 16:52:57 +0100

♠ Previously.

The tables turn: this time it was me who told Claude:

You are absolutely right!

— § —

Reply via email

#ai #claude #serenity

★ Claude Code: /insights

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 08 Feb 2026 15:33:50 +0100

♠ TIL via Ashik Nesin:

Claude Code now has support for /insights commands.

[…]

When you run it, Claude Code will read your message history from the past month. It’ll summarize your projects, how you use Claude Code, and give suggestions on how to improve your workflow.

Let’s try it:

 ▐▛███▜▌   Claude Code v2.1.37
▝▜█████▛▘  Opus 4.6 · Claude Team
  ▘▘ ▝▝    ~/Workspace/perrotta.dev

❯ /usage
  ⎿  Status dialog dismissed

❯ /insights

⏺ Your shareable insights report is ready:
  file:///Users/thiago.perrotta/.claude/usage-data/report.html

  Want to dig into any section or try one of the suggestions?

The generated report is a single self-contained HTML file.

The report is more useful than I anticipated! It’s definitely better than /stats: it contains actionable and concrete tips and suggestions to improve your workflow.

I’ll share a snippet of it:

How You Use Claude Code You are a prolific, infrastructure-focused power user who drives Claude Code hard across a wide surface area — 325 sessions, 809 hours, and 456 commits over roughly 7 weeks. Your workflow centers on Terraform infrastructure management, Hugo blog optimization, and DevOps tooling (ArgoCD, pre-commit hooks, CI pipelines). You lean heavily on Bash (6,780 invocations) as your primary tool, reflecting a hands-on operator style where you want Claude executing real commands and seeing real output rather than just generating files. Your use of TodoWrite (411 calls) and Task (124 calls) suggests you frequently tackle complex, multi-step projects — like importing existing AWS infrastructure into Terraform or implementing 8+ performance improvements for your Hugo blog — where structured planning is essential. You consistently push for clean git hygiene: granular commits, PRs, and proper branch workflows.

Your interaction style is best described as iterative refinement with active course correction. You don’t write exhaustive specs upfront; instead, you give Claude a clear goal and then steer as it executes. This shows up repeatedly: you interrupted Claude when it assumed a full 1Password migration (“only where applicable”), caught it when it reverted a change you only asked about (“revert. I just asked why”), pushed back on CSS inlining that would lose fingerprinting benefits, and redirected heading placement from shortcode templates to markdown files. Your friction data tells a consistent story — 24 instances of wrong approach and 24 of buggy code — but these rarely derail you because you catch problems quickly and redirect. You’re comfortable letting Claude run on multi-file changes (18 successful multi-file operations) but you interrupt decisively when the approach is wrong, such as stopping a file write to ask about pre-commit integration instead, or killing a premature commit attempt.

What’s striking is your high tolerance for iteration paired with low tolerance for sloppiness. Terraform import sessions required multiple rounds of fixing IDs, resource addresses, and provider syntax — and you stuck with it. But you also demanded succinct responses, rejected a poor-quality fullscreen feature outright, and expected Claude to understand nuances like provider read-only attributes before making sweeping changes. Your 94% achievement rate (32 fully + 15 mostly out of 50) despite working on genuinely hard infrastructure problems shows that this iterative, correction-heavy style works well for you. You treat Claude as a capable but supervision-required junior engineer — you trust it to do the legwork but always review the output critically before committing.

Key pattern: You operate as an active supervisor who assigns complex infrastructure tasks, lets Claude execute broadly, but intervenes decisively and frequently to correct approach, scope, and quality — treating the tool as a capable junior engineer that needs real-time steering.

Across 325 sessions and 809 hours, you’ve built a highly productive Claude Code workflow centered on infrastructure-as-code, Hugo blog optimization, and developer tooling — with a 94% goal achievement rate.

You’ve developed a sophisticated pattern for standing up new Terraform projects by importing existing AWS and MongoDB Atlas infrastructure, working through complex import ID formats and provider quirks across multiple garden environments. Your approach of creating files, running plans, and iteratively fixing mismatches shows deep Terraform expertise, and you consistently push through to clean PRs even when provider limitations surface. The breadth of this work — EKS clusters, security groups, MongoDB Atlas modules, Azure OIDC — demonstrates you’re using Claude as a true infrastructure engineering partner.

You systematically drove your Hugo blog toward Lighthouse 100 scores through a multi-session campaign covering CSS inlining, critical request chain elimination, SRI hashes, code block enhancements, and RSS feed fixes. You maintained high standards by pushing back when Claude’s suggestions sacrificed cache fingerprinting or batched too aggressively, ensuring each optimization was production-sound. The fact that you also created ADRs documenting your architectural decisions around search and caching shows you treat your personal blog with the same rigor as production infrastructure.

You’ve built a remarkably robust developer experience layer using pre-commit hooks, Claude Code settings files, and automation scripts — from custom code-block linting parsers to Justfile safety guards that prevent direct module applies. You research hooks from other major projects like Airflow to cherry-pick the best ones, and you iterate on implementations until they’re correct (like replacing a regex-based checker with a proper line-by-line parser after false positives). Your Claude Code settings PR for your Terraform repo, with carefully curated allow/deny/ask permission lists, shows you’re intentionally shaping how AI tools interact with your codebase.

There’s much more to it. I am not sharing actionable suggestions at this time.

There’s also negative feedback! And suggestions to improve / augment CLAUDE.md! “New Ways to Use Claude Code”!

I love it. And I definitely need to switch my workflow to writing specs upfront, though I can’t resist an iterative and incremental work style to achieve desired outcomes 🤔.

— § —

Reply via email

#ai #bestof #claude #dev

★ Making a slides presentation in 2026

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 07 Feb 2026 18:40:50 +0100

♠ Problem statement: make a slides presentation for a certain business or academic use case.

Part I: What? #

Classic approach: pick one of: LibreOffice, Microsoft PowerPoint, Google Slides.

Hipster approach: pick one of: Notion, Reveal.JS (or similar), Golang present, Prezi.

Academic approach: LaTeX beamer, LyX.

Minimalist approach: Emacs Org mode, Terminal.

Of course, I am pioneering – by choosing none of the above!

We’ll settle with Typst + Polylux, because we want best-in-class™ presentations:

Polylux is a package for the typesetting system Typst to create presentation slides, just like you would use the beamer package in LaTeX. (So far, it is much less advanced than beamer, obviously.)

If you haven’t heard of things like LaTeX’s beamer before, here is how this works: As a rule of thumb, one slide becomes one PDF page, and most PDF viewers can display PDFs in the form of a slide show (usually by hitting the F5-key).

But first, a bit of trivia:

Why the name?

A polylux is a brand of overhead projectors very common in Eastern German schools (where the main author of this package grew up). It fulfils a similar function to a projector, namely projecting visuals to a wall to aid a presentation. The German term for projector is beamer, and now you might understand how it all comes together. (The original author of the aforementioned LaTeX package is German as well.)

Germans, Germans everywhere {picture the Buzz Lightyear meme here}

Part II: You are pretty and you know it #

I am not using the default theme. Sorry, that’s just not gonna happen.

Built-in beamer themes inspire me. I choose metropolis, with a few bits of beamer frankfurt sprinkled in (mainly the top navigation guides).

Such a short section, so cute! ✨

Part III: How? #

It’s 2026. Agentic LLMs are all the rage.

Obviously, we’re going to use Claude Code. It’s the obvious choice. Nothing else comes close.

OK, I’ll also give you a break if you use OpenAI, it comes in a close second. No other choice is possible. Not if you want to become state-of-the-art. Sorry.

Checklist:

have claude code installed? Check
have enough, readily available tokens to burn? Check
have a workspace ready? Check
have git init run in the workspace? Check
have two claude code sessions open, one for content and one for form? Check
have a Justfile ready? Check

watch:
        typst watch slides.typ

Part IV: The Future Starts With You #

Good luck out there!

Iterate. Tell the LLM what you want. Be verbose in your prompting. Course-correct as needed.

There’s no right or wrong from here.

Just do it!

— § —

Reply via email

#ai #bestof #claude #dev #serenity

claude --teleport

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 10 Jan 2026 22:26:21 -0300

♠ After starting a coding session on the web with Claude Code on Web¹, you can resume it in the terminal with the traditional Claude Code CLI app by running claude --teleport.

Without arguments, it prompts you to interactively choose an existing session to resume:

 Select a session to resume:

   Updated  Session Title
 ❯ 1. 52m ago  Migrate secrets from Gringotts to AWS Secrets Manager
   2. 53m ago  Plan Hoth integration with dual provider OIDC
   3. 54m ago  Add Strangereal terraform state bucket standalone project
   4. 2w ago   Write a CLAUDE.md
   5. 1mo ago  Address review comments on pull request 42123

With a provided session ID argument, the session is immediately resumed.

The docs mention the existence of the /teleport command within Claude Code but I could not find it in my instance (version v2.1.4).

This workflow (“start on your phone, resume later on your computer afterwards”) is starting to become popularized.

https://claude.ai/code ↩︎

— § —

Reply via email

#ai #claude #dev

Claude Code: release notes RSS feed

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 05 Jan 2026 15:31:45 -0300

♠ Previously.

Stay up-to-date with the Claude Code CHANGELOG.

Did you know it’s possible to obtain a RSS feed straight from a github repo?

The Claude Code github repository: https://github.com/anthropics/claude-code/releases

Its feed: https://github.com/anthropics/claude-code/releases.atom – just append .atom to the repo releases URL.

If you don’t have a favorite RSS reader yet, I recommendd Miniflux.

— § —

Reply via email

#ai #claude #dev

Claude Code tips

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 05 Jan 2026 15:18:13 -0300

♠ These are great collections:

New tips to me:

/rename to set a session name, like you would with a tmux window. Later on, resume the session with /resume {name} or claude --resume {name}.

Since v2.0.74 LSP became a first-class citizen, comparable to OpenCode:

Added LSP (Language Server Protocol) tool for code intelligence features like go-to-definition, find references, and hover documentation

— § —

Reply via email

#ai #claude #dev

Claude Code: block dangerous commands

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 21 Dec 2025 18:16:12 -0300

♠ The outcome:

> Run rm -rf /tmp/test

⏺ Bash(rm -rf /tmp/test)
  ⎿  PreToolUse:Bash hook returned blocking error
  ⎿  Error: rm -rf is blocked for safety

⏺ The rm -rf command was blocked by a safety hook in your configuration (~/.claude/hooks/block-dangerous-commands.sh).

  If you want to remove /tmp/test, you have a few options:

  1. Run the command directly in your terminal (outside of Claude Code)
  2. Modify your hooks configuration to allow this specific command
  3. Use a safer alternative like rm -r /tmp/test (without force flag) which may prompt for confirmation

  Would you like me to try one of the alternatives, or would you prefer to run this directly in your terminal?

How to achieve this?

So far I had a deny list in ~/.claude/settings.json:

{
  "permissions": {
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(terraform apply:*)",
      "Bash(terraform destroy:*)"
    ]
  }
}

This is enough.

For extra safety though, I added a pre-tool use hook for redundancy:

Runs after Claude creates tool parameters and before processing the tool call.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/block-dangerous-commands.sh",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

The hook file (generated by Claude itself, needless to say):

#!/bin/bash
# PreToolUse hook to block dangerous commands like "rm -rf" and "terraform apply"

# Read hook input from stdin
input=$(cat)

# Extract tool name and command
tool_name=$(echo "$input" | jq -r '.tool_name // ""')
command=$(echo "$input" | jq -r '.tool_input.command // ""')

# Exit early if not a Bash tool
if [ "$tool_name" != "Bash" ]; then
    exit 0
fi

# Check for dangerous patterns
blocked=false
reason=""

# Check for rm -rf (with various flag orderings)
if echo "$command" | grep -qE 'rm\s+(-[a-zA-Z]*r[a-zA-Z]*f|(-[a-zA-Z]*f[a-zA-Z]*\s+)?-[a-zA-Z]*r|-rf|-fr)\b'; then
    blocked=true
    reason="rm -rf is blocked for safety"
fi

# Check for terraform apply (without -auto-approve is still dangerous)
if echo "$command" | grep -qE 'terraform\s+apply'; then
    blocked=true
    reason="terraform apply is blocked - use terraform plan first"
fi

# Check for terraform destroy
if echo "$command" | grep -qE 'terraform\s+destroy'; then
    blocked=true
    reason="terraform destroy is blocked for safety"
fi

# If blocked, return denial via JSON
if [ "$blocked" = true ]; then
    cat <<EOF
{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "$reason"
  }
}
EOF
    exit 0
fi

# Allow command to proceed
exit 0

— § —

Reply via email

#ai #claude #dev

Claude Code: stash

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 21 Dec 2025 16:48:26 -0300

♠ Problem statement: You’re midway in a long, multi-line prompt in Claude Code.

> Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy
eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam
voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet
clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit
amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam
nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat,
sed diam voluptua. At vero eos et accusam et justo duo dolores et ea
rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum
dolor sit amet.

Now you would like to “stash” it away temporarily to run a more important, one-off prompt, before resuming.

If this were an one-line prompt, you could hit C-u, run your one-off, and then hit C-y. This is pure readline / emacs wizardry, supported natively in the TUI that Claude Code employs.

For the multi-line situation, hit C-s.

Claude will then show:

› Stashed (auto-restores after submit)

From here, run your one-off. Your initial prompt will be automatically restored upon completion.

Alternatively, press C-s again to restore the initial prompt.

This is a simple quality-of-life improvement, but it’s specific to Claude Code. C-u + C-y works almost everywhere though.

— § —

Reply via email

#ai #claude #dev

Claude Code: add context window % to status line

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 20 Dec 2025 15:42:11 -0300

Claude code now officially supports showing context window information like percentage of usage in status line (via Ashik Nesin):

> /statusline Add a progress bar showing the percentage of context currently used

⏺ statusline-setup(Configure statusline progress bar)
  ⎿  Done (3 tool uses · 7.4k tokens · 44s)

⏺ I've configured your statusline to include a context usage progress bar. Your status line will now show something like:

  .claude (git:main) [Claude 3.5 Sonnet] [██████░░░░ 60%]

  The progress bar displays:
  - Filled blocks (█) for used context
  - Empty blocks (░) for remaining context
  - Percentage showing exact usage

  The context calculation includes input tokens, cache creation tokens, and cache read tokens relative to the total context window size.

My updated .claude/statusline.sh.

The diff.

— § —

Reply via email

#ai #claude #dev

★ Claude Code: notify when needed

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 04 Dec 2025 02:36:16 -0300

♠ This is one little productivity boost to make you a 10x Engineer! None of the popular AI blogs talk about this!!1!

Problem statement: Make Claude Code emit a chime whenever it needs attention.

commit e668b387b6b34943143b046ad915effbd3945601
Author: Thiago Perrotta <{redacted}>
Date:   Thu Dec 4 02:33:11 2025 -0300

    add a notification hook

diff --git claude/.claude/settings.json claude/.claude/settings.json
index 1979baf..1ac35da 100644
--- claude/.claude/settings.json
+++ claude/.claude/settings.json
@@ -1,7 +1,20 @@
 {
   "env": {
     "CLAUDE_CODE_ENABLE_TELEMETRY": "0"
   },
+  "hooks": {
+    "Notification": [
+      {
+        "hooks": [
+          {
+            "command": "afplay /System/Library/Sounds/Glass.aiff &",
+            "type": "command"
+          }
+        ]
+      }
+    ]
+  },

This is the JSON snippet for ease of copy and paste, you’ll add it to your ~/.claude/settings.json:

"hooks": {
  "Notification": [
    {
      "hooks": [
        {
          "command": "afplay /System/Library/Sounds/Glass.aiff &",
          "type": "command"
        }
      ]
    }
  ]
}

This command is for macOS only, but it could be easily adapted to Linux (use aplay instead).

Claude Code Hooks docs:

Runs when Claude Code sends notifications. Supports matchers to filter by notification type.

macOS ships with various system sounds in /System/Library/Sounds.

This inspiration came from Amp Code. Amp plays the Submarine.aiff sound by default.

— § —

Reply via email

#ai #bestof #claude #dev #serenity

Claude on ¬ just serendipity 🍀

drskill: lint claude skills

claude code: replace a hand-rolled loop with /goal

when Gen AI cites docs that don't exist

★ claude code: ship your skills as a plugin marketplace

★ caveman: talk like caveman, save tokens

bloggify

Claude Enterprise: plan usage

Grill me

prove_it: verification hooks for Claude Code

llm: Anthropic Claude plugin

★ Personal CLAUDE.md

Colophon #

claude: /powerup

Large context windows

claude: recap

claude, claudey, claudeyy

claude #

claudey #

claudeyy #

★ anki: flashcard generation with claude code

claude: /simplify

★ claude code: naming sessions

cco: OAuth refresh fix

claude code: kitty keyboard protocol garbage

What’s happening #

Fix #

Prevention #

cco: additionalDirectories

claude: srt: sandbox runtime

srt: sandbox-runtime #

native /sandbox #

★ claude: add session ID to status bar

Use cases #

The config #

Blocking Claude

★ cco: claude condom (sandbox)

★ Gimme subagents

★ New APKBUILD: LLM edition

★ new blog post via Claude Code

Claude Code: always be 'verbose'

Claude Code: swarm mode (agent teams)

You are absolutely right!

★ Claude Code: /insights

★ Making a slides presentation in 2026

Part I: What? #

Part II: You are pretty and you know it #

Part III: How? #

Part IV: The Future Starts With You #

claude --teleport

Claude Code: release notes RSS feed

Claude Code tips

Claude Code: block dangerous commands

Claude Code: stash

Claude Code: add context window % to status line

★ Claude Code: notify when needed

`claude` #

`claudey` #

`claudeyy` #

`srt`: sandbox-runtime #

native `/sandbox` #