Code
Six repositories, and the one file in each that is actually worth your time.
Most of what I build at work is private: the platform I work on is my teamβs code, and the customer deployments belong to the customers. What follows is the public half. It is small on purpose, so instead of a repository list I have pointed at the single file in each that shows how I think about the problem.
A pattern runs through most of them, if you want the short version: decide in a pure function, act in a wrapper. It is the only reason any of this is testable.
Python
Self-healing ops for the long-running agents on my Mac Mini. Health probes, layered self-heal, failure watchers, PII-safe logging.
Read this file: lib/launchd_selfheal.py · also its test suite
decide() is pure logic and returns what should happen; the wrapper owns every side effect (launchctl, state on disk, Telegram). That split is why it has a real unit-test suite at all, and the tests are nearly the size of the module. Note the two allowlists: only idempotent, non-customer-facing jobs are ever auto-remediated, and anything matching gateway can never be, no matter how it is configured.
TypeScript Β· React Native Β· Supabase
A couples app for people who hate couples apps. Daily prompt drops, a mutual reveal, AI conflict mediation. Live on the App Store since July 2026.
Read this file: supabase/migrations/0002_drops_answers.sql
The answers_select_partner_revealed policy is the whole product in one place: your partnerβs answer is unreadable until the shared drop reaches state = 'revealed', and that is enforced by row-level security in Postgres rather than by the app. A patched client cannot peek early, because the database will not return the row.
Shell
Makes any repo AI-native in one command: detects the stack, then generates a tailored CLAUDE.md, rules, agents, and hooks.
Read this file: .claude/skills/claude-init/SKILL.md · also what I got wrong building it
The interesting artefact is not the shell, it is the skill definition: everything the tool generates is conditional on what it detected, so a repo with no Docker never gets a devops agent and a repo with no API routes never gets API rules. Writing that as a spec rather than as branching code is what keeps it maintainable.
JavaScript Β· Playwright
Books my CrossFit classes at 09:00:00.000 SGT, two days out, for me and two friends. Running daily since March.
Read this file: lib.js · also the auth self-heal
Schedule resolution is pure functions over a date, with per-user overrides and a fallback slot when the 6:30am fills. The browser automation, the auth self-heal, and the Telegram alerts all sit outside it. Same discipline as the harness above, arrived at independently, which is roughly how I know it is the right shape.
JavaScript
Live observability for agent runs. Maps raw runtime activity into run lanes, a timeline, a scorecard, and stuck-detection. MIT.
Read this file: public/mapping.js
The hard part of agent observability is that every runtime logs differently. This is the heuristic layer that turns arbitrary JSON into typed events: candidate keys for type, time, and message, tried in order, with file paths pulled out by regex. Ugly by necessity, and honest about it.
Python
How a small DTC pet food brand ships Instagram Reels mostly autonomously with an AI coding agent.
Read this file: templates/anchor_driven_reel_build.py · also the format, written down
A build script rather than a prompt. The format is encoded as code so the agent produces the same structure every time and the variation lands in the content, not the template. The repo also carries the case studies, including the episodes that underperformed.
More context on what these are for: Projects, the automation fleet, and the failures that produced most of the guardrails. Everything above is on GitHub.