A shared library · learning in the open

I don't build alone.

In 2026, going solo isn't the smart default. This is a shared library of the open-source projects, Claude Skills, and creators I learn from, collaborate with, and borrow workflow ideas from — and I study how different people actually use AI to keep sharpening my own workflow. I'm publishing it so you can see how I think and learn, not just what I ship.

These aren't my output — they're my collaborators and teachers. Almost every entry is an official, community, or third-party tool; the links go to source and the authors are credited in each row. The systems I actually built live on the Operating Model page and in my own AI Skill Set.

On using AI, honestly. I don't treat it as a crutch or a source of truth. Models get stance, citations, and real-world facts wrong, and numbers stitched together aren't knowledge. But when I'm dropped into an unfamiliar industry from zero, you still need a starting point — mine is usually a stack of URLs in NotebookLM, learning a field's systems, needs, and gaps from primary sources before I ever open Figma. The point is to come at a problem from several angles, understand the client, and never fake expertise.

How I work with all this.

A library only matters if there's judgment behind it. Here's the thinking that decides what earns a place, and how these tools fit into real work.

01
Don't go solo
In 2026 the smart default is to learn from open source and shared work — not to build everything alone.
02
Verify, don't trust
Models get stance, citations and facts wrong; stitched-together numbers aren't knowledge. I check before I ship.
03
Start from primary sources
Entering a field from zero, I load the real docs — often a stack of URLs in NotebookLM — before I form an opinion.
04
Understand the client, don't fake it
The goal is to grasp the real need from several angles — never to perform expertise I don't have.
01 · Learn
NotebookLM on primary sources
A field's systems, needs and gaps — from the real docs, not a summary.
02 · Vet
Score before adopting
Run a tool through the rubric below before it earns a place in the stack.
03 · Build
Claude Code + the right skills
With my own harness (Ed Agent) governing the loop and sign-off staying human.
04 · Verify
Test & cross-check
Facts, edge cases and the honesty of every claim — judgment stays mine.
05 · Ship & give back
Release, then open-source
What's reusable goes back to the community that taught me.
How I vet a tool — what earns a place
Problem fitSolves a real bottleneck, or just looks clever?
HonestyStates its limits, or overclaims?
PortabilityReusable, or locked to one model or vendor?
MaintenanceActive, or quietly abandoned?
Trust surfaceWhat data and permissions does it touch?
CostFree or local, or a recurring dependency?

Maintained as a living document · last updated July 2026 · tools and growing. Entries marked are recommended starting points.

Platform
Level
Category