Editable-Design: agent-driven editable visual artifacts from a brief

What Editable-Design solves, and for whom

Most image generators return a flat bitmap. You get a poster, and the moment a date or a label changes you are back in the prompt box hoping the next sample keeps the rest of the composition intact. Editable-Design takes the opposite position: the deliverable is not the picture, it is the picture plus the structure that produced it. The README frames the project as "coding-agent-driven creation of editable, tastefully crafted visual artifacts", and the outputs listed for the editable-design Skill are HTML, PNG, a visual editor, a layer breakdown and an Agent Design Replay.

The audience is narrow and specific. You need a coding agent (the README's examples use Codex) and you need to care about post-generation edits. Researchers who want a workflow diagram in PowerPoint, marketing teams producing campaign visuals, and anyone building infographics where the text must remain real text rather than pixels. If you never intend to touch the output again, the editable layer is overhead you are paying for without using.

Three Skills, three output contracts

The repository is a monorepo of Skills rather than a single application. The README's comparison table lists three: paper-fig, which turns method descriptions into paper workflow and architecture diagrams and emits editable PPTX; editable-design, which covers posters, infographics and marketing campaigns and emits HTML, PNG, a visual editor, a layer breakdown and Agent Design Replay; and html-to-pptx, which converts an existing compatible HTML design into editable PPTX. The README states that paper-fig does not depend on either of the other Skills, so you can install one without dragging in the rest.

The mechanism is agent-mediated rather than library-mediated. You do not call a Python function that returns a file. You ask the agent to install a Skill from a repository subdirectory, then in a later task you invoke it by name and describe what you want. The README describes one persistent agent that "plans, builds, renders, and repairs the artifact", and Agent Design Replay is the artifact that exposes the HTML workflow's creation path. The design principles section is explicit that checks cover rendering and format-specific contracts, and that the output still needs human review for scientific accuracy. That is a meaningful admission: the pipeline validates that the file is well formed, not that the diagram is correct.

Installing the editable-design Skill and running a first brief

There are two installation routes. The agent route is the one the README leads with: open a Codex task and paste a request to install and initialize the Skill, including its runtime dependencies and font kit, then run its doctor check. The manual route exists for people who want to avoid downloading the Gallery media, and it uses a sparse, blob-filtered clone so only the Skill directory lands on disk.

After cloning the repository and setting the sparse-checkout path, the README copies the Skill into the Codex skills directory, installs its Node dependencies, installs the font kit and runs the doctor check:

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

The doctor script is the step worth watching. If it reports a missing dependency or font, fix that before generating anything, because a partially installed font kit changes what the renderer can lay out. Once it passes, start a new Codex task and describe the visual in plain language. The README's own example is a field guide about the red panda, invoked by Skill name:

Use $editable-design to create an editable encyclopedia-style field guide about the red panda.

The README recommends high reasoning effort or above for complex diagrams and layouts, which is a hint about where the pipeline gets expensive. Expect the task to take longer than a single-shot image prompt, and expect to iterate on the brief rather than on the pixels.

Paper Fig and the PowerPoint path

Paper Fig is the newest piece, announced on 2026-09-08 and described as developed with GPT-6. Its purpose is narrower than the rest of the repository: take a method description and a preferred visual style, and produce a paper workflow diagram as editable PPTX with individual text boxes, shapes and image elements. The README's screenshot caption says the diagram is open in PowerPoint with those elements selected, which is the claim to verify yourself.

Installation for Paper Fig is a separate guide at skills/paper-fig/INSTALL.md, and the manual sparse-checkout path selects skills/paper-fig instead. The agent-side request is short:

Install the paper-fig Skill from:
https://github.com/yejy53/Editable-Design/tree/main/skills/paper-fig

Then you supply the method description and the style. The Gallery section is careful about what these examples mean: it states that the reference cases come from PaperGallery and the credited original papers, and that they are "qualitative examples, not a model-performance benchmark". Read that literally. The gallery shows what the pipeline can produce; it does not tell you the success rate on your own methods, and the README offers no number that would.

Where the pipeline breaks down

The most concrete limitation is stated in the design principles: the output needs human review for scientific accuracy. Automated checks cover rendering and format-specific contracts, which means a diagram can be structurally valid, fully editable, and still wrong about the method it depicts. For a paper figure that is the failure mode that matters, and no amount of layer separation catches it.

The second constraint is dependency weight. The html-to-pptx Skill prepares an isolated Python environment and Playwright Chromium on its first conversion, and the README notes the user does not run dependency commands manually. That convenience hides a browser download. In an air-gapped or tightly controlled environment, that first conversion is where the install will fail.

Third, this is the wrong tool if you want a template. The related searches around editable design are dominated by template requests (wedding cards, menus, blank templates), and this repository is not that. It has no template library, no browser editor for non-technical users, and no free download of pre-made designs. It generates artifacts from a brief inside a coding agent. If your actual need is a fill-in-the-blank template, the README gives you nothing.

Editable-Design compared with Canva

The comparison that people will actually make is with Canva, and the difference is architectural rather than cosmetic. Canva is a hosted editor with a template catalogue: you start from someone else's layout and edit it in a browser. Editable-Design starts from nothing but a description and produces the layout, then hands you HTML with semantic layers, a visual editor, a layer breakdown and a Replay of the creation path. The editing surface exists, but it is generated per artifact rather than browsed from a library.

That changes what you can do. With Canva, the ceiling is roughly the template plus your patience for dragging boxes. With this project, the ceiling is the agent's planning and the renderer's contract, and the floor is that you must have a coding agent installed and working. Canva also has a free tier and a public template pool; Editable-Design is Apache-2.0 source that you install and run yourself. Neither is a superset of the other. If a colleague needs to tweak a headline next Tuesday without touching a terminal, the hosted editor wins outright, and no amount of layer separation compensates.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-08, so it is current as of writing. The release history is short: overview-v1 on 2026-08-28 and the Paper Fig announcement on 2026-09-08. There is no long tail of tagged versions, which means upgrade cost is mostly the cost of re-reading the README and the Toolkit guide rather than migrating between releases. The TOOLKIT.md file is the stated place for detailed setup and packaging.

Licensing is Apache-2.0, with a separate THIRD_PARTY_NOTICES.md at the repository root. The font kit is installed by a script rather than vendored, and the Gallery contains reference cases credited to PaperGallery and their original papers. If you plan to redistribute generated artifacts, the fonts and any bundled media are the parts to check against THIRD_PARTY_NOTICES.md, not the Skill code. This is a description of what the repository contains, not legal advice; for a commercial deployment, have someone read the notices.

The ongoing cost is reasoning budget. The README recommends high reasoning effort for complex layouts, and each artifact is produced by an agent task rather than a fixed function call, so cost scales with how much the agent has to plan and repair.

Editorial conclusion

Adopt Editable-Design if you already run Codex tasks and need posters, infographics or paper workflow diagrams whose text and images stay separately editable after generation. Skip it if you want a browser-based template editor or a GUI with a template library; the repository ships Skills and a gallery, not a template catalogue. Before committing, run the editable-design Skill's doctor check and install-font-kit.sh, confirm that the html-to-pptx conversion path produces a PPTX whose text boxes you can actually select, and check the Apache-2.0 and THIRD_PARTY_NOTICES.md terms for the fonts and any bundled media you intend to redistribute.

Frequently asked questions

Official sources

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