Editable-Design installs by prompting one agent, and its only release is named overview-v1

The documented install is a prompt, not a command

The quick start begins by telling you to open a Codex task and ask it to install the skill. The text to send is short:

Install and initialize the editable-design Codex Skill from:
https://github.com/yejy53/Editable-Design/tree/main/skills/editable-design

Install its runtime dependencies and font kit, then run its doctor check.

So the primary install path is a natural-language instruction handed to an agent, which is then asked to fetch a directory, resolve runtime dependencies, install a font kit and run its own diagnostic. Nothing about that is wrong, and it is a reasonable way to distribute a skill to an agent that can read a URL. But it means the install path is a behaviour of the agent rather than a procedure you can audit.

Three details in that prompt are worth noting. It says the Codex skill specifically, not an agent skill generically. It names a font kit as an install step, so typography is part of what gets installed rather than something the renderer fetches. And it ends with a doctor check, which implies the skill ships its own diagnostic and expects to be asked to run it.

The invocation afterwards uses the same agent's syntax, with a dollar-prefixed name: `Use $editable-design to create an editable encyclopedia-style field guide about the red panda.` That is a skill reference in one particular client's convention, not a portable one.

The recommended settings line is also agent-specific, advising high reasoning effort or above for complex diagrams and layouts. The artefact is an HTML file; the tooling around it is not portable.

A manual path exists because the gallery media is large enough to clone around

Collapsed under a heading for manual installation without gallery media, the page gives the real commands:

git clone --depth 1 --filter=blob:none --sparse \
  https://github.com/yejy53/Editable-Design.git
cd Editable-Design
git sparse-checkout set skills/editable-design

mkdir -p ~/.codex/skills
cp -R skills/editable-design ~/.codex/skills/
npm ci --prefix ~/.codex/skills/editable-design/scripts
~/.codex/skills/editable-design/scripts/install-font-kit.sh
~/.codex/skills/editable-design/scripts/doctor.sh

Three git flags do the work here: a shallow clone, a blob filter that skips file contents entirely, and a sparse checkout narrowed to one directory. The heading explains why: the repository carries gallery media, and this is the way to install the skill without downloading it.

That implies a large repository, but the page gives no size. A reader cannot tell whether the sparse route saves ten megabytes or ten gigabytes, which changes whether this is the recommended path or a nicety.

The rest of the sequence is four steps with a clear order: copy the directory into the agent's skills folder, install Node dependencies for the scripts subdirectory, run the font kit installer, run the doctor. So a complete install of one skill involves a Node package install and two shell scripts, which is more state than an agent prompt implies.

The page also notes that for the other skill you select a different directory in the sparse checkout and follow that skill's own installation guide, which is the right shape for a repo where you are told to install one skill at a time.

Three skills, three runtimes, and one declared primary language

The skill table lists three entries and their outputs. `paper-fig` generates paper workflow and architecture diagrams from method descriptions and outputs an editable PPTX. `editable-design` handles posters, infographics and marketing campaigns, and outputs HTML, PNG, a visual editor, a layer breakdown and an Agent Design Replay. `html-to-pptx` converts an existing compatible HTML design to an editable PPTX.

The page makes an independence claim that is worth crediting: install only the skill you need, and paper-fig does not depend on either of the other two. Most skill collections hide their coupling, and stating it means you can reason about the dependency graph from the page alone.

The runtimes are less tidy. The manual install runs `npm ci` against a scripts subdirectory and then two shell scripts. The PowerPoint skill automatically prepares an isolated Python environment and a Playwright Chromium, and the user is told they do not need to run dependency commands. The diagram skill is described as developed with GPT-6 and has its own install guide.

So across three skills you have Node, Python, a Playwright-managed browser and shell. The repository's recorded primary language is Python, which reflects one of the three rather than all of them.

The chart table also uses the phrase compatible HTML as the input condition for the conversion skill, without saying what makes HTML compatible. That is the one precondition a user is most likely to hit and the one the page does not define.

The deliverable is six artefacts, one of which is a replay of the build

When the skill finishes, the page says it creates the finished design together with its editable source: real text, independent imagery, semantic HTML layers, a visual editor, a layer breakdown, and an Agent Design Replay.

Count those and it is six things, not a file. Real text and independent imagery are the substantive claim, because they mean the text in the poster is the text in the document rather than text baked into a picture. Semantic HTML layers mean the structure is inspectable. The visual editor is the editing surface. The layer breakdown is a separate description of what is in the composition.

The replay is the unusual one. It is described as exposing the HTML workflow's creation path, so the artefact includes a record of the order in which the agent built the thing.

