Bloggify on ¬ just serendipity 🍀

homebrew: cask drift after an in-app update

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 16 Aug 2026 14:11:17 +0200

Problem statement: every brew upgrade died on a cask whose app had upgraded itself years ago.

% brew upgrade
==> Upgrading 1 outdated package:
1password 7.9.2 -> 8.12.33
==> Upgrading 1password
  7.9.2 -> 8.12.33
Error: 1password: It seems the App source '/Applications/1Password 7.app' is not there.
==> Purging files for version 8.12.33 of Cask 1password

That path stopped existing when 1Password 8 renamed its bundle from 1Password 7.app to 1Password.app. The app had updated itself in place, behind Homebrew’s back:

% defaults read /Applications/1Password.app/Contents/Info.plist CFBundleShortVersionString
8.12.30
% brew list --cask --versions 1password
1password 7.9.2

Two disagreeing sources of truth. --adopt looked like the obvious cure, and wasn’t — the stale receipt still routes into the upgrade code path, which still looks for the v7 bundle:

% brew install --cask --adopt 1password
==> Upgrading 1password
  7.9.2 -> 8.12.33
Error: 1password: It seems the App source '/Applications/1Password 7.app' is not there.

The receipt is the whole problem, so look at what it actually holds:

% find /opt/homebrew/Caskroom/1password -maxdepth 2
/opt/homebrew/Caskroom/1password
/opt/homebrew/Caskroom/1password/.metadata
/opt/homebrew/Caskroom/1password/.metadata/config.json
/opt/homebrew/Caskroom/1password/.metadata/7.9.2
/opt/homebrew/Caskroom/1password/7.9.2
% ls -A /opt/homebrew/Caskroom/1password/7.9.2/
% du -sh /opt/homebrew/Caskroom/1password
8.0K	/opt/homebrew/Caskroom/1password

Eight kilobytes of bookkeeping and an empty version directory. Nothing in there is the application. Delete it, then reinstall over the app that is really on disk:

% rm -rf /opt/homebrew/Caskroom/1password
% brew install --cask --force 1password
==> Fetching downloads for: 1password
✔︎ Cask 1password (8.12.33)
Warning: It seems there is already an App at '/Applications/1Password.app'; overwriting.
==> Installing Cask 1password
==> Removing App '/Applications/1Password.app'
==> Moving App '1Password.app' to '/Applications/1Password.app'
🍺  1password was successfully installed!

Both sides agree again:

% defaults read /Applications/1Password.app/Contents/Info.plist CFBundleShortVersionString
8.12.33
% brew list --cask --versions 1password
1password 8.12.33
% brew outdated --cask | grep 1password

Quitting the app first is mandatory, and this one ignored two polite osascript requests before a plain kill took:

% osascript -e 'quit app "1Password"'
% pgrep -x 1Password
740
% kill 740

The general shape: a cask whose app ships its own updater will drift, and Homebrew only notices when the vendor also renames the bundle. --adopt is for an app Homebrew never tracked; for an app it tracked wrongly, the receipt has to go first.

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #coding #dev #macos

new tag: bloggify

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 16 Aug 2026 13:50:00 +0200

♠ Previously.

Problem statement: some readers may not want AI-assisted posts in their feed reader, even with my edits. I support making it easier for people to opt out from such posts. They should be able to filter them out without unsubscribing from the whole blog.

Every post the /bloggify skill drafts already carries a footer disclosing it. What was missing was a machine-readable signal, not just a line at the bottom a feed reader can’t act on. So I grepped for the marker and tagged every post that has it:

% grep -rl "Drafted with \[\`/bloggify\`\]" content/posts/ | wc -l
27

% git show 79018e8cf1 -- content/posts/2026-06-09-bloggify.md
diff --git content/posts/2026-06-09-bloggify.md content/posts/2026-06-09-bloggify.md
index b0a5a8ee86..9d15d656fd 100644
--- content/posts/2026-06-09-bloggify.md
+++ content/posts/2026-06-09-bloggify.md
@@ -3,6 +3,7 @@ title: "bloggify"
 date: 2026-06-09T16:50:11+02:00
 tags:
   - ai
+  - bloggify
   - claude
   - dev
   - meta

Every post’s tags: list ends up in the RSS <item> as a <category> element, one per tag (see layouts/_default/rss.xml). So bloggify is now a regular, filterable category in the feed, same as any other tag.

For those of you who use Miniflux, filtering it out is the same trick from blocking an entry matching a URL and the global blocklist, except on the EntryTag field instead of EntryURL or EntryTitle:

EntryTag=(?i)^bloggify$

Added as a global block rule in miniflux, and every future /bloggify-drafted post never reaches the inbox. /tags/bloggify/ on the blog itself works too, for anyone who’d rather subscribe to the opposite: only the AI-assisted posts.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #dev #meta

pi: prompt before dangerous commands

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 16 Aug 2026 13:28:44 +0200

♠ Previously.

Problem statement: my Pi extension blocked dangerous shell commands outright, even when I had already preserved the state they could destroy.

The guard parses every bash tool call with tree-sitter, catching commands such as rm -rf, terraform destroy, and destructive Git operations. Today it did exactly what I had asked:

% git -C "$(brew --repo thiagowfx/pancake)" reset --hard origin/master
git reset --hard is blocked - discards changes irreversibly

Blocking remains the right default, but an interactive session can ask me. Pi extensions can intercept the tool_call event and open a confirmation dialog through ctx.ui.

The change in dangerous-command-guard/guard.ts:

