Open Source Radar · 2026-10-29: Skill packages start shipping their own checks

By Renchao Wu. Originally published on widechaos.cn.

I picked five GitHub projects for this issue, 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-29.

1. Leonxlnx/taste-skill ⭐ 104,666 · JavaScript

GitHub: https://github.com/Leonxlnx/taste-skill

In one line: A front-end design skill for coding agents: pick a direction, build the page, then measure the result in a real browser and redo it until it passes.

What it is: Since v2 the repo holds one skill, design-taste-frontend, but it is a ten-stage process rather than a prompt: read the brief, write the argument, draw a direction, find the idea, write the words, build, pass the gate, look at the screenshots, add motion, report. A script deals three of twenty researched directions and the agent picks one; from that direction it takes a type system, palette, hero and section compositions from a library distilled from 247 curated sites. Built in February 2026, with 21 contributors, and v2.1.0 through v2.1.5 landed within six days.

What stands out:

• The direction is dealt, not invented. The SKILL.md gives the reason plainly: the author argues that unconstrained generation tends toward category defaults; I have not measured that tendency across models. So the draw is mandatory; three options, no improvising a fourth.
• The gate measures rather than asserts. inspect.mjs opens the page in a real browser at 1440, 768 and 390 pixels and measures headline line counts, fonts actually loaded, colours, rules, shadows, gradients, contrast, overflow, and the frame: equal margins, sections huddled on one side, unexplained blank stretches, presence of a title. A FAIL must be fixed; a WARN is treated as wrong unless it can be defended to a designer in one sentence.
• It says out loud that passing is not the same as good. The gate only shows nothing banned was measured. The next step is opening the screenshots, running a fourteen-pass critique, scoring on an Awwwards-weighted rubric, fixing the top three problems, and repeating; three rounds at most. Only what is visible in a picture counts.
• The last gate runs on the production build. The README names a concrete trap: a minifier dropped a backdrop-filter, so the dev server showed something the deployed page did not. The inspector warns when it is looking at a dev server.
• The project estimates the resource cost. The README estimates roughly 30 to 45 minutes and a few hundred thousand tokens per build; the scripts need Node 22 or newer plus a local Chrome, install nothing and use no API keys. The workflow requires images from open collections under public-domain, CC0, CC BY or CC BY-SA terms, with page credits. Verify each asset and its applicable conditions.

Compared with: A component library hands over parts; this hands over judgement plus a check; the same rules constrain generation and then get measured as numbers. The split with project 2 below is clear: that one uses a fresh reviewer to read a document and taste is judged by a person, while this one runs commands against a page, and the inspector produces measurements that can be compared. Repeated results still depend on browser, fonts, timing, assets and viewport conditions. The ceiling of the first is the reviewer; the ceiling of the second is how precisely the rules are written.

Recent updates: v2.1.5 (10-24) is a round of community fixes; text inserted into charts and split headings is escaped, the release notes report fixes for keyboard reachability and accessible names, italic weights actually load, and two widths sharing a class no longer lose screenshots. v2.1.4 (10-20) fixed a race where concurrent inspector runs deleted each other's browser profiles. v2.1.3 (10-19) cut the repo down to one skill and moved the others to their own repositories under the same install names.

Who it's for: Anyone building landing pages, portfolios, product pages or admin screens who is tired of getting the same template every time; it is intended to be stack-independent; I have not tested it across frameworks. Three caveats: builds are expensive in minutes and tokens, the gate covers front-end output and not content quality, and the README carries an affiliate link and sponsor slots; those lines are commercial.

My take: ⭐⭐⭐ Worth reading to see how "looks good" gets decomposed into conditions that can FAIL. Do not treat passing the gate as proof of taste.

Checked: read the README, the SKILL.md, the v2.1.3-v2.1.5 release notes and recent commits; did not install.

2. google/elephant-goldfish-model ⭐ 4,914 · Python

GitHub: https://github.com/google/elephant-goldfish-model

In one line: A plugin that makes "write the spec first, then have reviewers with no prior context attack it, then you decide" a fixed procedure inside a coding agent.

What it is: Seven skills in a chain; brainstorm, draft, review, review loop, resolve findings, document an existing codebase, and compare documents against source. It installs through each agent's plugin marketplace (Antigravity, Claude Code, Codex, with setup notes for Claude Cowork and ChatGPT Work). The roles explain the name: the elephant holds the project context and drafts the spec, the goldfish reviews it with no context at all, and the person makes the trade-offs. The repo appeared on 2026-09-13 and only reached its first tag, v0.1.0, on 10-27.

What stands out:

• "The goldfish must have a fresh context" is a precondition, not advice. The review skill states that reviewers run in a new context with no conversation history; if the harness cannot spawn subagents, it stops and tells the user; a review in the same context is not a goldfish review. The skill makes fresh context a requirement. I have not tested how each supported harness enforces it.
• Five named review phases: initial zoom out, comprehension, design critique, intermediate zoom out, implementation readiness. The order puts broad design questions before detailed criticism; I have not measured its effect on review quality.
• Output lands in files, not in the chat pane. The skill forbids pasting large proposals, drafts or reports into the chat; they must be written to the working directory and referenced by path. In long-document work that matters: text in a chat drifts, text in a file can be diffed.
• Promotional adjectives are banned. Concept briefs and communication must use plain English, with no ungrounded words such as seamless, robust or blazingly fast, and no decorative adverbs.
• It declares its own instability. The v0.1.0 notes say the release-ZIP host validation is still pending and the version is not ready for stable-release claims. The README says thousands of Google engineers use it and, in the same file, that it is not an officially supported Google product; both sentences need reading together.

Compared with: It and the skill above divide the work: one judges a document with a reviewer, the other measures a page with commands. The skill requires a reviewer without prior conversation history. Whether that isolation holds still needs to be checked in the host environment. I have not read the documentation of other spec-driven workflows, so the precise differences are left untested here.

Recent updates: Commits on 10-28 changed the review loop to stop on convergence instead of on zero findings, added a comparison between the draft and the original brief, and added a guard against unsourced invention when bootstrapping documentation. The v0.1.0 notes also list two items: architecture decisions led by the owner (#157) and guidance for agent warnings (#127).

Who it's for: Anyone changing a feature that involves design trade-offs and wants to avoid rework; small bug fixes do not need it, and the README says as much. Apache-2.0.

My take: ⭐⭐⭐ It specifies where the reviewer should come from; the price is needing an environment that can spawn subagents.

Checked: read the README, the review skill's SKILL.md, the v0.1.0 release notes and the 10-27 / 10-28 commits; did not install.

3. milind-soni/OpenMausBot ⭐ 6,768 · TypeScript

GitHub: https://github.com/milind-soni/OpenMausBot

In one line: A team of AI bots delivered as a chat app: each bot is a real agent with its own model, computer and connected apps, and risky actions become approval cards in the conversation.

What it is: A local-first desktop app built from two processes. The Electron shell owns no transports: it sends typed HTTP commands to a harness and folds a single SSE event stream into state. The harness, listening on 127.0.0.1:8799, owns every agent process and normalises each provider's native protocol into one canonical event stream, logged per thread as NDJSON. The project documents local storage for transcripts, keys and events. Model requests, connected apps and configured cloud computers can still send data off the machine. The repo dates from August 2026 and shipped twelve versions in eight days (v0.1.120 to v0.1.131), each with concrete behavioural changes.

What stands out:

• The permission broker is the main interface. Shell commands, file edits and questions surface as inline cards with Allow, Deny, or an answer typed into the chat, for cloud computers and local machines alike. "Do not act rashly" becomes a path the user clicks through, not a line in a system prompt.
• The MCP surface is deliberately narrow. The bundled MCP server exposes inspecting bots and channels, reading and searching transcript pages, creating and configuring tasks, sending work, waiting for completion, switching models and interrupting turns. It explicitly does not expose approval grants, deletion, arbitrary settings, credentials or computer lifecycle. That list of what is withheld is more instructive than the feature list.
• The project documents platform-specific control restrictions. Bot control of the local machine is disabled on Ubuntu Wayland pending a safety gate, requires explicit opt-in on Xorg and runs without a full-screen cursor overlay, and the Windows installer is not code-signed, so the system shows an unknown publisher.
• Key storage is labelled honestly. API keys are stored as plaintext in a private config file (mode 0600 on Unix) and the README states they are not encrypted.
• Triggers have concurrency discipline. Interval schedules align to their start time and skip an occurrence when the previous run is still active, so the documented scheduling policy avoids accumulating interval occurrences. I have not tested crash recovery or all trigger sources. The webhook receiver binds a local port only and exposes health plus secret hook endpoints; bearer authentication is recommended so the secret stays out of URLs.

Compared with: The project presents itself as an open alternative to several closed personal-agent products; I have not verified those products, so no comparison conclusion here. The verifiable differences are architectural: bots reuse the logins of local CLIs, the UI and the runtime are separate processes, and an unknown engine degrades to unavailable instead of taking the fleet down. It also owns the agent processes itself, whereas the other two agent projects today either ship skills into someone else's agent or collect context into a workspace.

Recent updates: v0.1.131 (10-28) gives connected apps the same tool names on every engine so switching models no longer quietly breaks routines; a sign-in request can be settled by replying done in chat; a global ⌃⌥Space voice ask arrives on the Mac. v0.1.130 reworked simple mode and made a new bot send a test message so a bad key surfaces immediately. v0.1.129 installs updates at a quiet moment and lets bots borrow a real Chrome on a Mac with the user's own logins.

Who it's for: Anyone who wants several agents locally, on accounts they already pay for, with documented approval paths for supported actions. I have not audited complete action coverage. macOS is the most complete target, Ubuntu is still beta, and Wayland cannot control the local machine; cloud computers and connected apps are third-party paid services. The project labels its community code Apache-2.0 and the enterprise/ directory under a separate source-available licence. Check the exact components and dependency terms for the intended distribution.

My take: ⭐⭐ The architecture is worth copying, the product is early; anyone expecting a finished app will hit the beta edges first.

Checked: read the README, the v0.1.129 to v0.1.131 release notes, the 10-29 commits and the server/drivers directory; did not install.

4. macro-inc/macro ⭐ 5,496 · Rust

GitHub: https://github.com/macro-inc/macro

In one line: Email, chat, documents, tasks, agents and CRM in one workspace, everything linked in a bidirectional graph, with a team memory synthesised once a night.

What it is: A workspace rewritten in Rust with a SolidJS client. The surface is wide; multi-account inbox, channels and DMs, lightweight tasks, CRDT documents, a canvas, recorded calls, files, GitHub pull requests, CRM; but it shares one backend, so references between a document and a task, or a channel message and an email, are edges in the database rather than synchronised copies. The README reports 42 deployable services and 167 Rust libraries; counting directories through the GitHub API gives 47 under services/ and 267 under crates/ (I did not confirm which of those are deployable). Created November 2025, 26 contributors.

What stands out:

• It argues the case for building it. The author writes that at about twenty people in a previous company, each team bought its own tools and the company was held together by MCP and Zapier; "the company was not computable". So tasks and CRM moved back to where the conversation happens: a task grows out of an email, a channel or a checked bullet in a document, and links back to its source.
• Team memory is batched, not appended. Every night the system synthesises channel conversations, DMs, sent and received email, and tasks created or completed into one pass, merges it with the previous version, and stores the result as Markdown that can be exported or edited by asking.
• That memory is exposed outward. It is available to external agents over MCP; the project says the MCP surface covers nearly everything the UI can do and imposes no rate limits.
• Agents are peers in the collaboration system. Documents are CRDT-backed, and agents edit them like human collaborators, with concurrent document edits merged by the CRDT. This does not establish that the resulting content is semantically correct. The example given is a daily job that updates a document after scanning channels, and skips the update if someone edited it first.
• Permissions follow the channel. The README describes channel membership as the access rule for linked content. I have not audited nested sharing, exports or revocation propagation.

Compared with: Against buying a chat tool, a document tool, a task tool and a CRM and wiring them together, the difference is architectural rather than a feature list: one backend, one bidirectional graph, one permission model, and a memory synthesised from the whole company's context. Its criticism of those other products is the project's own account, and I have no verifiable data on them. Among today's agent projects it is the workspace kind: it neither owns agent processes nor ships skills, but collects context into a store for agents to read.

Recent updates: Three tags on 10-29 alone; routines can be saved as templates others activate, a highlighted snippet can become a task, agent tool calls stream with throttled argument previews, and production alerts gained a login and a graph each. Version numbers are date streams (v2026.10.28.N), not semantic versions.

Who it's for: A small team that wants to self-host its workspace and cares where its memory comes from. Two caveats: AGPL-3.0 applies to the whole thing (the project says it is not open core), so hosting and distribution obligations need reading; and directory counts do not establish the required number of deployed services; check the actual self-hosting topology. The security page reports SOC 2 Type II and zero data retention with model providers; I did not check the audit report.

My take: ⭐⭐ The memory design deserves a separate read; the self-hosting cost will put most people off.

Checked: read the README, the three release notes from 10-29 and the commits, counted the crates/ and services/ directories; did not install.

5. ruvnet/RuView ⭐ 101,183 · Rust

GitHub: https://github.com/ruvnet/RuView

In one line: A WiFi-sensing research stack with ESP32 firmware and models whose maturity differs by task. The headline capabilities are not established by one board's live output.

What it is: A WiFi sensing stack: an ESP32-S3 (about $9) or ESP32-C6 ($6-10) runs firmware as a sensing node, frames go through a bridge to a sensing service, and the output connects to Home Assistant (21 entities per node, ten of them inferred semantic states such as someone sleeping, an elderly person with no activity, elevated fall risk) and to bridges for Apple Home, Google Home and Alexa. There is also a Python package (PyO3, about 250 KB), pretrained weights, and a sensing panel for coding agents. Created June 2025, 40 contributors.

What stands out:

• It turns "which numbers are real" into a section. Model weights are graded in three tiers: labelled real and validated by the project (the pretrained encoder at 82.3% held-out temporal-triplet accuracy, and an MM-Fi pose model at 82.69% torso-PCK@20, or 83.59% as a three-model ensemble), real but weak and labelled as such (the in-repo model at 3.0% PCK@20 and 18.5% PCK@50, below its own 35% target, with a runtime path that is still a stub returning zero confidence), and architecture only with no weights at all (the old head is randomly initialised, with no checkpoint in the repo).
• It retracted one of its own figures. The earlier "100% presence" number was measured on a single-class recording and the README says it has been retracted. That sentence says more about the project's discipline than any new number.
• It states the physical limit. A single antenna, 56 subcarriers and a 20-frame window do not carry the fine spatial information that multi-antenna research relies on; distal and facial joints come out near random. The pose accuracy the project stands behind comes from the MM-Fi benchmark, not from a live single board.
• There is a one-command replay. The project provides a replay script that compares pipeline output with a published hash. A matching replay does not validate live sensing accuracy or clinical use.
• The release shape is not product-like. Tags are CI snapshots (v3422), firmware ships separately as a prerelease (v0.8.16-esp32), and the release notes state plainly that the entry contains no firmware bundles.
• Known problems are written down: the published weight file has a NUL-padded header that the reference loader rejects (issue open, re-upload pending), while another embedding file in the same repo loads normally.

Compared with: This project publishes maturity tiers, a retraction and physical limits. I have not surveyed other WiFi-sensing projects broadly enough to characterise their reporting. Its comparison with prior published results (MultiFormer at 72.25%, CSI2Pose at 68.41% on the same split) is the project's own account; I did not read those papers to check the protocol, so I do not treat it as independent verification.

Recent updates: The 10-26 firmware prerelease stops unrelated millimetre-wave frame types from establishing the wrong sensor identity, fixes container images built from Windows checkouts, and updates vulnerable Rust dependencies. The same day's source snapshot is a CI-validated artifact. A proposal to relax the startup requirement was withdrawn, leaving the existing zero-vitals startup requirement in place.

Who it's for: People with hardware who want to reproduce WiFi sensing, or anyone who wants a sample of how to report metrics honestly. The pipeline can be run with simulated data. MIT licence. Do not buy a board expecting to see through walls; the project itself says that number does not come from a single board.

My take: ⭐⭐ The gap between the metrics and the headline is real, and so is the value of how the metrics are labelled.

Checked: read the README including the model maturity and results sections, the v3422 and v0.8.16-esp32 release notes, and the 10-26 commits; no hardware, did not run it.

At a glance

Project	What it is	Most distinctive	Who it's for	Go deeper
taste-skill	Front-end design skill	Measured in a real browser at three widths, checks measured layout rules	People who need pages that do not look templated	⭐⭐⭐
elephant-goldfish-model	Spec and review process	Requires reviewers without prior conversation history; no subagents means stop	People changing features with real trade-offs	⭐⭐⭐
OpenMausBot	Desktop agent runtime	Approval cards plus a deliberately narrow MCP surface	People running several agents locally	⭐⭐
macro	Team workspace	One team memory synthesised nightly into Markdown	Small teams willing to self-host	⭐⭐
RuView	WiFi sensing	Three-tier model table plus a public retraction	RF hardware tinkerers and reproducers	⭐⭐

This week's notes

• Skill packages have become the unit of distribution, at three granularities. One repo cut to one skill, seven skills packed into a plugin, one Markdown file that installs a whole team. The shared direction: make "how to do it" into something installable, reviewable and removable.
• Verification is moving from prose into measurement. A browser measures the page, a review skill requires a fresh context, the sensing project labels model maturity without equating benchmark results with a live board. Three projects, three layers, one move: turn "I checked" into something someone else can re-run.
• Version numbers no longer signal maturity. Twelve releases in eight days, six in six days, CI snapshots used as tags. The release notes and a willingness to write "this version is not ready for stable claims" tell you more.
• Read the licence down to the directory. This batch spans MIT, Apache-2.0 (with one project carving out an enterprise directory under its own licence) and AGPL-3.0. The word "open source" alone does not say what you may do with it.