Open Source Radar · 2026-10-24: Skill files become deliverables with a spec

Each day I pick five projects that are rising on GitHub this week, mostly AI agents and developer tools. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-24.

1. OpenBMB/VoxCPM ⭐ 40,329 · Python

GitHub: https://github.com/OpenBMB/VoxCPM

In one line: A text-to-speech system that skips discrete tokenisation entirely — 2B parameters, 30 languages, 48kHz output, Apache-2.0 for both code and weights.

What it is: It avoids the usual step of compressing speech into codec tokens and instead generates directly in the continuous latent space of its audio VAE, in four stages: LocEnc, TSLM, RALM, LocDiT. The current release, VoxCPM2, is a 2B model trained on more than two million hours of multilingual speech. The repo was created in September 2025; it went from 0.5B to 2B within a year, has shipped 14 releases, and main-branch commits continued through 2026-10-08.

What stands out:

• The model includes 48kHz output in its architecture. The codec is asymmetric: it takes 16kHz reference audio in and emits 48kHz out, with super-resolution built in, so no external upsampler is needed. That kind of trade-off says more about the engineering than the parameter count does.
• Read "30 languages" column by column. In the project's own MiniMax-MLS-test table, the reported error scores include Chinese 1.136, German 0.679 and Dutch 0.913. Arabic scores 13.046, Czech 24.132, Romanian 21.577, Hindi 19.699. In the same table, Minimax scores 1.665 for Arabic and ElevenLabs 1.666. Coverage and per-language quality are two very different numbers, and this table makes the gap visible.
• Voice design goes in parentheses. Put a description at the start of the text to synthesise — age, tone, emotion, pace — and the model creates a new voice without any reference clip. Cloning takes a reference clip and can still be steered by style instructions that change emotion and pace while keeping the timbre. The README says both features vary between runs and may need one to three attempts.
• The project reports real-time factors and device memory use. The project reports around 0.30 real-time factor (RTF) on an RTX 4090, about 0.13 with Nano-vLLM, and roughly 8GB of VRAM under its setup. An RTF of 0.30 means ten seconds of audio costs three seconds of compute — but this does not establish time to first audio, end-to-end latency or concurrent serving capacity.
• The project describes fine-tuning with five to ten minutes of audio; that is not a quality guarantee. Both full fine-tuning and LoRA are supported. Version 2.0.3 adds a manifest validator that checks fields, audio readability, sample rate and duration statistics before training, which moves "the data format was wrong" from mid-run to before the run.

Compared with: In the project's own Seed-TTS-eval table, VoxCPM2 (2B) gets English WER 1.84 with speaker similarity 75.3, Chinese CER 0.97 with 79.5, and hard-case CER 8.13 with 75.3. In the same table FishAudio S2 (4B) reports English WER 0.99 and Qwen3-TTS (1.7B) 1.23, both lower, while LongCat-Audio-DiT (3.5B) reaches 79.7 similarity on hard cases. Those scores were produced by the project; I did not reproduce them, so cross-table reading is indicative only. Mechanically it is continuous-latent generation, a different path from the dominant "discrete tokens plus autoregression" line, and the multilingual table reports uneven results, without isolating which architectural choice caused them.

Recent updates: v2.0.3 (2026-05-11) — a pre-flight validator for training manifests; optional reference audio in fine-tuning data (packing format [103, ref_audio, 104, text, 101, target_audio, 102], with loss applied only to the target segment); a stateful StreamingVAEDecoder that processes only the newest latent patch and carries causal convolution state internally, removing redundant overlap decoding; safer LoRA loading with weights_only=True; a --device flag for cpu, mps, cuda and indexed devices. On main, preprocessing for fine-tuning data was sped up on 09-30, and two community PRs (i18n and Hugging Face training) landed on 10-08.

Who it's for: Teams building multilingual voice products that want local deployment, per-speaker voice cloning, and no per-minute SaaS pricing. Do one thing first: run your target languages through an intelligibility check instead of trusting the language count. Evaluate cloning variance with fixed settings and the full "reference audio plus transcript" mode; a fixed seed alone does not establish cross-device reproducibility. The project describes code and weights as Apache-2.0; verify the exact release files and any applicable usage conditions for the intended deployment; the README also asks deployers to run their own safety evaluation and forbids impersonation and fraud.

My take: ⭐⭐⭐

Checked: read the full README, the 2.0.1–2.0.3 release notes and the last six commits; no install, no benchmark run.

2. SnailSploit/Claude-Red ⭐ 8,579 · Python

GitHub: https://github.com/SnailSploit/Claude-Red

In one line: 78 structured SKILL.md files organised by security assessment surface, plus a written authoring spec. The spec alone does not establish specialist competence or correct triggering.

What it is: A content-only repository. Each skill lives at Skills/<category>/<skill>/SKILL.md, and the folder name must equal the name field in the frontmatter. Categories are cut by attack surface: web 16, wireless 14, infrastructure and red team 7, exploit development 6, fuzzing 4, and a dozen smaller categories with one to three each — 78 skills across 23 categories. Created in March 2026; the v0.3.0 release on 2026-08-30 reorganised 37 flat skills into this structure, and main has since taken community PRs only (an OSINT metadata viewer, a .DS_Store ignore rule, a skill-review pointer to the current commit).

What stands out:

• The authoring spec treats description as routing input. The spec asks for 50–500 words stating which surface the skill covers and when to use it, and explicitly tells authors to pack in the terms an operator would actually say while avoiding marketing language — that paragraph is what the model matches against. In the SQL injection skill, that one paragraph names error-based through NoSQL, GraphQL and WebSocket injection, WAF bypass, four database engines and ORM vulnerabilities.
• The body has a fixed skeleton. A framing paragraph, a numbered Quick Workflow for the field, sections per technique with copy-paste commands and payloads, a Detection / Defender View section, an Engagement Cheatsheet, and Key References with ATT&CK, CWE and OWASP identifiers, papers and advisories. Typical length: 200–800 lines.
• One skill per surface, with monoliths explicitly discouraged. The first contributing rule prefers focused skills over overview-style ones; the 14 wireless skills were split out of a single monolithic one. The split makes narrower descriptions possible; I have not measured whether it improves trigger accuracy.
• Bodies are intended to load on demand; that does not establish zero context overhead for the index. The intended benefit is avoiding loading every full skill body into every conversation. Actual loading and index overhead depend on the host tool.
• Red lines are part of the contribution rules. No hardcoded victim domains, customer data or credentials; every technique needs an attributable source.
• The roadmap admits what is missing. Nine phases, a target of roughly 130 skills, with five phases still planned: Active Directory, cloud identity, IoT, and two web phases. By its own count, coverage is around 60%.

Compared with: The checkable difference is at the engineering-constraint layer. I have not surveyed other skill repositories broadly enough to characterise their format rules; this one treats a skill as a reviewed deliverable, with mandatory frontmatter, a body skeleton, a length range, safety red lines and a phased roadmap. The content is not original either: the README credits an existing public offensive-checklist collection as the base for many skills. Whether other skill libraries also treat the description as a trigger key or run a review process is something I did not read enough to claim — I can only say this one writes those three rules down.

Recent updates: v0.3.0 (2026-08-30) grew from 37 flat skills to 78 across 23 categories, adding 20 skills in 10 new categories — container escape, CI/CD pipeline attacks, API security, cryptographic implementation attacks, privilege escalation, post-exploitation, anti-forensics and C2, supply chain, social engineering, network-layer attacks. Wireless became 14 per-surface skills (802.11 recon, WPA2/3, EAP, WPS, evil-twin, BLE, Zigbee, Z-Wave, LoRa, sub-GHz and more). 09-19 merged four community PRs at once; 10-12 refreshed the README counts and index.

