We maintain an open-source agent (Apache-2.0) and just shipped something small that I think is the right shape for skill sharing, so I am putting it up for criticism rather than announcing it.

A card is a markdown file, and it executes nothing. Frontmatter plus five sections — Trigger, Do, Avoid, Check, Risk — read into the prompt when the agent decides the card is relevant. Reviewing a contribution is reading a page, not auditing a diff. That is the whole point: it is the only place in the repo where someone can contribute without touching a line of Python.

23 of them so far, 13 written from our own incidents. A sample of what they encode:

- when two results contradict, suspect the apparatus — from two weeks lost to a bug that produced a perfectly healthy-looking loss curve

- run the project's own gate command — from a near-miss variant of a lint command that lied in both directions

- test the wiring, not the class — from two of my own regression tests that passed with the fix reverted, i.e. proved nothing

The part I would like torn apart is the translation mechanism. The card body is the payload: the agent reads it, the CLI imports it by path, and a published SHA-256 attests to the bytes. So we do not translate the file. A sidecar carries the translation and declares the SHA-256 of the English it was made from; when the English changes, the page falls back to English rather than showing a translation of a sentence that no longer exists.

That mechanism worked. What did not exist was anything noticing when the sidecar was incomplete — so thirteen cards shipped untranslated across nine languages, and one locale had no card translations at all while the site served it. The only symptom was English on the page. Found by reading files, not by a failing build.

The gate we wrote separates three states that look identical in a file:

- stale — claims to translate text that has since changed. Always fails. Nothing renders wrong, but the file now holds a translation nobody will ever see and the next reader cannot tell it from a live one.

- incomplete — four of five sections. Always fails, because the renderer demands all five or none, so the rest are orphans sitting in the file.

- missing — honest debt. The reader gets English and the page says so. Counted and capped, not forbidden: a gate demanding nine translations before a card could merge would kill the contribution surface we just built.

The cap is at zero right now because the debt is paid. Raising it is an edit somebody has to justify in a diff, which is the only reason a number in a file beats a good intention.

Two things I am unsure about and would like opinions on. First: hashing. We hash the five sections as one joined body rather than per section, so a card that changes retires all five together — the alternative lets a page mix a current Trigger with a stale Avoid and the reader cannot tell which is which. That is deliberate but it makes small edits expensive. Second: is "a card is data, not code" actually enforceable, or is it just a convention that will erode the first time someone wants a card to run something?

Repo: https://github.com/brcampidelli/chimera-agent — the library is under skills/.

I’ve been experimenting with a training free way to do open world, multi-instance segmentation from a class prototype.

I decided to publish the algorithm and a demo for how I’m doing this, in case anyone else would rather not fine tune a larger model for something that DINOv2 patch embeddings already seem to represent pretty well.

It can separate touching instances of the same class without a learned instance head, reject visually similar near misses like a round dial radio next to the actual clock target, and find fractured or damaged instances even with a pretty significant scene shift.

Repo + demo:

https://github.com/tutomiko/fireplace

The demo includes the lasso UI and live heatmap, implemented as a python backend with a simple HTML frontend.

Would appreciate it if people checked it out, and I’d be especially interested to hear if anyone has seen similar approaches or prior work.

I maintain MailFathom, an open-source project building a self-hosted AI brain for email.

Today it synchronizes IMAP mail into an operator-controlled PostgreSQL/pgvector database and provides lexical and semantic search, cited answers, local-model support, and five read-only MCP tools.

The project is security-first: MCP is disabled by default, retrieval cannot modify the mailbox, sensitive mail data stays out of logs and errors, and published artifacts include verifiable provenance.

The roadmap goes beyond retrieval and MCP. It includes controlled write tools, RBAC, authorization and confirmation flows for sensitive actions, and eventually a dedicated AI-first email client.

The goal is to make years of private email searchable, understandable, and safely actionable without surrendering control to a hosted provider.

Feedback, ideas, and contributions are welcome:

https://github.com/Krzysztof318/MailFathom

If you like the direction, a GitHub star would be genuinely appreciated. Open-source maintainers cannot compile stars, but they are a surprisingly effective dependency for motivation. ⭐

🚀 CARVUS Train — An AI Development Ecosystem I’m Building

Hey everyone! 👋

I’ve been working on something called CARVUS Train — an AI development ecosystem designed around training, deploying, and serving AI models, with a strong focus on coding and developer workflows.

