DEV Community: David Díaz

MOSS-Image Publishes 5B DiT Weights and Layout JSON Workflow

David Díaz — Fri, 23 Oct 2026 19:43:29 +0000

OpenMOSS has published code and weights for MOSS-Image-Base and MOSS-Image-SFT, giving developers a 5B-parameter DiT text-to-image model with a documented JSON layout-prompt format. The practical consequence is that text placement and composition can be expressed as structured input rather than left entirely to a natural-language prompt. The project repository describes the model as targeting text rendering, layout generation and efficient fine-tuning.

Two published variants and conventional entry points

The repository lists MOSS-Image-Base as its base text-to-image model and MOSS-Image-SFT as a version fine-tuned from the base on curated data. It provides a Python example built around diffusers.DiffusionPipeline, and documents a Gradio application for local use. The same repository also says MOSS-Image is supported natively in ComfyUI, with built-in loaders for ComfyUI-format weights.

For inference, the documented defaults are Flow-matching Euler sampling, 50 steps, CFG 3, shift 5, and negative-branch skipping at layer 22. These are project recommendations, not independent performance measurements. The repository's sampling table also documents GPU-resident, component offload and sequential memory modes, with sequential mode trading inference speed for lower memory use.

Layout is part of the prompt interface

MOSS-Image's most concrete control mechanism is a JSON input format containing a scene summary and an items array. Each item can include a label, description, optional text to render and a bounding box; the documented example uses centralized pixel coordinates and a yxyx box format. The layout guide in the repository instructs users to match those coordinates to the requested output dimensions and to pass the JSON as the prompt string in the Python API.

That makes the interface suitable for tooling that already has deterministic scene metadata—for example, an editor that knows where a headline or illustration should sit. It does not establish that a generated image will exactly obey every coordinate or render every string correctly; the repository presents examples and capability claims, but no evaluation methodology or benchmark results in the supplied documentation. The project page characterizes text rendering and layout control as key highlights.

Analysis: The useful distinction here is between a model that can be asked for a layout and one whose layout can be represented, stored and edited as data. MOSS-Image documents the latter interface, which could make generation pipelines easier to integrate with design tools. The unresolved trade-off is reliability: developers will still need their own validation loop for text accuracy, box adherence and composition quality because the repository does not supply quantitative evidence for those properties. The documented JSON workflow supports structured authoring, while the page's stated capabilities remain project claims.

Fine-tuning and licensing boundaries

The repository says community tooling includes full fine-tuning and LyCORIS training, including LoRA, for both model variants. It specifically points to KohakuMossTrainer, which the project says supports several precision modes, multi-GPU approaches and adapter training with as little as 6GB of VRAM. Those details appear in the repository's release notes, so teams should verify the linked trainer and its hardware assumptions before treating that memory figure as a deployment requirement.

The standalone pipeline code is released under the Apache License 2.0. The repository license section does not, in the supplied page text, separately spell out the terms governing every published model weight or every third-party community artifact. Developers planning redistribution or commercial deployment should therefore check the relevant weight and dependency terms rather than infer them from the pipeline-code license alone.

DigUp Searches Local Media, Documents and Code On-Device

David Díaz — Wed, 21 Oct 2026 19:40:00 +0000

DigUp is available as a free, open-source desktop application for searching selected local documents, images, recordings, videos and source code. Its macOS build is accompanied by beta releases for Windows and Linux. For developers, the immediate consequence is one search interface that can locate a function, screenshot, PDF page or point in a recording without uploading those files to a hosted service, according to the project repository.

One query, two retrieval paths

DigUp runs Google DeepMind’s EmbeddingGemma 2 through llama.cpp. Its readers convert files into text, pictures or sound representations, then store vectors for pages, passages, images, video frames and audio segments in a SQLite index. Those vectors occupy the same 768-dimensional space, allowing one text query to rank different media types together, according to the implementation description.

Semantic retrieval is only one part of the search path. DigUp also maintains a keyword index and boosts exact-word matches, which is intended to preserve literal searches for names, invoice numbers and error codes that an embedding may not represent precisely. Queries therefore combine vector proximity with lexical matching rather than treating embeddings as a substitute for exact search, as the README explains.

Indexing granularity depends on the format. DigUp processes PDFs page by page, splits audio into overlapping 30-second windows, and samples video frames while also indexing the soundtrack. Search results can point to a PDF page or media timestamp, although jumping directly to that location depends on the viewer available on each operating system, according to the supported-format and playback notes.

Code stays in a separate index

Code search is disabled until the user enables it for selected folders. It reads source files, notebooks without their outputs and repository documentation, then opens matches at the relevant line in a configured editor. The code index remains separate from general file search, and code queries must begin with code:, according to the code-search documentation.

The project says this path skips files ignored by Git, along with vendored or generated code, data files and content that resembles a key or password. It lists support for editors including VS Code, Cursor, Zed, Sublime Text and JetBrains IDEs, plus several platform-specific options, in the same documentation.

Local processing still has a cost

The maintainers state that indexed content does not leave the computer and that DigUp has no account requirement or telemetry. The application connects to download its model once and to check for updates once per day; the update check can be disabled and is described as sending no information about indexed files. These are claims made by the project itself.

That design shifts computation and storage onto the user’s machine. The initial model download is 865 MB, and the first indexing pass can take from minutes to hours depending on the selected files and hardware. DigUp estimates that duration during setup; on Windows and Linux it uses a GPU when a setup check finds that path faster than the processor while producing the same results, according to the installation and performance notes.

Platform constraints are uneven. The Mac version requires Apple Silicon and macOS 14 or later. Windows requires 64-bit Windows 10 or 11, and its beta installer is not yet signed. The documented Linux packages target 64-bit Intel and AMD systems, with .deb and AppImage distributions available from the project’s releases and installation instructions.

Analysis: broader retrieval means broader access

Analysis: DigUp’s consequential design choice is the combination of cross-media vector ranking with exact-string retrieval, not semantic search alone. That can make fragmented project material searchable through one interface, while the separate code index limits accidental mixing between repositories and personal files. The architecture and separation are documented in the repository.

The unresolved trade-off is scope. Better retrieval requires granting the application access to more folders and paying the corresponding indexing cost. Folder selection, opt-in code search and exclusions for several sensitive file categories narrow that boundary, but they do not remove the need to decide which local material belongs in a consolidated search index. Those controls and exclusions are described by the project; judging whether they are sufficient remains a user-side trust decision.

cleanyourtv Debloats Android TV and Replaces Its Home Screen

David Díaz — Mon, 19 Oct 2026 19:45:30 +0000

cleanyourtv packages Wi-Fi Android debugging, package-disable scripts and a replacement Home launcher into one workflow for Android TV and Google TV. For developers, the consequence is a reversible way to modify a television without root or a cable: selected packages are disabled rather than uninstalled, and the project provides restore tooling.

The workflow changes package state

Setup requires a computer on the same Wi-Fi network as the television. Users must enable USB debugging, authorize the computer through the television’s debugging prompt and, when a separate Network or ADB debugging option is present, enable that too. The documented quick start uses a coding assistant with shell access, while a manual route is available through Python 3 tools and shell or PowerShell scripts. Project instructions

Before making changes, the workflow backs up the installed-package list and settings. It then applies model-specific selections with Android’s pm disable-user; the supplied disable.sh and restore.sh scripts apply or reverse the same debloat list. The project’s checklist also asks which apps the user needs and whether voice assistance, Chromecast and system updates should remain enabled. Package-management workflow

A small launcher supplies the new Home screen

The replacement app, com.gathin.tvhome, is described as roughly 280 KB installed. It is written in Java with AndroidX RecyclerView and designed for televisions with 1 GB of RAM; the repository says it uses no network connection, background services, video or blur effects. Building it requires JDK 17 and Android SDK platform 34. Launcher documentation

The project describes the resulting interface as Apple TV-style. It includes a dock, a top shelf for the focused app, an application grid, input controls, network status, settings access, themes and a clock screensaver. Launcher feature list

The installation scripts query which package owns Home and disable only launchers they recognize as tvlauncher or launcherx, unless the operator supplies an override or chooses to leave the stock launcher alone. The build-and-install script also rolls back if the new launcher does not become Home. Installation behavior

Compatibility stops at OS boundaries

The repository reports 54 tested TV lists across 23 brands. Its detailed list is not limited to television sets: it also covers streaming boxes, sticks and projectors, including Chromecast with Google TV, NVIDIA Shield, Xiaomi devices, Fire TV hardware and XGIMI projectors. Tested-device lists

The project targets Android TV and Google TV. Samsung televisions running Tizen and LG televisions running webOS use different systems. Fire TV can use the debloat portion, but Fire OS does not assign Home to a third-party launcher; the repository also notes that some China-market TCL sets refuse launcher installation. Platform limitations

Analysis: The project’s central engineering choice is to treat disabled-package state as the rollback boundary instead of deleting software. That makes restoration possible, but it does not remove the need for device-specific judgment. The checklist concerning voice assistance, Chromecast and updates shows the unresolved trade-off: packages considered bloat may also participate in integrated services a household wants to retain. A restore script can reverse state changes, but it cannot make that selection for the operator. The documented workflow and restore model

Solid Glass Adds an AI UI Theme to shadcn/ui Projects

David Díaz — Sat, 17 Oct 2026 19:44:14 +0000

Solid Glass is a public GitHub project that packages a glass-inspired design system for AI applications as a stylesheet intended to work with shadcn/ui. For developers building chat and agent interfaces, its practical proposition is narrow but useful: the stylesheet targets the data-slot attributes and classes that existing shadcn/ui components already carry, so adoption is presented as a theme integration rather than a component rewrite. Source: Solid Glass repository

A theme layer, not an AI framework

The project describes its visual treatment as sitting between flat design and “liquid glass”: surfaces retain outlines, borders, highlights and shadows, while avoiding the highly transparent treatment that can interfere with text legibility. Its stated design goals are tactility, precision, physicality and materiality; for interfaces with streaming responses, agent tasks and pending human decisions, it argues that neutral surfaces and reserved use of colour and motion help keep the UI calm and readable. Source: Solid Glass repository

The core distribution is one CSS file. The repository says it defines colours, three glass thicknesses, a state and motion, while also defining shadcn/ui’s variable names. It supports light and dark modes, although the project describes dark mode as the intended material treatment. Source: Solid Glass repository

Installation begins from a shadcn/ui project using React 19, Tailwind CSS 4 and Base UI components. Developers add the deeplethe/solid-glass/solid-glass stylesheet through the shadcn CLI, import it after Tailwind and shadcn styles, and remove the :root and .dark colour variables created by shadcn initialization because Solid Glass defines variables with the same names. Source: Solid Glass repository

Components for agent-facing screens

Beyond the theme, the project supplies installable components including status-glyph, panel, tag, dot-loader, turn-status, composer, tool-steps, diff-view, ask-card, context-ring, task-notice and reasoning. The README positions these around an agent workflow: showing activity, accepting a prompt, rendering tool steps and diffs, asking for user input, and displaying context usage. Source: Solid Glass repository

The repository also includes complete screen-level “Blocks,” including an agent-workspace, plus a Create page that exposes controls for thickness, tint, chart colour, type, radius, rim and blur and produces corresponding CSS variable changes. Source: Solid Glass repository

The compatibility trade-off

Analysis: Solid Glass’s most consequential choice is to treat shadcn/ui as the compatibility surface rather than create another self-contained component ecosystem. That should reduce initial adoption cost for teams already on the shadcn stack, because the theme is designed around existing slots and classes. It also leaves an unresolved maintenance question: the approach depends on those structural conventions remaining stable enough for a stylesheet to keep selecting the intended parts. The repository notes that some displayed shadcn/ui components differ slightly from stock versions, while saying the stylesheet does not depend on those differences. Source: Solid Glass repository

This is therefore best read as a focused UI layer, not evidence of a broader agent runtime or application framework. Its value will depend less on the glass treatment itself than on whether its component conventions fit a team’s existing shadcn/ui codebase and the information density of its AI workflows. The repository is licensed under MIT and includes contribution, code-of-conduct and security-policy materials. Source: Solid Glass repository

ARTEX Preserves Its Final Version as a Pure-Source Backup

David Díaz — Thu, 15 Oct 2026 19:42:56 +0000

ARTEX’s maintainers are preserving the autonomous penetration-testing system’s final version as a pure-source backup. The former autumn27/artex Docker image is unavailable, so the repository now directs users to the maintained mianhuatang11/artex image or a local source build. Developers evaluating or operating ARTEX should note that these deployment paths have different update behavior, as documented in the project repository.

The project describes ARTEX as the champion entry in Baidu’s “agent+” attack-and-defense competition. That designation is the maintainers’ description and should not be read as independent verification of either the contest result or the system’s effectiveness against real targets. The repository page is the source of the claim.

A planner, workers and two linked graphs

ARTEX combines a Go monolithic backend, a statically exported Next.js frontend embedded in the Go binary, and PostgreSQL storage. Exploration requires an LLM configuration through Anthropic or OpenAI credentials or the application’s interface. Its documented agent roles include goal decomposition, a planner, multiple workers and a human-in-the-loop main agent. The architecture documentation describes these components.

The system separates its data into two linked structures. A shared asset graph stores domains, subdomains, IP addresses, services, applications and endpoints. A task-specific exploration graph stores goals, intents, facts, findings and hints, while anchors associate those records with individual assets. This separation supports both an investigation’s lineage and asset-level coverage views, according to the dual-graph design.

The planner reads the exploration state and dispatches uncovered directions as intents. Workers claim one intent at a time, run tools and write resulting assets, facts or findings back to the graphs; those changes can wake the planner for another cycle. Workers can also search traces from other work items in the same task, excluding their own current trace. The engine documentation specifies this event-driven loop and cross-worker search.

Controls around execution and retesting

ARTEX documents a recording MITM proxy for tool traffic and guard and intercept components that provide approval gates. Its interface exposes activity streams, approval records, traffic recordings, asset coverage and human-in-the-loop conversations. The repository’s subsystem and interface documentation lists those controls and views.

Vulnerability retesting runs in a separate agent session rather than restarting the original scan. A retest can conclude that an issue remains reproducible, has been fixed or cannot be confirmed. A successfully completed retest marked as fixed can update the vulnerability’s status automatically, while the original evidence and report remain available. The retesting documentation defines that workflow.

Deployment has two update layers

The installation script supports either an all-Docker deployment or a locally compiled application, while Docker Compose and a manual source build are also documented. The backup repository does not host precompiled binaries; it instead refers users to releases from the original repository when available. The installation instructions describe these options.

ARTEX’s in-application updater replaces the program but not the Docker image. The documentation warns that tools bundled in the image, including Playwright and nmap, are not updated through that path, and recreating the container restores the application version included in the image. Updating the full environment instead requires pulling and recreating the ARTEX container. The update documentation distinguishes these procedures.

Analysis — ARTEX effectively treats the application binary and its containerized security toolchain as separate release units. The unresolved operational issue is release coordination: an application-only update leaves bundled tools unchanged, while container recreation can replace the application with the image’s bundled version. Teams adopting ARTEX should therefore decide which combination constitutes a tested deployment and track both layers rather than treating the two update paths as interchangeable. This interpretation follows from the project’s documented Docker update behavior.

Aurelio Pairs Local Finance Records With an Optional AI Adviser

David Díaz — Tue, 13 Oct 2026 19:42:29 +0000

Aurelio is a public, MIT-licensed personal-finance application that runs on the user’s computer and keeps its records there. Its AI adviser is optional and connects through OpenRouter with the user’s API key. Developers can therefore clone and run the financial tracker locally while deciding separately whether to configure the external AI integration. The repository documents the license, local operation and optional adviser.

A ledger for assets, liabilities and goals

Aurelio records banks, brokers, cash and dated holdings. Its portfolio views calculate position costs, gains and dividends, while its fund look-through breaks exposure down by country, sector, company and currency. The app also covers recurring investments, homes, debts, income, expenses, savings rates and the returns required for financial goals. These functions are listed in the project README.

Running the demo requires Git, Node.js 22 or later and uv. The supplied macOS, Linux and Windows scripts start the app with an invented household and open it at http://localhost:8000. The repository provides the requirements and demo commands.

For non-demo use, records reside in backend/data.db. The project says it saves a copy beside that file before an update changes the data format. The storage path and pre-update copy behavior are documented in the README.

The repository also documents separate backend and frontend test commands using pytest and npm test, plus hot-reload commands based on Uvicorn and the frontend development server. Those development workflows appear in the project documentation.

The adviser introduces a second boundary

The “Ask Aurelio” chat answers from the user’s records, can search the web and presents proposed changes as cards that the user must confirm. Enabling it requires an OpenRouter account with credit and an API key stored in backend/.env; users can select a model in the chat. The repository describes the chat behavior and OpenRouter configuration.

Analysis: Local record storage and local AI processing are not the same property. Aurelio keeps its ledger on the user’s machine, but the optional adviser routes through OpenRouter and can use those records when answering questions. Developers evaluating the app should therefore treat storage and AI processing as separate trust boundaries rather than reading “runs on your own computer” as a claim that every enabled operation remains local. That interpretation follows from the project’s description of local records and its OpenRouter-backed adviser.

The confirmation-card flow provides a visible checkpoint before a proposed change is accepted. Analysis: It does not settle the separate question of what financial context is appropriate to submit to an external AI service. The unresolved trade-off is between the adviser’s record-aware answers and web search on one side, and keeping the application free of that external integration on the other. The underlying confirmation, record access, web search and optional-AI behaviors are documented by the project.

OpenDots Packages Persistent Agents for Chat, Calls and Slack

David Díaz — Sun, 11 Oct 2026 19:38:51 +0000

OpenDots is a public, MIT-licensed template for building persistent AI “coworkers” that can work through documents, text chat, voice calls and Slack. For developers, the important constraint is that it is not a hosted agent product: teams run the application, configure its infrastructure and connect the external services that make conversations, calls and computer tools work. OpenDots repository

The project organizes work around Spaces and specialist “Dots.” A Dot can receive a name, role instructions and permitted tools, while its access can span multiple Spaces. Pages live in the local workspace database and support a searchable library, a visual editor, autosave, revision checks and page-specific conversations. OpenDots repository

Agent work with explicit approval points

OpenDots includes two notable controls for agent actions. A Dot can present a draft through a human-in-the-loop card, where approval creates a page in an authorized Space; changing the draft requires a new review. For MCP-connected tools, read-only tools run directly, while other tools pause for an Approve & run decision in chat. Tool availability can also be enabled or disabled for each Dot. OpenDots repository

The template can also attach a separate computer to each Dot through OpenBot’s container supervisor and computer service. Its browser profile and workspace files persist across stops and starts, and the interface exposes browser control, files, terminal output and human takeover. The repository is explicit that an unconfigured template does not execute commands on the host. OpenDots repository

For communications, the project describes continuous text conversations, voice calls that pair realtime speech with a separate compute agent, and a Slack integration built with Channels SDK. Calls and longer-running work share the same conversation context and tool permissions, according to the project documentation. OpenDots repository

The deployment boundary is the product boundary

A developer can create Spaces, write pages and configure Dots locally before connecting services. Chatting requires an Intelligence project and a model configuration; calls additionally require a speech provider, while Slack and computer features need their respective setup. The architecture uses AG-UI between the application and agent interface, plus CopilotKit components and runtime, TanStack AI, Threads, and Channels SDK for Slack. OpenDots repository

That distinction matters because OpenDots separates local workspace data from conversational and provider data. Pages, workspace metadata and thread bindings are stored in SQLite, but conversation messages, tool calls and run events are persisted in the configured Intelligence deployment. In the hosted configuration, those records go to CopilotKit’s cloud; the configured model provider receives conversation context, including authorized page content and tool results. OpenDots repository

Public-web research has another boundary: queries and selected URLs go to Parallel by default unless WEB_SEARCH_PROVIDER=disabled is set. Speech and messaging integrations send data to their configured providers when used. The repository also documents telemetry opt-outs through COPILOTKIT_TELEMETRY_DISABLED=true or DO_NOT_TRACK=1. OpenDots repository

Analysis: OpenDots’ useful contribution is not a claim that agents can safely operate unattended; it is the attempt to make the intervention points visible in the application: per-Dot permissions, approval cards, isolated computer services and explicit provider configuration. The unresolved trade-off is operational rather than cosmetic. A team that wants persistent agents across documents, Slack, voice and browser tasks must also own the integration surface, permission design and data flows that those channels introduce. The repository’s own separation of local page storage, conversation persistence and external provider traffic makes that responsibility hard to ignore. OpenDots repository

invisible_playwright_mcp Pairs MCP With Stealth Firefox

David Díaz — Fri, 09 Oct 2026 19:40:53 +0000

invisible_playwright_mcp packages a browser agent as an MCP server and a local web UI, while its maintainer claims the underlying Firefox engine is undetected by anti-bot systems and CAPTCHAs. For developers, that means assistant clients can drive page interactions with configuration that may retain login state, route traffic through a proxy and send page content to an external provider. The repository documents each of those behaviors.

