DEV Community: Mārtiņš Veiss

Weekly Update: ✨ fix(automation): count landed files, not just surviving li

Mārtiņš Veiss — Wed, 02 Sep 2026 09:00:08 +0000

Weekly Update: ✨ fix(automation): count landed files, not just surviving lines, in the branch sweeps (#15036) (#15489)

AutoBot is an open-source, self-hosted AI agent platform — your data, your AI.

This week we shipped:

🔧 fix(automation): count landed files, not just surviving lines, in the branch sweeps (#15036)…
🔧 test(coverage): give every collection exemption a decision, an issue and a down-only ceiling…
🔧 feat(health): report the served frontend bundle, not just the process (#15462) (#15465)

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-08-26T09:00:04.342434Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

The half of your Claude setup that can't be shared — and why it still needs to be a plugin

Mārtiņš Veiss — Tue, 01 Sep 2026 13:00:02 +0000

Last time I wrote about the portable half of a Claude Code setup — the process discipline
that transfers to any codebase, packaged as a plugin. Explore before building, prove the
helper doesn't already exist, never claim "done" without pasting the output.

That half is genuinely reusable. It's also not where most of the damage happens.

Watch a capable agent work on an unfamiliar project and the failures aren't reasoning
failures. It opens the PR against main when the project ships from a different branch. It
writes a PR body missing the three headings your CI requires, and the check fails for reasons
the error message doesn't explain. It puts the migration in the plausible-looking directory
rather than the real one. It calls the API endpoint that was deprecated in March, because the
old one is still in the tree.

None of that is a thinking problem. It's that the information doesn't exist in any form the
agent can find. Your conventions live in your team's heads, in a wiki nobody's opened since
onboarding, and in the reflex of the one person who's been there three years.

The information isn't in the codebase

This is the part I got wrong for a while. I assumed that a sufficiently good agent reading a
sufficiently well-organised repo would infer the conventions. Sometimes it does. But
inference from code gives you what the code does, not what the team has agreed, and those
differ constantly:

Both main and a development branch exist and look active. Which one do PRs target? The code cannot tell you. Both have recent commits.
Two service-layer patterns exist because one is being migrated to the other. Which is correct for new work? The tree shows both, in roughly equal numbers.
A directory holds twelve files, eleven of which are deprecated. Nothing marks them.

An agent reading that repo will make a defensible choice and be wrong half the time. So will
a new human contributor — they just ask in Slack instead, which is why the problem stays
invisible until you try to scale it.

Why this doesn't go in CLAUDE.md either

Same argument as last time, sharper. Project instructions are resident in context permanently,
so everything you add competes with the actual task for attention.

Conventions are unusually bad at justifying that cost, because almost all of them are
situational. The rules about PR body structure matter during PR creation and nowhere else.
The deploy path matters when deploying. The full-stack debugging map — which layer owns
which symptom — is critical when something breaks and pure noise the rest of the time.

Push all of it into one always-on file and you get a document nobody can keep current, where
the two rules that would have prevented today's incident are buried among forty that wouldn't.

Skills load on trigger. That's the whole argument, and it applies harder to project
conventions than to general discipline, because there are far more of them.

The boundary that turned out to matter

I ended up splitting my skills into two marketplaces, and the dividing line is simpler than I
expected:

If a skill names a branch, a path, a service, or a table — it's project-specific.
If it names a discipline — it's portable.

canonical-coding ("one implementation per concept, prove the thing doesn't exist before you
write it") names a discipline. It's true everywhere. pr ("target this branch, these headings
are required, run these checks first") names a branch. It's true in exactly one repo and
actively harmful anywhere else.

The test is useful because it's mechanical. You don't have to reason about whether something
feels general — you look at whether it can be written without naming a proper noun from your
infrastructure.

What the project-specific half looks like

For AutoBot-AI that came to twelve skills, in
their own marketplace:

Issue → merge — implement (the full loop: umbrella gate, worktree, design, code, verify,
PR, CI, closure check), batch-implement (the same across a list of issues, with per-issue
verification), pr (pre-flight branch checks, correct base branch), pre-merge-validate
(syntax, imports, call-site impact, tests, types, lint), drain (pick up the backlog items
that need no human decision).

Review — review (CI diagnosis, three-angle finder pass, merge decision) and
review-fleet (ten parallel review angles with separate verifier agents, posting only
confirmed, deduplicated findings as a single comment).

Audit — api-wiring-audit (frontend calls an endpoint that exists, backend route is
actually mounted) and dead-code-audit (unregistered routers, uninvoked hooks, orphaned
components).

Debug — debug-autobot, which dispatches an investigator per layer (Vue, FastAPI, Redis,
ChromaDB, NPU, browser, AI stack) and synthesises one root cause. This one is the clearest
example of why the split exists: its entire value is knowing which layers exist and what each
one owns. There is no general version of that.

Platform and session — github-cli and session-lifecycle, the start-of-session and
end-of-session protocol.

None of that is useful to you. That's the point — it's not meant to be, and trying to make it
general would strip out exactly what makes it work.

The payoff is onboarding, human and otherwise

One install, and every developer on the project has the same workflow — and so does every
fresh agent session. That second part is easy to undervalue. Agent sessions start from nothing
every time; whatever conventions you established yesterday are gone unless something reloads
them. A plugin is how you make "how we do things here" survive a new context window.

It also makes conventions reviewable. When the rule lives in a skill file in a repo, changing
it is a pull request someone can argue with — rather than a habit that drifts silently until
two people are doing it differently and neither knows.

Where this fails

Skills encoding conventions are only worth it if the conventions are stable. If your branch
strategy is genuinely in flux, a skill that confidently states the wrong base branch is worse
than nothing — a human hesitates and asks, an agent complies immediately and at scale.

So they need the same maintenance as any other checked-in artefact: when the convention
changes, the skill changes in the same PR. A skill that lies is more expensive than a
convention nobody wrote down.

The portable half is at
Claude-Dev-Skills, the project-specific half
at AutoBot-AI-Claude-dev-skills.
Both Apache-2.0.

I'd like to know whether the boundary rule holds up against your setup — is there a skill in
your workflow that names a proper noun but still feels like it should be portable? That's the
case I haven't figured out yet.

Weekly Update: ✨ fix(setup-wizard): bound the provision-fleet 409 lock by s

Mārtiņš Veiss — Wed, 26 Aug 2026 09:00:09 +0000

Weekly Update: ✨ fix(setup-wizard): bound the provision-fleet 409 lock by staleness, not just status (#14856) (#15090)

AutoBot is an open-source, self-hosted AI agent platform — your data, your AI.

This week we shipped:

🔧 fix(setup-wizard): bound the provision-fleet 409 lock by staleness, not just status (#14856)…
🔧 fix(access-control): provision the enforcement mode instead of inheriting an unset key (#14866)…
🔧 docs(bedrock): the module documents a re-export it does not have (#15081) (#15082)

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-08-19T09:00:03.226436Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Agents don't fail at writing code — they fail at everything around it

Mārtiņš Veiss — Tue, 25 Aug 2026 13:00:02 +0000

I've spent about six months running Claude Code agents against a codebase big enough to
hurt — several hundred open issues, agents committing daily, a CI pipeline that fails loudly
when they get it wrong.

Here's the thing nobody told me going in: the agents were fine at writing code. Genuinely
fine. Give one a well-scoped function and it comes back with something reasonable.

What they were bad at was everything around writing code. Deciding whether the thing
should be built at all. Noticing that the helper they were about to write already existed
sixty lines up. Checking whether the fix worked before announcing that it did. Those aren't
coding failures — they're process failures, and no amount of better prompting fixed them,
because the problem was never the prompt.

What fixed them was writing the process down.

Four failure modes, and what each one taught me

1. The second helper

An agent needs to format a duration. It writes formatDuration(). Your codebase already has
humanizeElapsed() in a utils file it never opened.

This is the most expensive failure mode I hit, because nothing about it looks like a
failure. The code works. Tests pass. Review approves it. You only find out six months later
when you change how durations are displayed and catch three of the four places.

Agents are strongly biased toward writing new code rather than finding existing code,
because writing is what they're rewarded for and searching is expensive. The counter-pressure
has to be explicit: before you write a helper, prove the concept doesn't already exist.
Not "check quickly" — prove it, with a search you can cite.

The same discipline kills the "v2" reflex, where an agent that finds a function it doesn't
fully understand writes processDataV2() next to it and leaves both in the tree forever.

2. "Done" that was never checked

Ask an agent whether the fix works and it will tell you the fix works. It is not lying. It
has genuinely reasoned its way to a confident answer, and reasoning feels like verification
from the inside.

The rule that fixed this is blunt: you may not say "done", "fixed", or "passing" without
pasting the command output that proves it. Not a description of the output. The output.

The interesting part is how often an agent following that rule catches itself. It goes to
run the test so it can quote the result, the test fails, and the claim never gets made. The
verification step isn't a check on the answer — it's what produces the answer.

3. Fixing one of twelve

An agent fixes a null-check bug in UserService. The same bug is in eleven other services,
because they were all written from the same template by the same agent three weeks earlier.

Agents fix what you point at. They don't generalise from one instance to a class of
instances unless you ask, and the whole reason the bug is interesting is that it's probably
systemic. So after every fix: sweep the adjacent files for the same defect, and file what
you find. File it even if you can't fix it now — an unfixed bug you've recorded is a
backlog item, an unfixed bug nobody noticed is a landmine.

4. Debugging by guessing

An agent hits a failing test and immediately proposes a fix. Then another. Then another. Each
one is plausible, none of them work, and forty minutes later the file has accumulated three
speculative changes and the original bug is still there — now harder to see.

What's missing is the step where you find out why it fails before deciding what to change.
Read the actual error. Reproduce it in isolation. Form one hypothesis, test that hypothesis,
and only then edit. And when three attempts have failed, stop — a fourth attempt is not a
strategy, it's a slot machine. Escalate with what you learned.

Why I put these in skills rather than CLAUDE.md

The obvious place for rules like these is your project instructions, and I started there. It
doesn't scale.

Everything in CLAUDE.md is in context permanently, competing with the actual task for
attention. A twelve-line debugging protocol is exactly right when a test is failing and pure
noise the other 95% of the time. Push enough process in there and the important rules get
diluted by the situational ones.

Skills load on trigger. The debugging discipline shows up when something breaks and stays out
of the way otherwise. That's the whole difference, and it turns out to matter a lot.

The second reason is portability. Process discipline isn't project-specific — the "second
helper" problem is the same in every codebase I've worked in. Keeping it in one project's
instructions means re-deriving it in the next project. Packaged as a plugin, it moves.

The set

I've extracted the general, project-agnostic half of what accumulated and published it as a
Claude Code plugin marketplace:

/plugin marketplace add mrveiss/Claude-Dev-Skills
/plugin install claude-dev-skills@claude-dev-skills

Eight skills:

process — the approach discipline: explore before building, plan a multi-step change, debug methodically, verify before claiming, dispatch parallel agents, finish a branch.
canonical-coding — one implementation per concept. Failure mode 1.
commit — commit workflow with pre-flight checks, auto-format, and retry logic for when pre-commit hooks rewrite files underneath you.
review-lenses — review by domain lens (architecture, delivery, frontend, docs, UX, visual craft) instead of one undifferentiated "review this".
gap-audit — sweep adjacent files after a fix and file the gaps. Failure mode 3.
web-audit — security, SEO and AI-friendliness audit of a site: headers, DNS, TLS, CORS, email spoofing, exposed panels, per-page SEO, compromise indicators.
ui-design — visual direction, typography, colour, layout, spacing, motion, accessibility.
memory-cleanup — end-of-session memory hygiene, so context files stay an index instead of growing into sludge.

Apache-2.0, and two of them consolidate ideas from other skill authors — notably Jesse
Vincent's Superpowers suite, which is worth reading on
its own.

They came out of building AutoBot-AI. The
project-specific ones — the issue-to-merge loop, full-stack debugging, the codebase audits —
live in their own marketplace,
because they hardcode that platform's branch names and paths and are no use anywhere else.
This is the half that travels.

The part I'd push back on myself

Process discipline has a real cost. Every one of these rules makes the agent slower, and some
of them make it slower in ways that feel pointless in the moment — proving a helper doesn't
exist takes longer than writing the helper, almost every time.

The trade only pays off over a codebase's lifetime, which means it's genuinely the wrong call
for a prototype you'll throw away in a week. If you're spiking something, skip all of this
and let the agent write.

Where it pays is the second year, when you're the one maintaining what the agents built.

If you try the set, I'd like to know where it's wrong: does process route the way you
actually work, or does it fire when you don't want it? Is canonical-coding too strict for a
codebase that legitimately carries parallel implementations? And what's missing?

Repo: https://github.com/mrveiss/Claude-Dev-Skills

Weekly Update: ✨ fix(provision): stamp node_roles_declared from the setup w

Mārtiņš Veiss — Wed, 19 Aug 2026 09:00:07 +0000

Weekly Update: ✨ fix(provision): stamp node_roles_declared from the setup wizard too (#14594) (#14637)

AutoBot is an open-source, self-hosted AI agent platform — your data, your AI.

This week we shipped:

🔧 fix(provision): stamp node_roles_declared from the setup wizard too (#14594) (#14637)
🔧 fix(infra): read the report file each analyzer writes, not stdout (#14587) (#14636)
🔧 security(mcp): govern manual_mcp as the twelfth bridge (#14586) (#14627)

Contributors: +1

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-08-12T09:00:02.662484Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ refactor(agents): split memory-monitor into capture vs cur

Mārtiņš Veiss — Wed, 12 Aug 2026 09:00:09 +0000

Weekly Update: ✨ refactor(agents): split memory-monitor into capture vs curation so capture runs on the cheap tier (#14139)

AutoBot is an open-source, self-hosted AI agent platform — your data, your AI.

This week we shipped:

🔧 refactor(agents): split memory-monitor into capture vs curation so capture runs on the cheap tier…
🔧 docs(claude): split CLAUDE.md into a trigger-routed index and deconflict the doc set (#14133)
🔧 perf(agents): pin explicit model tiers on all agent definitions and add a Haiku repo-sweeper…

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-08-05T09:00:03.299578Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ test(kb): make the GPU chunker and KB stats tests able to

Mārtiņš Veiss — Wed, 05 Aug 2026 09:00:05 +0000

Weekly Update: ✨ test(kb): make the GPU chunker and KB stats tests able to fail (#13563) (#13613)

AutoBot is an open-source, self-hosted AI agent platform — your data, your AI.

This week we shipped:

🔧 test(kb): make the GPU chunker and KB stats tests able to fail (#13563) (#13613)
🔧 test(mcp): make the injection tests reach the handler instead of a 404 (#13598) (#13612)
🔧 fix(api-contract): keep absolute filesystem paths out of OpenAPI schema defaults (#13572) (#13611)

Contributors: +2

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-07-29T09:00:02.182745Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions