# Shaun Zhang — full content This is the full, flat content view for agents. It concatenates every project in the catalog. The summary version is at /llms.txt. The operating manual is at /skill.md. ## Profile - name: Shaun Zhang - role: Chief AI Solution Officer at Think Technologies - also: Co-lead, AI Collective Detroit - location: Detroit, Michigan, USA - email: szhang1@me.com - booking: https://calendar.app.google/aGC4un1y9QPvgVqx7 - github: https://github.com/ShotgunZZ - linkedin: https://www.linkedin.com/in/shaunzhangsg - youtube: https://www.youtube.com/@ShaunLearnsAI - org: https://www.think-technologies.com/ - community: https://www.aicollective.com/chapters/detroit Civil engineer turned harness-builder. Ships production AI for SMB and enterprise. Construction, then architect-track and strategy roles, then pivoted to AI systems in 2023. NUS MBA, Yale MAM (STEM). At Think Technologies, builds agents, harnesses, and the glue that makes them useful inside a real business. --- ## Agentic Second Brain — A vault an AI operates, not just a folder of notes - slug: agentic-second-brain - type: wip - tilt: engineer - status: wip - year: 2026 - stack: Obsidian, Claude Code, MCP, semantic search, Python - source: (private) - demo: https://www.youtube.com/watch?v=4AxSc9Nf7IE A personal knowledge base where an AI agent does the filing — searching, distilling, linking, and capturing across email, calendar, Drive, Notion, and a local vault, with capture on the move over a chat bot. Semantic search over everything; the human curates, the agent operates. ## Problem Notes, email, calendar, Drive, and a dozen chat threads each hold part of the picture — but none of it connects, and keeping any of it organized by hand doesn't scale. A folder of markdown is a graveyard unless something actively files and links it. ## Approach Treat the vault as a system an agent *operates*, not a folder a human maintains. An AI agent is the librarian: it searches the vault first, then live sources, captures new material as structured notes with the right metadata, links them to what already exists, and keeps the indexes current. A chat bot handles capture on the move; a scheduled sync folds in anything new from the connected services. The human curates and decides; the agent does the filing. ## Stack An Obsidian vault as the store, an AI coding agent as the operator, MCP connectors for email / calendar / Drive / Notion, and a semantic-search layer so retrieval works by meaning, not just keywords. A periodic sync sweeps the live sources; captures arrive over a chat bot and get distilled in. ## What shipped In daily use: search-first retrieval across the whole vault, automated capture-and-link, a multi-source sync, and a mobile capture path. The agent maintains folder indexes and cross-links as it works. ## What's next Tighten the capture-to-distillation loop and move more of the routing into reusable skills. --- ## Brokerage Matchmaker — CRM and matchmaking engine for a commercial brokerage - slug: brokerage-matchmaker - type: anon-client - tilt: engineer - status: wip - year: 2026 - stack: Monday.com - source: (private) A commercial real-estate brokerage ran client intake on web forms and tracked deals in spreadsheets and on personal laptops. The build replaces that with a CRM and a scoring engine that ranks property matches against each tenant's intake. ## Problem A commercial real-estate brokerage took in tenant requirements through a web form, then cross-referenced them by hand against listing portals and personal networks before presenting a shortlist. Deal data lived in a spreadsheet and on individual laptops — no shared system, and no view into where applicants dropped off. ## Approach Lead with the highest-pain workflow instead of the whole pipeline. Digitize intake first, then replace the spreadsheet with a CRM, then build a matchmaking index that scores tenant requirements against a property dataset and auto-ranks the best fits for the sales team. ## Stack Monday.com for the CRM and the structured intake form; a scoring layer that ranks on space type, square footage, outdoor space, years in business, headcount, and buildout needs. ## What shipped Client intake is digitized and flowing into a shared workspace. The CRM — with drop-off tracking — and the matchmaking scoring engine are in active build. ## What's next A map-based view layering foot traffic, demographics, and anchor employers over candidate sites, deferred behind the CRM and matchmaking work. --- ## QuotaBar — Live AI quota windows in the macOS menu bar - slug: quotabar - type: wip - tilt: engineer - status: wip - year: 2026 - stack: Swift, SwiftUI, SwiftPM, MenuBarExtra, FSEvents, swift-testing - source: (private) A native SwiftUI menu-bar app that shows how much headroom is left across three AI subscriptions, refreshed by local agent activity instead of a fixed timer. Built by an agent crew, with every diff reviewed by a model from a different vendor than the one that wrote it. ## Problem I run three AI coding subscriptions with three separate rolling usage windows, and no vendor pushes a usage signal. Checking headroom meant opening three dashboards or running a CLI by hand — usually right after a long build had already eaten a weekly limit. A local HTML dashboard on a timer answered the question, but only as often as the timer fired, and it was one more surface to keep alive. ## Approach A menu-bar app that reads a local quota CLI and refreshes when there is a reason to. No vendor offers a push channel for subscription quota, so "live" means polling at the right moments: file-level watchers on the local agent session directories treat agent activity as the trigger, refreshing on the leading edge of a burst and once more after it settles. The watchers see path metadata only — no session file is ever opened or read. Two rules kept it honest. A coalescing floor, so a two-hundred-write burst produces one refresh instead of two hundred. And no invented numbers: vendor figures lag local writes, so a single delayed trailing read closes the gap at fifteen seconds — three times the longest settle time I measured — and a pool whose vendor exposes no session window contributes no session figure at all, rather than a zero that would read as full headroom. ## Stack Swift and SwiftUI on SwiftPM, MenuBarExtra for the bar item, FSEvents for the activity watchers, swift-testing for the suite. It compiles with the Command Line Tools alone — no Xcode install — so the build reproduces from a shell. ## What shipped Running in my own menu bar. The bar carries one number plus a gauge glyph rendering that same figure; the panel holds per-pool windows, reset times, staleness, and sign-in rows for pools that aren't authenticated. 80 unit tests cover the refresh state machine, the coalescing guarantee (verified with synthetic two-hundred-event bursts), and the rendering rules. It was built by an agent crew rather than by hand: a Claude lead planning and orchestrating, a Codex executor writing the diffs, a Grok reviewer checking them. Every change had to pass review by a model from a different vendor than the one that wrote it — cross-vendor review caught real defects that a same-model pass waved through. ## What's next Auto-start as a login item, a notification at a headroom threshold, and non-AI pools once the shape generalizes. --- ## Storytelling engine — A community-media pipeline with eval-graded quality gates - slug: storytelling-engine - type: anon-client - tilt: multi - status: wip - year: 2026 - stack: TypeScript, Next.js, Anthropic Claude, Supabase, Vercel, eval harness - source: (private) An AI storytelling pipeline that drafts member-success stories and grades every draft on voice, grounding, and sourcing before an editor — and the member — approve it. ## Problem A community storytelling nonprofit wanted to scale long-form member-success stories without losing the founder's voice, fabricating details, or burying editors in unstructured drafts. The bottleneck wasn't the writing — it was grading and gating quality at volume. ## Approach A pipeline where every draft is scored before a human sees it: an 8-point pass/fail check (all story blocks present and ordered, self-reported figures labeled, no fabricated claims, verified public data points) plus a 5-point rubric (voice fidelity, narrative clarity, grounding, dignity, movement significance). Drafts below threshold get kicked back with the failing criteria. It never publishes on its own — an editor approves, then the member explicitly approves, before anything goes live. ## Stack A custom Next.js app with Supabase (Postgres + Auth) and Google login, Anthropic Claude for both generation and as the eval judge, deployed on Vercel. The pass/fail and rubric criteria live in version control next to the prompts; a CLI regression runner grades the whole submission bank end-to-end. ## What shipped A beta batch of eleven member stories ran end-to-end: voice fidelity averaged 4.7/5, opening scenes landed in ten of eleven, and there were zero fabricated metrics across the batch even where intake data was missing. That last result surfaced the real risk — the model reconstructs plausibly from gaps — so a hard intake gate and explicit member approval became mandatory. The client green-lit a pilot conditional on four gates: intake validation, automated quantitative checks, member approval, and press-tier source traceability. ## What's next Build the four gates, then move from beta to the live pilot. --- ## Ticket-swap platform — Members-only ticket-swap with admin-moderated matching - slug: ticket-swap - type: anon-client - tilt: commercial - status: wip - year: 2026 - stack: Next.js, React, TypeScript, Supabase, Resend, Google Cloud Run - source: (private) A members-only platform where a closed community posts and claims event tickets, with admin-moderated matching. ## Problem A closed community of event-goers swapped tickets through a spreadsheet and a group chat: unverified members, double-allocations, and growing admin overhead on every event. ## Approach A members-only platform — vetted signup with manual approval, members post "have" and "want" listings, and an admin moderates matches rather than auto-matching, which keeps the MVP simple and the community curated. Magic-link login, no passwords. ## Stack Next.js (App Router) with React and TypeScript, Supabase (Postgres + Auth) with row-level security, Resend for email, deployed on Google Cloud Run with CI on push. ## What shipped The member and admin portals are built and signed off: application review, verification uploads, listing management, and admin-moderated matchmaking with status tracking. The client is growing membership privately ahead of a public launch. ## What's next Payment integration and an optional AI match-suggestion layer to reduce the manual admin effort. --- ## Live Meeting Scribe — Live transcript, notes, and diagram from your mic - slug: live-meeting-scribe - type: oss - tilt: engineer - status: shipped - year: 2026 - stack: Python, FastAPI, AssemblyAI, OpenRouter, gpt-4o-mini, Mermaid - source: (private) A local web app that listens to a meeting and renders a live transcript, consolidated notes, and an evolving flow diagram as you talk. No accounts, no database — it runs entirely on localhost. ## Problem Notetakers summarize after the meeting. Reading a transcript later does nothing for you *during* the conversation — when you actually want to see the structure forming and catch the action item as it's assigned. ## Approach A local web app that transcribes the mic in real time and runs two separate model passes. One consolidates the talk into notes — open questions, decisions, action items. The other draws an evolving flow diagram of how the topics connect. The diagram reads from the abstracted notes rather than the raw transcript, so it stays structural instead of noisy, and warm-up topics drop out once the conversation pivots. ## Stack FastAPI WebSocket backend, AssemblyAI streaming transcription with diarization, a gpt-4o-mini notes analyzer and a Haiku diagram model via OpenRouter, and a vanilla-JS front end using an AudioWorklet and Mermaid. No build step, no database — it runs on localhost. ## What shipped End-to-end on localhost: a live transcript, a notes panel, and a Mermaid diagram that all update as you speak, plus one-click export of notes, diagram, and transcript. Backed by a self-test harness of 116 tests that drives the prompts through injected transcripts with an LLM-as-judge eval. ## What's next Tighter speaker attribution on direct-address handoffs ("Marcus, can you draft this?"), and an auto-iteration mode where the harness reads its own scorecard and proposes prompt changes. --- ## VoxTail — The notetaker that remembers people - slug: voxtail - type: oss - tilt: engineer - status: wip - year: 2026 - stack: FastAPI, SpeechBrain, Pinecone, AssemblyAI, OpenAI, PWA - source: https://github.com/ShotgunZZ/voxtail - demo: https://www.youtube.com/watch?v=9-zidg9YeZc An open-source AI notetaker that learns speakers' voices across meetings, built on AssemblyAI plus a Pinecone voice-print store. ## Problem Notetakers were expensive subscriptions, hardware-locked, or labeled people "Speaker 1 / Speaker 2." None carried a speaker's identity across meetings — every session started from scratch. ## Approach A persistent voice-print library: enroll a speaker once from a meeting recording, and every later transcript gets named diarization automatically. The library improves as it sees more audio. It's a web app, so there's no hardware to buy. ## Stack FastAPI backend; SpeechBrain for speaker embeddings; Pinecone as the voice-print store; AssemblyAI for transcription and OpenAI for summaries (bring your own API keys); a PWA front end for mobile recording. Deploys on Railway. ## What shipped Open-sourced in early 2026. Speaker matching, meeting-based enrollment, and the mobile PWA are done; per-speaker LLM summaries and a one-click Railway deploy are in progress. ## What's next Speaker-attributed summaries ("Sarah committed to X by Friday") and meeting-platform integrations (Zoom, Teams, Meet). --- ## Commerce unifier — BigCommerce + eBay + QuickBooks, kept in sync - slug: commerce-unifier - type: anon-client - tilt: engineer - status: wip - year: 2026 - stack: BigCommerce, eBay, QuickBooks, webhooks - source: (private) An integration that keeps a retailer's storefront, marketplace, and accounting in sync — inventory, sales tax, and listings. ## Problem A specialty retailer ran a storefront, a marketplace, and their accounting as three disconnected systems. Inventory drifted between them, sales tax landed in the wrong account, and every listing's custom fields (size, offset, finish) were rebuilt by hand. ## Approach Wire the three systems together around clear rules instead of a big rebuild: inventory deducts on a booked sale, sales tax maps to the right ledger account, and listing custom-fields are templated and bulk-loaded. Existing marketplace listings stay manual on purpose, to preserve years of sales history. ## Stack BigCommerce (storefront), eBay (marketplace), and QuickBooks (accounting) tied together via their connectors and webhooks, with a CSV bulk-load path for listing custom fields. ## What shipped Inventory-to-accounting sync is live; tax mapping and a paid multi-channel marketplace connector are being finalized. Fixed a webhook edge case that created phantom accounting entries on failed payments. ## What's next Finish the marketplace automation for new listings and hand the business-rule decisions back to the retailer. --- ## Festival Intake Validator — An AI layer that cleans messy event submissions - slug: festival-intake-validator - type: anon-client - tilt: engineer - status: shipped - year: 2026 - stack: - source: (private) A nonprofit's annual design festival took 90+ event submissions a year through a web form, many incomplete or off-spec. This POC put an AI validation layer in front of intake — standardizing and flagging submissions before they reached downstream systems. ## Problem A nonprofit that runs a city-wide design festival collected 90+ event submissions a year through a web form. They came in incomplete or off-spec — weak descriptions, images that missed standards, missing fees — and staff cleaned each one by hand before it could flow into the CRM, email, and the public events gallery. None of those systems talked to each other. ## Approach Map the full intake-to-go-live pipeline, find the highest-pain step, and prove it could be automated before scoping the whole thing. The wedge: an AI layer on the intake form that validated and standardized each submission at the door, flagging incomplete or off-spec entries before they reached anything downstream. ## Stack A proof-of-concept built on top of the existing web intake form, with an AI validation and standardization layer sitting in front of the downstream CRM, email, and gallery tools. ## What shipped A validated POC: the AI intake layer cleaned and standardized messy submissions in a live demo, run against the festival's real intake. ## What's next The full pipeline integration — fee collection, venue matching, CRM sync, and gallery publishing — is mapped and scoped; the POC proved out the highest-pain step first. --- ## General Download Renamer — A Chrome extension for renaming downloads with page context - slug: auto-renamer - type: oss - tilt: engineer - status: shipped - year: 2026 - stack: JavaScript, Chrome Manifest V3, HTML, CSS - source: https://github.com/ShotgunZZ/General_Download_Renamer - demo: https://chromewebstore.google.com/detail/general-download-renamer/pbjlahgadmnhacddhincanlcffjjjclb A published Chrome extension that renames downloads using customizable patterns and smart placeholders. ## Problem Default download filenames are garbage — `download (47).pdf`, `IMG_2241.png`. A folder of those is a hostile place to search through weeks later. ## Approach A Chrome extension that catches the download and renames it from a rule set: smart placeholders (`{domain}`, `{date}`, `{time}`, `{originalFilename}`, `{category}`, `{extension}`), custom regex placeholders with text and counter types, and a floating preview that shows the resolved name before the file is saved. ## Stack Plain Manifest V3: vanilla JavaScript, no framework, no build step. HTML + CSS for the options UI, a small placeholder DSL, and safe filename sanitization. A few hundred lines — easier to audit than to bundle. ## What shipped Published on the Chrome Web Store (v1.3.0): drag-and-drop placeholder ordering, automatic file categorization, custom separators, and the live preview panel. ## What's next Cross-browser support and an exportable rule pack so teams can share conventions. --- ## Meeting Notes Pipeline — No-bot meeting transcription and summary - slug: meeting-notes-pipeline - type: wip - tilt: community - status: wip - year: 2026 - stack: n8n, AssemblyAI, gpt-4o-mini, SMTP, Google Drive - source: (private) - demo: https://www.youtube.com/watch?v=z5Jmug9V9Bw An n8n pipeline that turns a weekly community meeting's recording into emailed notes — triggered by the file upload, with no bot in the call and cents of API cost per run. ## Problem A weekly community meetup wanted shared notes without paying for a per-seat notetaker or letting a bot sit in every call. The off-the-shelf options all wanted a bot in the meeting, hit usage caps, or needed a subscription. ## Approach Trigger off the recording instead of the call. When a new meeting recording lands in a Drive folder, a workflow downloads it, transcribes it, summarizes it into topics, action items, and announcements, and emails the result to attendees. No bot, no per-seat cost. ## Stack n8n orchestrates the flow; AssemblyAI handles transcription; a small LLM writes the structured summary; SMTP delivers the email. Large recordings stream from disk so the box doesn't choke on big files. ## What shipped The workflow is built end to end — Drive trigger, download, transcription, summarization, and email delivery wired together as an n8n blueprint. The demo video shows the voice-memo variant of the same pipeline — same trigger-off-the-recording pattern, different capture source. ## What's next Final credential wiring and activation against the live meeting folder. --- ## Never-Submit Autofill Engine — An MV3 form-fill engine that never submits - slug: never-submit-autofill-engine - type: wip - tilt: engineer - status: wip - year: 2026 - stack: Manifest V3, Chrome Extensions API, LLM, h2 - source: (private) A Chrome extension that reads a web form's structure, maps every field to saved profile data in one model call, and fills it inside your own browser session — then stops, leaving submit to a human. Built by a three-agent coding pod with cross-model review and a never-submit end-to-end suite. ## Problem Long web application forms are slow and repetitive to fill by hand. The obvious automation — a server-side bot that submits on your behalf — gets blocked by modern identity-layer form detection and, worse, takes the human out of the loop on something you want to read before it goes out. ## Approach A Manifest V3 Chrome extension that runs inside your own browser session. Content scripts (reaching into embedded third-party iframes) read the form's structure; one model call maps each field to your saved profile data; the extension fills the form — and then stops. It never clicks submit; a person always reviews and sends. Because it's a real human session, bot detection is a non-issue by construction. ## Stack Manifest V3 (content scripts + service worker), a single LLM field-mapping pass, and a data layer kept out of version control. Built by a standing three-agent coding pod — a builder, a profile/asset service, and a separate cross-model reviewer that signs off each milestone. ## What shipped A working extension with the fill engine in place and a never-submit guarantee enforced by a black-box end-to-end suite: it runs against real Chromium with a live submit-suppressor and hard-halts on any submit path (~300+ tests). In active development. ## What's next Harden field mapping across more form layouts and finish the optional computer-use fallback for the rare non-DOM widgets. --- ## OpenAI Hackathon Judge — Codex-powered CLI that judges hackathon submissions - slug: openai-hackathon-judge - type: oss - tilt: engineer - status: shipped - year: 2026 - stack: TypeScript, Node, OpenAI Codex SDK, Playwright, yt-dlp, ffmpeg - source: (private) A command-line judge that scores hackathon entries end-to-end — it clones each repo, drives the live demo in a browser, transcribes the demo video, then scores everything against a two-track rubric with Codex and ranks a leaderboard. ## Problem Judging a hackathon by hand doesn't scale or stay consistent — dozens of entries across two tracks, each with a repo, a live demo, and a video, all needing the same rubric applied fairly and fast. ## Approach A CLI that takes the registration CSV and judges every entry end-to-end. For each one it routes to the right track rubric, clones the GitHub repo when there is one, drives the live URL in a real browser (screenshots, console and network errors, a few safe clicks), and turns the demo video into text — host captions first, an audio speech-to-text fallback when there are none. It hands that evidence to Codex, which scores each criterion against fixed band anchors. A broken submission is logged and skipped, never aborting the run. ## Stack A TypeScript/Node CLI on the OpenAI Codex SDK, Playwright for live-demo probing, csv-parse for tolerant CSV ingest, and yt-dlp + ffmpeg + speech-to-text for video transcription. ## What shipped Used to judge the OpenAI × AIC Business Hackathon in Detroit (June 2026): every registration-CSV entry scored against a two-track, 100-point rubric anchored on one question — would a real SMB operator pay for this, deploy it this week, and actually use it? Output is a per-submission report plus a ranked leaderboard. ## What's next Reusable for any future hackathon by pointing it at a new registration CSV. --- ## Reporting Deck Automator — Spreadsheets to a finished slide deck, automatically - slug: reporting-deck-automator - type: anon-client - tilt: engineer - status: shipped - year: 2026 - stack: Python, Node.js, pptxgenjs, Playwright, Sharp, Power Query - source: (private) A pipeline that turns operational spreadsheets into polished, account-branded reporting decks — replacing hours of manual slide-building for recurring account reviews. ## Problem A facilities-services team rebuilt the same account-review decks by hand every reporting cycle — copying operational numbers (inspections, service requests, quotes) out of spreadsheets into dozens of formatted slides, per site, across several national accounts. ## Approach A pipeline that reads the master and per-site spreadsheets, computes the reporting metrics, renders each view as an HTML dashboard, screenshots those in a headless browser, and assembles them into a finished, consistently-branded slide deck. The operator runs one command instead of editing slides. ## Stack A Python analytics step (with Power Query for the source sheets), a Node.js deck builder using `pptxgenjs`, Playwright to render HTML dashboards into slide-ready images, and Sharp for image processing — driven by a templated slide library so every deck looks the same. ## What shipped An end-to-end build script that produces the full deck straight from the spreadsheets, covering several national accounts with per-site breakdowns — turning a recurring slide-building chore into a single run. ## What's next Push more of the layout into the templates so a new account format needs no code changes. --- ## Self-Critiquing Content Agent — A LangGraph agent that drafts, critiques, and revises itself - slug: self-critiquing-content-agent - type: oss - tilt: engineer - status: shipped - year: 2026 - stack: Python, LangGraph, LangChain, Claude, Tavily, LangSmith, pytest - source: (private) An autonomous agent that researches a topic, drafts a post, scores its own draft, and loops to revise — then pauses for human approval before anything is final. Built on LangGraph as a critique-and-revise state machine. ## Problem Posting consistently on a professional channel eats time and drifts off-voice. Naive "let an LLM write it" output is generic, repeats angles you've already used, and posts itself with no one in the loop. ## Approach An autonomous agent built as a state machine: a research node pulls fresh angles from the web, a draft node writes the post, a critique node scores the draft 1–5, and a conditional edge loops back to revise (up to twice) until the score clears the bar — then it stops and hands off to a human to approve or edit before anything publishes. Past posts are persisted so the agent doesn't repeat itself. ## Stack Python and LangGraph — a `StateGraph` wiring research → draft → critique → revise → human-review — with Claude for drafting and self-critique, Tavily for web research, LangSmith for tracing, and a pytest suite that mocks the model calls. ## What shipped A working agent with the full critique–revise–interrupt loop and test coverage. The human-in-the-loop gate (LangGraph's `interrupt()`) means nothing goes out unreviewed. ## What's next Generalize beyond a single content domain and add a small scheduler so approved drafts queue instead of needing a live session. --- ## VirtuMic — A Swift macOS virtual mic with noise-gate DSP, on Homebrew - slug: virtumic - type: oss - tilt: engineer - status: shipped - year: 2026 - stack: Swift, AVAudioEngine, CoreAudio, launchd, Homebrew - source: https://github.com/ShotgunZZ/virtumic Open-source macOS audio daemon — a Swift virtual microphone with noise-gate DSP, distributed via Homebrew. ## Problem The macOS virtual-mic options were paid, abandoned, or shipped as kernel extensions that broke on every OS update. I wanted a low-latency virtual input device with a noise gate — and a clean install and update path that didn't fight the system. ## Approach A small Swift daemon that builds a CoreAudio aggregate device and runs an AVAudioEngine processing chain with a custom noise-gate AUAudioUnit. No kext, no signed-installer dialog, no preference pane. It runs under launchd and installs as a Homebrew cask, so updates land via `brew upgrade`. ## Stack Swift with AVAudioEngine and CoreAudio for the audio path and a custom AUAudioUnit for the gate; launchd for lifecycle; a Homebrew cask (depends on BlackHole) with GitHub Actions building releases on every tag. ## What shipped Open-sourced and installable via Homebrew — scaffold through public release: config loading with validation, the noise-gate DSP unit, CoreAudio device enumeration, a CLI with signal handling, and the cask pipeline. ## What's next A small companion menu-bar app for level monitoring. Optional — the daemon is the product, the UI is convenience.