Two interfaces to the same browser

The repository provides installation paths for Claude Code, Codex and Gemini CLI. Its standalone interface runs locally, presents chat beside a live browser and requires an OpenRouter key. The same package starts the MCP server when invoked without a subcommand and launches the interface with the ui subcommand. The project also points Python developers to invisible_playwright, a related library whose API follows Playwright’s.

The README says the agent interacts through pointer movements and key presses. Configuration includes proxies, seeded browser identities, persistent profile directories and a headed mode. The project says a repeated seed produces the same browser identity, a profile directory preserves cookies and logins across restarts, and proxy selection determines timezone, locale and network egress. These options are described on the project page.

Analysis: The anti-detection promise is stronger than the evidence presented on the repository page. The claim appears without a target-site matrix, testing protocol, success rate or independent validation. That does not establish that the claim is false, but it leaves developers without a documented basis for estimating reliability against a particular site’s defenses. The repository page presents the claim and configuration details but none of those measurements.

Local execution still has external data flows

The project says the agent runs on the user’s machine and has no server of its own. Sessions, profiles and screenshots are stored locally. However, sites receive browser traffic, the web UI sends its conversation and page content read by the agent to OpenRouter, and an MCP client sends corresponding information to whichever provider it uses. Those boundaries are set out in the project’s privacy policy.

The engine is downloaded from a GitHub release when the server or interface first starts, and a GeoIP database is downloaded when a proxy is configured. Each browser launch also fetches a one-line counter file from a GitHub release. The project says that request carries no identifier, although GitHub sees the originating IP address as it would for another HTTPS request. The maintainer says nothing else is collected or sent to the author.

The README warns that changing the interface host from its loopback default exposes a service with no authentication. It also says passing an OpenRouter key on the command line places the key in shell history and, on Linux, the process list; using an environment variable or local .env file avoids those two exposures. The project documents both warnings.

The unresolved control boundary

Analysis: Pairing persistent browser state with an agent intended to appear less detectable shifts the central deployment question toward authorization and review. A profile can preserve cookies and logins, page data can leave the machine, and a host change can expose an unauthenticated interface. The unresolved trade-off is whether teams can gain useful browser access without granting overly broad access to stored sessions or sensitive page content. Those risks follow from the project’s documented persistence, data-flow and host settings.

The project tells users to read the terms of sites they visit, respect rate limits and avoid submitting anything that a human has not reviewed. Its responsible-use guidance places those obligations on the operator.

Logo Design Skill Packages SVG Checks for AI Agents

David Díaz — Wed, 07 Oct 2026 19:40:26 +0000

The public, MIT-licensed logo-design-skill repository packages a staged logo-design workflow for Claude Code, Gemini CLI, Codex CLI and other agents that support skills. Developers can install its instructions, reference material and Python tools to move from a brief to tested SVG concepts and, after approval, a broader identity kit.

Three concepts, then a hard stop

The prescribed process begins with a brief and category research. It then calls for eight to 12 one-line concepts, of which three are built in SVG and tested before presentation. At the checkpoint, the agent shows the directions in one overview image, recommends one and waits for the user to choose or request changes, according to the repository’s workflow.

That stop is mandatory in the documented process. The agent does not produce the colour system, lockups, presentation board, icons or guidelines until the user approves a direction and requests the kit. The project says this avoids completing the most substantial part of the work for an unapproved idea (GitHub).

SVG tests and delivery tools

The repository includes dependency-free Python utilities for auditing SVGs, rendering PNGs, assembling concept sheets and creating presentation boards. Its test sheets cover 16-pixel rendering, one-colour and reversed variants, squint and mirror checks, contextual mockups and a competitor shelf test. It can also export favicon, app-icon and web-manifest assets (GitHub).

A separate reference library contains more than 1,400 real-world SVG logos classified by attributes including mark type, technique, geometry, subject, typography, mood and industry. The collection is searchable from the command line and browsable through a local gallery. The project frames it as material for studying construction, identifying category conventions and avoiding look-alikes—not for copying existing marks (GitHub).

Portability depends on the host agent

The skill follows the Agent Skills structure: a folder containing SKILL.md, with instructions in Markdown and tools in Python. The installation guide supplies personal and project-level paths for Gemini CLI and Codex CLI, while directing users of other compatible agents to their respective skills directories. The README says an image-capable model works best because the workflow renders drafts to PNG and inspects them before presentation (GitHub).

