<Projects>

Projects

Things I've built — open source tools, experiments, and consulting portfolio pieces.

Claude Code · active

AI Agent Minder

A lightweight project governance layer for Claude Code — slash commands, markdown templates, and minimal hooks that add structured planning and decision tracking without getting in the way.

Claude Code Node.js Markdown Git

Claude Code is powerful out of the box, but it doesn’t have strong opinions about project planning, architectural decisions, or how work should be structured across sessions. AIAgentMinder fills that gap with a small, opinionated layer built entirely from markdown and two tiny Node.js hooks.

What it actually is

A set of template files and slash commands you drop into a project alongside Claude Code:

  • /plan — interview-driven planning session that produces a product brief, defines MVP scope, picks a quality tier, and optionally enables sprint planning
  • /handoff — session-end checkpoint that captures decisions, writes priorities to Claude Code’s native persistent memory, and commits tracked changes
  • DECISIONS.md — architectural decision log; the pattern is to record significant choices with alternatives considered, so you stop re-debating them
  • Sprint workflow (optional) — structured issue decomposition with one branch per issue, per-issue PRs, and state tracked in SPRINT.md
  • Two hooks — an auto-commit on session end (feature branches only), and a post-compaction reorientation that surfaces the active sprint when Claude’s context gets pruned

No database, no external dependencies beyond Node.js, no MCP server. State is plain markdown in your repo.

Why it exists

I kept running into the same friction when using Claude Code for personal projects: good at executing, not great at remembering why things were decided the way they were, or what the shape of the next phase should be. The governance layer I wanted was basically a structured CLAUDE.md plus a couple of conventions — so I extracted it into something reusable.

The project evolves alongside Claude Code itself — when something gets built natively, it gets removed from here. The goal is to stay minimal and focused on what’s genuinely not covered elsewhere.

Current status

Active development. Maintained as a personal tool I use on my own projects — including this site. Check the GitHub repo for current version and changelog.

C# · active

Airdrop Architect

SaaS platform for tracking crypto airdrop eligibility and DeFi points programs — Telegram bot plus web dashboard, built on Azure and C#/.NET.

C# .NET Azure Functions CosmosDB Telegram Bot API Stripe TypeScript React

Keeping up with DeFi airdrop eligibility is tedious. Every protocol has its own points system, its own snapshot schedule, and its own set of qualifying actions — and missing a snapshot means missing the drop. Airdrop Architect automates the tracking so you don’t have to.

What it does

A Telegram bot paired with a React web dashboard. Users connect their wallet addresses, and the platform continuously monitors eligibility across supported protocols — surfacing your current points balances, eligibility status, and upcoming snapshot deadlines. The goal is a single place to answer “am I going to get this drop, and what do I still need to do?”

Key capabilities:

  • Eligibility checking — real-time queries against supported DeFi protocols via their APIs
  • Points tracking — aggregates points/XP balances across programs like EigenLayer, Hyperliquid, Scroll, and Linea
  • Notifications — Telegram alerts for snapshot deadlines and eligibility changes
  • Subscription tiers — free tier for basic tracking; paid tiers ($9–$99/mo) unlock more wallets, protocols, and data history

Architecture

Azure-native: Azure Functions handle the bot webhook and scheduled eligibility polling, Cosmos DB stores user state and historical snapshots with tenant-aware partitioning, Redis caches protocol data to avoid hammering third-party APIs. Stripe and Coinbase Commerce handle subscriptions.

The polling architecture uses Polly for retry/circuit breaker patterns against external protocol APIs — reliability matters when you’re dealing with RPC endpoints that have variable uptime.

Why I built it

Partly because I wanted to use the problem as a forcing function to build a real multi-tenant SaaS on Azure from scratch — not a tutorial, but something with actual payment flows, GDPR compliance, and operational runbooks. Partly because I was doing the tracking manually and it was annoying enough to automate.

It’s also a useful testbed for the kind of event-driven, subscription-based architecture patterns I’ve worked with professionally — just in a domain I own end to end.

Status

Active development. Phase 1 (core bot + eligibility + Cosmos DB) is in progress. Follow the GitHub repo for updates.