Open Source Radar · 2026-10-17: Vendors start shipping agent skills

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

Feature, security and performance descriptions come from project documentation; I did not independently validate claims unless an entry says so.

1. android/skills ⭐ 8,132 · Kotlin

GitHub: https://github.com/android/skills

In one line: Google's official library of 30 skill files covering the places where models fumble Android engineering work, ready to drop into a coding agent.

What it is: A versioned, dated skill artifact. The body is Markdown, spread across 18 domains — build, performance, camera, Play publishing, Wear, TV, automotive, testing and more. The Kotlin label comes from the build scripts, not from the skills themselves. The repo was created on 2026-03-16 and had shipped 27 releases by 10-14, with the last commit on 10-16, eight contributors and 37 open issues.

What stands out:

• Topics are chosen by evaluation, not by author interest. The README says it focuses on use cases and workflows where evaluations show LLMs underperform, and explicitly deprioritizes what models already do well (the example given is basic Jetpack Compose best practices). That is the bar for entry: every skill has to say where the model went wrong and what changes if you follow it.
• The skills carry version detection. Take r8-analyzer: the body first checks the AGP and R8 versions — AGP ≥ 9.3.0 goes through a Gradle task, R8 ≥ 9.3.7-dev goes quantitative, everything else falls back to heuristics. Commands that must actually run are marked MUST, with scripts and references alongside. This is the branch structure of an executable program, not a prompt.
• One copy of the content, three kinds of agent. Claude Code, Codex and Gemini each get their own distribution descriptor, while the content is maintained once instead of rewritten per vendor.
• Official identity, closed to outside contributions. The README states that public contributions are not accepted at this time and only issues are taken. Authority comes from Google's backing rather than the crowd; the cost is that coverage can only follow the official toolchain.

Compared with: The two direct comparisons are Anthropic's anthropics/skills and the community-collected awesome-claude-skills. The first teaches how to write skills — methodology and general samples; the second is large and uneven in quality. Two distinctions here: vertical depth, with specific failure points (redundant R8 keep rules, edge-to-edge adaptation, Media3 Cast integration, Leanback migration to Compose TV) each written up as a procedure; and selection discipline, where evaluation results rather than popularity decide what gets written.

Recent updates: v1.0.15 (2026-10-14) bulk-updated skill content and bumped the plugin version; v1.0.14 (10-12) changed plugin configuration. Lately a release every two days suggests the distribution layer is still being trialed. Release bodies are a single version line; the substance is in the commits.

Who it's for: Teams writing Android, and anyone doing Android work with a coding agent. The domain is Android only — other stacks get nothing here. Not accepting outside contributions means an uncovered failure point can only become an issue while you wait. Skills are written against toolchain versions, so a major upgrade means checking them again.

My take: ⭐⭐⭐. The content only helps Android, but "let evaluations decide which skill to write" transfers to any skill library.

Checked: read the README, release list and recent commits; did not install.

2. melgarafael/DeskcommCRM ⭐ 4,646 · TypeScript

GitHub: https://github.com/melgarafael/DeskcommCRM

In one line: A self-hosted AI sales and support system that puts a WhatsApp inbox, a CRM pipeline and an AI agent with RAG and memory into one application.

What it is: A business system that turns "how an AI agent gets managed" into product features. Next.js 16 plus Supabase (Postgres, Auth, Storage, Realtime, pgvector), with two WhatsApp channels: a QR-scan gateway or Meta's official Cloud API. Created 2026-04-28, with 161 contributors and 109 releases — a new version every other day; 315 open issues, and recent commits are almost all merged PRs, so the outside contribution flow is steady. The README says it runs in clinics, real-estate agencies, paid-knowledge businesses and retail stores.

What stands out:

• Governance lives in the feature layer. Per-tenant RAG, the AI as a "first-class assignee" (it can be dispatched work, handed off and counted), an audit trail when the AI hands a conversation to a human, a per-organization spend cap, and a built-in MCP server. Those four answer who catches it when the AI errs, how much it costs, and whether data leaks across tenants.
• Self-improvement comes with a human gate. Resolved conversations become new knowledge; the agent proposes improvements to itself; applying one makes a new version, but a human must approve it. The backend also shows whether the agent is getting better or worse, and where it goes wrong.
• Multi-tenancy is a hard constraint. Every tenant-aware table has RLS, and isolation tests act as a CI gate. The project documents an append-only audit log with five-year retention and anonymization where possible. I did not assess its legal compliance.
• It acknowledges the risk controls. The QR channel has throttling, jitter and time windows, and the interface translates "why am I rate-limited" into plain language. The official channel goes through Meta Cloud API with approved templates.
• The cost model is honest. Self-hosted, no monthly fee, no locked features; revenue comes from VPS affiliate links and installation services, not licenses. That is why it does not have to cripple features to sell a tier.

Compared with: The open-source comparison that matters is Chatwoot — also self-hosted, also WhatsApp, also a multi-channel inbox. Chatwoot's core is an inbox for humans plus automation rules, with AI attached through bots and webhooks. Here the agent is the seat itself, with RAG, skills, memory, spend caps and handoff auditing: the system still works without AI, and with AI present the AI is a first-class citizen. The other split is MCP, which opens CRM capabilities to the outside agent ecosystem instead of locking them into a proprietary plugin marketplace. Its own benchmarks, Kommo, Octadesk and Intercom, are commercial SaaS and not open-source comparisons.

Recent updates: v1.84.0 (10-16) covered billing and plans: once billing is enabled you must name a default signup plan, or the Google sign-in entry disappears, signups without a plan are rejected, and the tenant provisioning endpoint returns 409. A plan with a zero-day free trial sends new businesses straight into a suspended state. v1.83.0 (10-16) merged inbox multi-select and bulk operations into a single route, after users complained about toggling things on and off. The repo also carries a spec document for an external agent governance contract, so the open interface is written down rather than merely promised.

Who it's for: Small and mid-size teams that want to self-host sales and support on WhatsApp and have someone to maintain a VPS and Supabase. The QR channel is an unofficial gateway, so account risk is yours. The interface is in Portuguese, and the documentation is written around LGPD; I have not assessed its compliance in any jurisdiction. What is really worth taking is the acceptance checklist for those four layers of governance, not the business code.

My take: ⭐⭐⭐. Anyone can wire up RAG; not many make handoff auditing, spend caps and tenant isolation default behavior.

Checked: read the README, release notes and recent commits; did not deploy.

3. storytold/artcraft ⭐ 30,757 · Rust

GitHub: https://github.com/storytold/artcraft

In one line: An AI image IDE for artists, designers and film people: block out the scene, camera and pose in 2D/3D first, then pick a model to render stills or video.

What it is: A desktop application built around "build the shot before generating", which calls itself The IDE for artists — canvas and scene on the left, model picker on the right. Windows and macOS have official builds; on Linux you compile it yourself. Created 2022-03-31, with 28 releases and 436 open issues, but only three contributors: a very small core team making a lot of noise. The repo is 1.31 GB, most of it sample media. Recent commits cluster on 10-10 to 10-11, rewriting the desktop client in pure Rust.

What stands out:

• Blocking the shot before generating is the line between it and prompt tools. Image to Location places characters into reusable environments with multiple cameras in the same room; 3D Image Compositing layers background, foreground and props by depth; Character Posing sets the pose before the camera; Kitbashing assembles 3D assets to get occlusion right.
• Character consistency is a first-class requirement. Character Identity Transfer uses a posed mannequin to drive a character's position and posture. The hardest part of serial content is the same person staying the same person across frames; here it is a feature, not a prompt trick.
• Models change, workflow does not. 62 models in five classes: 16 image, 25 video, 5 music, 11 3D mesh, and 5 world and Gaussian splatting, covering FLUX, Seedream, Kling, Veo, Sora, Suno, Hunyuan 3D and other major families. Re-render the same scene with another model, and composition is decoupled from the model — that is the confidence behind calling itself an IDE.
• The license is moving wider. On 10-10 it went from a single license to MIT or Apache-2.0, and the same day shipped artcraft-native, a pure-Rust (egui) desktop client. Loosening a license usually means wanting to be embedded and redistributed.

Compared with: ComfyUI centres on a node graph; ArtCraft puts a saved 3D scene, camera and pose in the foreground. That is the workflow distinction I am interested in, rather than a claim that a ComfyUI extension cannot support scenes. Here camera, occlusion and pose are savable scene objects, and changing the camera is changing a parameter. Krea and Runway go the other way: cloud-integrated but tied to their own models. The split in one line: ComfyUI orchestrates a compute graph, ArtCraft orchestrates a photo studio.

Recent updates: 10-11 made the generation backend selectable per provider (Midjourney or fal); 10-10 added audio, in-app playback, animation preview and character references, and shipped the pure-Rust desktop client, starting with image and video. The official v0.41.0 (09-26) release body is only download instructions; the substance is in the commits.

Who it's for: People producing serial visuals where the same character and scene recur across images. Three obstacles: it is a desktop app, so Linux needs a build; most models are paid APIs and the aggregation layer runs through its own service; a three-person core team means the roadmap can turn at any time. Go in knowing you want reproducible composition.

My take: ⭐⭐⭐. Model aggregation stopped being a differentiator long ago; locking down camera and composition is. It turns that into reusable scene files.

Checked: read the README, release notes and recent commits; did not install.

4. fuxicodex/Fuxi ⭐ 3,340 · Python

GitHub: https://github.com/fuxicodex/Fuxi

In one line: A terminal AI coding agent whose pitch is cost-aware routing across providers and automatic failover.

What it is: Boundaries first: the source is closed, and the repo holds only documentation, an installer and scripts — which is why GitHub labels it Python while the product is a single static Go binary. The LICENSE says Proprietary. Three contributors, four releases, zero open issues, a 7,959 KB repo: the shape of a product launch rather than a community effort. It claims that roughly two million lines of code were all written in-house, which cannot be verified from this repo. The form factor follows Claude Code and Codex CLI: zero runtime dependencies, mandatory account login, and you can bring your own key.

What stands out:

• Routing sits in the kernel. Choosing among providers by cost, switching automatically on failure, and pooling multiple keys all live in the product rather than in wrapper scripts. Three commits in October worked this area: multiple keys per provider, key selection by fallback model, and configurable routing and fallback strength.
• Overages are made visible. The documentation describes an explicit notice when quota exhaustion rolls into extra usage.
• Permissions are explicit tiers. default, plan and bypassPermissions; even the widest tier still blocks extreme commands like rm -rf /, and root and sudo are refused outright on Linux and macOS.
• The privacy statement is specific. No code or session collection by default; with your own key, requests go straight to the provider; conversations upload only when the switch is explicitly turned on; credentials stay local.

Compared with: Claude Code, Codex CLI, OpenCode and Aider. Two splits: routing, where most terminal agents let you pick one model and run it to the end while this puts cost-based selection, failover and key pools in the kernel — real money for high-frequency long tasks; and distribution, a single binary with no runtime. Aider and OpenCode make their source available for changes. Fuxi does not expose its implementation in this repository, which limits this comparison to its documented behaviour. So its distinctiveness is at the product level, not something to borrow at the engineering level.

Recent updates: v0.1.8 (09-22) unified the rate-limit banner, moved the plugin marketplace to an official GCS mirror, and optimized long-session scrolling; 09-29 migrated the marketplace to the .fuxi-plugin format. The version is still 0.1.x, and 1.0 has not arrived.

Who it's for: People running frequent long tasks who care about token cost and do not want to install a runtime. If closed source, mandatory accounts or needing to modify source bother you, stay away. To study its routing design you can only infer from docs and commit messages.

My take: ⭐⭐. The routing is worth learning from, but with no line of code visible, what you learn is design only.