Analysis: reviewability comes at the cost of autonomy

Analysis: The approval checkpoint is the project’s most consequential constraint. By refusing to create the full kit before a direction is selected, the workflow prioritizes reviewable intermediate work over unattended completion. That can limit effort spent finishing a rejected concept, but it also means teams seeking batch or hands-off generation will encounter a deliberate interruption (GitHub).

The evidence for output quality remains internal. The repository presents 28 fictional briefs run through the process across multiple sectors, with some examples showing a selected concept that differs from the skill’s recommendation. Those examples document how the workflow behaves, but they should not be read as independent validation of originality or professional design quality (GitHub).

AIHOT Open-Sources a Configurable Industry News Site Framework

David Díaz — Tue, 06 Oct 2026 12:56:21 +0000

AIHOT’s public GitHub repository packages the engine behind an AI-news site as a reusable template: developers can replace its sources, selection criteria and branding to run a sector-specific news site of their own. The practical consequence is that the project offers more than feed aggregation; it supplies an editorial pipeline whose rules are intended to be changed by the operator. The AIHOT repository describes the project as a public template and framework for this purpose.

The repository says the system ingests material from six source types: RSS, web lists, JSON interfaces, X accounts, WeChat public accounts and externally pushed content. It then deduplicates and pre-filters items, scores potentially important material twice independently, generates Chinese titles and summaries, groups coverage into events, and produces daily reports. The AIHOT repository also states that sources are assigned three tiers with different admission thresholds.

Editorial rules are configuration, not a black box

AIHOT exposes its prompts and selection thresholds, with the project directing operators to industry/prompts/ for changes to editorial standards. Its customization guidance identifies industry/sources.json for initial sources, industry/taxonomy.ts and industry/topics.json for categories and topics, and industry/selection.ts for admission thresholds. The AIHOT repository recommends calibrating selection rules against one or two hundred operator-labelled items using its evaluation script.

For clustering, the project says it first finds candidates from the previous two weeks using title-and-summary vectors, or text overlap when no vector service is configured, and then asks a model whether the material is the same event, a follow-up, or a separate event. Hotness is calculated at the event level: within 48 hours, each independent source counts once, with a 24-hour half-life. The AIHOT repository says that repeated retrievals and multiple articles from one outlet therefore do not add repeated weight.

The stack listed by the project is Node.js 24, TypeScript, React Router server-side rendering, Fastify, PostgreSQL, pg-boss, Tailwind CSS and Docker Compose. The AIHOT repository requires Docker, Node.js 24 for its configuration initializer, and an OpenAI-compatible model API key for the documented quick-start path.

The unresolved issue is editorial accountability

Analysis: AIHOT’s useful distinction is that it treats an industry-news site as a configurable editorial system rather than as a generic chatbot wrapper. Exposed prompts, thresholds and evaluation hooks give an operator places to express domain judgement. But that also leaves the central quality problem with the operator: selecting authoritative sources, defining what is important, and checking whether generated titles, summaries and event groupings preserve the underlying reporting. The repository itself emphasizes that its included 18 public overseas AI sources are examples and that real sources should be replaced for another industry. The AIHOT repository

The licensing boundary is also concrete. The code uses the MIT license, while the repository says the AIHOT name and logo are not included; a deployment intended as an independent publication needs its own identity as well as its own source policy. The AIHOT repository

Claude Opus 5.5 Video List Publishes 475 Prompts

David Díaz — Mon, 05 Oct 2026 19:40:19 +0000

The awesome-opus5-5-videos repository has published 475 Claude Opus 5.5 prompt files associated with generated videos, along with a data/videos.json index. Its practical consequence for developers is direct: the documented workflow is to copy a prompt into Claude Code, the Claude app or another agent running Opus 5.5, request a single HTML file, and record the rendered page.

The README highlights 100 entries—one for each distinct prompt—split into 58 motion graphics, 16 explainers, 14 3D scenes and 12 games or interactive projects. The latest listed update, dated September 29, 2026, says 86 videos were added, mostly in the motion-graphics and explainer categories.

From creator post to browser remake

Every entry links to its creator’s original post. The repository also directs readers to Skillry, where all 475 originals can be viewed beside live remakes, according to the project page.

