nexu-io/html-anything: an agent-driven HTML editor that reuses your existing coding CLI session

The gap html-anything is aiming at

The README states the premise directly: Markdown is the draft, HTML is what humans read, and your local agent writes it. That framing targets a specific workflow, not document editing in general. People who write long posts, decks, posters or platform-specific cards usually start in Markdown because it is fast to type and easy to diff, then spend the second half of the job translating that text into something presentable. The translation step is where the time goes, and it is also where the tooling usually breaks down: a Markdown-to-slide converter gives you its template, not yours.

This project's answer is to skip the converter and let a coding agent emit the HTML directly, guided by skill templates that constrain layout and palette. The audience is narrow and identifiable: developers and technical writers who already have a coding agent CLI installed and logged in, and who want a finished visual artifact rather than a styled Markdown render. Someone who only needs a clean README does not need this. Someone who needs pixel-identical output on every run probably does not want it either.

How the agent, the skills and the surfaces fit together

The repository is a Next.js application whose skill library lives under next/src/lib/templates/skills/. Each skill is a directory containing a SKILL.md file plus a real example.html that the README says you can open straight from the repo with no auth and no setup. The SKILL.md frontmatter carries metadata the picker reads, including a recommended: rank that orders the Featured group. The README gives deck-guizang-editorial as recommended: 1, deck-swiss-international as 2, doc-kami-parchment as 3, magazine-poster as 4 and video-hyperframes as 5.

On the agent side, the README lists nine coding-agent CLIs that are auto-detected on your PATH: Claude Code, Cursor Agent, Codex, Gemini CLI, GitHub Copilot CLI, OpenCode, Qwen Coder, Aider and IBM Bob. The data flow is therefore: you supply content, the app selects a skill template, and the local CLI session does the generation. No API key is involved because the app is reusing credentials the CLI already holds. That is the central architectural decision, and everything else follows from it.

The 75 skills are grouped across nine deliverable surfaces: magazine articles, keynote decks, résumés, posters, Xiaohongshu cards, tweet cards, web prototypes, data reports and Hyperframes videos. The video-hyperframes skill is described as a Remotion-compatible storyboard producing 6 to 10 sequential 1920x1080 frames with hidden duration and transition markers plus an auto-play script, intended to be handed to another tool. That is a storyboard generator, not a video renderer, and the README does not claim otherwise.

What a skill directory actually constrains

The showcase entries are the most concrete evidence of how tightly a skill pins down output. deck-guizang-editorial is described as 10 locked layouts across 5 palettes (Ink, Indigo Porcelain, Forest Ink, Kraft, Dune), and the README credits op7418/guizang-ppt-skill as the inspiration. deck-swiss-international is described as a 16-column grid with one saturated accent chosen from Klein Blue, Lemon, Mint or Safety Orange, across 22 locked layouts. doc-kami-parchment uses a #f5f4ed ground with an ink-blue accent and a single serif voice, credited to tw93/kami.

The word doing the work here is locked. A skill is not a theme you tweak; it is a bounded design system the agent is expected to stay inside. That is a reasonable trade: you give up free-form layout control in exchange for output that does not look like an agent improvised it. The cost is real. If your content does not fit 10 or 22 predefined layouts, the agent has to either bend the content or break the constraint, and the documentation does not describe which of those it does. I would want to see that behaviour on an awkward input (a deck with 30 sections, say) before trusting the locked-layout claim in production.

Getting it running and what the export step does

The README advertises a 30-second quickstart and anchors it at a #quickstart section, but the supplied material does not include the install commands themselves, so I cannot reproduce them here without inventing them. What the material does establish is the precondition: a supported coding-agent CLI must be present and logged in on your PATH, because that is where the generation happens. The homepage at open-design.ai/html-anything/ is presented as the place to review surface modes before cloning.

