webtoon-harness, twenty-seven agents and no code to install

The install is a directory copy into someone else's repo

There is no package to add and no binary to fetch.

# 1) place the harness into your project
git clone https://github.com/revfactory/webtoon-harness.git
cp -r webtoon-harness/.claude /path/to/your-project/

# 2) run Claude Code in that project, then

The repository's top level holds a .claude directory, a licence, a README, and a docs directory. Everything the harness is made of lives inside .claude, split into an agents folder holding the twenty-seven agent definitions and a skills folder holding the six methodology skills.

That is why the repository's primary language reads as HTML in places. The only markup it produces is the vertical scroll viewer that gets assembled at the end, and the harness itself is markdown. The copy step puts a directory named .claude at the root of a project you already have, which is the same place Claude Code expects to find its own configuration.

Once it is in place you drive it by asking in natural language inside a Claude Code session. The four examples given are: make the first episode reflecting current trends, make the next episode reusing worldview and style and continuity, make this episode's twist stronger, and redraw panel 23. The orchestrator skill is described as triggering automatically and coordinating the teams.

Twenty-seven agents across four teams, reconstituted per phase

The team structure is stated as four teams of twenty-seven agents, and the teams are described as being reconstituted at each phase.

The research team has five. Four investigate in parallel, covering genre trends, platform ranking, reader reaction, and hook or twist reverse-engineering, and a fifth synthesises their findings into a single planning brief.

The scenario team has nine and covers the whole distance from a high concept to a final script: concept architect, worldbuilder, character designer, series plotter, twist master, tension engineer, episode outliner, dialogue writer, and script editor. The twist plan and the tension curve are designed in parallel, and the work converges through a beat sheet into a script and then a final version. Two guarantees are stated for every episode, one twist per episode and fifty or more panels.

The visual team also has nine, and the assembly and review team has four: episode compositor, quality reviewer, continuity manager, and a showrunner who signs off before packaging as a release.

Korean dialogue is drawn by the image model, not typeset

The central technical decision is that speech bubbles and Korean dialogue are rendered as part of the image, and the assembly step adds no text overlay at all.

The stated reason is consistency of character appearance, and the mechanism is a reference sheet rendered before anything else. Character angle and expression references are produced first, and that sheet becomes the single source of truth across episodes. Everything downstream injects it, through a style bible, consistency tokens, and location tokens passed into every prompt.

The cost of that choice is that the legibility of Korean text becomes the image model's problem. The validation loop explicitly checks for Korean text corruption, alongside duplicate images detected by md5 hash and sudden changes in background. Six axes in total are checked, and only panels that fall below the standard are regenerated.

That single decision is what makes the pipeline coherent and also what makes it fragile. A separate letterer agent is named in the visual team, which suggests the lettering is specified as a contract rather than left to chance, and the shot list stage produces an in-image bubble specification for each scene. But the rendering itself is still a diffusion model asked to draw Hangul inside a bubble.

Panel rendering goes through a second vendor's CLI

The image stage is not part of Claude Code, and the requirement is specific.

Rendering runs through the codex CLI, using the image generation tool exposed by its exec mode, and authentication is described as requiring ChatGPT OAuth rather than an API key. The requirement also caps global concurrent codex sessions at five.

Three named artist agents share that pool, and the stated batch size is five images at a time. That lines up exactly with the cap, which means the concurrency limit is the unit of work rather than an incidental setting.

It also sets a throughput ceiling. Fifty or more panels per episode is the stated minimum for a single episode, so at five per batch an episode needs at least ten sequential rounds of the image pipeline, all through one logged-in ChatGPT session. The cap is described as something that is kept to, which reads as a deliberate limit rather than a documented quota.

The reference to how the codex CLI is used points at a skill in a separate repository, so the operational documentation for the rendering half of this pipeline lives somewhere other than in the harness it powers. The README also notes that the infographics in the repository itself were produced the same way, five at a time at a 16 by 9 ratio.

