開源雷達 · 2026-10-25：技能套件不只有操作手冊，還加入檢查流程

By Renchao Wu. Originally published on widechaos.cn.

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-25.

1. lemomo-ai/lemo-opuscar ⭐ 6,719 · JavaScript

GitHub: https://github.com/lemomo-ai/lemo-opuscar

In one line: A library of 59 film styles, each with a demo film rendered entirely by code, packaged as a skill a coding agent can call.

What it is: The README's author says he made every film himself ("Every film here was made by me"). In 29 days the author produced 59 styles, each one a style description plus a demo film. The showcase is a 6:31 film that redraws all 98 Best Picture winners from 1927 to 2025, each in a style that fits it (77 in 2D, 4 in 2.5D, 17 in 3D), with every frame and every note written as code and rendered frame by frame through canvas and WebGL. Two guide documents ship with it: one on directing (story, sound, rhythm, camera, self-checks) and one on building (rendering, voice, music, mixing). The README states plainly that the styles were tuned against one specific model, and other models may not reproduce them.

What stands out:

• No video generation model and no stock footage. Picture is rendered by code, music comes from free sample libraries, narration is text-to-speech. The output includes re-runnable rendering code. Details can be edited in that code and rendered again; I have not tested repeatability across models or machines.
• Style and story live in separate files. A style file defines only what it looks and sounds like; the story stays with the user. That is how 98 films can share one pipeline and each get its own style.
• "Make a style your own" is a pipeline with checkpoints, not a single request. It asks about purpose, platform and brand colours one question at a time, sorts what can change into safe to change / changes the character / cannot change, then renders one real style frame (side by side with the original when you are modifying a library style), then makes a 15 to 30 second demo with music and sound effects, and only then asks whether to keep it. Kept styles go into your own directory and can be named later.
• Cost is stated up front: the README's Before you start section says one film takes an agent 30 to 60 minutes and a fair amount of tokens; default output is 1920×1080 at 24fps.
• Three licence layers: code and docs are MIT; demo films and stills are CC BY 4.0, commercial use allowed with credit and a note on changes; films you make with the library are yours with no credit needed. Third-party assets in the demo films keep their own licences (see each demo's CREDITS); films being yours does not remove those obligations. Three voice tracks are explicitly excluded from CC BY, and the author says not to reuse them.

Compared with: The deliverable includes rendering code that can be edited and rendered again. That gives a different revision path from requesting a fresh video generation.

Recent updates: On 2026-10-24 the 6,000-star thank-you film replaced the 5,000-star cut (1080p60). On 10-22 four commits landed in one day: eight Edit & Documentary styles cut from real archive footage, documents and data, a second version of the make-it-your-own flow, and an English pass over the whole library. On 10-16, eight Evidence Films styles arrived, built around sourced numbers.

Who it's for: People who want an agent to make short films in a chosen style and can accept the model and machine constraints. Note the model binding and the machine requirements (Node, ffmpeg, Python); the time cost is the README's 30 to 60 minutes per film. If the work is a daily talking-head clip, compare a ready-made template before committing.

My take: ⭐⭐⭐. Whether the films are good is a matter of taste, but the package structure — general guides, per-style books, and a loop for making your own — is the most complete skill package among the five I read this week.

Checked: read the README and four releases; not installed.

2. Osmantic/ODS ⭐ 7,677 · Python

GitHub: https://github.com/Osmantic/ODS

In one line: The documented installer sets up an AI server core, with optional services for voice, workflows, retrieval and image generation.

What it is: Osmantic Deployment System. The default install is a minimal core — local inference, dashboard, chat UI — while voice, workflows, search, RAG, image generation and observability are added from the installer menu or the extensions page, already connected. Every service is an extension: drop in a folder, run one enable command. The installer detects the GPU, picks a model, generates credentials and starts services; it brings up a small model first so the UI is usable while the large one downloads. On Windows a PowerShell block sets up WSL2, installs Docker, pulls Ubuntu and then installs inside it.

What stands out:

• It manages orchestration at the configuration level: which service gets which GPU, how secrets are generated, how ports are remapped, how a failed change rolls back — all written into the install and extension flow. SECURITY.md says the installer generates credentials with openssl rand and writes .env with mode 600. Public web services bind to 127.0.0.1 by default, but the host agent does not: the Windows native installer defaults to 0.0.0.0, Linux auto-detects a Docker bridge address, and /v1/* is protected by ODS_AGENT_KEY. Exposing to a LAN still means understanding the firewall and auth trade-offs yourself.
• Services as extensions: keep the core minimal, switch the rest on and off. Debugging can start with one service's logs and switches; dependencies between services still determine whether a fault spreads.
• The README describes outbound connections: the README says that by default it goes online only to download models and images, check GitHub for ODS releases, and run web searches the Portal agent makes for you, and the FAQ explains how to turn each off.
• The downsides are equally specific, and printed on its own release page: v3.0.0 (2026-09-24) carries Pre-Release in its title; GitHub's prerelease flag is false. Its release notes and v2.6.0 carry security advisories (critical; v2.6.0 also high) and say the fixes are on main: the advisories belong to the old tags, and main has the fix. ods update refreshes container images only; picking up code fixes means re-running the installer. An older release pinned an image tag that no longer exists, so installing it failed.
• It runs without a GPU: cloud mode swaps local inference for external APIs on the same stack.

Compared with: The README prints its own comparison table against Ollama, Open WebUI, AnythingLLM and the n8n starter kits, arguing that it supplies the whole server. The orchestration it documents: GPU assignment, secret generation, port conflicts and rollback are all part of the install and extension flow.

Recent updates: On 2026-10-04 all three release lines got a security notice and an older release was marked deprecated. On 10-25 six commits in a row were fixes, all in the same direction: stop reporting unverified things as success (the diagnostic script now judges tool calling by a real call; the CLI no longer reports a template as applied when its services were never enabled). In July, 2.6.0 added remote providers, a model switchboard and GPU reassignment rollback.

Who it's for: People studying a self-hosted AI stack. Check the data paths for every enabled extension and provider, especially cloud mode. It is not a production base yet: V3 is still in public testing, the old tags carry a critical advisory, and the installer ships main, which adds up to asking you to carry the verification burden. The README says no release has qualified for the verified channel; waiting for a signed release is the reasonable move.

My take: ⭐⭐. Worth copying the design, not worth installing today.

Checked: read the README, three releases and SECURITY.md; not installed.

3. yamadashy/repomix ⭐ 29,013 · TypeScript

GitHub: https://github.com/yamadashy/repomix

In one line: Packs a whole repository into one model-friendly file, with token counts, structural compression, a secret scan, and optional output as an agent skill directory or an MCP server.

What it is: A tool that started in July 2024 and now ships in many shapes — CLI, web app, browser extension, editor extension, Docker image, GitHub Action, and as a library. Input is a directory or a remote repository; output is one packed file with token counts per file and for the whole repository, in a choice of formats. Three releases from July to September: two minor versions, 1.17.0 and 1.18.0, plus the 1.18.1 patch. The last week of commits is dependency bumps.

What stands out:

• Content is graded by purpose: structural compression uses a syntax tree to keep class, function and interface signatures while folding away the bodies, and per-path patterns let different files get different levels of detail instead of one global setting. That is structural compression; it does not replace testing the generated code.
• Token count is a first-class output: one flag prints the directory tree annotated with token counts, optionally only files above a threshold, so you can size the job before packing it.
• It can generate an agent skill package: one flag produces a standard skills directory — skill description, summary, project structure, all file contents, detected tech stacks — from a local or remote repository, and it runs non-interactively for CI. That is a ready-made path from a reference implementation to an asset an agent can search.
• The MCP server has a sandbox mode: by default it can read any path the host user can, which is too wide; sandbox mode locks paths to one workspace and refuses absolute paths, home directory, parent traversal and Windows drive or UNC paths, while disabling remote packing and skill generation. The release notes call this application-level confinement, not an OS sandbox; hosting it for untrusted clients still needs containers or a dedicated user.
• It scans for secrets by default: a secret scanner runs after packing and lists suspicious files with a warning. It recognises known secret formats only; it is not a guarantee that nothing leaked.
• Remote configuration is treated as data you must not trust blindly: a config file is executable code and can run external commands, so loading one from an unfamiliar repository requires confirmation — that became an interactive prompt in the August release.

Compared with: One artifact can take three forms — packed file, skill directory, MCP tool; compression is graded per path and token counts ship with the pack. Token savings depend on the repository and how it is used, so I do not put a number here.

Recent updates: 1.18.1 on 2026-09-21 closed a real attack surface — packing runs a few git commands in the target directory, and a repository's own .git/config can name external programs such as gpg.program, diff.external, textconv drivers and core.fsmonitor, so a crafted repository (inside a zip, say) could run arbitrary commands during a pack; a normal clone does not carry the remote's git config, and --remote removes the clone's .git, so that path was not affected. 1.18.0 in August added the MCP sandbox. 1.17.0 in July added custom file processors (run a command on matching files before packing, for example converting JSON to a more token-efficient format) and confirmation before trusting a remote config.

Who it's for: Anyone who feeds unfamiliar repositories to a model often, and teams that want to accumulate a reference-implementation library for their agent. Two caveats: structural compression is marked experimental, and packing code out of the machine is itself a risk — the secret scan is a warning, not a guarantee.

My take: ⭐⭐⭐. Its value comes from turning "what does the model see, and how much" into a repeatable step; the feature count matters less.

Checked: read the README sections on features, compression, skill generation and security check, three releases and the last six commits; not installed.

4. elizaOS/eliza ⭐ 19,649 · TypeScript

GitHub: https://github.com/elizaOS/eliza

In one line: An agent runtime plus desktop, web and mobile apps, a CLI, cloud services and a set of first-party plugins — and one layer further out, tooling that turns a whole device into this system.

What it is: A monorepo. The core package defines the runtime, types, authorization, memory and state primitives, and the plugin contract. Above it sit the package that wraps the runtime into a standalone agent with an HTTP backend, the application host, and a shared UI. The app's capabilities all come from the runtime and installed plugins: chat, voice, memory, knowledge, documents, messaging connectors, calendar, reminders, inbox, goals, health, browser and desktop automation, native bridges to camera and contacts, non-custodial EVM and Solana wallet operations with approval boundaries, scheduled workflows, coding-agent orchestration, and installable app views. Availability depends on the operating system, installed plugins, permissions, and the configured model or service provider. A separate set of packages builds bootable Linux and Android images.

What stands out:

• The plugin contract lists nine things a plugin can register: actions, providers, evaluators, services, model handlers, routes, events, tests and app views. An evaluator is a registrable judging routine that can score or decide whether a task completed; an app view lets a plugin ship its own UI. That is finer than "a tool is a function".
• Local inference is a built-in path: the Eliza-1 registry lists 2B, 4B, 9B and 27B text tiers based on Gemma 4, plus local embeddings, speech, vision and image generation. Each capability is routed to local, a direct provider or its own cloud depending on the hardware, and machines that cannot run locally are not forced to.
• Whole-device distributions: the goal is not an app install but a device running the system.
• The contribution rules are an anti-slop template: issues must be written by hand and agents may not create them; a change must prove itself with before-and-after behaviour or a score; no unnecessary tests or defensive code; every UI change needs a video walkthrough, desktop and mobile screenshots and reproducible steps; issues and pull requests must be written in Simplified Technical English. Violations get closed and penalized.
• Third-party plugins are no longer accepted: only the first-party runtime and apps are maintained, and outside registry items are closed.
• Pick a version by separating the product beta from the evidence store: 14 of the 17 items on the release page are evidence-asset stores for pull requests, and the product version sits at a beta from the end of June.

Compared with: This repository's centre of gravity is an agent that ships to a device: it brings its own UI, native bridges, local inference and distribution tooling. The repository includes an application layer; I have not verified installation or the availability of every listed capability.

Recent updates: On 2026-10-25 a dependency was locked to a patched version and CI fixes landed for gateway image convergence and for stale searches blocking unrelated messages. Since July the pull-request evidence stores have kept expanding because a single release is capped at 1,000 assets. The last three product betas were 2026-06-26 to 06-28, with no product release since.

Who it's for: Anyone studying how to layer an agent runtime, draw a plugin contract, or route local models per capability will get their time's worth. Anyone wanting it as a stable dependency should get it running themselves first.

My take: ⭐⭐. The architecture reads well; the release page is mostly an evidence store right now, so get it running yourself before relying on it.

Checked: read the README and the release list; not installed.

5. pollen-robotics/microduck ⭐ 11,071 · Rust

GitHub: https://github.com/pollen-robotics/microduck

In one line: The brain of a 25 cm, 800 g biped robot duck — a set of Rust daemons running a 50 Hz control loop over fifteen servos, driven by reinforcement-learning policies.

What it is: The company behind Reachy open-sourced the runtime of the whole duck. The control loop and motor bus, the updater, configuration, Bluetooth, gamepad, camera and depth sensing are each a single-purpose process, and between them there is one remote-call contract over local sockets, so the app, the console, a gamepad and your own script send exactly the same calls. The policies live in a neighbouring repository: trained in MuJoCo with PPO, domain-randomized, exported to ONNX, loaded here. The skills include walking, switching to a roller mode with wheels (which loads a different brain), picking something up beak-first, standing up after being knocked over, sitting, kicking a ball, and quacking in its own voice.

What stands out:

• The documented clients use the same contract. The README describes phone, CLI, gamepad and scripts using one contract. I have not audited every internal path or tested equivalent permissions.
• Updates are reversible and health-gated: the README says each update is signature-verified and followed by a health check, an unhealthy robot is rolled back, and a version can be pinned.
• Development signatures and shipping signatures are separated: the release notes say branch builds are signed with a development key and a customer robot refuses them by default; installing one requires the public key on the board and explicitly allowing development keys.
• The project documents a simulator that reuses its daemons: The documented simulation drives a body in a physics engine, with one duck or multiple simulated machines. It supports software development without establishing hardware behaviour.
• Failure notes are first-class: one directory explains why things are the way they are, another records what has gone wrong and what would close it.

Compared with: The runtime boundary this repository documents is single-purpose processes behind one contract, an update path that is its own process, README-described signature checks, health checks and rollback, and a simulator that reuses production code instead of a second mock layer. There is no middleware abstraction: processes talk over a contract and a socket, so extension rests on convention. Whether this duck actually walks steadily, I cannot say without the hardware.

Recent updates: On 2026-10-19 the 0.17.8 release was published. Three branch builds after that changed the encoder to import dmabuf, stopped the media process from downscaling, and reworked the gamepad path (the duck opens its beak and the laptop makes the sound). Branch builds were still shipping on 10-24.

Who it's for: People studying health-gated updates for embedded or robotic systems, and anyone who wants to read a small, complete multi-process runtime. Buying the duck is a separate matter — this repository is its brain, not its assembly guide.

My take: ⭐⭐. The hardware is irrelevant to most readers, but the three disciplines — one contract, a health gate, separated signing keys — are general.

Checked: read the README, three release notes and the last five commits; no hardware, not installed.

At a glance

This week's notes

• Skill packages are growing three layers: general guides, per-item books, and a loop for making your own. A single file that explains a workflow is missing the part where you check whether a change was made correctly. The film-style library offers a copyable order: render one real frame, compare side by side when modifying someone else's style, make a short demo, and only then save.

• A hardware project is talking about signed releases while a software stack says install the main branch. The first uses keys to separate development builds from customer devices; the second puts security advisories on old tagged releases, says the fixes are on main, and explains that updating only refreshes images, so code fixes mean re-running the installer. Both write down what gets installed and what gets verified.

• Packing tools now produce agent assets as a side effect. One repository can become a packed file, a skill directory or an MCP tool, which turns "what the model sees" from a one-off action into a file you can keep.

• Pick a version by separating the product beta from the evidence store. One project this week has 14 of 17 release items as evidence attachments for pull requests, while its product version sits at a beta from the end of June; stars do not show that difference, the release page does.