Open Source Radar · 2026-10-31: Skill packs get an acceptance bar, SDKs start wrapping agents

By Renchao Wu. Originally published on widechaos.cn.

For this issue I picked five projects from GitHub Trending and topic-search candidates, all agent infrastructure: a skill pack, a rewritten headless browser, an Android agent, a multi-provider SDK, and a distributed inference mesh. 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-31.

1. jakubkrehel/skills ⭐ 9,398 · Markdown

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

In one line: A design engineer turned his interface-review method into 14 agent skills that plug into a coding agent.

What it is: The repository is Markdown only: 14 directories, each with a SKILL.md that agents discover through name and description frontmatter. better-interface is the orchestrator and routes a screen to six domain skills; accessibility, layout, writing, typography, colors, UI. interface-review, break, state-machine, variant, explain-interface and teardown are tools the user has to invoke. build-design generates UI from a Figma file or a design image. The material comes from the author's personal site and a design-engineering magazine rather than a copied checklist. The repo was created in July 2026, the latest commit is 25 October 2026, and there are no GitHub releases; the version number lives in commits.

What stands out:

• The orchestrator only orchestrates. The first line of better-interface is "Orchestration is all it owns." It dispatches, collects evidence and merges one ranked report; accessibility rules belong to the accessibility skill, structure to the layout skill. The intended separation keeps domain rules out of the router; I have not audited all fourteen skills for duplication.
• Approval has an evidence bar. Two sentences carry the method: "The bar for reporting is evidence. The bar for Approve is that you inspected what you claim to have inspected." It also separates a rule violation from a matter of taste: density, radius or voice are preferences, not findings; a trigger is a failure no matter what the style guide says.
• Scope is fixed before judging. If the scope is too large, it narrows to one complete flow, states the boundary and what was excluded, and never implies that uninspected surfaces were reviewed. The orchestrator is also forbidden to guess a diff: change review must be started by the user through interface-review.
• Which skills the model may not start is written into the skill. The pack marks user-invoked workflows in their descriptions; on a branch, PR or uncommitted change the orchestrator can only ask the user to run the review.
• The output is values, not adjectives. The UI skill covers border radius, optical alignment, shadow levels, icon states and animation parameters; the typography skill covers type scale, spacing, font features, wrapping and truncation.

Compared with: expo/skills, also in today's candidate pool, is the other kind of skill pack. Both are collections of SKILL.md files. Expo's is a vendor's engineering workflow for one framework, installed through the official Claude Code and Codex plugin marketplaces, and its README says Expo docs, the CLI and EAS CLI remain the source of truth while the skills help an agent apply them correctly. Jakub's set is an independent author's cross-cutting review of how an interface should look, distributed through skills.sh and npx. The difference is not the number of skills; it is whether the pack makes clear who may reach a verdict and who may start a skill.

Recent updates: A commit bumped the version to 1.17.0 on 25 October 2026 and added playback and annotation to the technical-illustration viewer; the same round renamed /technical-drawing to /teardown. No formal release; the project iterates on main.

Who it's for: People writing frontend code, maintaining a design system and already using Claude Code or Cursor. The skills are in English and assume the project has design tokens and a component library. If the project has no component conventions yet, run build-design first rather than expecting a review skill to invent a design. MIT licensed.

My take: ⭐⭐⭐. The design rules are learnable elsewhere; what is worth copying is the structure; the orchestrator only routes, the skill requires inspection evidence before approval, and some skills are off-limits to automatic invocation.

Checked: read the README, the full better-interface/SKILL.md, recent commits and the root LICENSE; did not install.

2. lightpanda-io/browser ⭐ 38,506 · Zig

GitHub: https://github.com/lightpanda-io/browser

In one line: A headless browser written from scratch for agents and automation; not a Chromium fork, not a WebKit patch.

What it is: The browser core and DOM are implemented in Zig; the README says it has no graphical rendering engine, JavaScript runs on V8, HTML parsing uses Servo's html5ever, and networking uses libcurl. It presents three faces: fetch dumps a page as HTML, markdown, PNG, PDF or structured data; serve starts a CDP server on port 9222 with a documented Puppeteer browserWSEndpoint example, not a guarantee of full Chrome CDP or website compatibility; mcp starts an MCP server over stdio or HTTP for an agent. The repo dates from February 2023; version 1.0.0 shipped on 2 October 2026, followed by 1.0.1 and 1.0.2 within three weeks.

What stands out:

