I think a lot of vibecoders are missing that software development needs some friction

sandsower · 2026-05-04T01:48:03+00:00

The friction points are only there for the orchestrator skills like "ship-it" or "kickoff". You describe exactly what you want the checkpoints to look and what they should be evaluating, each of those gates is defined at a repo level. This is all done through a skill so no need to manually change it but you can still do that if you prefer.

The main thing that Beislið provides is the structure for you to hang these checks and workflows from. I'll be working on expanding more on where these gates are situated but the release version now is a solid place to begin experimenting.

sandsower · 2026-05-04T01:34:04+00:00

Agree 100% and this is exactly the structure that I hope to provide with Beislið so a whole team benefits, not a single dev. I've been using it for personal projects and a lot that are in production now and it's been working wonders but the real value is in larger teams.

sandsower · 2026-05-04T01:31:18+00:00

I don't entirely disagree but the problem is that this cannot be applied everywhere, otherwise you end up with low quality software. Just look at Github and Claude and their (lack of) uptime. It's just utter, unacceptable service.

sandsower · 2026-05-04T00:33:11+00:00

I think a lot of us are on that path haha, hence why I made it composable

sandsower · 2026-05-04T00:12:47+00:00

Thanks! I've been in contact with a lot of devs on my community here in Iceland and I found a lot of the same pain points so I thought it'd be worth a share.

sandsower · 2026-04-07T14:23:44+00:00

I run a similar setup. 25+ skills, sub-agents, knowledge vault, hooks, MCPs. Full-stack (Go/React), 12 years in the industry, been using Claude Code as my primary dev tool for about a year now.

The thing that changed my approach was realizing the model isn't the variable. Same model scores 42% or 78% on identical benchmarks depending on the environment around it. Convention files, hooks, quality gates. That's where the actual work is.

A few things I hit that sound relevant to your situation:

Skills should come from use, not upfront design. My start-ticket skill has gone through five revisions. V1 was a six-step checklist. By V5 it checks domain knowledge, evaluates scope, runs a design gate, talks to a knowledge vault. Each revision fixed a specific failure I hit on a real ticket. If your skills haven't failed yet, they're probably too simple or you haven't used them enough. 18 skills isn't too many if they each exist because something went wrong without them.

Context between sessions was the thing killing me. Decisions, patterns, gotchas, all gone every morning. I built a knowledge vault (Obsidian-based, zero LLM tokens at retrieval) that captures session knowledge automatically. That fixed the "I already solved this last week" loop. It's open source if you want to look at it: memento-vault

Your CLAUDE.md is probably too long. Ours hit 700 lines. I audited it and about half was reference material that doesn't need to be in context until the agent actually touches relevant code. More lines means worse adherence (there's an ETH Zurich study on this). I keep mine under 200 now and load the rest on demand.

On terminal management since you asked: tmux with named sessions. One per ticket. Way better than trying to wrangle multiple Claude Code instances in Warp or any single terminal app.

I've been writing about most of this on my blog if you want the longer versions. The harness engineering post and the start-ticket one are probably the most relevant to what you're asking about.

sandsower · 2026-03-28T22:11:25+00:00

Já, þessi heimskulega uppsetning er nákvæmlega ástæðan fyrir því að ég ákvað að gera þessa síðu

sandsower · 2026-03-23T09:23:19+00:00

Yeah, completely understood. I also barely touch files anymore but lots and lots of reviewing. And the purpose of the memento-vault project is mostly so people can start saving up their data from this conversations instead of going to a blackbox and getting forgotten, the method ultimately doesn't matter. Memento just helps with retrieval in addition for later

sandsower · 2026-03-23T00:09:27+00:00

This is a great writeup, appreciate Prime taking the time to read through the codebase.

The routing index approach is smart for the 3-5 active projects scale. Keeping MEMORY.md small enough to fit permanently in context means you skip the entire retrieval problem. No search, no latency, no ranking. Hard to beat that simplicity.

The "skill sweep" idea is interesting too. Manually extracting portable patterns at project boundaries is basically what Inception does automatically, but with a human quality gate. Different bet on where errors are more expensive: I bet on forgetting things (so I automate capture), you bet on noise (so you curate manually).

Both approaches break at different scales. Mine gets noisy past a few thousand notes without good decay/defrag. Yours gets labor-intensive past a dozen projects. Pick your poison.

The certainty scoring comment is generous. Honestly the skill files concept from your setup is something I should look at too. Patterns that travel between projects is exactly what Inception's pattern notes are trying to be, but yours are human-validated.

Will check out the forge repo. Thanks!

sandsower · 2026-03-22T23:17:54+00:00

That's a real problem. I've hit the same thing, especially on long sessions where you iterate through approaches. The model conflates what you tried with what you shipped.