Checked: read the README, release notes and recent commits; did not install (the source is closed).

5. hmjz100/LinkSwift ⭐ 23,870 · JavaScript

GitHub: https://github.com/hmjz100/LinkSwift

In one line: A userscript that pulls real direct download links out of nine cloud-drive web pages and pushes them to Aria2, IDM and similar downloaders in one click.

What it is: A single-file browser userscript that handles only the "get the link" layer, leaving the download to a proper downloader. With a script manager installed, cloud-drive pages grow a download assistant: copy the direct link, export a cURL or aria2 command, or push straight to a configured downloader. Created 2022-08-10, with 64 releases and 38 open issues, but only six contributors — effectively a single maintainer. Almost every release follows a front-end redesign of the drives; the changelog is full of "adapted to the new page" and "fixed the button disappearing after the redesign".

What stands out:

• Nine drives, one UI. Baidu, Alibaba, China Mobile, Tianyi, Xunlei, Guangya, Quark, UC and 123 — different page structures, auth schemes and link signing, flattened into a single button. Every additional drive is another adaptation to maintain indefinitely.
• Downloading can start right after the link. Built-in push to Aria2 RPC (with multiple server switching), IDM, ABDM and BitComet, plus command-line export to run on a server. That is the difference between it and scripts that only copy a link.
• The compliance line is drawn hard. Two IMPORTANT paragraphs in the README: it calls only the public APIs of each drive, does not promise or implement any speed-limit bypass, and explicitly objects to being marketed as an accelerator. Most peers in this category pull stars with speed-limit cracking; this one gives up that selling point on purpose.
• It tidies the page too. Removes promo slots, unifies the theme color, adds dark mode with Dark Reader support. Pure download scripts usually skip this, and the gap shows.

Compared with: It descends from an earlier Chinese cloud-drive direct-link assistant, and against that upstream it widened from a few drives to nine, from a single IDM target to four kinds of downloader, and added page cleanup plus four years of continuous adaptation. Motrix and similar tools are the downloader that takes over after the link — upstream and downstream, not competitors. The real split is stance: plenty of drive accelerators sell speed-limit cracking, while this one uses public APIs only and publicly disclaims any acceleration.

Recent updates: stable v1.1.3 (2026-02-18) added IDM client settings and adapted Baidu's share page; v1.1.4 beta (09-09) added Guangya, adapted the 123 redesign, introduced eslint, and fixed the Xunlei popup and a false ABDM push failure; 09-10 fixed a memory leak in theme-color switching. The beta has sat for over a month without promotion, and stable has not moved.

Who it's for: People who need to pull large cloud-drive files onto a NAS or server without installing a client. Two boundaries: the repository uses AGPL-3.0; and it survives by matching the front-end DOM, so a redesign silences it — treat it as a manual tool and never put it on a critical path in automation.

My take: ⭐⭐⭐. Dirty work with a clean stance — refusing the speed-limit-cracking business is worth more than supporting a few more drives.

Checked: read the README, changelog and release notes; did not install the script.

At a glance

This week's notes

• Skill libraries are getting version numbers, so check which toolchain version one targets before you pick it. Skills used to be scattered notes; now they have versions and maintenance dates. Content written against a toolchain version can become stale after an upgrade, and being able to ask "which version is this written for" matters more than the number of skills.

• Star counts have shifted from an open-source signal to an exposure signal. To judge whether a repo is worth reading, contributor count, open issues, repo size and LICENSE are four more honest numbers than stars: a real project cannot hide its code volume or outside commits, and a docs-only repo cannot either. Check the LICENSE and the size first, then the stars.

• For generative tools the competition has moved from "more models" to "controllability". Aggregating dozens of models is table stakes; fixing composition, camera and character is the difference, and whether a result is reproducible decides if the output is a work or a lucky draw.

• Two projects today trade doing a little less for trust. The download script publicly denies that it accelerates anything, and the CRM makes AI spend caps and handoff auditing the default. Fewer features and clearly stated boundaries make it easier to put something into production.