Who it's for: Two audiences. People writing agent skill libraries should borrow the format spec — how to write the description, how to section the body, how long to make it — because those rules transfer to any domain. People doing authorised penetration testing and red-team exercises can use the content, but should re-check freshness, since exploitation write-ups age fast. Licence: MIT. One thing must be said plainly: the content is attack methodology and belongs only on targets with written authorisation.

My take: ⭐⭐⭐

Checked: read the README, the contributing guide, the v0.3.0 release notes and the last six commits, and read Skills/web/offensive-sqli/SKILL.md in full; no install.

3. autonomous-ai/openharness ⭐ 1,358 · TypeScript

GitHub: https://github.com/autonomous-ai/openharness

In one line: One window for coding agents spread across several machines — a daemon per machine, agents inside tmux, direct encrypted links between machines.

What it is: A multi-machine, multi-engine agent console. It supports 14 engines (Claude Code, Codex, Cursor, OpenCode, Devin, Amp, Copilot and others), and its store carries 49 craft-specific bundles — Blender, KiCad, FreeCAD, MuJoCo, RDKit, Typst, Strudel, vLLM and more — each a folder with a harness.json that gives an agent the tools and a live viewer for that craft. Created 2026-08-04; within about two and a half months it reached CLI 0.4.60 and web 1.3.66, with changelogs that often run to a dozen entries and pull-request numbers already past #1675 — a rapid release cadence, which does not itself establish reliability or adoption.

What stands out:

• It does not wrap the agent. Each agent runs in its own tmux pane, so scrollback, colours and keys behave like a real terminal, and each session gets its own git worktree so the main checkout stays clean. The README states it never wraps an agent: it reads transcripts and uses the vendor's own hooks. Compatibility still depends on transcript formats and vendor hooks; I have not tested upgrades or the extent of state visible through those interfaces.
• The daemon only dials out. One daemon per machine connects outward, which the project says avoids opening inbound ports, supplying SSH keys or configuring an overlay network and port forwarding for its supported connection flow. I have not audited network exposure. Adding a machine is a few commands on the target plus entering a password in the app.
• Three transport tiers, with automatic fallback. Direct machine-to-machine WebRTC first, when a direct route is available; then Cloudflare's TURN network when a firewall blocks the direct route; then its own relay as a bridge, holding no keys and forwarding ciphertext. The project documents ChaCha20-Poly1305, X25519 session keys and pinned Ed25519 identities. This is a protocol description, not an independent security audit. Remote terminals stream text bytes rather than pixels, so no remote desktop is involved.
• A native app, not a browser shell. It is written in Flutter, and closing the window leaves agents running. The project publishes idle measurements on an M2 Max with 16 terminals of 1,000 scrollback lines in a release build: UI response 11–13ms median and 15–18ms p95; local terminal echo 1.1ms median and 7.2ms p95 excluding rendering; about 0.1% of one CPU core and 304MiB resident, including terminal rendering and scrollback but excluding agent processes.
• The collaboration layer is still moving. Sessions in the same tab can message each other through a command, marked experimental and off by default. There is also a Swarm mode with per-project custom roles and a Lead role, and removing a machine cascades into cleaning up its roles, folders and worktrees. On 10-23 alone the release notes cover per-project roles, machine removal with cleanup, and recoverable resume failures.
• The hardware is open too. An optional desk device: ESP32-S3, a 466×466 round AMOLED with touch and microphones, connected to the daemon over USB, with firmware, PCB (including Gerbers and a bill of materials) and enclosure files (STEP and STL) all in the repo. Its job is to show which agent is waiting on you.

