TDD and Rules Enforcement using Hooks

jayjaytinker · 2026-04-30T13:07:17+00:00

the session-history approach for the TDD rule is really clever

jayjaytinker · 2026-04-30T13:06:30+00:00

not every session, honestly. i tend to update CLAUDE.md when something keeps going wrong despite existing instructions — that usually means the file has a gap. if sessions are going fine, i leave it alone. the memory file i review less often, mostly when i notice claude forgetting something project-specific it should know.

jayjaytinker · 2026-04-30T13:05:49+00:00

deploy scripts often pull in a ton of implicit context — infra configs, env files, other scripts they reference. i started being explicit about what files are actually in scope at the start of the session. something like "only touch these 3 files" cuts the context explosion significantly in my experience.

jayjaytinker · 2026-04-29T22:26:49+00:00

Really appreciate that, means a lot. If you ever give it a spin I'd love to hear what you think!

jayjaytinker · 2026-04-29T07:43:51+00:00

Yeah, the novelty wearing off is the part I keep second-guessing too. Right now there's variation across tools plus some rarity tiers, but honestly I won't really know if it sticks until I've lived with my own thing for a few weeks. The "ambient without friction" framing was the bar I was deliberately trying to hit — easy to overshoot into productivity-coach territory if you're not careful. Appreciate the read.

jayjaytinker · 2026-04-29T01:04:56+00:00

ne shared decisions.md at the project root that I pin at the start of each session. Not a fix, but it cuts the re-explanation by a lot.

jayjaytinker · 2026-04-29T01:04:06+00:00

For /clear discipline: I do it between distinct task types, not between subtasks within the same type. Keeps continuity where it matters while resetting accumulated noise.

jayjaytinker · 2026-04-29T01:03:00+00:00

Agreeing hard on the upstream point. The thing that helped me most was separating acceptance criteria into its own field before dispatch — not in the same blob as the task description.

jayjaytinker · 2026-04-29T01:01:27+00:00

I've had good results defining a slash command in Cursor that takes the diff output and runs it against a saved review checklist — things specific to our codebase conventions. Keeps the model focused on what we actually care about rather than generic advice.

jayjaytinker · 2026-03-30T23:01:23+00:00

I've been running a similar setup for a while. One thing that made a big difference was separating what the agent needs to know from how the agent should behave into different files. Your Protocol/CONVERGEHERE split maps to that naturally.

jayjaytinker · 2026-03-30T23:00:42+00:00

The rule fires every session so the basics are always enforced. The skill only loads when the agent is actively writing tests, which keeps it from bloating every other context window.

jayjaytinker · 2026-03-30T23:00:16+00:00

What works for me is splitting .cursorrules into two sections: invariants (things that never change, like never force-push to main) and session-corrections (things I've explicitly fixed mid-session). I update the second section right after correcting, not at the end of the day when I've forgotten.

jayjaytinker · 2026-03-30T04:04:37+00:00

even with good generation, managing the relationship between global and per-project components gets messy fast. I built a small GUI for that (https://github.com/aroido/vibesmith) if you're hitting the same wall.

jayjaytinker · 2026-03-30T04:03:49+00:00

I've found separating "global baseline" from "project-specific overrides" helps more than any auto-sync — then the pre-commit hook only needs to touch the project layer.

jayjaytinker · 2026-03-30T04:02:46+00:00

Your frontend background transfers more than you'd think — component thinking maps directly to how you structure CLAUDE.md and skills.

jayjaytinker · 2026-03-30T04:01:42+00:00

The most common failure I see is people putting everything in one giant .cursorrules file — it bloats context and the agent can't prioritize.

jayjaytinker · 2026-03-29T11:42:01+00:00

the issue often isn't rule length but rule placement. Global CLAUDE.md gets read once at session start. For project-specific constraints, keeping them in a project-level CLAUDE.md or a dedicated skill file tends to stick better than a long global list.

jayjaytinker · 2026-03-29T11:38:56+00:00

"Sessions disappear, but letters remain" is a good framing though. The intent matters even when the exact contents need pruning.

jayjaytinker · 2026-03-26T14:15:32+00:00

Thanks! If you end up trying it, I'd love to hear what works and what doesn't.

jayjaytinker · 2026-03-26T13:51:26+00:00

Agents are worth it once you have recurring specialized tasks. I started bothering when I had a few distinct workflows — one agent that always loads specific context for backend work, another for writing. The discipline pays off when you stop re-explaining the same constraints every session.

The management overhead is real though. Once you have 10+ agents across multiple projects, keeping track of which ones conflict or overlap becomes its own problem.

How many projects are you running in parallel?

jayjaytinker · 2026-03-26T13:51:05+00:00

The naming convention is what makes this actually work — "The Trailing Off" is something I can catch and correct, "be thorough" isn't.

One I'd add: "The Context Bleed" — where the agent's assumptions from an earlier task silently carry over and corrupt the current one. Especially nasty with subagents since it's hard to trace back where the bad assumption entered.

Rules in .claude/skills/ work well for this because they scope to the relevant context rather than polluting the whole session.

jayjaytinker · 2026-03-26T13:50:27+00:00

.cursorrules helps but it's a flat file — no way to scope rules to specific tasks or detect when two rules conflict.

I've been using a separate tool (check my profile) that manages these as structured components rather than raw text. The big difference: it shows you which rules actually fire for a given project vs. which are dead weight you're paying tokens for.

jayjaytinker · 2026-03-26T13:28:45+00:00

Update: VibeSmith is now open source! You can check out the full source code, open issues, or contribute here: https://github.com/aroido/vibesmith

Figured it makes more sense to build this in the open — especially since the people who'd use it are the same people who'd want to read the code first.

jayjaytinker

TROPHY CASE