-  pi.on("tool_call", async (event) => {
+  pi.on("tool_call", async (event, ctx) => {
     if (event.toolName !== "bash") return;

     const command = event.input.command;
     if (typeof command !== "string") return;

     const blocked = await findBlockedCommand(command);
-    if (blocked) return { block: true, reason: blocked.reason };
+    if (!blocked) return;
+    if (!ctx.hasUI) return { block: true, reason: blocked.reason };
+
+    const allowed = await ctx.ui.confirm(
+      "Allow dangerous command?",
+      `${blocked.command}\n\n${blocked.reason}`,
+    );
+    if (!allowed) return { block: true, reason: "Blocked by user" };
   });

Interactive Pi now pauses for approval. Print and JSON modes have no UI, so they still fail closed. Safe commands never prompt.

The tests exercise all three decisions:

✔ extension prompts before dangerous bash tool calls (0.66225ms)
ℹ tests 48
ℹ pass 48
ℹ fail 0

Same guardrails, with an escape hatch operated by a human rather than a model.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #security

pi: am I sandboxed?

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 15 Aug 2026 00:56:29 +0200

♠ Problem statement: asking a coding agent whether it runs in a sandbox returns a confident answer derived from its system prompt, not from the machine it is actually running on.

I asked Pi exactly that. The reply was assured:

No — pi itself doesn’t sandbox tool execution. When I run bash, edit, or write, they execute directly on your machine with your user’s permissions, in the current working directory (/Users/thiago.perrotta/.pi). […] But there’s no OS-level sandbox (no container, no seccomp, no filesystem jail).

It’s plausible, well-formatted, and…wrong!. One typo-ridden command was enough to break the illusion:

% ls ~/worksppace
ls: cannot access '/home/hostuser/worksppace': No such file or directory

~ is not /Users/thiago.perrotta. The follow-up probe:

% pwd; uname -a; whoami; cat /etc/os-release
/Users/thiago.perrotta/.pi
Linux lima-rancher-desktop 6.18.37-0-virt #1-Alpine SMP PREEMPT_DYNAMIC 2026-06-29 10:52:25 aarch64 GNU/Linux
hostuser
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"

A macOS-shaped pwd inside an aarch64 Debian container, on an Alpine Lima VM, under Rancher Desktop. Containerception.

And the giveaway at the filesystem root:

% ls -la / | head -5
total 68
drwxr-xr-x   1 root root 4096 Aug 15 00:54 .
drwxr-xr-x   1 root root 4096 Aug 15 00:54 ..
-rwxr-xr-x   1 root root    0 Aug 15 00:54 .dockerenv
drwxr-xr-x   3 root root 4096 Aug 15 00:54 Users

/.dockerenv, plus a /Users bind mount recreating just enough of the host path for the system prompt’s cwd to resolve.

The model was not lying; it had no way to know. Its self-description comes from tokens someone else wrote, while the ground truth sits one uname away. The useful lesson is that agent introspection is a documentation lookup, not a measurement — for anything security-relevant, make it run the command.

The sandbox was cco.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #security

homebrew: replace deprecated and orphaned packages

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 10 Aug 2026 15:10:42 +0200

♠ Problem statement: brew doctor found one deprecated cask and one installed keg whose formula had disappeared.

tflint #

Warning: Some installed casks are deprecated or disabled.
You should find replacements for the following casks:
flameshot

Warning: Some installed kegs have no formulae!
You should find replacements for the following formulae:
  tflint

Homebrew/core removed TFLint after its executable became subject to both MPL 2.0 and BUSL 1.1. Upstream now maintains terraform-linters/tap as a cask, so migrate the old formula instead of merely reinstalling it:

% brew uninstall tflint
Uninstalling /opt/homebrew/Cellar/tflint/0.61.0... (8 files, 51.8MB)

% brew install terraform-linters/tap/tflint
==> Tapping terraform-linters/tap
Tapped 1 cask (15 files, 14.7KB).
==> Installing Cask tflint
==> Linking Binary 'tflint' to '/opt/homebrew/bin/tflint'
🍺  tflint was successfully installed!

% tflint --version
TFLint version 0.64.0
+ ruleset.terraform (0.15.0-bundled)

Flameshot → Shottr #

The Flameshot cask was deprecated because it does not pass macOS Gatekeeper checks. I replaced it with Shottr:

% brew uninstall --cask flameshot
==> Uninstalling Cask flameshot
==> Removing App '/Applications/flameshot.app'
==> Purging files for version 14.0.0,14.0 of Cask flameshot

% brew install --cask shottr
==> Installing Cask shottr
==> Moving App 'Shottr.app' to '/Applications/Shottr.app'
🍺  shottr was successfully installed!

The corresponding Brewfile change keeps the migration reproducible:

+tap "terraform-linters/tap"

-brew "tflint"

-cask "flameshot"
+cask "shottr"
+cask "tflint"

Both offending entries are now gone:

% brew doctor 2>&1 | grep -E 'flameshot|tflint|deprecated|no formulae'

% brew list --cask | grep -E '^(flameshot|shottr|tflint)$'
shottr
tflint

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #coding #dev #macos

terraform: fileset does not respect gitignore

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 07 Aug 2026 11:27:13 +0200

♠ Problem statement: a terraform project planned clean locally (terraform plan), but CI insisted on a diff. Every apply fixed it for one side and broke it for the other, back-and-forth.

The culprit was a null_resource that rebuilds an AWS Lambda for a NodeJS app bundle whenever its sources change, keyed on a hash of the whole directory:

resource "null_resource" "lambda_build" {
  triggers = {
    dir_sha = sha256(join("", [for f in sort(fileset("${path.module}/lambda", "**")) : "${f}:${filesha256("${path.module}/lambda/${f}")}"]))
  }

  provisioner "local-exec" {
    command = "cd ${path.module}/lambda && npm ci && npm run build"
  }
}

fileset() walks the filesystem. It has no idea .gitignore exists. So node_modules/ and dist/, present locally after a build, but absent in a fresh CI checkout, creates the discrepancy.

A minimal reproduction test case, with node_modules/ and dist/ gitignored:

% git ls-files lambda | wc -l
2
% echo 'sha256(join("", [for f in sort(fileset("./lambda", "**")) : "${f}:${filesha256("./lambda/${f}")}"]))' | terraform console
"a0af67e204ae2b73a7452d0c2755be1f665b377b5d49e7cc520bd31607adb832"

Then with npm ci && npm run build:

% find lambda -type f | wc -l
4
% git status --porcelain | wc -l
0
% echo 'sha256(join("", [for f in sort(fileset("./lambda", "**")) : "${f}:${filesha256("./lambda/${f}")}"]))' | terraform console
"728a40d04abc2b8292d57465d1f037f833a67d4cc0607a6c64cef487292d9be6"

Git says nothing changed; Terraform says everything did (ugh!).

That’s the issue. CI plans one value, my laptop plans the other, and each apply sets up the next one to “detect drift” again.

Nothing in AWS had changed. The deployed artifact was byte-identical the whole time; only the build trigger churned.

The fix is to hash the build inputs, not the build directory:

dir_sha = sha256(join("", [for f in sort(setunion(
  fileset("${path.module}/lambda", "src/**"),
  ["package.json", "package-lock.json"],
)) : "${f}:${filesha256("${path.module}/lambda/${f}")}"]))

Same value on both sides, and still sensitive to anything that actually matters:

% # dirty tree, after npm ci
"a0af67e204ae2b73a7452d0c2755be1f665b377b5d49e7cc520bd31607adb832"
% # pristine `git archive` checkout
"a0af67e204ae2b73a7452d0c2755be1f665b377b5d49e7cc520bd31607adb832"
% # after editing lambda/src/handler.ts (hypotetically)
"53ef69e287a65f9785cf05985942a5c62a8175348c91c7d9c83039bfc31b8714"

terraform console is the right tool here — it evaluates an expression against the real filesystem without an apply, so both variants can be diffed against a pristine git archive tree and a working one before committing anything.

The general shape: any fileset() over a directory that also holds build artifacts, virtualenvs, or vendored dependencies is environment-dependent, and will read as permanent drift for exactly as long as nobody looks closely.

🤖 Drafted with /bloggify.

— § —

Reply via email

#aws #bloggify #coding #dev #git #terraform

dual-review: address review findings automatically

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 05 Aug 2026 14:01:30 +0200

♠ Previously.

My dual-review skill runs two independent LLM reviewers over a commit / diff / PR, validates every finding against the code, and hands back one action plan — Blockers, Important, Suggestions.

Recently I added a flag argument that closes the loop:

 argument-hint: "[branch|staged|all] [--pr NUMBER] [--post]"
+argument-hint: "[branch|staged|all] [--pr NUMBER] [--post] [--address]"

 - `--post`: post final action plan to target pull request after showing it; never post otherwise
+- `--address`: after showing (and, if requested, posting) the action plan, fix Blockers and Important findings directly in the reviewed tree; never fix Suggestions without explicit confirmation

+## 7. Address Findings (only with `--address`)
+
+Skip this section entirely unless `--address` was requested.
+
+1. Work in the same tree that was reviewed (existing worktree or user's checkout for `staged`/`all`); never create a second copy of the changes.
+2. Address every Blocker and every Important finding. For Suggestions, ask the user which (if any) to apply; default to none.
+3. For each finding: re-read the exact `file:line` locations, apply the `Fix:` recommendation, and fix every sibling location listed under that finding, not just the first instance.
+4. If a finding is ambiguous, requires a design decision, or the recommended fix turns out to be wrong once you're in the code, stop and ask the user instead of guessing.
+5. After edits, rerun any locally available checks that cover the change (tests, linters, type-checks) before treating a finding as resolved.
+6. Stage only the files touched while addressing findings. Commit with a message describing which findings were fixed (e.g. `address dual-review findings`), listing them briefly in the body.
+7. If scope was `branch`/`--pr`, push to the branch. If the action plan was posted (`--post`), leave a short follow-up comment noting the findings were addressed and pushed; do not repost the full plan.
+8. Report: which findings were fixed, which were skipped and why, and which need user input.

The important line is the second one: Suggestions never get auto-applied, only Blockers and Important.

/dual-review --post --address now reviews, posts the plan, fixes what’s fixable, and pushes.

Why two review(er)s instead of one? Because LLMs are non-deterministic.

Why not more than two review(er)s then? Tokens ($$$) and time. It’s a balance.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #claude #coding #dev #meta

pi: remove redundant github MCP

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 03 Aug 2026 18:47:51 +0200

♠ Previously.

I’ve finally removed the GitHub MCP server from my Pi configuration, after piloting it for a while with pi-mcp-adapter.

GitHub already has a mature CLI (gh) installed and authenticated:

% gh --version
gh version 2.97.0 (2026-07-31)
https://github.com/cli/cli/releases/tag/v2.97.0

% gh auth status
github.com
  ✓ Logged in to github.com account thiagowfx (keyring)
  - Active account: true
  - Git operations protocol: ssh

gh handles pull requests, issues, workflows, and releases directly. Anything else remains available through gh api, including GraphQL. The MCP server added another interface without adding capability.

 {
   "mcpServers": {
-    "github": {
-      "auth": "bearer",
-      "bearerToken": "!gh auth token",
-      "url": "https://api.githubcopilot.com/mcp"
-    },
     "slack-mcp": {

MCP remains useful for APIs without a better (or any) CLI, but it should be avoided wherever possible.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #dev #pi

DNS: negative cache behind a local resolver

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 31 Jul 2026 14:02:20 +0200

♠ Problem statement: a newly created Route 53 record resolved through public DNS, but ~~Chrome~~ Brave and macOS still returned DNS_PROBE_POSSIBLE.

It smells like a DNS caching issue.

Flushing mDNSResponder did nothing though.

The system resolver was Tailscale’s local DNS proxy, so I asked that resolver rather than trusting dig’s default path:

% dig +time=3 +tries=1 @100.100.100.100 kargo.tools.example-corp.net A +noall +answer +authority +comments
; <<>> DiG 9.10.6 <<>> +time=3 +tries=1 @100.100.100.100 kargo.tools.example-corp.net A +noall +answer +authority +comments
; (1 server found)
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13683
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
tools.example-corp.net. 225 IN SOA ns-1609.awsdns-09.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Route 53’s authoritative nameserver and several public resolvers already had it:

% for resolver in 1.1.1.1 1.1.1.2 8.8.8.8; do
    printf '%-16s ' "$resolver"
    dig +time=2 +tries=1 +short @"$resolver" kargo.tools.example-corp.net A | paste -sd, -
  done
1.1.1.1          192.0.2.11,198.51.100.50,203.0.113.95
1.1.1.2          192.0.2.11,203.0.113.95,198.51.100.50
8.8.8.8          203.0.113.95,198.51.100.50,192.0.2.11

% dig +short @ns-1609.awsdns-09.co.uk kargo.tools.example-corp.net A
192.0.2.11
203.0.113.95
198.51.100.50

Tailscale had cached the previous NXDOMAIN response for a couple of minutes. Its cache is not macOS’s cache; restarting mDNSResponder cannot clear it. Waiting out that TTL fixed the web browser lookup.

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #dev #macos

git: repair unreachable object corruption

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 29 Jul 2026 22:16:46 +0200

♠ Problem statement: git fsck failed in a linked worktree, even though every branch and reflog remained intact.

The initial diagnosis was noisy: missing blobs, hundreds of dangling objects, and an invalid commit graph:

missing blob 97f9a2ed29f84e47848244c2d2626b2536a33c55
error: Could not read 003fb43a3aa361b52f2ab3f27bdabcb9b5137103
failed to parse commit 003fb43a3aa361b52f2ab3f27bdabcb9b5137103 from object database for commit-graph

Worktrees have their own administrative directory but share an object database:

% git rev-parse --git-dir
.git/worktrees/thiagowfx-prm-revenue-tagging
% git rev-parse --git-common-dir
.git

I checked every missing blob against objects reachable from refs and reflogs. None were reachable. Before removing them, I backed up objects, commit graphs, and index:

% common=$(git rev-parse --git-common-dir)
% backup="$common/repair-backup-20260729221124"
% mkdir -p "$backup"
% cp "$(git rev-parse --git-path index)" "$backup/worktree-index"
% ditto "$common/objects" "$backup/objects-before-gc"
% mv "$common/objects/info/commit-graphs" "$backup/commit-graphs"

The index also had an invalid cache-tree entry. Rebuilding it from HEAD preserves working-tree files; comparing its old entries found no staged changes:

% git read-tree HEAD
% GIT_INDEX_FILE="$backup/worktree-index" git ls-files --stage > /tmp/index-before-repair
% join -t $'\t' -v 1 \
    <(awk '{print $4 "\t" $1}' /tmp/index-before-repair | sort) \
    <(git ls-files --stage | awk '{print $4 "\t" $1}' | sort)
% # no output

Then Git could discard unreachable corrupt objects and rebuild its graph:

% git gc --prune=now
% git fsck --full --strict
% echo $?
0
% git fsck --full --no-reflogs --strict >/tmp/fsck
% echo $?
0

The backup remains under .git/repair-backup-20260729221124. fsck is clean; recovery material remains available.

It’s very weird to experience this kind of error. We’re not used to it.

The one trick to remember from this post is git fsck.

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #coding #dev #git

obsidian: logseq-compatible tasks

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 29 Jul 2026 14:34:39 +0200

♠ Previously.

Problem statement: preserve Logseq’s task syntax while opening the same markdown files in Obsidian.

My migration script originally converted every task into Obsidian’s checkbox syntax:

- TODO buy milk     ->  - [ ] buy milk
- DOING ...         ->  - [/] ...
- DONE ...          ->  - [x] ...

Obsidian itself does not recognize the left-hand side as tasks. The TODOseq community plug-in does:

- TODO buy milk
- DOING ...
- DONE ...

It keeps the file unchanged, adds clickable task states and a task list to Obsidian, and remains compatible with Logseq.

Before granting a community plug-in write access to my vault, I inspected the current release with the LLM™:

% git clone --depth=1 https://github.com/scross01/obsidian-todoseq.git /tmp/obsidian-todoseq-audit
Cloning into '/tmp/obsidian-todoseq-audit'...
% cd /tmp/obsidian-todoseq-audit
% git rev-parse --short HEAD
4ba5e81
% jq '{id, version, minAppVersion, description}' manifest.json
{
  "id": "todoseq",
  "version": "0.18.1",
  "minAppVersion": "1.11.0",
  "description": "Lightweight keyword-based task tracker using Logseq style keywords."
}

A source scan found no network requests, telemetry, process execution, or dynamic code evaluation¹.

It does read and modify notes through Obsidian’s vault API, as expected:

% rg -n 'vault\.(read|modify)' src/services/editor-controller.ts | head -4
1130:        const currentContent = await this.plugin.app.vault.read(todayNote);
1135:        await this.plugin.app.vault.modify(todayNote, newContent);
1283:        const todayContent = await this.plugin.app.vault.read(todayNote);
1286:        await this.plugin.app.vault.modify(todayNote, newTodayContent);

Low risk, and no task-format conversion needed.

This should make it easier for me to adapt my LogSeq muscle memory to Obsidian, even if at the cost of enabling community plug-ins.

🤖 Drafted with /bloggify.

Hope is not a strategy. ↩︎

— § —

Reply via email

#bloggify #dev #pkm #security

pi: change directories mid-session

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 29 Jul 2026 14:13:03 +0200

♠ Today I learned: pi 0.82.1 cannot change its working directory mid-session.

The interactive shell syntax looks tempting, but ! and !! run commands in a child process. cd ends with that process; Pi keeps the session’s original cwd. There is no built-in /cd either:

% pi --version
0.82.1
% docs="$(brew --prefix pi-coding-agent)/libexec/lib/node_modules/@earendil-works/pi-coding-agent/docs"
% rg -n 'ctx\.(newSession|switchSession|changeCwd|switchCwd)' "$docs/extensions.md"
1109:### ctx.newSession(options?)
1117:const result = await ctx.newSession({
1187:### ctx.switchSession(sessionPath, options?)
1192:const result = await ctx.switchSession("/path/to/session.jsonl", {
1220:      await ctx.switchSession(choice, {
1247:    await ctx.newSession({
1262:    await ctx.newSession({
% rg -n '^\| `/[^|]+`' "$docs/usage.md" | tail -5
56:| `/share` | Upload as private GitHub gist with shareable HTML link |
57:| `/reload` | Reload keybindings, extensions, skills, prompts, themes, and context files |
58:| `/hotkeys` | Show all keyboard shortcuts |
59:| `/changelog` | Display version history |
60:| `/quit` | Quit pi |

This has been requested several times upstream:

% for n in 2102 2992 3921 4423 6997; do
    gh issue view "$n" --repo earendil-works/pi \
      --json number,title,state,stateReason \
      --jq '[.number, .title, .state, .stateReason] | @tsv'
  done
2102	Allow extensions to change cwd at runtime	CLOSED	COMPLETED
2992	Allow session CWD to be changed	CLOSED	COMPLETED
3921	Feature request: ExtensionCommandContext.changeCwd() for lightweight cwd switching	CLOSED	NOT_PLANNED
4423	Add command API to switch cwd	CLOSED	COMPLETED
6997	Windows Bash inside Pi not working properly	CLOSED	NOT_PLANNED

The exact /cd proposal lives in #3921. The maintainer responses on #2102, #2992, and #4423 capture the trade-off:

#2102 @badlogic: use case makes sense, however, it can be done by overriding the built-in tools to support cwd changes.
#2992 @badlogic: setting a new cwd in a session is not great, as a bunch of things need to be rewired. currently unsupported.
#4423 @badlogic: this is part of the big refactor work and will be available in the new extension api.

That last API still is not exposed in 0.82.1. Changing cwd means rebuilding tools, project settings, extensions, skills, context files, autocomplete, footer state, and session storage—not merely calling process.chdir().

For now, the boring path is the supported one:

/quit
% cd ~/Workspace/perrotta.dev
% pi

Session cwd is a runtime boundary. Oh well.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi

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 #bloggify #claude #coding #dev

pi: block dangerous commands syntax-aware

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 28 Jul 2026 10:57:06 +0200

♠ Problem statement: block destructive shell commands issued by pi without resorting to grepping shell source with regular expressions.

My first guard was a direct port of an older hook in Claude Code:

const BLOCKED_COMMANDS: ReadonlyArray<{ pattern: RegExp; reason: string }> = [
  { pattern: /terraform\s+apply/, reason: "terraform apply is blocked - use terraform plan first" },
  { pattern: /terraform\s+destroy/, reason: "terraform destroy is blocked for safety" },
  { pattern: /git\s+reset\s+.*--hard/, reason: "git reset --hard is blocked - discards changes irreversibly" },
];

const blocked = BLOCKED_COMMANDS.find(({ pattern }) => pattern.test(command));

This matched harmless strings such as echo 'terraform destroy', while shell quoting, wrappers, substitutions, and reordered options kept opening holes. Regexes aren’t robust in this context.

Enter ASTs! Shell source could leverage a shell parser.

I switched the extension to the Bash grammar from tree-sitter-bash, loaded through the WASM Tree-sitter runtime:

await Parser.init();
const languagePath = require.resolve("tree-sitter-bash/tree-sitter-bash.wasm");
const language = await Language.load(languagePath);
return new Parser().setLanguage(language);

Tree sitter is an amazing parser.

The policy now works on executable names and arguments:

if (executable === "rm") {
  const recursive = staticArguments.some(
    (argument) => argument === "--recursive" || hasShortOption(argument, "r") || hasShortOption(argument, "R"),
  );
  const force = staticArguments.some(
    (argument) => argument === "--force" || hasShortOption(argument, "f"),
  );
  if (recursive && force) return { command, reason: "rm -rf is blocked for safety" };
}

The AST walker also follows command substitutions, heredocs, bash -c, eval, find -exec, xargs, and common wrappers. Comments and quoted data remain data. Malformed syntax and dynamic guarded arguments fail closed.

ℹ tests 48
ℹ suites 0
ℹ pass 48
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0

Local extensions do not get npm dependencies installed by Pi. I kept index.ts dependency-free: on first load it checks for the parser files, runs a pinned installation when needed, then imports the real guard.

const result = await pi.exec("npm", ["ci", "--ignore-scripts"], {
  cwd: extensionDirectory,
  timeout: 120_000,
});

const { default: dangerousCommandGuard } = await import("./guard.ts");
await dangerousCommandGuard(pi);

Finally, testing the real tool call:

% rm -rf /tmp/foo
rm -rf is blocked for safety
% test -f /tmp/foo/marker && cat /tmp/foo/marker
guard-test

The guard blocked the command; /tmp/foo/marker survived.

The source lives in my dotfiles.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #security

pi: asynchronous exit summaries

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 27 Jul 2026 18:18:38 +0200

♠ Problem statement: ctrl+d in pi took several seconds to quit.

The culprit was pi-memory’s session_shutdown handler. It sent one last LLM request to summarize the session, wrote its answer to the daily log, then ran qmd update. Pi awaits all shutdown handlers, correctly, so quitting waited for everything:

pi.on("session_shutdown", async (event, ctx) => {
  const result = await generateExitSummary(ctx);
  fs.writeFileSync(filePath, entry, "utf-8");
  await runQmdUpdateNow();
});

Making that promise fire-and-forget would not work: Pi exits immediately after shutdown, and either the in-flight request keeps Node alive or gets killed before it can write anything.

Instead, I made the shutdown path write a durable job, synchronously:

const job: ExitSummaryJob = {
  version: 1,
  id: randomUUID(),
  createdAt: new Date().toISOString(),
  date: todayStr(),
  reason,
  sessionId: shortSessionId(ctx.sessionManager.getSessionId()),
  conversationText: truncated.text,
  truncated: truncated.truncated,
  totalChars: truncated.totalChars,
};

const jobPath = path.join(
  EXIT_SUMMARY_JOBS_DIR,
  `${job.createdAt.replace(/[:.]/g, "-")}-${job.id}.json`,
);
fs.writeFileSync(jobPath, `${JSON.stringify(job)}\n`, { encoding: "utf-8", flag: "wx" });

The next interactive session starts an unref’ed worker. It atomically renames one job to claim it, generates summary with active model, writes it back to original day’s daily log, and deletes job. Failed jobs return to queue. A stale claimed job retries after ten minutes.

I kept upstream package intact by replacing it with a local package, effectively forking it:

% pi remove npm:pi-memory
Removed npm:pi-memory
% pi install ~/.pi/agent/local/pi-memory-async
Installed /Users/thiago.perrotta/.pi/agent/local/pi-memory-async
% pi list
User packages:
  local/pi-memory-async
    /Users/thiago.perrotta/.pi/agent/local/pi-memory-async

Jobs live in ~/.pi/agent/memory/exit-summary-jobs/. ctrl+d only writes one JSON file now; summary happens during next session, without blocking exits.

Source code: pi-memory-async.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #pkm

pi: update pinned npm packages

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 27 Jul 2026 14:28:59 +0200

♠ Problem statement: pin pi npm packages without giving up convenient updates.

My settings.json used to leave some package versions unpinned, until now:

     "npm:@heyhuynhgiabuu/pi-diff@0.7.6",
-    "npm:@tifan/pi-recap",
-    "npm:@tmustier/pi-tab-status",
-    "npm:@tintinweb/pi-subagents"
+    "npm:@tifan/pi-recap@0.4.4",
+    "npm:@tmustier/pi-tab-status@0.1.4",
+    "npm:@tintinweb/pi-subagents@0.14.3"

Exact versions make package installation reproducible (& safer), but Pi then does not automatically pull newer packages.

To tackle that, I added a just update-pi recipe that asks npm for each package’s current latest version and writes back an exact pin:

[doc('Update pinned Pi npm packages')]
[group('update')]
update-pi:
    #!/usr/bin/env bash
    set -euo pipefail

    settings="pi/.pi/agent/settings.json"
    updates="{}"
    while IFS= read -r spec; do
        if [[ "$spec" =~ ^npm:((@[^/]+/[^@]+)|([^@]+))(@[^@]+)?$ ]]; then
            package="${BASH_REMATCH[1]}"
        else
            echo "Invalid npm package spec: $spec" >&2
            exit 1
        fi

        latest="$(npm view "$package@latest" version)"
        pinned="npm:$package@$latest"
        updates="$(jq -cn \
            --argjson updates "$updates" \
            --arg spec "$spec" \
            --arg pinned "$pinned" \
            '$updates + {($spec): $pinned}')"
        echo "✓ $pinned"
    done < <(jq -r '.packages[] | select(type == "string" and startswith("npm:"))' "$settings")

    updated_settings="$(jq --argjson updates "$updates" \
        '.packages |= map($updates[.] // .)' "$settings")"
    printf '%s\n' "$updated_settings" > "$settings"

It handles every npm: entry, including scoped packages:

% just update-pi
✓ npm:@heyhuynhgiabuu/pi-diff@0.7.6
✓ npm:@heyhuynhgiabuu/pi-pretty@0.6.20
✓ npm:@tifan/pi-recap@0.4.4
✓ npm:@tmustier/pi-tab-status@0.1.4
✓ npm:@tintinweb/pi-subagents@0.14.3

The aggregate just update recipe invokes it alongside submodule, prek hook, and vendored-file updates.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi #security

pi: /btw side-chat

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 22 Jul 2026 14:07:54 +0200

♠ Previously.

Problem statement: mid-task, I want to ask the LLM agent a quick tangential question — “will this change cause downtime?” — without polluting the main agent thread.

Claude Code has /btw¹ for exactly this. pi doesn’t, but patriceckhart/pi-btw does, as an extension. It opens a side-chat overlay: the LLM gets to see the full main thread context and answers, but nothing is written back to the conversation history.

The upstream extension imports the pre-fork @mariozechner/* package names, which are now deprecated. As such, I use earendil-works/pi. Rather than trust a diff I hadn’t read, I reimplemented it against the current API, and cross-checked against the bundled examples/extensions/summarize.ts (the canonical example for calling the model from an extension):

import { complete } from "@earendil-works/pi-ai/compat";
import type { ExtensionAPI, SessionEntry } from "@earendil-works/pi-coding-agent";
import { convertToLlm, getMarkdownTheme } from "@earendil-works/pi-coding-agent";

// ...inside the /btw command handler, once at entry:
const branch = ctx.sessionManager.getBranch();
const mainMessages = branch
  .filter((entry): entry is SessionEntry & { type: "message" } => entry.type === "message")
  .map((entry) => entry.message);
const mainLlmMessages = convertToLlm(mainMessages);   // frozen snapshot
const systemPrompt = ctx.getSystemPrompt();

// ...per question, the side-chat calls the model directly:
const response = await complete(
  ctx.model!,
  { systemPrompt, messages: [...mainLlmMessages, ...btwLlmMessages] },
  { apiKey: auth.apiKey, headers: auth.headers, env: auth.env, signal },
);

The key move is what’s missing: the handler never calls pi.sendMessage() or appends anything. It reads the branch once, talks to the model in an ctx.ui.custom() overlay, and returns. The main session is untouched, so the next real prompt doesn’t pay for any of it.

Added to ~/.pi/agent/extensions/btw.ts.

🤖 Drafted with /bloggify.

I am no longer using Arch, btw (sad!) ↩︎

— § —

Reply via email

#ai #bloggify #coding #dev #pi

pi: auto-retry stalled requests

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 22 Jul 2026 13:45:41 +0200

♠ Previously.

Problem statement: sometimes a prompt in pi just hangs, as if the network dropped. It never recovers on its own — I have to hit Esc and re-prompt.

It’s 2026, this symptom should be self-recoverable.

Pi already has agent-level retry on transient errors (retry.enabled defaults to true). The catch is when it fires: a stalled connection isn’t an error until the HTTP idle timeout trips, and that defaults to five minutes:

httpIdleTimeoutMs | number | 300000 | HTTP header/body idle timeout in milliseconds […] Set to 0 to disable.

So pi would have eventually recovered. I was just quitting long before the five-minute clock ran out. Who has patience to wait for 5 minutes?!

:∴ Lower the idle timeout to O(seconds) instead:

{
  "httpIdleTimeoutMs": 30000,
  "retry": {
    "enabled": true,
    "maxRetries": 5,
    "baseDelayMs": 2000
  }
}

Dropped into ~/.pi/agent/settings.json, documented in docs/settings.md. Now a stall errors out after 30s and pi retries automatically with exponential backoff (2s, 4s, 8s…), up to five attempts. There’s no need for Esc nor re-prompting.

The idle timer resets on every byte received, so long thinking or a slow stream won’t trip it — only a genuinely dead connection will. Restart pi for the change to take effect.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi

pi: cycle models backward with ctrl+n

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 22 Jul 2026 13:23:53 +0200

♠ Previously.

Problem statement: pi binds ctrl+p to app.model.cycleForward¹ by default, but has no default binding to cycle backward other than shift+ctrl+p, which is arguably difficult to remember.

Every keybinding in pi is namespaced and overridable via ~/.pi/agent/keybindings.json, documented in docs/keybindings.md:

{
  "app.model.cycleBackward": [
    "shift+ctrl+p",
    "ctrl+n"
  ]
}

ctrl+n is also the default for app.session.toggleNamedFilter, but that only fires inside the session picker, not while a model selector or the main editor has focus.

Run /reload in pi to pick up the keybinding addition without restarting the session.

∴ ctrl+p/ctrl+n now cycle models forward/backward, matching the readline (emacs!) history bindings I already have muscle memory for.

🤖 Drafted with /bloggify.

It cycles through models selected in /scoped-models. ↩︎

— § —

Reply via email

#ai #bloggify #coding #dev #pi

pi: caveman mode

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 22 Jul 2026 12:14:47 +0200

♠ Previously, previously.

Problem statement: adopt caveman in pi.

Pi isn’t one of the 30+ agents caveman auto-detects. The install matrix (INSTALL.md) lists agent detection rules one by one — claude, cursor, windsurf, opencode, openclaw, etc — and pi isn’t in it. Running the one-liner installer here would just skip everything silently. Booo!

Rather than run someone else’s curl | bash against an agent it wasn’t built for, “““I””” reimplemented the terse-speak part natively, since pi already ships the two primitives needed: skills and extensions.

A skill for /skill:caveman documentation, and an extension that rewrites the system prompt on every turn via pi.on("before_agent_start", (event) => ...):

const INSTRUCTIONS = `Caveman mode: on. Respond terse. Drop articles (a/an/the), filler (just/really/basically), pleasantries, hedging. Fragments OK. Short synonyms. Technical terms exact. Pattern: [thing] [action] [reason]. [next step]. Example — not: "Sure! I'd be happy to help you with that." yes: "Bug in auth middleware. Fix:"
Boundaries, always: code blocks, commit messages, and PR descriptions stay normal full verbosity, never compressed. Drop caveman style for security warnings, irreversible/destructive actions, or when the user seems confused — resume caveman after.`;

export default function (pi: ExtensionAPI) {
  let on = true; // auto-on by default, every session

  const applyStatus = (ctx: { ui: { setStatus: (k: string, v?: string) => void } }) => {
    ctx.ui.setStatus("caveman", on ? "[caveman]" : undefined);
  };

  pi.on("session_start", async (_event, ctx) => applyStatus(ctx));

  pi.on("before_agent_start", (event) => {
    if (!on) return;
    return { systemPrompt: `${event.systemPrompt}\n\n${INSTRUCTIONS}` };
  });

  pi.registerCommand("caveman", {
    description: "Toggle caveman terse-response mode: on|off (default: on)",
    handler: async (args, ctx) => {
      const arg = args.trim().toLowerCase();
      if (arg === "off" || arg === "stop" || arg === "normal") on = false;
      else if (arg === "on" || arg === "") on = true;
      else return ctx.ui.notify(`Unknown arg "${arg}". Use: on | off`, "error");
      applyStatus(ctx);
      ctx.ui.notify(on ? "Caveman mode on." : "Caveman mode off.", "info");
    },
  });
}

before_agent_start fires on every prompt, before the agent loop starts, so the instructions are re-appended each turn instead of relying on one message that could get pruned from context. Dropped in ~/.pi/agent/extensions/caveman.ts, auto-discovered, no /reload needed after the first load.

Unlike the Claude Code plugin, I skipped lite/full/ultra/wenyan — I called that bloat back in June, and I’m not adding it to my own version either. On or off is enough.

The result, unprompted:

user: caveman on or off now?

assistant: Caveman: on.

user: how to turn it off?

assistant: /caveman off

I also skipped the parts that don’t have a pi equivalent: the statusline savings counter, /caveman-stats, the caveman-shrink MCP proxy that rewrites tool descriptions (a proxy that rewrites what an agent sees is exactly the kind of thing worth reading before installing). The 40-line extension above covers what I actually wanted.

One rule baked into both the skill and the extension: code, commits, and PRs stay full verbosity, never compressed.

This experience was an eye-opener for me to realize how bloated the upstream caveman project became.

🤖 Drafted with /bloggify.

— § —

Reply via email

#ai #bloggify #coding #dev #pi

myrepos: a wip action to find unfinished work

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 17 Jul 2026 12:23:10 +0200

♠ Previously.

Problem statement: I manage a few dozen repos via myrepos (mr), and I wanted a single command to show which ones have work in progress (“WIP”) — uncommitted changes, dirty staging area, stray branches and alike.

I want essentially a filtered version of mr ls.

So I defined my own command. A repo is not WIP when all three hold:

the default branch is checked out;
no other local branches exist;
and the working tree is fully clean.

Anything else gets flagged with a reason.

The definition:

# List repos with work in progress: not on default branch, extra local branches, or dirty tree.
# Run as `mr -m wip`: the -m (minimal) flag drops mr's per-repo "mr wip:" header and blank
# lines, leaving only the flagged repos. This cannot be defaulted per-action (mr only honors
# -m/-q as CLI flags, not via config).
wip =
 reasons=""
 cur=$(git symbolic-ref --quiet --short HEAD 2>/dev/null || echo "(detached)")
 def=$(git symbolic-ref --quiet --short refs/remotes/origin/HEAD 2>/dev/null | sed 's|^origin/||')
 if [ -z "$def" ]; then if git show-ref --verify --quiet refs/heads/main; then def=main; elif git show-ref --verify --quiet refs/heads/master; then def=master; fi; fi
 if [ -n "$def" ] && [ "$cur" != "$def" ]; then reasons="$reasons branch:$cur"; fi
 n=$(git for-each-ref --format='%(refname)' refs/heads | wc -l | tr -d ' ')
 if [ "$n" -gt 1 ]; then reasons="$reasons +$((n-1))_branches"; fi
 if [ -n "$(git status --porcelain)" ]; then reasons="$reasons dirty"; fi
 if [ -n "$reasons" ]; then printf '%s [%s]\n' "$MR_REPO" "${reasons# }"; fi

Naturally, the snippet above is art from the LLM, but it accomplishes exactly what I want:

thiago.perrotta ~
% mr -m wip
mr wip: /Users/thiago.perrotta/Corp/gitops
/Users/thiago.perrotta/Corp/gitops [branch:thiagowfx/acme +1_branches]

mr wip: /Users/thiago.perrotta/Corp/terraform
/Users/thiago.perrotta/Corp/terraform [+1_branches]

mr wip: /Users/thiago.perrotta/workspace/perrotta.dev
/Users/thiago.perrotta/workspace/perrotta.dev [+3_branches dirty]

Clean repos stay silent. I get to see all repos with unfinished work, and I can see exactly why each one is dirty.

mr wip works too but it’s noisier. I need to add mr -m wip to my muscle memory¹. Without the -m flag, mr prepends a mr wip: header and a blank line for every repo, WIP or not.

-m can’t be baked into the action definition — mr only honors it as a CLI flag — so the comment above the action documents it.

Previously I’d run mr xl (an alias for git branch -vv across every repo) and eyeball the result — but that’s dozens of lines of branch tips for tens of repos, and I still have to scan for the ones that are actually behind or dirty. wip does the scanning: it only prints the repos that need attention, with the reason attached. Much more ergonomic than visually diffing a wall of green.

Runs read-only, so it’s safe to run twice.

🤖 Drafted with /bloggify.

Should I rely on this workflow more often, I could leverage Espanso or a shell alias/function to easen its recall. ↩︎

— § —

Reply via email

#bloggify #coding #dev #git

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 #bloggify #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 #bloggify #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 #bloggify #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 #bloggify #claude #dev

espanso: reload config after editing

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 24 Jun 2026 13:34:06 +0200

♠ Previously.

Problem statement: espanso edit corp opens a config file, but saving it doesn’t take immediate effect.

At $DAILYJOB I keep a separate match file for work-specific snippets (“corp”). Espanso supports multiple match files under match/:

% espanso edit corp
Editing file: /Users/thiago.perrotta/Library/Application Support/espanso/match/corp.yml

After saving, the new trigger doesn’t expand. Espanso doesn’t auto-reload on file change.

The intended fix:

% espanso restart

Except that it has timed out:

unable to start service: timed out
Hint: sometimes this happens because another Espanso process is left running for some reason.
      Please try running 'espanso restart' or manually killing all Espanso processes, then try again.

A stale process was holding the IPC socket lock, so espanso restart, espanso start, and even espanso service start all timed out — while espanso status cheerfully reported espanso is not running. The hint is right, but its suggested remedy (run espanso restart again) doesn’t break the cycle.

On macOS, espanso runs as a launchd service. The reliable escape hatch is to bounce it through launchd, which owns the process:

% launchctl kickstart -k "gui/$(id -u)/com.federicoterzi.espanso"

-k kills the existing instance before restarting it. After that, corp.yml expands again.

Meta: should I create a trigger for this command? :P

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #dev #macos

keychron k2: bluetooth always-on

serendipity@perrotta.dev (Thiago Perrotta) — Sat, 20 Jun 2026 23:51:02 +0200

♠ Problem statement: the Keychron K2 (C3, stock firmware) disconnects from macOS after ~10 minutes idle — and there’s no way to prevent it.

I spent some time looking for a fix. The usual suggestions:

Disable Bluetooth auto-sleep in macOS? macOS doesn’t do that — the keyboard decides to sleep, not the host.
Install a keep-alive app? The keyboard’s firmware powers down its own radio. By the time the app could send a ping, there’s nothing on the other end listening.
Key combo to disable sleep on the keyboard? Only on newer Keychron boards (QMK/VIA). The C3 runs stock firmware with no configurable sleep timer.
Flash QMK and set an infinite sleep timeout? The C3 isn’t a QMK board. Can’t.

The C3 stays paired — macOS reconnects on the first keypress, with ~1s lag. That’s the firmware’s design. The radio sleeps to save battery. Nothing running on the Mac can reach through a sleeping radio and wake the other end.

The only real fix: flip the side switch to Cable, plug in USB-C. No Bluetooth, no sleep, no drops.

Time to shop for a new Keychron, with QMK?

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #macos

pre-commit: authentication in internal github repos

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 18 Jun 2026 14:42:26 +0200

♠ Problem statement: prek can’t clone a repo: that lives in an internal (private) GitHub repo — https:// clone fails without credentials.

I forked my personal pre-commit-hooks into an org-owned repo and updated all our .pre-commit-config.yaml files to point at it:

- repo: https://github.com/<org>/pre-commit-hooks
  rev: 5695e23285bef67d1dee957e5c12e86f58ba843b # frozen: v1.0.0
  hooks:
    - id: check-bash-shebang

This approach works locally (my GitHub token is broad).

CI (github actions) fails though:

fatal: could not read Username for 'https://github.com': terminal prompts disabled

The repo is INTERNAL, not public. As such, prek clones the repo: URL to fetch the hooks; with no credentials on the runner, it can’t.

First instinct: git@github.com:<org>/pre-commit-hooks. Runners have no SSH key though!

The fix is to keep https:// in the config, mint a short-lived token that can read the hooks repo, and tell git to rewrite the URL:

- name: Generate app token
  uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
  id: generate-token
  with:
    client-id: ${{ vars.APP_CLIENT_ID }}
    private-key: ${{ secrets.APP_PRIVATE_KEY }}
    owner: ${{ github.repository_owner }}
    repositories: pre-commit-hooks
    permission-contents: read
- uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
  with:
    persist-credentials: false
- name: Authenticate git for internal hook repos
  env:
    TOKEN: ${{ steps.generate-token.outputs.token }}
  run: git config --global url."https://x-access-token:${TOKEN}@github.com/".insteadOf "https://github.com/"
- uses: j178/prek-action@bdca6f102f98e2b4c7029491a53dfd366469e33d # v2.0.4

Two things worth noting.

First: never inline ${{ steps.generate-token.outputs.token }} directly into a run: shell string — zizmor (a GitHub Actions security linter) flags it as a template injection risk. Pass it via env: and use the shell variable instead.
Second: the repositories: pre-commit-hooks scope only works if the App is actually installed on that repo. That one is a manual step in GitHub’s UI — github.com/organizations/<org>/settings/installations → the App → Repository access → add the repo. No amount of YAML fixes it otherwise; it silently returns a 404 from the App installation endpoint otherwise.

After the installation grant, the clone goes through and prek runs cleanly.

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #dev #git #pre-commit

git: switch-to-default with wt

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 14 Jun 2026 20:03:03 +0200

♠ My switch-to-default git alias had been trying branch names in order:

switch-to-default = !git switch --force main 2>/dev/null \
    || git switch --force master 2>/dev/null \
    || git switch --force $(git symbolic-ref refs/remotes/origin/HEAD \
        | sed 's@^refs/remotes/origin/@@')

It works, but it’s trial-and-error. Different people and different projects cannot decide whether to use main or master. It’s a mess.

Worktrunk tracks the default branch as part of its worktree state:

% wt config state default-branch
master

No need to guess!

New alias:

switch-to-default = !git switch --force \
    $(wt config state default-branch 2>/dev/null \
        || git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null \
            | sed 's@^refs/remotes/origin/@@' \
        || echo master)

wt first, then fall back to origin/HEAD if wt is not installed, then master as a last resort.

🤖 Drafted with /bloggify.

— § —

Reply via email

#bloggify #dev #git

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 #bloggify #claude #dev #meta