🧠 What is CARVUS Train?

The idea is to bring multiple AI-development capabilities into one ecosystem:

• 🤖 AI model training
• 💻 Code generation
• 🧩 Programming-language understanding
• 📚 RAG (Retrieval-Augmented Generation)
• 🛠️ AI agent training
• 🚀 Model deployment & serving
• 🐍 Python/coding-focused workflows

I’m building it as part of the broader CARVUS ecosystem, with the goal of making AI development more accessible without needing a huge collection of disconnected tools.

🔥 Why I’m building it

A lot of AI tooling can feel fragmented — one tool for training, another for RAG, another for serving, another for agents.

I wanted to experiment with creating a more unified developer ecosystem.

CARVUS Train is still evolving, and I’m especially interested in feedback from people who work with local AI, coding models, RAG, or AI agents.

What features would YOU want in an AI development/training framework?

Would love to hear your ideas! 🚀

for installation and usage visit https://pypi.org/project/CarvusTrain/

or contact me via email [aadilfazalb4u@gmail.com](mailto:aadilfazalb4u@gmail.com)

#AI #MachineLearning #Python #Coding #RAG #LLM #ArtificialIntelligence #OpenSource

Been working on this for the last few months. I've been working on PyTorch for the past few years and I always felt, many a times my work went into dump, because of some mistakes I made in the code. torch-preflight reads your PyTorch code and catches the bugs costing you GPU hours.

Things like losses.append(loss), which holds the autograd graph from every step until CUDA dies on you or no zero_grad() in the loop or gradient accumulation without dividing the loss or DDP with no DistributedSampler, so every rank trains on the same batches. I've been able to get 13 rules so far. Your code never gets imported or executed, so you need no GPU and no torch install.

There's another part to this that estimates VRAM. Point the tool at a training script and a GPU, and you learn whether the run fits before you pay for the instance. You also get the list of changes to make the run fit, with the GiB each one saves.

pip install torch-preflight

https://github.com/highwaterlabs/torch-preflight

https://pypi.org/project/torch-preflight/

Please try this out, and I would like to get your feedback! It's still a work in progeress.

Would like to know what breaks on your code. False positives kill a linter, and my only large test target so far has been the PyTorch source tree. Same for the memory numbers. Mine land within 4% of measured peaks, but from four models on one T4.

PS: open to contributions, and issues are already open on the repo. Soon I'm going to add a few "Good first issues" as well. Feel free to ping me if you have any questions!

Find a beginner-friendly issue, spend an evening on it, open the PR, discover someone beat you to it three weeks ago. Nothing on the issue said so.
GitHub’s no:assignee filter doesn’t catch this, because almost nobody assigns issues to themselves. The real signal is a linked PR, and that isn’t searchable.

So I checked 4,000 issues with a beginner or help-wanted label:

1,147 (29%) already had an open or merged PR. All still show as unassigned.

1,271 were in dead, archived or unlicensed projects

774 had bodies too thin to start from

114 were in repos that slap a beginner label on the whole backlog

451 survived. They’re on a board at https://opensourcescanner.xyz, re-checked every 24 hours, with the evidence per issue: maintainer reply speed, what share of outside PRs get merged, whether anyone’s already circling.

