StaffEngineer
Deterministic Claude Code skills for a production stack
Start new thread

StaffEngineer - Deterministic Claude Code skills for a production stack

by•
StaffEngineer is a pack of deterministic Claude Code skills that scaffold and wire a production-grade dev stack the same correct way every time — instead of re-prompting Claude each session. Skills run deterministic scripts (e.g. /squidci for CI) over a known toolchain (OrbStack, Doppler, Docker). Free today: squidapp (full-stack scaffold) and squidops (toolchain doctor). The full pack (deploy, observability, real-time, durable workflows) is a one-time purchase you own, not a subscription.

Add a comment

Replies

Best
Maker
📌
Hey PH, I'm Tamas, solo maker. StaffEngineer came out of a simple frustration: every session I'd re-prompt Claude Code to set up the same production stack (CI, deploy, secrets, observability) and it'd do it a little differently each time. So I turned the correct way into deterministic skills that run the same scripts every time. Two are free today - squidapp scaffolds a full-stack app, squidops checks your toolchain - drop your email and you get install instructions. Prompts improvise; skills ship. Two things I'd genuinely love feedback on: (1) which part of your prod setup do you most wish was one deterministic command? (2) does a one-time, you-own-it purchase (vs a subscription) feel right for dev skills? Thanks for taking a look.

Curious how this handles updates when Claude Code itself evolves, since the skills rely on specific toolchain versions. Do you ship patches for new model behavior or is that on me to retest?

Maker

  Great question — it's the core of why these are skills, not prompts.


Two layers:


Model drift: the skills are deterministic scripts — the CLI does the work, Claude just orchestrates. So new model behavior barely touches them. That's the whole "skills ship" bit; a prompt would rot, a script doesn't.


Toolchain + Claude Code changes: that's on us, not you. Versions are pinned, and when Node / a GitHub Action / Prisma / Claude's plugin format moves, we bump, retest, and ship the patch. squidup pulls the latest in place (the marketplace auto-updates too) — you don't retest, you just get the fix.


So: a maintained product, not a one-and-done dump. You own your copy; the updates keep flowing.

How does the deterministic scripting actually hold up when my project's toolchain drifts from the defaults you baked in, say if I'm not on OrbStack or I'm already wired into a different secrets manager?

Maker

 Honest answer: they're opinionated on purpose — one proven path (OrbStack + Doppler + this stack), not a config buffet. That's the value and the tradeoff.


But opinionated ≠ locked-in:

- Deviations live in a .squid/config.yml manifest the skills read — today you can turn monitoring off, skip realtime/workflows, etc. Missing key = the default, so a clean setup just works, and your changes stick.


- Right now Doppler + OrbStack are the hard assumptions. Not on OrbStack? Only the dev-domain wiring assumes it — swapping to host-ports or your own proxy is a small edit. A non-Doppler secrets path (plain .env first, other managers next) is the top roadmap item — precisely because of questions like yours.


- And since it's deterministic scripts you own (plaintext, MIT), you can fork the one assumption that doesn't fit. No black box.


So: great fit if you take the defaults, adaptable if you don't, and I'm actively closing the gap on the big two. What's your secrets manager? Happy to make sure it's on the path.

You asked which part of a prod setup people wish was deterministic: for me the initial scaffold was never the pain, the operational routines six months in are. I've ended up encoding my App Store ops, QA regression passes, even a Product Hunt routine as Claude Code skills with scripts behind them, because prose instructions drift a little every session until the output is unrecognizable. Curious how you handle skill updates when the underlying toolchain moves, do users re-download or do skills version themselves?

Maker

 This is the thread I hoped someone would pull. Scaffold is day 0; the day-100 operational routines are where prose really rots — you nailed it. App Store ops / QA regression / a PH routine as scripted skills is exactly the move.

On updates: skills version themselves — no manual re-download. The free pack ships as a Claude Code plugin, so it rides native marketplace auto-update (or /plugin update), and there's a squidup skill that re-pulls the latest in place. When the toolchain moves — Node, a GitHub Action, Prisma — we bump, retest, and ship; it just flows to you. Deterministic scripts mean model drift barely matters, and toolchain drift is our patch to own, not your retest.

Honestly, your ops-routine angle is where I want to take this next — today the pack is scaffold→deploy→monitor, but the recurring six-month routines are the durable value. Would genuinely love to see how you've structured yours.