Export targets are named as WeChat, X, Zhihu, plus .html and .png downloads. The README also mentions a sandboxed preview, which is the right call: agent-generated HTML can contain scripts, and rendering it inside a sandbox before you export limits the blast radius. The export step is not a file copy. Platform targets like WeChat and Zhihu impose their own HTML and CSS restrictions, so something in the pipeline has to inline or rewrite styles to survive the paste. The documentation does not detail that transformation, and it is the part most likely to surprise you, because a layout that looks correct in the sandboxed preview can lose its grid once a platform strips unsupported properties.

Where the design breaks down

The largest limitation is the one the architecture creates. Because generation is delegated to a CLI, output is non-deterministic in a way a template engine is not. Two runs with the same content and the same skill can produce different HTML. For a poster or a tweet card that is usually acceptable. For a data report that gets regenerated on a schedule, it means you cannot diff two versions and expect the difference to reflect only your data.

Second, the nine-CLI support list is also a nine-way compatibility surface. Each CLI has its own invocation, output conventions and failure modes, and the README does not describe how the app normalizes them. If your CLI of choice is detected but returns output in an unexpected shape, the failure will look like an app bug rather than an adapter gap, which makes it harder to diagnose.

Third, the project is HTML-first by design, so anything that needs PDF, DOCX or a slide file as the deliverable is out of scope. The .png export covers images, and the Hyperframes skill hands off to Remotion, but there is no native path to an editable deck file. If a colleague needs to open your deck in presentation software and move a text box, this is the wrong tool.

How it differs from a Markdown-to-slides converter

The obvious comparison is Marp or Slidev, which take Markdown and compile it to slides through a fixed theme system. The difference in approach is where the variability lives. In Marp, the theme is a CSS file and the compiler is deterministic: same input, same output, and a theme author can predict exactly what any Markdown construct will render as. In html-anything, the variability lives in the agent, and the skill is a prompt plus a reference example rather than a compiler. You gain layouts that would be tedious to express as pure CSS rules, and you lose reproducibility.

That trade makes sense for one-off artifacts with a visual bar to clear. It makes much less sense for anything that runs unattended. A Marp build can sit in CI and fail loudly on a syntax error. An agent-generated deck cannot, because there is no syntax to fail on, only a judgment about whether the output looks right. The README's own framing, that you do not hand-edit docs anymore, is consistent with this: it assumes a human is looking at the result before it ships.

Licence, lineage and what maintenance looks like

The project is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirements around preserving notices and stating changes. That is a permissive licence and it is compatible with most corporate policies, but I am not giving legal advice and you should route it through whoever handles that at your organisation. One practical note: the skill templates embed design decisions credited to third-party projects (op7418/guizang-ppt-skill, tw93/kami), and the README does not state the licence of those specific skill directories. If you plan to redistribute modified skills, check the individual directories rather than assuming the repository-level Apache-2.0 covers every asset.

On maintenance, the README positions html-anything as the focused sibling of nexu-io/open-design, described as the same team's larger project, and the last push recorded for this repository is 2026-08-23. No releases were retrieved, so there is no version history to reason about. The upgrade cost that matters here is not code, it is skills: because each skill is a directory with its own SKILL.md and example.html, local edits to those files will conflict with upstream changes, and there is no documented migration path for skill-level customisation.

Editorial conclusion

Adopt html-anything if you already run one of the nine listed coding-agent CLIs and you produce recurring visual deliverables (decks, posters, Xiaohongshu cards, data reports) that you currently rebuild by hand in a browser tool. Do not adopt it if you need a deterministic renderer, a headless CI pipeline, or a non-HTML output format, because the generation step is an agent writing markup, not a template engine filling slots. Before committing, verify three things on your own machine: that the CLI you intend to use is detected on PATH, that the sandboxed preview opens the HTML your agent produces without console errors, and that the export path for your target platform (WeChat, X or Zhihu) preserves the CSS you care about after its inlining and rewriting pass.

Official sources

1. Issues
2. License: Apache-2.0
3. nexu-io/html-anything on GitHub
4. Project website
5. README