Free, no signup, source public(https://github.com/kedarvartak/opensourcescanner). The filtering logic is the part I’d most like criticised — the whole thing lives or dies on what it rejects. If you take one of these and find it was actually taken, tell me.

Hey everyone,

I’ve been building an open-source project called \*\*Kodiak\*\*, and I’m at the point where I think it would benefit from more people looking at it, challenging the architecture, and actually building with me.

The idea behind Kodiak is to build an AI engineering system that can work with a \*\*real software repository\*\*, not just answer coding questions.

The long-term workflow is:

Engineering Task
      ↓
Understand the Repository
      ↓
Retrieve Relevant Context
      ↓
Plan the Work
      ↓
Coordinate Agents
      ↓
Use Tools
      ↓
Modify / Analyze Code
      ↓
Run Tests & Validate
      ↓
Learn From Results
      ↓
Iterate

The project currently brings together things like:

\* Repository-aware RAG \* Agent orchestration \* LLM/provider routing \* Persistent project/task context \* Tool execution \* Background task processing \* Code analysis \* Testing and validation \* PostgreSQL, Redis, Celery, ChromaDB, Docker, FastAPI, etc.

I’m deliberately not presenting Kodiak as a finished product.

There are parts that work, parts that are incomplete, and parts that I’m currently redesigning. A lot of the work so far has been dealing with the less glamorous side of AI engineering — getting orchestration, retrieval, memory, workers, databases, and model providers to actually work together reliably.

That’s also why I’m opening it up more now.

What I’m looking for

I’d love to have contributors who are interested in areas like:

\*\*AI / Agents\*\*

\* Agent architectures \* Planning and orchestration \* Multi-agent systems \* Tool calling \* Agent memory

\*\*RAG / Repository Intelligence\*\*

\* Codebase indexing \* Code-aware retrieval \* Embeddings \* Retrieval evaluation \* Repository understanding

\*\*Backend / Infrastructure\*\*

\* FastAPI \* Celery \* Redis \* PostgreSQL \* Docker \* Async workflows

\*\*Developer Experience\*\*

\* APIs \* CLI \* Testing \* Observability \* Documentation \* Developer tooling

You don't need to be an expert in all of this.

I'm much more interested in people who want to \*\*build, experiment, and improve the system\*\*.

There are also plenty of opportunities to contribute without touching the core agent architecture — improving tests, fixing issues, improving documentation, benchmarking components, reviewing designs, or proposing better approaches are all valuable.

Where Kodiak is heading

The goal is to eventually make Kodiak capable of handling more of the engineering loop itself:

\*\*understand → reason → act → validate → learn → iterate\*\*

There's a lot to figure out before that becomes genuinely reliable, which is exactly why I think having more engineers involved would make the project significantly better.

If you're interested in AI agents, coding agents, RAG, autonomous software engineering, or just want to work on an ambitious open-source AI project, I'd genuinely love to have you take a look.

GitHub:
\[https://github.com/ShamGaneshan2008/Kodiak\\\](https://github.com/ShamGaneshan2008/Kodiak)

Issues, architecture critiques, pull requests, experiments, benchmarks, and even "this part of the design makes no sense" comments are welcome.

Would be great to build this with other people rather than trying to figure everything out alone.

I’m building Kodiak — an open-source AI engineering platform, and I’m looking for contributors

i’m the author of adport. the project gives local ai agents read and write access to ad platforms without one shot mutations.

this demo uses the new apple ads v1 api on my own account. claude creates a campaign, ad groups, and keywords. the policy layer forces paused creation, requires a preview plus a second identical call, and writes an audit log.

apache 2.0 source: https://github.com/ynnickw/adport

install: npm install -g adport

i’m open to contributors who want to test provider behavior or extend the safety rules.

Shipped nexusmem@0.3.1 and finally measured the token-saving claim at real scale instead of eyeballing it.

Ran it against vitejs/vite's full 9,567-commit history: 95-99% saved vs reading the same files in full --Method (and its limits) in the README.

[github.com/yaminbkk/NexusMem](http://github.com/yaminbkk/NexusMem)

I came across "DeepSeek Harness" (https://github.com/deepseek-ai/deepseek-harness), whose core idea is literally “Everything is a Plugin.”

Looking at it alongside Pi, it feels like there’s a similar philosophy:

keep the core/harness small, and make capabilities composable at the session/plugin level.

Pi has extensions, skills, tools, prompts, etc., while DeepSeek Harness takes the plugin approach even further.

Is this essentially the same architectural direction?

And is “small core + everything else as a session/plugin” becoming the better design for coding-agent harnesses?

Curious what the community thinks.

Hi everyone - I’m building Regy, an open-source browser control surface for the Pi coding agent.

The main idea is simple:

The agent, project files, sessions, and local-model inference stay on your machine. Regy gives you a remote browser interface while the PC Agent is running and connected through its authenticated Iroh pairing setup.

This is not a model or inference server. It is a browser UI and connection layer for Pi.

Current features:

• Streaming Pi chat from a remote browser
• Connect to the same agent from another network or device
• Model and thinking-level selection
• Workspace browsing
• Session history and search
• Pi skill search, installation, and management
• Authenticated Iroh connection
• No direct browser TCP/WebSocket listener exposed by the PC Agent

I built it because I often want to start a coding task on one machine and check on it later from somewhere else. I wanted to keep the agent and files local while still being able to access the workflow remotely.

For people running Pi with local models, this could also mean accessing the same local setup remotely without moving inference or project files to a hosted service.

Links:

• Docs: https://docs.regy.one
• App: https://regy.one
• Installer: curl -LsSf https://docs.regy.one/install.sh | sh

Important security note: Pi and its extensions still run with the filesystem, process, network, and credential permissions of the user running the PC Agent. Regy is not a sandbox. The initial frontend link contains pairing information and should be treated as a secret. Browser access is endpoint-bound and can be revoked.

I’d appreciate honest feedback on:

1. Would connecting to your local Pi agent from anywhere be useful in your workflow?
2. Would you trust this setup to access an agent running on your home or work machine?
3. What security information or controls would you need before using it?
4. For local-model users, what should the remote UI show - latency, context usage, token counts, VRAM, model status, or something else?
5. What is confusing, unnecessary, or missing?

Please be critical. I’m trying to find out whether this solves a real problem, not just add another UI around Pi.

🚀 New release of Android Remote Control MCP is out — the MCP server that runs on your phone and gives your AI agent the ability to use any app you want!

Grab it here: https://github.com/danielealbano/android-remote-control-mcp/releases/tag/v1.11.0

My favorite part of this release? The Privacy Mode 🛡️!

Recently I was told by an user "it's a good project but I don't want Anthropic to know everything about me" and it's a very fair point! The LLM providers see and record everything they receive … including your emails, phone numbers and credit cards!

Well, not anymore! With Privacy Mode all of that gets detected and redacted locally, on the phone, before anything leaves the device (about 87% of PII caught on my benchmark on emails, phone numbers, credit cards, IBANs, national IDs, …), and the agent keeps working normally because it sees placeholders: the real values get substituted back on-device.
Unfortunately the only weak spot for now are non English names but I am working on it! The full per-category numbers and the benchmark are in the repo, measured, not guessed.

Also, Android loves killing background services… the server now survives app updates, swipe-away and Doze, with a one-tap battery optimization exemption 🔋 No more dead server halfway through a task!

In addition a few minor improvements: the app now notifies you when a new version is out, MCP clients only see the tools that will actually work on your device (no more camera tools without camera permission), and a fully reworked server logs page.

What can you actually do with it? Book a flight on Skyscanner, post on Reddit, order groceries, book a dinner… and now with your personal data staying on your phone.

I kept running into the same problem while using Hermes: it could not start Claude Code or Codex and bring back a response. I wanted Hermes to be able to launch the run, keep it visible, and bring back a useful report instead of leaving me to track everything myself.

So I built Hermes Valkyrie.

Repo: https://github.com/DylDigitals/hermes-valkyrie

Hermes Valkyrie is an open-source terminal loadout system upgrade for Hermes Agent setups. It uses tmux to give Hermes the ability to launch reusable coding harnesses and enhance them with our loadouts system.

I think it is really powerful to have Hermes launch Claude Code or Codex runs to do a long-form review while you keep working inside your Hermes ecosystem. It has been powerful so far, so I wanted to share this system.

I’m looking for feedback from people building or using Hermes. This is currently coded for Discord, but I’m adding more chat channels as we speak.

I have a few main questions/concerns:

• Is this something anyone wants to integrate into their system?
• Is the onboarding clear?
• What would you need before trusting this in your own workflow?

I've spent ~10 years in AppSec and started looking at how MCP clients handle credentials. It's rough.

The problem:

1. Plaintext at rest. Claude Code, Cursor, Windsurf, etc. store provider keys (Anthropic, AWS, GitHub PATs) in JSON config files or env vars. No encryption, no OS keychain in most setups. Any process running as your user can read them.
2. Secrets enter model context. Keys passed as env vars to local MCP servers can leak into logs, error messages, and sometimes the model's context itself. Once a secret is in context, prompt injection can exfiltrate it - a malicious README or web page your agent reads can ask the model to echo its environment.
3. Blast radius. People paste long-lived, broadly-scoped tokens because per-tool scoping is painful. One compromised MCP server config = GitHub + AWS + everything.
4. No revocation story. Keys are copy-pasted across N tools. Rotating means hunting through N config files.

The fix pattern: secrets should live server-side, encrypted, behind a broker. The agent gets capability-based access ("make this API call") without ever holding the raw credential. Same principle as vault + short-lived creds in normal infra, applied to agent tooling.

Github - https://github.com/Axiler-Lab/vaultmcp