The gallery shows what that produces in practice, and the flagship example is instructive. The prompt for the tea poster specifies a 3:4 vertical format, a palette of dark green, off-white and gold, rice-paper texture and restrained negative space, and then lists the exact strings to display: the brand name, the product line, a launch message, two prices, a second-cup half-price offer, an upgrade price, and a promotion limited to the first hundred customers each day. Every string is written out to be displayed exactly.

So the demonstrated capability is marketing collateral where the copy is prescribed and the composition is generated, with the copy surviving as real text. That is a specific and useful thing, and it is narrower than the general claim of visual artefacts.

The checks cover rendering and format contracts, and concede accuracy is out of scope

One bullet in the design principles section states the verification scope precisely, and it is the most useful sentence on the page:

> Local editing and verification. Text and structural elements remain independently editable. Checks cover rendering and format-specific contracts; the output still needs human review for scientific accuracy.

So the verification is two-part and neither part is about whether the content is right. Rendering checks confirm the thing displays. Format-specific checks confirm the file honours the contract of its format, which for a PPTX means it opens and its layers behave. Neither checks a claim.

The concession matters most for the diagram skill, whose whole purpose is producing scientific figures. A workflow diagram can render correctly, sit in the right layers, be fully editable and still be wrong about the method it depicts. The page says this once, in a design-principles bullet, and does not repeat it in the Paper Fig section.

The other two principles are about the process rather than the output: one persistent agent plans, builds, renders and repairs the artifact, with the replay exposing that path, and the agent plans a visual composition before building it with editable text, layout and independent image assets.

So the pipeline is plan, build, render, repair, and the replay is the record of it. That is a sensible loop for a tool whose failure mode is a broken layout, and it says nothing about a wrong diagram.

The Design Arena post is footnoted as an internal simulation

The most eye-catching link on the page is a blog post titled How to hacking Design Arena: What Makes Generated Websites Fascinating?, offered in English and Chinese.

Underneath it, in small print, the page disclaims it:

> Exploratory internal simulation, not official Design Arena results. The animation term for image generation denotes images used per page, not image-generation tool calls.

Both halves are worth reading. The first says the post is not reporting results from Design Arena, which is a third-party evaluation, but the author's own simulation of what might drive such a result. A post whose title asks what makes generated websites compelling, attributed to a tool that makes generated websites, would otherwise read as a benchmark claim.

The second clarifies a term used inside the post's own animation, which appears to use a Chinese phrase for generating images in a way that could be read as calling an image generator. The page says it means images placed per page instead. So the clarification is about the reader's interpretation of the demonstration rather than about a factual claim, but it is the kind of thing that would otherwise be argued about in the comments.

The blog is dated 2026-08-16 in the news list, ahead of the initial release announcement on 2026-09-04. So the blog about generated websites came before the public release of the thing that generates them.

The rest of the news list is dated and specific: a paper-figure tool on 2026-09-08 and the initial release on 2026-09-04.

One release named overview-v1, and a version scheme for the skills that is never stated

The repository has a single release, and it is not a version of anything that runs. It is tagged `overview-v1` and titled Editable Visual Design Overview, published 2026-08-28. There is no v1, no v2, and no package version for any of the three skills anywhere on the page.

For a repository whose entire delivery mechanism is an agent fetching a directory from a branch, that absence is a real operational question. The prompt-based install points at `tree/main/skills/editable-design`, so an install tracks the default branch rather than a tag, and nothing on the page tells you how to ask for a known-good state.

The repository is also the website. The root holds `.nojekyll`, `index.html`, a custom `player.html` that the overview links into with a fragment, and separate `site/`, `assets/`, `notes/`, `docs/`, `gallery/`, `skills/` and `tools/` directories, plus `pack.sh` for packaging and a `TOOLKIT.md` for detailed setup. The Apache-2.0 licence sits alongside `THIRD_PARTY_NOTICES.md`, which is the right pairing for a project that bundles assets, and the news list is mirrored into `NEWS.md`.

The gallery is the one place a count is committed to: thirteen visual-design examples across five categories, campaigns, information design, text-led design, poster and art design. The diagram examples are named separately, three of them, OmniManip, Compact3D and ICEdit.

One loose thread: the font kit is installed by a script and the third-party notices file exists, but the page never names a single typeface.

Editorial conclusion

This is worth trying if you produce visual documents where the text has to stay editable, because that is the specific thing it addresses and the output format explains why: semantic HTML layers rather than a flattened image. Two cautions before you commit time to it. The whole documented workflow is bound to one agent, since the install is a prompt, the install directory is that agent's home, and the invocation syntax is that agent's skill reference, so a different harness means a manual install at minimum. And the project says plainly that its checks cover rendering and format contracts rather than scientific accuracy, so a diagram that renders correctly can still be wrong. Treat the output as a draft a designer signs off on. If you need the same result on several machines, the sparse clone path is the one to automate.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. yejy53/Editable-Design on GitHub