The PromptMates squad keeps cookin’. Here are two builds from this week that I think are worth a peek because they’re a good look at what’s possible right now.
Aston Rankins: The Batcave
The why: Aston had two things bugging him. All the knowledge he’d built up about his professional relationships was living in his head or scattered across random docs, nothing tying it together. And every time he needed market intel or a screen kit, he was pinging Claude or jumping into another app to go get it. No single place to just pull what he needed.
The how: He split it into two pieces. A Chief of Staff to hold the “brain,” built on Obsidian using wikilinks to connect everything about his relationships so the right info surfaces on its own instead of him hunting for it. And a dashboard, his single visual source of truth for recommendations, market intel, and screen kits, so he’s not bouncing between apps or pinging Claude every time he needs something.
Tech stack: Obsidian for the knowledge base, Claude Code for building out the dashboard and visualizations, synthetic data (Claude generated a fake “Gotham” dataset) to test it with a live feel before real data gets wired in.
Where it’s headed: Aston was honest that he’d never been a “dashboard person” before this. He didn’t know what good even looked like for himself, so he had to figure that out first, with Claude alongside him the whole way. That’s a lesson here- sometimes the hardest part of building a tool isn’t the tech, it’s figuring out what you actually want it to do for you. He’s still refining the research layer and competitor intel before wiring it all together, and plans to explore Claude Design once the foundation is solid.
Bryan Hong: Talent One
The why: Bryan built 11 recruiting agents and had them running through a fairly technical workflow, until a TA buddy told him “if your tool requires a GitHub account, it’s already failed.” Now- I don’t necessarily agree with that but it’s one of those things where everyone has their own opinion (there is no right or wrong on this one). And regardless of your take, the overall point is is that Bryan ultimately felt he was overengineering. And when that happens, you need to press pause and assess options. Which is just what he did.
The how: He stripped out the complexity, ditched n8n, and rebuilt the whole thing as a Claude plugin. Upload it to Claude Cowork, answer five setup questions, then type a single line like “Run Talent One for a Senior ML Engineer.” Thirty minutes later you get a full hiring package: role brief, JD, talent map, sourcing strategy, outreach campaign, HM calibration, and screen script, delivered in clean HTML.
Tech stack: Claude Cowork as the delivery layer, a Claude plugin packaging up what used to be 11 separate agents, no external workflow tool required.
Where it’s headed / the lesson: The core design rule is: every number in the output carries a receipt, sourced, estimated, or internal, so if the data can’t back a claim you get a labeled gap instead of a confident hallucination. Need one document instead of the full package? Just ask for it. Comp band changes? It re-renders in just a few seconds. Bryan’s real lesson was less technical and more about audience: what’s the need, what’s the cleanest way to get their, build for who’s actually going to use it. And I think that’s important because I see alot of folks building systems that aren’t going to be able to be used by their audience because its too technical to control.