• Export is a first-class feature. fetch --dump markdown returns readable text, and --dump structured_data returns JSON-LD, OpenGraph, Twitter card, meta and link tags as JSON, the same source as the MCP structuredData tool. For feeding pages to a model, that removes a home-grown HTML cleanup step.
• An agent session can become a replayable script. Drive the browser in natural language, run /save, and the session is exported as PandaScript; plain JavaScript over native browser primitives; then replayed with lightpanda run. The project calls these scripts deterministic and token-free. Replay can avoid model calls while still depending on changing pages, timing, authentication and network responses; I have not tested repeatability.
• MCP exposes separate browsing contexts. The README describes separate HTTP browsing sessions and context reuse through Mcp-Session-Id. Session identity is not the same as a TCP connection, an authenticated user or an audited security boundary. The session_new, session_list and session_close tools manage them explicitly.
• After 1.0 it has been filling in real-site compatibility. 1.0.0 made CORS enforced by default and built out classic HTTP WebDriver. 1.0.1 made MCP and agent modes load external stylesheets by default and raised the redirect limit from 10 to 20. 1.0.2 added Ed25519, X25519 and ECDSA in Web Crypto, plus WebCodecs and OfflineAudioContext.
• Telemetry is on by default. The README states that usage telemetry is collected and sent unless LIGHTPANDA_DISABLE_TELEMETRY=true is set.

Compared with: The difference from headless Chrome is mechanical. It does not carry Chromium's rendering stack, so page capture collapses into one fetch --dump, and an agent's exploration can be frozen into a script that needs no model at runtime; Chrome has automation and export paths too; I have not compared setup effort or output fidelity. The performance numbers need their source: the README's table reports 933 real pages over the network on an AWS EC2 m5.large, with 100-page peak memory of 123MB against 2GB for Chrome and 5 seconds against 46 seconds. Those figures are self-reported and collected by the project's own demo repository; I did not re-run Chrome on the same benchmark.

Recent updates: 1.0.2 on 23 October 2026 gave each top-level page its own session history, extended --block-private-networks to CGNAT, benchmarking, reserved and NAT64 ranges, and fixed a batch of Web API details. 1.0.1 on 15 October fixed stylesheet loading in MCP and agent modes and raised the redirect limit.

Who it's for: People building scraping pipelines who need JavaScript but not full rendering, and anyone who wants a lighter execution environment for an agent. Three limits come first: the license is AGPL-3.0-only, and the repository's LICENSING.md says only that the default license is AGPL-3.0-only, with no separate commercial terms; the reviewed installation instructions direct Windows users to WSL2; the distributed Linux binary expects glibc; do not assume that binary runs unchanged on a musl system such as Alpine.

My take: ⭐⭐⭐. It turns "a browser designed for agents" from a slogan into interfaces: structured export, recordable scripts, multi-session MCP. Version 1.0 is three weeks old, so long-term stability is unknown, but the direction matters more than the benchmarks.

Checked: read the README, the 1.0.0, 1.0.1 and 1.0.2 release notes, LICENSE and LICENSING.md, and recent commits; did not install.

3. wangzan101/Mika ⭐ 1,589 · Kotlin

GitHub: https://github.com/wangzan101/Mika

In one line: An Android-hosted agent designed to operate installed apps on a separate background display, browses the web and runs scripts, and can be called by AI tools on a computer over MCP.

What it is: You give it one sentence; it opens the target app on a separate background virtual display, reads the screen, taps, types and scrolls with concurrent phone use depending on Android version and application behaviour. When controls cannot be read it falls back to bundled text recognition, and with a vision model it can look at the screen to find buttons. Three more capabilities sit alongside: a built-in browser (desktop pages by default, logins preserved), a Linux sandbox per conversation (arm64, network off by default), and an MCP server over USB. The code is two Gradle modules: :core is pure Kotlin holding the main loop, tools, context, memory, knowledge and run records, testable on a computer with fake models; :app holds the virtual display, accessibility, WebView and sandbox. Capabilities do not reference each other, the core does not reference a capability, and one assembly layer wires them together; a dependency test guards that direction. The repo was created on 29 October 2026 and went from 0.1.12 to 0.1.14 in two days.

What stands out:

• A steer is an addition, not a restart. Inputs during a run are split into Steer, Redirect, Answer, Confirm, HandBack and Cancel. A steer cancels the pending model request, but messages already sent stay byte-for-byte and a tool call already handed to the executor finishes; the steer is appended before the next model call, so the context prefix only grows.
• Waits are interruptible without losing pacing. Plain waits, vision tools, conditional waits inside a batch and the dwell before a page change all sit behind an interruptible wait that ends with a "skipped for new message" marker. The unused part of a dwell or action interval is still owed by the clock and is paid before the next outward action, the design intends to preserve pacing after interruption; I have not verified the scheduler under races.
• Stopping leaves an account. After a stop, one model call (light model first, 12-second budget) writes down what was done, what was seen, how many outward actions were sent and what was left unfinished; if that fails, the run record is rendered directly. The next turn's context says "you stopped this task midway; before stopping: …".
• Delivery has a ledger and does not resend unknowns. States run Pending → Attempting → Delivered / Failed / Uncertain; the documentation says an uncertain send is not retried automatically. This avoids one duplicate-send path; it does not prove end-to-end exactly-once delivery.
• A process restart never resumes from the middle. The recovery design accounts for interrupted runs and pending replies without replaying screen actions. Pending replies must be distinguished from sends with unknown outcomes. The documentation's phrase is that screen state cannot be restored.
• Human hand-back is part of the flow. Every run carries Present, Reachable or Unattended. The current README asks for hand-back on login, verification codes and payment passwords. Inquiry mode asks before spending, while autonomous mode may proceed without that prompt; unattended and MCP payment paths have separate restrictions. Hand-back states do not prove that every consequential action requires approval.

Compared with: I did not find first-hand material on comparable projects this round, so I am not naming a competitor. The workflow differences I can confirm are the three the documentation states: three layers of screen reading (virtual display, accessibility, bundled OCR); a desktop browser and a local Linux sandbox without external hardware; and an MCP server that lets an agent on a computer call the phone, USB-only by default and token-protected. The scarcer part is the granularity of failure handling; those state machines are not a feature list, they are documented failure-handling choices, not independently verified recovery guarantees.

Recent updates: 0.1.14 on 31 October 2026 made the computer link an MCP server (USB plus token; payment confirmation stays on the phone) and fixed saving a provider such as Gemini getting stuck on a retired model. 0.1.13 on 30 October added starting from a computer over a cable, letting an AI agent on the computer perform the install, and an operation-pace setting (fast, standard, human-like) that slows down on apps with strict bot detection and caps the number of screens browsed per task.

Who it's for: People who want Android-hosted automation. The README explicitly says messages, screen content and screenshots go to the configured model provider; on-device execution does not mean screen data stays on the phone. The thresholds are real: the current README says Android 11 supports chat, web and sandbox tasks, Android 12+ supports app control, and Android 14+ is recommended for independent background-display focus; the sandbox is arm64 only; the author labels it a beta tested mainly on one Android 14 phone. The README also warns that automating third-party apps may violate their terms and risk restrictions or account bans. Apache-2.0.

My take: ⭐⭐⭐. The hard part of an on-device agent is not tapping accurately but accounting for failure; treating steers, stops, delivery failures and process restarts as first-class concerns is more instructive than the feature list.

Checked: read the Chinese README, docs/architecture.md, the 0.1.13 and 0.1.14 release notes, recent commits and LICENSE; did not install (no Android device at hand).

4. vercel/ai ⭐ 27,635 · TypeScript

GitHub: https://github.com/vercel/ai

In one line: Vercel's AI SDK, a provider-agnostic TypeScript interface; what is new in 7.x is that it abstracts agents as well as models.

What it is: The core is one entry point: a provider/model string supplied to generateText goes through Vercel AI Gateway by default, or through a provider package installed directly. On top sit ToolLoopAgent with a tool loop, structured output via Output.object() with zod, and framework-agnostic UI hooks. packages/ holds 84 directories: providers plus mcp, otel, policy-opa, code-mode, sandbox-just-bash, sandbox-vercel, tui and workflow. The current ai package is 7.0.159 (30 October 2026), and the v6 line still received a patch the same day.

What stands out:

• The abstraction moved from model to agent. packages/ contains 10 harness adapter directories for specific agents (including Claude Code, Codex, Cursor, Cline, GitHub Copilot and OpenCode) plus a generic ACP adapter. The usage is new HarnessAgent({ harness: claudeCode, sandboxConfig, tools }): the child agent reads and writes files and runs commands inside a sandbox, while the host passes its own capabilities in through tools. Both packages are marked experimental.
• Gateway by default, direct providers when needed. Without provider packages, one key covers many vendors; when latency, region or terms matter, use direct provider packages while retaining the high-level API. Provider options, supported features and data-handling terms still differ.
• The tool loop ships with the library. Model asks for a tool, the tool runs, the result is fed back, the model is asked again; that loop lives in a class, and the frontend consumes the stream through createAgentUIStreamResponse with input-available and output-available states to render.
• Some structured-output paths have a fallback. A recent Anthropic-related change maintains a tool-based JSON response path for some schemas. This is provider- and version-specific, not a universal guarantee that every unsupported schema is repaired or every task constraint is satisfied.
• The sandbox is a replaceable interface. The session interface gained stat, listDirectory and deleteFile, with relative paths resolved against the directory run and spawn start in; both the just-bash and Vercel Sandbox adapters implement it.
• It also ships a skill for coding agents. A README section called "Skill for Coding Agents" installs SDK guidance with npx skills add vercel/ai, so the documentation's audience includes agents, not only people.

Compared with: Against calling each provider SDK directly and writing your own retries and tool loop, the difference is a verifiable workflow: one interface covers text, structured output, tools, streaming UI and sandboxes, and the high-level call pattern can stay similar when switching providers; feature compatibility still needs testing. The harness layer goes further and treats an existing coding agent as an orchestration component instead of asking you to rebuild one. The limits are equally clear: it is a TypeScript SDK, so Python is not its native integration surface; a Python service can still communicate with a TypeScript service over an API; harness and ACP are experimental and recent commits still add required callbacks; the model-string default uses a commercial gateway, while direct provider packages offer another path. Self-hosting the application does not by itself make model inference local.

Recent updates: 7.0.158 on 30 October 2026 added stat, listDirectory and deleteFile to sandbox sessions. A 31 October commit made harness-acp require new resolveHostToolCall() and isMcpToolCall() callbacks, and tool-web-fetch now returns network_error for an invalid redirect instead of throwing. 7.0.159 was a dependency bump only.

Who it's for: TypeScript and Node teams building multi-model products or agent frontends, and people already using Claude Code or Codex who want one orchestration layer. Apache-2.0 (I read the root LICENSE). Treat harness as experimental because its interface is moving, and if production must avoid the commercial gateway, write the provider packages and failover before launch.

My take: ⭐⭐⭐. Provider abstraction has been table stakes for a while; the real signal is that it now abstracts agents, which makes existing coding agents available as components. It does not establish market saturation or reliable interchangeability.

Checked: read the README, packages/ai/package.json, the harness and harness-acp READMEs, release notes, the root LICENSE and recent commits; did not install.

5. Mesh-LLM/mesh-llm ⭐ 3,687 · Rust

GitHub: https://github.com/Mesh-LLM/mesh-llm

In one line: It pools GPUs and memory across machines and exposes the result as one OpenAI-compatible endpoint.

What it is: Two product trees share one Cargo workspace. Skippy owns model management, native inference, split execution and OpenAI serving; Mesh adds peer discovery, transport, routing, plugins and a web console. The README describes mesh-llm serve --auto as selecting a backend, potentially downloading a model and joining a public mesh, with API and console ports 9337 and 3131. This is a documented default, not a recommendation to send private prompts to discovered peers. The scheduling rule is single-machine fit first: if one node holds the whole model it serves locally with no stage traffic; otherwise layers are split into contiguous ranges, downstream stages start first, and the stage-0 route is published once they are ready. The project describes QUIC-encrypted peer transport, public meshes are discovered through Nostr, and private meshes use invite tokens.

What stands out:

• Fetch shards by package instead of downloading the whole model. A package repository holds model-package.json plus GGUF fragments, and each peer fetches only the pieces its stage needs. The larger the model, the more this "shard as deployment unit" matters.
• Single machine first, so distribution is not a default. --local-model-only bypasses the mesh entirely and serves one local process; that path skips discovery, splits, plugins and the console, so tool-calling production traffic is still expected on the normal mesh port.
• Encrypted transport does not mean peers cannot see content. QUIC encrypts node-to-node traffic and relays forward encrypted packets without reading them, but on a public mesh the peer serving a request still sees the request and response. The project does not dress this up as a privacy guarantee.
• The mixture-of-agents gateway is experimental. A request with "model": "mesh" fans out to every model in the mesh and the project describes a code arbiter that merges answers and may escalate conflicts to a reducer model. A deterministic arbitration rule does not make model outputs deterministic or prove conflicts were correctly identified. The project marks it experimental and says semantics will change.
• Compatibility rests on its own matrix. It tracks llama.cpp family parity: the project reports 72 P0/P1 family rows and 89 rows labelled certified in its inventory; it labels split multimodal support for Qwen2-VL, Qwen3-VL, Qwen3-VL-MoE, HunyuanOCR/Hunyuan-VL and DeepSeek-OCR.
• It puts "not usable yet" on the front page. The README lists three distribution and loading bugs still blocking the native Windows path as of v0.76.0-rc8 (installer verification, missing Windows runtime, DLL load error 126) and gives a manual workaround sequence.

Compared with: The relationship to llama.cpp needs to be exact. This is not another inference kernel: the README says Skippy uses a patched llama.cpp runtime and tracks llama.cpp family parity. The difference is the layer above it; splitting a model that does not fit on one machine into contiguous layer stages, fetching shards by package, encrypting peer traffic with QUIC, discovering public meshes through Nostr, and presenting one OpenAI-compatible endpoint. Against rolling your own inference cluster plus a load balancer, the trade-off is putting splitting and routing into one binary, at the cost of a self-maintained compatibility matrix and network transfer, the stage schedule and bottleneck compute. I have not measured how these costs interact. The README gives no end-to-end throughput for cross-machine splits, and I did not measure one.

Recent updates: 0.78.1 on 5 October 2026 fixed three issues: chunked requests now go through admission, a rejected wallet identity fails closed on reopen, and an Auto tool request is no longer refused when capability metadata is missing. 0.78.0 on 4 October let a plugin page request the primary tab, let catalog entries pin a version and per-platform SHA-256, and hosted mixture-of-agents as a virtual model. The rolling preview on 30 October fixed a stalled inbound frame on Windows, sized the model-open queue and added a plugin guide for the DwarfStar engine.

Who it's for: Teams with two or three GPU machines who want to run a model too large for one box, or who want a private inference mesh. If one machine is enough, compare the simpler local path before adding cross-machine routing; its operational cost needs measurement. Apache-2.0. Windows users should follow the README workarounds rather than assume it works out of the box.

My take: ⭐⭐. The direction is right; it offers a cross-machine route when one machine cannot hold a model. I have no basis here for predicting which deployment pattern will dominate. But maturity depends on operational detail, and I have no numbers for cross-machine split latency, so I would watch it before depending on it.

Checked: read the README, the 0.78.0 and 0.78.1 release notes, the root LICENSE, recent commits and the Windows troubleshooting section; did not install (no multi-machine GPU environment).

At a glance

Project	What it is	Most distinctive point	Who it's for	Worth a look
jakubkrehel/skills	Interface-review skill pack	The orchestrator only routes, and the skill requires inspection evidence before approval	Frontend people using coding agents	⭐⭐⭐
lightpanda-io/browser	Headless browser built for agents	Agent sessions export to scripts intended to replay without model calls	Scraping pipelines and agent runtimes	⭐⭐⭐
wangzan101/Mika	On-device Android agent	Steers, stops, delivery and restarts are state machines	Personal Android automation	⭐⭐⭐
vercel/ai	Multi-provider agent SDK	Wraps existing coding agents as sandboxed sub-agents	TypeScript teams	⭐⭐⭐
Mesh-LLM/mesh-llm	Distributed inference mesh	Layer splits, package shards and QUIC transport	Running large models across machines	⭐⭐

Notes from this issue

• Skill packs are starting to layer, and the test is who may reach a verdict. One router-only orchestrator, six non-overlapping domain skills and user-invoked workflows; that structure separates routing, findings and authority. Its effectiveness still depends on the host following it. A skill pack becomes a product when responsibility is clear, not when the content is long.

• The agent boundary is moving toward execution surfaces while decisions concentrate. This issue's projects turn a browser, a phone and someone else's coding agent into execution surfaces. The common move is separating where work happens from who decides: the browser exports structured results, the phone taps, the child agent works inside a sandbox. The higher the abstraction, the more precisely it has to answer which step must return to a person.

• Engineering quality in on-device agents shows up on the failure paths. How a steer preserves completed work, what a stop leaves behind, whether an uncertain delivery is resent, whether a restart resumes; none of that appears in a feature list, yet it decides whether the thing is usable every day. Read the state machine before the demo.

• Distributed inference also has an operational barrier. Layer splits, package shards and encrypted transport are all buildable; what is hard is a stage going down, versions drifting apart, or a Windows package failing. Whether a project puts those on its front page says more about maturity than its star count.