Compared with: Against the "multi-agent terminal manager" category, it puts three decisions on the record: agents are never wrapped (transcripts and vendor hooks only), the remote path has its own three-tier fallback with a keyless relay, and the extension unit is a folder plus one JSON file. Four dimensions worth checking one by one, which I cannot settle for it: whether remote output is bytes or pixels, whether a machine must be reachable from the internet or joined through a third party, whether session state lives locally or on a server, and how machines authenticate each other. Those four decide who holds the data when something breaks.

Recent updates: CLI 0.4.60 (2026-10-24) — per-project custom Swarm roles that the CLI recognises; a machine owner can remove a machine from a Swarm with cleanup of its folders and worktrees; resume failures become recoverable; a fix for switching agents when an older daemon replies; and on Windows, Claude Code's > composer is now read as its prompt. A web build 1.3.66 shipped the same day from the same Flutter codebase.

Who it's for: People with two or more machines and two or three different vendors' coding agents in use. Two cautions: the collaboration interfaces changed repeatedly in the past two weeks, so do not weld long-lived processes onto them yet, and every machine needs the daemon plus acceptance of the "password plus pinned identity" connection model — a keyless relay means the relay stores no keys, not that the whole link has no trust assumptions.

My take: ⭐⭐⭐

Checked: read the full README, three release notes and the last six commits; no install, and performance figures are the project's own.

4. FengZhenfei/carrel ⭐ 463 · Python

GitHub: https://github.com/FengZhenfei/carrel

In one line: A self-hosted knowledge base for agents, where the retrieval service recalls evidence and does not generate answers.

What it is: Documents come in, get parsed (PDF, Word, PowerPoint, spreadsheets, images, HTML, Markdown, source code, using MinerU plus native parsers per format), chunked, and indexed for both vectors and keywords, with an optional knowledge graph on top. An agent calls a search endpoint to get source passages, images and related facts, then composes its own answer. It does not build its own components: Qdrant for vectors, OpenSearch for keywords, Neo4j for the graph, SQLite for file and task state. Created 2026-09-28, three releases in under a month, 463 stars and three forks — repository counters that do not establish production usage or reliability.

What stands out:

• "Retrieval does not generate" is a hard boundary. The stated division is that the service recalls, reranks and arranges evidence without generating. The upside is that one set of evidence can serve several models, without an answer-generation step in that service. Retrieval, parsing and evidence selection can still be wrong; answer quality also depends on those stages and the calling agent.
• It adds batch-invariant settings to reduce retrieval variation. Version 0.2.1 switched three model services to batch-invariant mode (VLLM_BATCH_INVARIANT=1), because scores had drifted slightly with batching and caching, so candidates near the top-k cutoff appeared and disappeared between identical searches. The release notes state the cost: text embedding and reranking keep their throughput, image embedding gets somewhat slower. Repeatability is useful for testing and diagnosis as well as reports. I have not reproduced the throughput or top-k stability results, and the setting alone does not prove complete determinism.
• Parsing is checked for consistency twice. Once before parsing against what the scan recorded, once again before writing back. A file whose content changed after the scan waits for the next scan, while a mere modification-time change is checked by hash, so retries and full re-parses are not blocked.
• Graph builds recover, with a retry cap. A build whose process died is marked failed by the next scan; a full build interrupted by a machine shutdown resumes under the same version, at most twice. The cap is itself a form of honesty — it prevents a silent infinite retry loop.
• Relations are leads, not evidence. The bundled 24KB search skill defines seven labels (source, fact, page, entity, relation, neighbourhood, neighbourhood relation) and lets later commands point back at results instead of copying IDs. Anything longer than one page must be read to the end before use, and only sources, facts and pages may be used as grounds for a conclusion — graph relations are explicitly leads. Writing "do not treat a relation as a fact" as operating discipline beats putting it in a design document.
• The access boundary admits its own gap. The console binds to localhost by default and the stores and model servers listen on loopback. The README warns that loopback binding does not by itself protect against web pages opened on the same host. I have not audited authentication, browser-origin checks or the complete access boundary.

