Coding on ¬ just serendipity 🍀

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

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

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

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

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

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

★ 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 #coding #dev