> "Done does not mean DONE"

Ya know, respect. I don't feel like a lot of people who went the vibe coding route have had that moment.

Yeah there's so many "bad habits" you can stop via a gate. My go-to is static analysis tools in the tree-sitter family.

I am currently testing a "too simple" gate. Claude loves to turn everything into helper functions, and if the helper function isn't actually helping (too short, doesn't perform enough actions, etc) the commit gets bounced and Claude gets told why it's wrong and what to do about it.

This has generally kept the worst of things out of the codebase.

> skill behavior changes across different models

This has bitten me so badly SO many times. Every time there's a new model, it's time to re-evaluate the skills. It got so bad I put a lot of the skill behind a CLI.

Evals saved me, but I really wish skills had a `writtenFor` field in their frontmatter so an agent could warn you it was running a skill written for a different model.

Some of my current toolchain:

- I'm currently using Sentry's dotagents to share skills and pin versions

- I avoid a centralized "single brain" and instead have started a "knowledge" directory in each repo. I copy relevant learnings in so stuff stays isolated

- I use an OSS tool from my company to turn anything that could be enforced by code into something that can be enforced by code (keeps the markdown files leaner)

- My daily driver is cmux with a silly amount of sessions, so I'm constantly throwing away sessions and keeping context small

My biggest problem with that setup was to keep skills etc in sync across projects. That’s why I started using https://yarkr.com to distribute and synchronize them automatically.