Compared with: It does not build retrieval components itself, so its value is in orchestration and boundaries — who owns what, how evidence is labelled, when a conclusion is allowed. Two checkable differences are "retrieval does not generate" and "batch-invariant search". Whether comparable self-hosted RAG stacks also treat identical repeat results as a default goal, mark graph relations as unusable evidence, or verify parsing twice, I did not read widely enough to assert; those are the dimensions to compare.

Recent updates: v0.2.1 (2026-10-22) — batch-invariant retrieval; a stitched chunk beside a short hit now appears once in the sources; the two-phase parse check; dead graph builds marked failed and shutdown-interrupted full builds resumed at most twice; nightly cleanup that reclaims unreferenced parse caches; and an explicit explanation of path format when a path matches no document, instead of an empty result. On 10-20 the docs gained the author's real deployment on a DGX Spark and a pattern for using cloud-drive sync from a Mac or a NAS as the entry point.

Who it's for: Teams with a pile of documents that keep changing — contracts, policies, product material, meeting notes — where every answer must point back to the original passage. The prerequisite is accepting a Docker stack: Qdrant, OpenSearch, Neo4j and MinerU together, with resource needs depending on models and corpus size. The component list implies more deployment work than a single search process. I have not compared resource use or operating cost against a custom stack. Licence: MIT, with dependencies and model weights under their own terms.

My take: ⭐⭐

Checked: read the README, the v0.2.1 release notes and the last six commits, plus skills/carrel-search/SKILL.md; no deployment.

5. Renhuai123/ziwei-doushu ⭐ 6,975 · TypeScript

GitHub: https://github.com/Renhuai123/ziwei-doushu

In one line: A chart engine for Zi Wei Dou Shu astrology, plus a corpus of interpretations generated deterministically by that engine — 674,976 charts, 8.77 million interpretation segments, about 20.4 billion characters.

What it is: Two things in one repository. First, a chart engine in pure TypeScript, including the four-transformations system, more than 1,100 lines of pattern rules, three classical texts, and structured knowledge for 14 major stars across 12 palaces. Second, a corpus built with it: every real calendar date from 1950 to 2026, times 12 double-hour slots, times two genders — 674,976 charts, 13 dimensions each, totalling 8,774,688 segments, 56.6GB uncompressed and only 161MB compressed with zstd in 77 per-year files, so you can download just the years you need. Created in May 2026; open issues went from 18 down to 4 during the September cleanup and stand at 6. The early-October overhaul grew the core from 181 to 641 lines, added eight modules totalling 1,367 lines, and added the repository's first tests.

What stands out:

• The corpus is described as deterministic rule-generated text, without model inference. Interpretations are generated deterministically from the engine plus a phrase library, and the dataset carries a content version aligned with the live site. This supports regression checks against fixed outputs, but does not validate astrological predictions or establish that every input and rule is correct. Consistency with fixed rules does not establish predictive accuracy.
• Conventions are switches rather than opinions baked in. Leap months have four configurable placements (previous month, next month, split by day, current month); star brightness has seven levels, and different schools' — including different versions of mainstream software — judgements are switches too; the late-zi-hour day-boundary rule can be flipped. This is a direct answer to "one school, one program, no mutual recognition".
• Regression tests cover specified chart-engine conventions. The test suite runs 768 charts covering core rules, China's 1986–1991 daylight saving time, the start-of-spring boundary, specific star pairings, sample hour consistency, hour-index bounds, date validity and duplicate transformations in one palace; it runs on every push and PR. Since October the engine rejects non-existent calendar dates outright.
• Four licences, and the boundaries are clearer than the feature list. Code is MIT; datasets are CC BY 4.0, commercial use allowed with attribution; the three classical texts are public domain; 1,848 quoted lecture passages (each with a video timestamp) are under a non-commercial share-alike licence, and the dataset explicitly excludes those quotes from its own grant.
• "What is not open" is a table. Open: the engine, public-domain classics, structured knowledge, the demo UI, both datasets. Closed: the phrase library (the file in the repo is a placeholder), the AI interpretation prompts, backend APIs, user and payment systems, anti-abuse and watermarking.
• The README distinguishes demo code from the production system. Chart page 75 lines versus 1,227 in production; interpretation panel 467 versus 5,088; chart board 285 versus 1,334. The README says the demo draws a chart but cannot produce the production interpretation, and separately discloses impossible dates in a 518,400-sample dataset: 2,520 rows (0.49%). That is a different denominator from the 674,976-chart corpus above; a promised future correction is not a verified corrected release.

