sam/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sam-4screen-desktop 2026-9-9:11:54:8

Browse Source
This commit is contained in:
Sam Rolfe
2026-09-09 11:54:08 +10:00
parent c120e56fef
commit 421c048602
8 changed files with 16 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

100
100 inbox/AI Design.md
View File

@@ -1,100 +0,0 @@
---
created: 2026-06-20 11:45
modified: 2026-06-20 11:52
type: reference
tags:
- ai-agents
- open-source
- automation
- ai
- tool
- tools
- design
- dev-ops
aliases:
- Agentic UI Pipeline
---
## 🛠️ The Local Stack
* **Visual Prototyping Engine**: **Penpot** (Self-hosted via local Docker container [Penpot]).
* **Visual Code Mutator**: **Onlook** (Reads/writes directly to local React components in place) [Onlook].
* **Headless Visuals**: **Chai Builder SDK** (Open-source developer React/Tailwind visual engine) [Chai Builder SDK].
* **Terminal Agent**: **Goose** (Block's autonomous developer agent run locally via terminal) [Goose].
* **Local Inference**: **Ollama** running `Qwen2.5-Coder` via Docker container [Ollama].
* **Sync Pipeline**: Shell script automation executing `rsync` to a target machine managed by **Caddy**.
---
## 🎨 The Plain-Text Design Engine (Google Stitch & DESIGN.md)
### 💡 Core Mechanics
* **Google Stitch Paradigm**: An open standard developed by Google Labs to feed design guidelines directly to AI agents [Google Stitch].
* **DESIGN.md Structure**: A standalone markdown file placed in your project root combining YAML design tokens with markdown prose explaining the visual rationale [DESIGN.md].
* **Penpot Integration**: Use Penpot's built-in Model Context Protocol (MCP) server [Penpot MCP] to connect your terminal agents. This translates your design shapes, tokens, and layouts straight into a machine-readable context file, bridging your visual wireframes with your coding engine.
### 🗂️ Scaling with Awesome-Design-MD
Instead of drafting schemas from scratch, pull standard markdown design sheets from **awesome-design-md** [awesome-design-md]:
* **Ready-Made Blueprints**: Features 55+ design languages reverse-engineered from platforms like Linear, Vercel, Stripe, and Supabase.
* **Drop-In Protocol**: Drop the curated markdown file into your project tree. Tell your agent pipeline: *"Review DESIGN.md and generate a settings view matching these visual guardrails"*.
---
## 🔄 Execution Flows
### Flow A: The Fully Terminal Pipeline (Goose + Ollama)
[User Pipeline / Pi Prompt] ----> [Goose CLI] ----> [Parses local DESIGN.md context]
|
v (Generates clean .tsx / Tailwind)
[Local Repo Workspace]
|
v
[rsync Script ----> VPS with Caddy]
### Flow B: The Visual/Agentic Hybrid (Onlook + Penpot Local)
[Visual Adjustment in Penpot/Onlook] ----> [Mutates local .tsx code file instantly]
|
v (Triggers local git tracking)
[Goose agent fixes states & connects backend logic]
|
v
[rsync Script ----> VPS with Caddy]
---
## 🚀 Terminal Extensions & Skills for Pi Agent
* **Penpot MCP Bridge**: Expose your self-hosted Penpot canvas variables locally by connecting the Penpot MCP server key to your terminal execution environments [Penpot MCP].
* **Automated Design Context**: Inject design constraints directly by aliasing Goose to parse your schema file on launch: `goose run --instruction "$(cat DESIGN.md)"`.
* **Instant Refresh Loop**: Use `watchexec` or `entr` to monitor your React source directory. The split second Onlook or Goose modifies a file, `rsync` triggers to push the payload to Caddy.
* **Ollama Endpoint Spoofing**: Map your agent pipelines natively to local Docker execution layers by swapping your base API routing address to `http://localhost:11434/v1` [Ollama].
## 🎨 Adding Local Text-to-Layout Design Features to Pi
### 1. Install the Local Canvas Viewport
Bridge your terminal with a live graphical preview window to see your layouts update in real time:
```bash npm install -g pi-canvas ```
* **Usage:** Run `pi-canvas` in a secondary terminal split to open a hot-reloaded browser window at `http://localhost:3000`.
### 2. Register the Design Skill
Create a custom agent skill to enforce structured layout rules, protect against unwanted UI design shifts, and handle local visual synchronization.
[!file] `~/.pi/agent/skills/ui-builder.skill`
```markdown > # UI Builder Skill > Enforces web-standard design rules and manages local visual canvas synchronization.
## Instructions
1. When creating UI layouts, always use semantic elements and modern layouts (Tailwind CSS, Flexbox, CSS Grid).
2. Isolate all visual tests inside the workspace's local `./preview.html` or a dedicated test harness file.
3. Read any local `tailwind.config.js` or token files before generation to match existing spacing and color systems.
4. Do not rewrite unaffected code blocks during layout adjustments; isolate updates strictly to the requested components.
```
### 3. Iteration Workflow
1. **Initialize Viewport:** Start `pi-canvas` in one terminal window, and run `pi` in another.
2. **Text to Layout:** `/skill ui-builder Create an isolated interactive Tailwind dashboard card in preview.html.`
3. **Change with Text:** *"The layout feels cramped. Make the card wider and change the primary button to a ghost variant."*
4. **Layout to Code:** The code changes update instantly in the local file and live browser window, ready for backend integration.

220
100 inbox/Photo Consolidation Plan.md
View File

@@ -1,220 +0,0 @@
---
created: 2026-05-28
modified: 2026-05-28
type: note
tags: [photos, consolidation, archive]
aliases: [photo-consolidation]
---
# Photo Consolidation Plan
> Consolidating all photo collections across drives into a single clean archive.
---
## Principle
**Do not touch Immich** — it manages its own library at `/mnt/hd/immich/` (40K photos, Dec 2024 – Jan 2025). All other photos get consolidated into one archive.
---
## Current State — All Photo Collections
### Immich Library — DO NOT TOUCH
| Machine | Location | Photos | Period | Organized |
|---------|----------|--------|--------|-----------|
| .35 | `/mnt/hd/immich/` | 40,769 | Dec 2024 – Jan 2025 | Immich-managed |
### Collections to Consolidate
| # | Collection | Machine | Path | Photos | Period | Organized | Duplicate Of |
|--|-----------|---------|------|--------|--------|-----------|-------------|
| **1** | **sorted_pictures_holder** | .13 | `/mnt/data/ALL_TRANFERS/Pictures/sorted_pictures_holder/` | **31,279** | **1990–2023** | **✅ Year → Month** | Master collection |
| **2** | **temp_transfer** | .13 | `/mnt/data/ALL_TRANFERS/Pictures/temp_transfer/` | ~? | 2024 | ❌ By event name | Unique (latest photos) |
| **3** | **PICTURES_GROUPED_SUBJECT_OLD** | .13 | `/mnt/data/ALL_TRANFERS/Pictures/PICTURES_GROUPED_SUBJECT_OLD/` | ~? | 2005–2012 | ❌ By topic | **= #7 Back Up drive** |
| **4** | **Integral300 recovery** | .27 mounted | `/run/media/sam/Integral300/` | 30,747 | — | Mixed | **= #5 SmartDrive + #1** |
| **5** | **SmartDrive backup** | .27 | `/run/media/sam/SmartDrive/integral300_backup_20260305/` | 30,747 | — | Mixed | **= #4 recovery img** |
| **6** | **Photos-001 (1-4)** | .13 | `/mnt/data/ALL_TRANFERS/Pictures/Photos-001 (1-4)/` | ~119 | May–Jun 2023 | ❌ Raw dumps | Unique |
| **7** | **Back Up drive photos** | .27 | `/mnt/backup/old_photos_backup/pictures/` | ~? | 2005–2011 | ❌ By topic | **= #3** |
| **8** | **sorted_pictures/2019** | .13 | `/mnt/data/ALL_TRANFERS/Pictures/sorted_pictures/` | ~? | 2019 | ✅ Year only | Might be in #1 already |
| **9** | **sam rolfe/previous years** | .13 | `/mnt/data/ALL_TRANFERS/sam rolfe/previous years/` | ~? | 2018–2019 | ❌ Mixed | Unique? |
| **10** | **grandas_wake** | .13 | `/mnt/storage/Users/Sam Rolfe/Desktop/grandas_wake/recent photos sams/` | ~7 | — | ❌ | Unique? |
### Duplicate Summary
| Group | Collections | Action |
|-------|------------|--------|
| **A — sorted_pictures_holder** | #1 only (on .13) | **Keep as master** — best organized |
| **B — PICTURES_GROUPED_SUBJECT_OLD** | #3 (#7 is same) | **Keep one copy, delete the other** |
| **C — Integral300** | #4 (#5 is same) | **Delete SmartDrive copy** — recovery .img is source of truth |
| **D — temp_transfer + misc** | #2, #6, #8, #9, #10 | **Merge into archive** — these are unique |
---
## Proposed Archive Structure
### Target Location: `.13` — `/mnt/ubuntu_storage_3TB/archive/photos/`
Moved from `/mnt/data/` (ran out of space — 1.9T full). Ubuntu storage has **2.2T free**.
```
/mnt/ubuntu_storage_3TB/archive/photos/
├── by_date/sorted_pictures_holder/ ← 373G (year→month, 1990–2023)
├── by_subject/PICTURES_GROUPED_SUBJECT_OLD/ ← 69G (topic-organized)
├── phone_dumps/Photos-001 (1-4)/ ← ~119 phone photos
└── temp_transfer/ ← 2024 events (unsorted)
```
```
/mnt/data/archive/photos/
│
├── by_date/ ← The master date-organized collection
│ ├── 1990/
│ │ └── 01-Jan/
│ ├── 2003/
│ ├── 2004/
│ ├── ... (years 2005–2023)
│ ├── 2023/
│ │ ├── 02-Feb/
│ │ ├── 03-Mar/
│ │ ├── 04-Apr/
│ │ └── 05-May/
│ └── 2024/ ← From temp_transfer (sorted into months)
│ ├── 03-Mar/ → footy_round_5_2024, etc.
│ ├── 04-Apr/ → fin round 7, etc.
│ └── ...
│
├── by_subject/ ← Topic-based albums (no clear dates)
│ ├── baby_harry/
│ ├── wedding/
│ ├── grandma_funeral/
│ ├── bruges/
│ ├── byron_bay/
│ ├── footy/ ← All footy games combined
│ ├── dad_80th/
│ └── ... (others from PICTURES_GROUPED_SUBJECT_OLD)
│
└── phone_dumps/ ← Raw phone exports (keep original names)
└── pixel_6_pro_2023/
├── 2023-05/
└── 2023-06/
```
### Explanation
| Folder | Source | Rationale |
|--------|--------|-----------|
| **`by_date/`** | `sorted_pictures_holder/` + `temp_transfer/` (sorted into dates) | **Primary** — date-organized is the most useful for finding photos. `temp_transfer` events will be sorted into year/month folders |
| **`by_subject/`** | `PICTURES_GROUPED_SUBJECT_OLD/` | Secondary — some photos make more sense grouped by event (weddings, funerals, trips) |
| **`phone_dumps/`** | `Photos-001 (1-4)/` | Raw exports — useful to keep original PXL_ filenames for reference |
---
## Consolidation Steps
### Step 1 — Delete Obvious Duplicates
```bash
# These are identical to PICTURES_GROUPED_SUBJECT_OLD on .13:
# Delete from .27 Back Up drive after confirming .13 copy exists
# /mnt/backup/old_photos_backup/pictures/ ← DELETE SAFELY
# These are already extracted and match recovery .img:
# Delete SmartDrive integral300_backup_20260305/ ← DELETE SAFELY
```
### Step 2 — Build the Archive (on .13)
```bash
# Create archive structure
mkdir -p /mnt/data/archive/photos/{by_date,by_subject,phone_dumps}
# A) Copy sorted_pictures_holder as the foundation of by_date/
cp -a /mnt/data/ALL_TRANFERS/Pictures/sorted_pictures_holder/ \
/mnt/data/archive/photos/by_date/
# B) Copy subject-organized albums into by_subject/
cp -a /mnt/data/ALL_TRANFERS/Pictures/PICTURES_GROUPED_SUBJECT_OLD/* \
/mnt/data/archive/photos/by_subject/
# C) Copy phone dumps
cp -a "/mnt/data/ALL_TRANFERS/Pictures/Photos-001 (1)/" \
/mnt/data/archive/photos/phone_dumps/2023-05/
cp -a "/mnt/data/ALL_TRANFERS/Pictures/Photos-001 (2)/" \
/mnt/data/archive/photos/phone_dumps/2023-05/
# ... etc
# D) Copy temp_transfer events — needs manual sorting into by_date/2024/
cp -a /mnt/data/ALL_TRANFERS/Pictures/temp_transfer/ \
/mnt/data/archive/photos/temp_transfer_to_sort/
```
### Step 3 — Sort `temp_transfer` into `by_date/2024/`
The folder needs manual review. Photos can be filed into:
```
by_date/2024/
├── 03-Mar/ ← footy_round_5_2024, fin round 7
├── 04-Apr/ ← fin round 8, harry round 8
├── 05-May/ ← harry round 9
├── 06-Jun/ ← whatever dates are in there
└── ...
```
Each file has timestamps — use `exiftool` or file timestamps to determine the right month.
### Step 4 — Verify & Clean Up
1. Run `du -sh` on the archive to confirm all photos arrived
2. Spot-check a few folders with `ls`
3. Delete source directories from ALL_TRANFERS **only after confirmed**
4. Unmount recovery .img + delete SmartDrive copy
---
## Additional Photo Sources to Check
| Source | Where | Action |
|--------|-------|--------|
| .35 My Passport `/mnt/hd/data/` | .35 | Check if any photos exist in the data folder |
| Immich database | .35 | Already managed — leave alone |
| Integral300 recovery .img | .27 `/mnt/tempbackup/` | Data is in the archive already — keep for now? |
| **Obsidian attachments** | .27 `~/obsidian/` | These are notes, not photos — keep in vault |
---
## What to Keep vs Delete After Consolidation
| Item | Keep? | Reason |
|------|-------|--------|
| `sorted_pictures_holder/` on .13 | 🗑️ Delete | Moved to archive |
| `PICTURES_GROUPED_SUBJECT_OLD/` on .13 | 🗑️ Delete | Moved to archive |
| `temp_transfer/` on .13 | 🗑️ Delete | Moved to archive |
| `Photos-001 (1-4)/` on .13 | 🗑️ Delete | Moved to archive |
| **old_photos_backup** on Back Up | ❌ Can't delete | NTFS read-only mount |
| **SmartDrive integral300_backup** | ❌ Can't delete | Needs sudo (parent dir root-owned) |
| **Recovery .img** (298G) | 🔵 Keep for now | Safety net — delete later |
| **Immich** | ✅ Keep | Live service |
| `sam rolfe/previous years/` on .13 | ❓ Check | Mixed |
| `grandas_wake/` on .13 | ❓ Check | ~7 photos |
| `.27` Back Up drive | ❓ Repurpose | 158G freed eventually |
## Archive Built — 2026-05-28
**Completed:** Copied all photo collections to `.13` `/mnt/ubuntu_storage_3TB/archive/photos/` — 471G total, 2.2T free remaining
**Could not delete:**
- SmartDrive backup needs `sudo rm -rf /mnt/smartdrive/integral300_backup_20260305/`
- Back Up drive is NTFS read-only — need config change to remount rw
Both source copies on `.13` ALL_TRANFERS still exist — can be deleted after verification.
---
## Discarded Approaches
- **Merging into Immich**: Immich handles ingestion well, but it's running on .35 and the archive target is .13. Better to keep a simple filesystem-based archive.
- **Deleting all duplicates immediately**: Too risky. Only delete after confirming the archive copy is intact.
- **Keeping everything on .27**: The NVMe drive is fast but limited (490G free). .13 has more space (416G free on Data, 2.6T on ubuntu_storage_3TB) and is always-on.

84
100 inbox/Pi Dashboard.md
View File

@@ -1,84 +0,0 @@
# Pi Dashboard — Build Plan & Checklist
## Task Checklist
- [x] **Step 1: dashboard.ts extension** — written, tested, deployed to .13 (.51 offline)
- [x] Event hooks: agent_start, agent_end, tool_call
- [x] Write agent state JSON files atomically (`~/.pi/agent/dashboard/<session>.json`)
- [x] Task tools: register_task, complete_task, list_tasks (todo.txt format)
- [x] NTFY + Apprise notifications on completion
- [x] Session name detection (tmux aware, configurable via PI_SESSION env)
- [x] Tested: state files written correctly, no crashes
- [x] **Step 2: Install companion tools** — Tuxedo (built from source via nix), Hunk (already available)
- [x] Tuxedo: `/home/sam/bin/tuxedo` (NixOS-compatible nix build)
- [x] Hunk: available via nix profile at `/etc/profiles/per-user/sam/bin/hunk`
- [x] **Step 3: Go TUI viewer** — built and deployed to .27 and .13
- [x] Initialize Go module at ~/src/pi-dashboard/ (Go 1.26)
- [x] Local state file reader + TUI table rendering (Bubble Tea + Bubbles table)
- [x] Keyboard controls: Enter (attach), d (Hunk), Tab (Tuxedo), r (refresh), q (quit)
- [x] 2s polling loop
- [x] Built to ~/bin/pi-dashboard (5.4MB static binary)
- [x] Deployed to .13 via scp
- [x] `--list` mode for non-TTY testing, `--help` for usage
- [x] **Step 4: Cross-machine SSH pull**
- [x] YAML config file at ~/.config/pi-dashboard.yaml (remotes: .13, .51)
- [x] SSH remote state reader (shells out to `ssh user@host cat .../*.json`)
- [x] Remote attach (local: `tmux attach`, remote: `ssh -t user@host tmux attach`)
- [x] Viewer deployed to .13
- [ ] **Step 5: Try Herdr**
- [ ] Install Herdr via nix
- [ ] Create test layout on WS 2
- [ ] Run pi inside Herdr, verify dashboard picks it up
- [ ] Evaluate migration vs keeping Zellij
---
## Architecture
```
┌─────────────────────────────────────────────────────────────────┐
│ pi sessions (each machine) │
│ │
│ pi (with dashboard.ts extension) │
│ ├── agent_start → track: status, model, duration, tokens │
│ ├── agent_end → notify: NTFY/Apprise + mark complete │
│ ├── tool_call → track: last tool, tokens consumed │
│ └── register_task / complete_task → write to todo.txt │
│ │ │
│ └── Writes to: │
│ ~/.pi/agent/dashboard/<session>.json (agent state) │
│ ~/.pi/agent/dashboard/tasks/todo.txt (task list) │
│ │
│ On agent_end / error: │
│ └── curl → NTFY server (phone notification) │
│ └── apprise → Slack/Telegram/email (configured routes) │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ pi-dashboard viewer (Go + Bubble Tea) │
│ │
│ Reads: ~/.pi/agent/dashboard/*.json (local + SSH remote) │
│ Renders: agent status table with cost, duration, location │
│ Controls: │
│ Enter → tmux attach -t <session> (jump to agent) │
│ d → hunk diff (review agent's worktree changes) │
│ Tab → launch Tuxedo (task list in todo.txt) │
│ r → force refresh │
│ q → quit │
└─────────────────────────────────────────────────────────────────┘
```
## Key Decisions
| Decision | Choice | Why |
|----------|--------|-----|
| State transfer | SSH pull Phase 1 → HTTP collector on .13 Phase 2 | Zero infra to start, resilient later |
| TUI framework | Go + Bubble Tea | Single binary, fast, portable |
| Web UI | Phase 2, optional | SSH from Termux works for Phase 1 |
| Task board | Use Tuxedo — don't build custom | Already polished with vim keys, phone capture |
| Diff review | Use Hunk — don't build custom | Purpose-built for agent changeset review |
| Notifications | Use NTFY + Apprise — don't build custom | Both already available, extension calls curl/apprise |
| Polling | 2s intervals, no file watcher | Simple, no edge cases |
| Session naming | pi-<role> (pi-work, pi-explore) | Consistent jump target |
| Herdr | Try alongside, no special integration | Dashboard is multiplexer-agnostic |

25
100 inbox/Pi Subagent Integration.md
View File

@@ -1,25 +0,0 @@
# Agent Integration Test
## Test Items
- [ ] Sub-agent spawns and returns result
- [ ] Widget shows agent activity
- [x] Background agent completes and notifies (2026-06-13)
- [x] /agents command shows agent types (2026-06-13)
## Pi-Subagents Architecture Analysis (2026-06-13)
The pi-subagents system is a multi-agent orchestration framework built on an RPC-based subagent protocol. It provides a structured execution environment where specialized agents can be spawned, steered, and composed into workflows. Below is an architectural breakdown of its core subsystems.
**Agent Types & Specialization.** The system maintains a roster of agent types — including `obsidian`, `Explore`, `research`, `coder`, `devops`, `general-purpose`, and `meta-subagent` — each with distinct model assignments and tool access profiles. Agent types are defined declaratively in the agent roster, specifying which model (e.g., `sonnet`, `haiku`, `4o-mini`) drives the agent and which tool subsets it can invoke. This allows the system to route tasks to appropriately-capable agents: lightweight types like `Explore` use faster, cheaper models for browsing, while `coder` and `devops` types get more capable reasoning models with development tool access.
**Background Execution Model.** Agents support two execution modes: foreground (sequential, caller blocks on result) and background (parallel, caller receives an agent ID immediately). Background agents are spawned via `task_spawn` and tracked by the subagent manager. The caller can poll for completion or await notification — this test note itself verified that background agents complete and signal their parent. The background model is critical for parallelizing independent work: data gathering, research, and code generation can proceed concurrently, with results merged later.
**Steering & Resumption.** A distinguishing feature is mid-execution steering. A running background agent receives new instructions via `steer_subagent`, allowing the parent to correct course, inject context, or redirect focus without restarting. Completed agents can also be resumed via the `resume` parameter, re-entering execution with fresh instructions while retaining prior context. This enables iterative refinement workflows — e.g., having an agent draft code, then resuming it to apply review feedback.
**Task List Integration.** The task system (TaskCreate/TaskUpdate/TaskList/TaskExecute) provides structured work management. Tasks carry status (pending/in_progress/completed/deleted), dependencies (blocks/blockedBy), owners, and optional agent type annotations. TaskExecute spawns matching pending tasks as subagents, enabling declarative workflow definition: create a task graph, then execute it and let the system resolve dependencies and dispatch agents automatically.
**Isolation Mode.** For file-modifying operations, agents can be launched with an isolation flag that creates a temporary git worktree. Each agent operates on its own sandboxed copy of the repository, making parallel edits safe. On completion, changes can be reviewed cleanly via diff before applying. The worktree is automatically cleaned up after the agent finishes, preventing accumulation of stale working directories.
**Memory & Context Persistence.** The memctx subsystem provides durable memory across sessions. Agents can save observations, decisions, actions, runbooks, and session summaries via `memctx_save` with appropriate type tags. Retrieval supports three modes: `keyword` (BM25, fast), `semantic` (embedding-based, ~2s), and `deep` (hybrid with reranking, ~10s). The Memory Gateway Brief mechanism injects relevant context at session start, and agents can search memory mid-execution to avoid repeating prior work.
**MCP Gateway.** External tool access is mediated through an MCP (Model Context Protocol) gateway. Agents can connect to MCP servers, list tools, describe parameters, and call tools with JSON arguments. This abstracts away the transport layer (stdio, HTTP, WebSocket) and provides a uniform interface to databases, browsers, filesystems, and other external services. The gateway supports lazy connection — servers are connected on first tool use — and auto-refreshes metadata.

128
100 inbox/Tools to try with AI.md
View File

@@ -1,128 +0,0 @@
---
created: 2026-06-27 12:17
modified: 2026-06-27 12:17
type: note
tags:
- ai
- ai-agents
- tool
- tools
aliases: []
---
# [[Tools to try with AI]]
| Repository / Project Name | GitHub Repository URL | Description |
| :--- | :--- | :--- |
| **OpenMontage** | [calesthio/OpenMontage](https://github.com) | Text-to-video AI editor |
| **codebase-memory-mcp** | [DeusData/codebase-memory-mcp](https://github.com) | Agent context memory |
| **timesfm** | [google-research/timesfm](https://github.com) | Time-series forecasting model |
| **Zapier MCP** | [zapier/zapier-mcp](https://github.com) | App integration gateway |
| **peerd** | [notasithlord/peerd](https://github.com) | Local browser agent |
| **FluidVoice** | [altic-dev/FluidVoice](https://github.com) | Local dictation tool |
| **birdclaw** | [steipete/birdclaw](https://github.com) | Clean X reader |
| **worldmonitor** | [koala73/worldmonitor](https://github.com) | Global event dashboard |
| **penpot** | [penpot/penpot](https://github.com) | Open-source Figma alternative |
| **voicebox** | [jamiepine/voicebox](https://github.com) | Local voice cloner |
| **system_prompts_leaks** | [asgeirtj/system_prompts_leaks](https://github.com) | AI prompt repository |
| **Agent-Reach** | [Panniantong/agent-reach](https://github.com) | Social media connector |
| **ai-berkshire** | [xbtlin/ai-berkshire](https://github.com/xbtlin/ai-berkshire) | Turn Claude Code into a value-investing research team. |
| **ponytail** | [DietrichGebert/ponytail](https://github.com/DietrichGebert/ponytail) | Make AI coding agents solve tasks with the simplest code possible. |
| **inbox-zero** | [elie222/inbox-zero](https://github.com/elie222/inbox-zero) | A self-hostable AI email assistant for organizing and drafting replies. |
| **design.md** | [google-labs-code/design.md](https://github.com/google-labs-code/design.md) | Give AI agents a reusable design system so outputs match your brand. |
| **no-mistakes** | [kunchenguid/no-mistakes](https://github.com/kunchenguid/no-mistakes) | Add an AI safety gate before code reaches your team's repo. |
| **ai-website-cloner-template** | [JCodesMore/ai-website-cloner-template](https://github.com/JCodesMore/ai-website-cloner-template) | Rebuild an existing site as a clean modern codebase. |
| **lingbot-map** | [Robbyant/lingbot-map](https://github.com/Robbyant/lingbot-map) | Reconstruct a 3D scene from streaming camera frames. |
| **free-for-dev** | [ripienaar/free-for-dev](https://github.com/ripienaar/free-for-dev) | A huge maintained list of free developer tools and service tiers. |
| **orca** | [stablyai/orca](https://github.com/stablyai/orca) | Run multiple AI coding agents in parallel from one desktop environment. |
| **claude-video** | [bradautomates/claude-video](https://github.com/bradautomates/claude-video) | Give Claude the ability to watch any video. |
| **notebooklm-py** | [teng-lin/notebooklm-py](https://github.com/teng-lin/notebooklm-py) | Unofficial Python API and agentic skill for Google NotebookLM. |
| **obsidian-skills** | [kepano/obsidian-skills](https://github.com/kepano/obsidian-skills) | Agent skills for Obsidian — teach your agent to use Obsidian CLI and open formats. |
| **impeccable** | [pbakaus/impeccable](https://github.com/pbakaus/impeccable) | The design language that makes your AI harness better at design. |
| **pg_durable** | [microsoft.github.io/pg_durable](https://microsoft.github.io/pg_durable) | PostgreSQL crashproof functions. |
| **DuckDB** | [duckdb/duckdb](https://github.com/duckdb/duckdb) | Embedded analytical SQL database for high-performance data processing. |
| **BGS Stack** | [Obsidian note →](obsidian://open?vault=obsidian&file=200%20projects%2F210%20AI%20Resume%2FThe%20Modern%20Web%20Architecture%20Landscape%20Beyond%20the%20React%20Monopoly) | Go + HTMX + SQLite — the premier AI-friendly web architecture. |
| **last30days-skill** | [mvanhorn/last30days-skill](https://github.com/mvanhorn/last30days-skill) | AI agentic search tool for real-time social signals and community consensus. |
### pg_durable
pg_durable is a new open-source PostgreSQL extension that runs durable, crash-proof workflows right inside the database. The queue, worker, retry logic, and crash recovery you'd normally hand-build collapse into a few lines of SQL.
If you've been running Temporal, cron, or a background worker just for durable execution, watch this first.
📺 [pg_durable — Crashproof PostgreSQL workflows](https://www.youtube.com/watch?v=4Lmqvn_yz-c)
### DuckDB
DuckDB is an open-source, embedded analytical database that runs inside your application process — no server needed. It combines the lightweight simplicity of SQLite with the analytical speed of a cloud data warehouse like Snowflake.
**Key capabilities:**
- **Columnar storage** — reads only the columns you query, minimising disk and memory usage.
- **Vectorised execution** — processes data in CPU-cache-sized chunks (2,048 rows at a time) for maximum hardware efficiency.
- **Direct file querying** — queries Parquet, CSV, and JSON files directly on disk or in cloud storage (S3) without importing.
- **Rich integrations** — zero-copy data exchange with Pandas, Arrow, Polars, and R dataframes.
- **Advanced SQL** — Postgres-compatible dialect with window functions, complex joins, and nested data types.
### BGS Stack (Go + HTMX + SQLite)
The BGS Stack is the premier AI-friendly web architecture — a server-driven alternative to React SPAs built with **Go**, **HTMX**, and **SQLite**. It eliminates `node_modules`, build pipelines, and client-side state management, replacing them with a single linear backend loop that LLMs excel at generating.
Why it's optimised for AI coding:
- **Single-loop context** — one Go function reads from SQLite and returns HTML. No fragmented useState/useEffect/API layer to track across paradigms.
- **Deterministic HTML** — LLMs generate clean HTML and server routes far more reliably than complex React component hierarchies.
- **Fewer moving parts** — no Webpack, Vite, or bundle config for an AI agent to break. Bugs stay contained in one Go file or template.
📄 [Full breakdown — The Modern Web Architecture Landscape Beyond the React Monopoly](obsidian://open?vault=obsidian&file=200%20projects%2F210%20AI%20Resume%2FThe%20Modern%20Web%20Architecture%20Landscape%20Beyond%20the%20React%20Monopoly)
### last30days-skill
last30days-skill is an open-source AI agentic search tool for platforms like Claude Code and Cursor. It focuses on real-time social signals and community consensus over the past 30 days, aggregating data from Reddit, X, and YouTube to produce curated research briefs that bypass SEO-optimised content.
🔗 [mvanhorn/last30days-skill](https://github.com/mvanhorn/last30days-skill)
# AI Engineering Tools Overview
## 🛠️ Structured Data & Model Control
### Instructor (567-labs)
* **What it is:** A library that patches LLM clients (OpenAI, Anthropic, Gemini) to return strict Python data structures.
* **Why you need it:** Instead of asking an LLM for JSON and hoping it formats it correctly, you define a Pydantic schema. Instructor guarantees the model's output will match that schema perfectly, automatically retrying and feeding errors back to the LLM if validation fails.
* **URL:** https://useinstructor.com
### Outlines (dottxt-ai)
* **What it is:** A library that enforces strict structure at the token generation level for local and API-based LLMs.
* **Why you need it:** Unlike Instructor (which validates data after or during generation), Outlines guides the LLM dynamically. It alters the model's math so it physically cannot choose a token that violates your regex, schema, or choice list, resulting in 100% reliable structure with zero parsing errors.
* **URL:** https://github.com
---
## 🔌 Universal Integration & Routing
### LiteLLM
* **What it is:** A lightweight proxy and SDK that acts as a universal translator for over 100 different LLM APIs.
* **Why you need it:** Every AI provider has a slightly different code structure for API calls. LiteLLM lets you use the standard OpenAI format (`openai.chat.completions.create`) to talk to Anthropic, Bedrock, Cohere, or HuggingFace, while also handling fallbacks, load balancing, and spend tracking.
* **URL:** https://github.com
---
## 🧠 Programming & Optimizing Prompts
### DSPy (Stanford NLP)
* **What it is:** A framework that treats prompt engineering like programming rather than manual "prompt hacking."
* **Why you need it:** Instead of spending hours tweaking strings like "You are an expert...", you write Python modules (e.g., Chain-of-Thought, RAG). DSPy then compiles and automatically optimizes the prompts and few-shot examples based on your evaluation data, similar to how neural networks learn weights.
* **URL:** https://github.com
---
## 🕸️ Data Scraping & Preparation
### Crawl4AI
* **What it is:** An open-source web crawler designed specifically to scrape websites and convert them into data optimized for LLMs.
* **Why you need it:** Standard web scrapers pull raw, messy HTML full of ads and scripts. Crawl4AI extracts the core text, strips the noise, and outputs clean Markdown or structured JSON, making it perfect for feeding live web data into a RAG pipeline.
* **URL:** https://github.com
### Chonkie
* **What it is:** A highly optimized, lightweight text-chunking library designed for Retrieval-Augmented Generation (RAG).
* **Why you need it:** LLMs cannot ingest massive documents all at once; text must be broken down first. Chonkie focuses on speed and accuracy, splitting text intelligently (by tokens, sentences, or semantics) so context is never cut in half mid-sentence before being embedded.
* **URL:** https://github.com