DEV Community: Mārtiņš Veiss

Weekly Update: ✨ security(secrets): ask the secret's own scope, not just th

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

Weekly Update: ✨ security(secrets): ask the secret's own scope, not just the vault grant (#16982) (#17772)

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

This week we shipped:

🔧 security(secrets): ask the secret's own scope, not just the vault grant (#16982) (#17772)
🔧 config(tts): one spelling per side of the boundary, and the inventory port configured nothing…
🔧 chore(deps-dev): bump the oxlint group in /autobot-frontend with 2 updates (#17705)

Contributors: +2

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

Weekly Update: 🐛 fix(rag): preserve per-view provenance and multiplicity th

Mārtiņš Veiss — Wed, 23 Sep 2026 09:15:12 +0000

Weekly Update: 🐛 fix(rag): preserve per-view provenance and multiplicity through RRF fusion (#17207)

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

This week we shipped:

🐛 fix(rag): preserve per-view provenance and multiplicity through RRF fusion (#17207) (PR #17216)
🔧 fix(security): close an arbitrary file write and two path-injection holes (#17300) (#17301)
🔧 fix(pricing): migrate LLM cost tracking off hardcoded price tables (#16230, #16233, #16316) (#17187)

Contributors: +3

→ Full changelog: https://github.com/mrveiss/AutoBot-AI/commits/Dev_new_gui?since=2026-09-16T09:15:07.621043Z
→ Discuss on GitHub: https://github.com/mrveiss/AutoBot-AI/discussions

Weekly Update: ✨ feat(mcp): admin-configured external MCP server bridge

Mārtiņš Veiss — Wed, 16 Sep 2026 09:01:03 +0000

Weekly Update: ✨ feat(mcp): admin-configured external MCP server bridge

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

This week we shipped:

✨ feat(mcp): admin-configured external MCP server bridge (PR #16458)
🐛 fix(mcp): rename autobot-backend/mcp/ off the name it shadows (#16449) (PR #16454)
📚 docs(adr): supersede ADR-001's fixed VM count with role-separation placement (#15194)

Contributors: +3

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

The one you reported is gone. This one is still up.

Mārtiņš Veiss — Mon, 14 Sep 2026 20:03:55 +0000

On 2026-08-17 I reported Leutenegger/book-to-skill to GitHub Trust & Safety: TLS
verification disabled at import, a beacon to a Cloudflare Worker, eight wallet-extension
IDs enumerated, Ledger data archived and uploaded, and a Windows EXE launched via
PowerShell with ExecutionPolicy Bypass. It was impersonating
book-to-skill — a genuinely useful,
26,868-star project (PDFs into Claude Skills) — riding on its sudden popularity to get
installs. GitHub actioned it on 2026-08-23. The repository and the entire account now
return 404.

That should be the end of it. It isn't. On 2026-08-29, diffing every repository sharing
the project's name against the real upstream tree turned up a second operator, still live
at the time of writing.

What is in the archive

Both of the impersonator's repositories ship the same 487,256-byte zip. One path is
frond/book_to_skill_3.8.zip, the other docs/v1.7.zip — byte-identical, three members,
matching timestamps.

Application.cmd — 24 bytes. Its entire contents: start utils.exe cert.txt. One file runs the other.
utils.exe — 759,808 bytes, a PE executable. Not malicious on its own: the embedded strings identify an unmodified LuaJIT 2.1, built from the Defold project's pipeline. It's here purely to execute the payload.
cert.txt — 183,728 bytes. Not a certificate. Obfuscated Lua source, opening local Tq=function(i)local k,Z=i[#i],""….

The technique is living off a clean binary: ship a legitimate interpreter that no scanner
objects to, keep the actual logic in a data file with a reassuring extension, and let a
24-byte batch file put them together. A file named cert.txt that is executable Lua,
sitting next to an interpreter, inside a repository named after a widely-installed
developer tool, is not an accident.

SHA-256, for anyone who wants to pivot on them in VirusTotal or MalwareBazaar (GitHub
itself can't be searched by hash — more on that below):

Application.cmd  2fd3cb8aa174b29406cd39f62369603891840e90bb65cd8aaf4fb3e32a28f166
cert.txt         9303b32a3fdf241d38aaaaff46ef9fdb0800b678a4ea2be4bf35d475610eb152
utils.exe        e227d47facf0e2f5b9e5c54a23a86b31272696b64bbbb9932a31fe06973677bd

Two doors, one payload

1 repository — orestedevoted590/book-to-skill, created 30 July. No source code. A one-line README and the archive.
1 Pages site — orestedevoted590.github.io, a published site with real marketing copy, a Download badge, and Windows-only system requirements.
0 inbound links — no stars, no forks, no followers, not in GitHub's code index. Nothing points at either repo or the site.
90 other name-copies checked — every exact-name repository diffed against the upstream tree. One other shipped an archive at all; it turned out to be markdown and YAML, and benign.

The Pages site is the more dangerous of the two. It reads as a legitimate product page —
"Turn PDF books into usable skills," "System requirements: Windows 10 or Windows
11," "You must have Claude Code installed" — and it's served from github.io, so it
borrows the platform's own credibility. Nobody has to browse a repository or read a diff
to get caught by it. They only have to click Download.

Four ways of searching that don't work

Worth recording, so nobody burns an afternoon rediscovering the same dead ends:

Search by hash. GitHub doesn't expose a searchable content hash — no SHA-1 blob query field, and SHA-256 of file content isn't stored anywhere searchable.
Search inside the archive. Zip contents are never indexed. The launcher string start utils.exe cert.txt returns nothing, because it only exists inside a zip.
Search the repository's own text. A control query against the malicious Pages site returns 0 results, while the same query shape against a large repository returns 32. The account is too new and too small to be in the code index at all.
Search for the payload's shape. The obfuscator randomizes variable names per sample, and code search tokenizes on words, so local k,Z=i[#i] matches nothing. The two Application.cmd/cert.txt hits that do surface are a Mac packaging script and someone's unrelated notes.

What actually worked is unglamorous: notice a name-squat, list every repository sharing
the name, diff each against the upstream tree, and open whatever ships that the original
doesn't.

Not the same operator, as far as the evidence goes

Same impersonation target, same delivery class the first security notice describes — but
this payload is obfuscated and carries no plaintext URLs, so neither Cloudflare Worker
endpoint from the first report appears in it. A link between the two is neither
established nor excluded here, and it shouldn't be implied either way without evidence.

Why this is on a blog about a self-hosted agent platform rather than a security
newsletter: this is a supply-chain problem aimed directly at people building with AI
coding tools. The impersonation target here converts PDFs into Claude Skills — the exact
kind of small, popular, quickly-forked utility that anyone assembling an agent's toolkit
downloads without a second look. The name is the entire distribution strategy. If you
install skills, MCP servers, or agent tools from GitHub by name rather than by verified
publisher, this is what the failure mode looks like from the inside.

I write this from building AutoBot-AI, a
self-hosted agent platform — the same category of project where "check what you're
installing before you run it" is the whole point, not an afterthought.

Static analysis only. Nothing was executed and no interpreter was invoked on the
payload; the second archive was extracted to a temporary directory solely to compute the
hashes above, then deleted. Impersonation target:
github.com/virgiliojr94/book-to-skill
(26,868 stars). Prior case: Leutenegger/book-to-skill, reported 2026-08-17, actioned
2026-08-23.

Weekly Update: ✨ docs(process): name the selector — an empty result is not

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

Weekly Update: ✨ docs(process): name the selector — an empty result is not a true negative (#15953) (#16102)

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

This week we shipped:

🔧 docs(process): name the selector — an empty result is not a true negative (#15953) (#16102)
🔧 security: allow the two unfixable dev-only npm advisories (#16089) (#16103)
🔧 ci(duplication-guard): scan the three trees it never opened (#13044) (#16095)

Contributors: +2

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

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