Compared with: The base is not written from scratch; the stack names iztro and lunar-javascript, so the difference lies in the convention layer built on top. It lists six items: true solar time correction (longitude offset plus equation of time), China's 1986–1991 daylight saving time, four leap-month placements, the late-zi-hour boundary, seven brightness levels with school switches, and layered starting rules for the twelve spirits. I checked both READMEs: iztro documents global configuration and a plugin mechanism for school differences in transformation and brightness tables, and its README does not mention true solar time or China's daylight saving time. This project implements both as separate modules and extends the birthplace longitude table down to county-level divisions. Whether iztro has another implementation in its source is something I did not read, so the fair statement is that at the README level these two are additions here.

Recent updates: dataset v4.0 (2026-10-15) — 71% larger than the previous version, with per-chart interpretation length rising from about 21,000 to about 30,000 characters; the project reports decompressing all 77 files and byte-comparing them against its source data before release. I have not repeated those checks. The project reports checking interpretation text against sources: quotations that could not be located were removed or replaced with verifiable wording, sentences about transformations that cannot occur were deleted, and classical citations grew from 244 to 405, each traceable word for word. On 10-20 the default brightness table switched to the Dou Shu Quan Shu, with missing minor-star brightness filled in and checked palace by palace against five reference charts.

Who it's for: People who want to study or build on Zi Wei Dou Shu without writing calendar conversion and chart logic from scratch, and people who need a large, structurally uniform domain corpus for retrieval or fine-tuning experiments — 674,976 input-output pairs, described by the project as CC BY 4.0 with attribution; read the dataset-specific licence and exclusions. Two cautions: the interpretations are deterministic, so do not expect them to read more like a person; and the production phrase library stays closed, so building your own interpretation means writing your own rules. The lecture quotations may not be used commercially.

My take: ⭐⭐⭐

Checked: read the full README, the v3.0, v4.0 and engine release notes and the last six commits, plus iztro's README to verify the base; no install.

At a glance

This week's notes

• Skill files are starting to be treated as deliverables with a format spec. Two unrelated projects are writing the same thing: one requires that a skill description act as a routing key, that the body follow a fixed six-part skeleton, and that each skill cover one surface; the other requires that anything longer than a page be read to the end, and that graph relations be treated as leads only. The shared premise is that a skill is an index loaded on demand, not a pile of prompts — larger bodies and broader descriptions need measured trigger and context-budget tests; length alone does not establish trigger error.

• Several projects document reproducibility or recovery mechanisms. One project reports slowing part of its pipeline to reduce variation between identical queries; one insists that 20.4 billion characters of corpus never pass through a model; one spends half its weekly release notes on how state recovers and how removed machines get cleaned up. Different directions, one question: when something breaks, can you restore the state.

• Published failure cases help choose what to test. A multilingual table shows 1.1% error in one language next to 13.0% in another; a README lists the line-count gap between demo and production page by page and adds that 0.49% of its samples carry impossible dates. Those disclosures expose test cases. They do not establish overall maturity or the correctness of the remaining samples.

• "Supports N languages" and "works in each language" are two different numbers. Coverage is a total; selection is a single column. This is the easiest thing to misread this week: per-language results and the intended workload need to guide deployment; this table alone does not establish a defensible count of deployable languages.