The project says every listed video was made by asking Claude Opus 5.5 to write animation as code, using technologies such as HTML, Canvas, SVG and Three.js. Individual entries carry more specific implementation labels, including GLSL, WebGL, GSAP, CSS, Web Audio, particles and playable interactions, as shown in the repository index.

The inputs are not uniformly complete. Some creators shared only part of a prompt, while others published a description of the result rather than the prompt itself; the corresponding files identify those limitations, according to the README.

Analysis: a pattern library, not a benchmark

Analysis: The uneven inputs make this collection more credible as a prompt-pattern archive than as a controlled test of model performance. Because the project acknowledges partial and missing prompts, a difference between an original and its remake cannot establish that the published words alone caused the result. The side-by-side view supports visual inspection, but not strict reproducibility claims.

The repository carries an MIT license, while its README separately says each video and prompt belongs to its creator and invites creators to request changes or removal through an issue. Analysis: That leaves the scope of reuse less explicit than the copying workflow. Developers can inspect and test the published inputs, but the page does not reconcile its repository license with the stated ownership of each underlying prompt and video.

anything2explainer Packages Remotion Explainers as an Agent Skill

David Díaz — Sat, 19 Sep 2026 19:40:10 +0000

anything2explainer packages a Claude Code and Codex skill that turns a topic, article or document into a narrated explainer video. Developers get a code-first production path: every frame is drawn with Remotion in React and TypeScript, rather than assembled from stock footage or produced by a generative video model, so individual shots remain editable as source code.

The project targets a 1280×720, 30fps H.264 MP4 with synchronized voiceover, word-aligned subtitles, chapter cards, a top HUD and a chapter progress bar. It supports Chinese and English and delivers the research document, narration, storyboard, per-shot source code and QC reports alongside the finished video, according to the repository specification.

A production method, not a CLI

The repository explicitly describes the project as something other than a CLI. It ships a compilable Remotion template, visual primitives, lighting components, voiceover and rendering tools, style and motion specifications, a multi-agent work protocol and a complete reference film intended to establish the quality target for a run, as detailed in the project documentation.

Its prescribed workflow has nine stages: scaffold the project; research the subject; write the narration and frame-accurate timeline; storyboard each shot; build overlays and topic-specific primitives; produce a pilot group and 30-second preview; construct the remaining shots in parallel; render the full film and collect frame metrics; then run QC, apply fixes, re-verify the result and prepare delivery notes. Build agents receive groups of five to seven shots and write Remotion components for them, according to the documented process.

Narration structure controls the edit. A blank line marks both a paragraph and a shot, while TTS word boundaries feed the subtitle table and frame-level timeline. The repository says shots retain a short hold after their final element appears, making the completed film longer than the raw speech by design under its timing rules.

The process stops at four checkpoints: selection of length and language, narration approval, choice of voiceover engine and review of the first 30 seconds. The narration checkpoint occurs before voice generation because shot frame numbers are subsequently fixed to that timeline, while the preview is rendered before all shot groups are built to allow an earlier style decision.

The repository estimates one to three hours of wall-clock time depending on video length. Its reference tier for a three-to-five-minute film specifies 40–50 shots, eight build agents and roughly two hours; these figures are the project’s planning estimates rather than an external benchmark published by the maintainer.

Manual control remains available

For agent use, the documented installation symlinks the repository into either the Claude Code or Codex skills directory. That setup is optional: developers can instead invoke the project template, TTS, storyboard, preview, render and frame-metrics scripts by hand using the documented sequence.

The listed environment includes Node 18 or later, FFmpeg and Python packages selected partly by the TTS engine. The scripts were developed and verified on macOS; the repository says Linux should work, documents a verified Raspberry Pi 5 configuration and labels Windows untested in its platform notes.

Analysis: inspectability versus pipeline ownership

Analysis: The project’s defensible distinction is not automatic video creation by itself, but the conversion of production decisions into inspectable artifacts: sourced research, narration, timing tables, storyboards and shot components. That structure may make a factual correction or visual revision easier to isolate than it would be in a single generated clip. The same design leaves the developer responsible for dependencies, TTS selection, agent execution and final review, all of which remain explicit parts of the documented workflow. The unresolved trade-off is whether that added control justifies operating a multi-stage video toolchain rather than using a less editable service.