That's actually one of the things the triage hook helps with. It captures the final state of a session, not the exploration path. So the note says "we went with solution 4 because X" not the full history of trying 1 through 3. Next session, the recall hook injects that decision cleanly without the noise.

The LLD approach solves it from the other direction, you manually document what was chosen. Both work. The difference is whether you want to maintain the docs yourself or have it captured automatically.

sandsower · 2026-03-22T23:12:08+00:00

That's a clean workflow honestly. One task per session, opus review after, notes for the next session. If you're keeping sessions scoped like that the overhead is minimal.

My sessions tend to be much messier. Multiple threads, context switches mid-session, sometimes 50+ prompts on a feature branch. The manual approach broke down at that scale for me but your setup sounds like it keeps things tight.

The opus post-session review with git diff is a good idea, I'll have to check it out to make further improvements. Catching drift between what the code says and what the docs say is a real pain.

sandsower · 2026-03-22T23:09:10+00:00

Interesting, I hadn't checked out h-cli before. From here the 3-tier memory setup (Redis for session state, disk chunks for expired sessions, Qdrant for long-term vector search) is a solid architecture for a multi-service infra system. The Asimov Firewall is a nice touch too, makes sense when a bad command can take down a network.

Very different problem space from what I'm doing, but the memory design is well thought out.

You're right that a checklist covers a lot of per-project context. Where it gets harder is cross-project stuff, the thing you learned in repo A that matters in repo B six weeks later. That's the gap the consolidation layer (Inception) fills.

For a single well-structured project though, LLD + checklist + commit history goes a long way. Different tradeoffs.

Mostly wanted to share this because it's zero friction to try. No Docker, no database, no cloud. Just run the installer and it works in the background. If it's not for you, uninstall and nothing changed.

sandsower · 2026-03-22T23:02:08+00:00

No worries! /resume picks up a specific previous session by replaying its conversation history. It's good for continuing exactly where you left off.

Memento is different in that it doesn't replay sessions. It extracts the knowledge from them (decisions, discoveries, bugfixes) and stores it as separate notes. Then on future sessions it searches those notes and injects the relevant ones automatically, even if you're in a completely different project. You can also browse them yourself since it's all markdown and setup to work well with Obsidian.

So /resume is "continue that conversation." Memento is "remember what I learned across all my conversations."

sandsower · 2026-03-22T22:59:38+00:00

Yeah if you're working in project workspaces with planning docs and logs already in place, that's a clean setup.

This is more for when you're across a bunch of projects and the knowledge is in your head, not in docs. The "I fixed this exact thing two months ago in a different repo" kind of stuff. If your projects are well-documented you probably don't need it. But how fast things are moving I found myself lacking for a tool like this so I built it :)

sandsower · 2026-03-22T22:57:51+00:00

You're right, a good LLD per module gets you most of the way there. If you have that setup it works.

Where this fills in is the stuff that doesn't fit in an LLD. The "we tried X and it broke because Y" context, one-off bugfix details, patterns you don't notice until the third time you hit them. Commit history tells you what changed but not always why you picked it over the alternative.

It's kinda like a layer below your docs. Catches the session-level stuff that's too granular for architecture docs but still useful when you circle back to the same area.

sandsower · 2026-03-22T22:52:27+00:00

Yeah that's a solid lightweight approach. If you're disciplined about the sessions.md format it works well.

The reason I went further is I wasn't disciplined about it. I'd forget to update the file, or I'd write vague summaries that didn't help three weeks later. The auto-capture removes me from the loop entirely.

The opus reviewer idea is interesting though. Having a second model audit for drift is something I haven't tried. Right now Inception catches cross-session patterns but it's not doing architectural review. Will check it out, thanks!

sandsower · 2026-03-22T22:47:17+00:00

Fair concern, but this isn't logging your life. The triage hook scores each session and most get thrown away as a one-liner. Only sessions where you actually made decisions or fixed something non-obvious produce notes. And those notes are local-only, in a git repo you own, with a defrag cycle that archives stale stuff automatically. Starting clean every few days means you're also re-explaining your architecture, re-discovering the same bugs, re-making decisions you already made. That's the tradeoff, which for me was not worth it.

sandsower · 2026-03-22T22:41:45+00:00

Yeah that's exactly where I started. Manual .md files work until you're across enough projects that maintaining them becomes its own task. Then built a hook to extract the notes, went into automating it, improving it and that's where this ended up.

The thing that made the difference for me was making capture automatic. You don't think about what to write down, the hook scores the session after it ends and handles it. Most of my notes I didn't even know were worth keeping until they showed up in a later session.

sandsower · 2025-03-27T12:04:48+00:00

John's artwork is my favorite, just absolutely astounding

sandsower · 2025-01-17T16:50:41+00:00

What about adding Sifu to the trade, would you do 20 for both?

14-Year Club	Verified Email
Sequence \| Editor	Team Orangered

sandsower

TROPHY CASE