I build the layer between an AI agent and the things it is allowed to do.
claude-second-brain A connected skill ecosystem for Claude Code. Most skill repos are catalogs: isolated prompts you have to remember to invoke. This one is a system. Every skill declares what comes after it, honesty is enforced by hard prohibitions rather than by tone, and the graph that links them is maintained by one of its own nodes. MIT, live site.
PlutoGate Permissions as contract clauses, not machine settings. An orchestrator that turns a goal into verifiable task contracts and submits every agent action to approval against that contract: default-deny, with an audit trail. An action the contract does not foresee writes nothing. Today the repository is the design and a full statement of what does not work yet; extracting the running gate is the open milestone.
The two connect. The first writes the contract, the second enforces it.
I read the code before I have an opinion about it. Most of what I contribute starts as a trace through someone else's read path, becomes a question the maintainer is the only person able to answer, and only then becomes a patch.
Recent work has been on instrumentation that reports confidently while measuring the wrong thing: telemetry whose detectors cannot fire, and usage accounting that drifts because it recomputes from files that get rewritten underneath it.
path-of-gods, a 2D action-platformer in LÖVE2D/Lua. Different problem, same habit of building the system before the content.
Tools that read agent transcripts mostly run their tests on Linux. The paths inside those transcripts are the one thing that changes shape on Windows, so I went looking there. Fork, add a workflow with an ubuntu and windows matrix, run the suite, compare. The ubuntu leg is the control: without it a Windows failure tells you nothing, because you cannot separate a broken platform from a broken suite.
junhoyeo/tokscale is the one worth citing. 947 tests passed and 12 failed on Windows, against 2461 passed and none failed on Ubuntu, with the suite stopping at the first binary and never reaching the end. Three of the twelve were in the program itself, not in its tests.
All three shipped fixed in v4.9.0. The maintainer then put the windows leg in
himself and ran it with --no-fail-fast, which reached the nine binaries that
had never executed on Windows at all: 34 failures, not 12, and 33 of them
predated the report. They are enumerated now in six root-cause groups, two of
which look like Windows defects in the program rather than artefacts of its
tests.
The run,
the report,
what it uncovered.
Before that, three merged patches on splitrail, and Claude-Code-Usage-Monitor #238, where six of the nine failures were tests asserting on a POSIX API that the program had already worked around.
phuryn/claude-usage came back clean, eight green jobs out of eight. That one is in the record too, with the same detail as the others.