Continuity is a tracked asset, not a hope

Two features exist to stop the pipeline from drifting, and both are about memory across runs.

The first is the reference sheet, already described as the single source of truth for appearance. The second is a continuity management role in the assembly team, and its scope is stated as tracking character appearance, settings, and foreshadowing across episodes.

Foreshadowing is the interesting one. It is the kind of plot element that only matters if something set up in episode four is paid off in episode nine, and a pipeline that regenerates every episode from a brief has no natural place to keep that debt. The design principle that follows is dialogue-driven and high tension, with narration minimised and tension, information, and twists carried by character dialogue and action instead.

The audit trail is the third mechanism, and it is the bluntest. All intermediate output is preserved in a workspace directory. That means every reference sheet, every style bible, every shot list, every validation report, and every rejected panel stays on disk. For a fifty panel episode produced with a regeneration loop, that is a lot of files, and it is the price of being able to answer where a particular panel came from.

Six phases, six skills, and three truncated diagrams

The execution is described as a six step run, and the phases are enumerated from zero to six.

Phase zero checks context, then preparation, research, scenario, visual, and assembly with review, and a final wrapping phase. Whether phase zero counts as a step is left to the reader, which is a small thing but the kind of ambiguity that shows up later as an off-by-one in a schedule.

Six methodology skills sit alongside the agents, and the main orchestrator is marked as the entry point. The named ones are the orchestrator, trend research, scenario writing, panel breakdown with style and consistency tokens, and panel render for the parallel image stage. The sixth directory name is cut off in the file, ending partway through.

Two of the three diagrams in the README are truncated in the same way. The directory tree ends mid-word inside the skills listing, and the workflow diagram ends with an arrow pointing at a single letter. The workflow itself is otherwise the most useful artefact in the file, because it names every artefact and every hand-off: a trend brief feeds concept, world, characters, and series arc, which branch into a twist plan and a tension curve, converge on a beat sheet, script, and final script, then split into a style bible with location tokens and speech bubble conventions on one side and character sheets on the other, produce reference images, a shot list keyed by scene and location, a lettering specification, then composed prompts, then panel images that loop through six-axis validation until a validation report says everything passed, and finally an index page with no overlay.

Narrow requests re-run part of the team, not the episode

The four example prompts are worth reading as an API, because each one names a different scope of re-execution.

Asking for the next episode reuses worldview, style, and continuity and generates a new one. Asking for a stronger twist this episode re-runs part of the scenario team rather than the whole pipeline. Asking to redraw panel 23 re-renders that panel and re-validates it.

That granularity is the point of the agent split. A monolithic prompt would either redo everything or nothing. Because the teams are reconstituted per phase and the phases have stable names, a request can name a phase and the orchestrator can work out which agents belong to it.

The panel-level example also shows the validation loop closing properly. Regenerating one panel means re-entering the six-axis check for that panel rather than trusting the render, which is what keeps a manual fix from silently reintroducing a problem the validator had already caught.

What the prompts do not show is any way to change the pipeline's own shape. Every design decision in the file, from fifty panels per episode to a twist in every episode to consistency above all, is fixed in the agent definitions and the skills. The interface is a natural language request against a fixed pipeline, not a configurable one.

Editorial conclusion

This harness is worth reading as a worked example of how far a team of narrowly scoped agent definitions can be pushed, and worth copying if you build webtoons in Korean and already have both a Claude Code session and a codex CLI login. Check four things first. Whether you can live with the in-image bake, since every line of dialogue is drawn by an image model rather than typeset, which is what the Korean corruption check exists to catch. Whether five concurrent codex sessions is enough throughput for fifty or more panels per episode. Whether the sixth skill is the one you expected, since the README cuts off before naming it. And whether you want the whole directory copied into your project root, because that is the installation.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. revfactory/webtoon-harness on GitHub