The previous post (Chinese) covered Li Bai (李白) — the orchestrator on the novel production line who manages no writing, only discipline. But a production line can’t run on a single role: who builds the skills? Who reviews them once built? Who fixes what the review finds? Who files the fixed versions into the library? All of these positions are staffed, and every one of them is named after mythology — Cangjie (仓颉), Nüwa (女娲), Bian Que (扁鹊), Hua Tuo (华佗), Gao Yao (皋陶), Yushi (御史), Shiqu (石渠), Suiren (燧人), Ou Yezi (欧冶子), Mozi (墨子), Lu Ban (鲁班), Huangdi (黄帝). This post is about the crew itself: what each skill manages, why one role gets one skill, how they hand work to each other, and why the naming follows a mythological scheme. Every responsibility described here follows the actual SKILL.md of each skill — I read through each one before writing.

One Role, One Skill

The organizing principle of the crew is a single rule: one role, one skill, single responsibility. This is not an aesthetic preference; it was beaten in by a counterexample. Before Li Bai there was a do-everything writing skill in which writing, data, and process grew inside one body, and after years of iteration it bloated to the point of being unmaintainable — Li Bai’s design document has a section specifically titled “the boundary between governance principles and narrative mechanisms,” declaring a brand-new mechanism design with zero inheritance, keeping only the workspace-level general governance discipline. The old lesson became the new structure: capabilities split apart, each standing on its own.

Single responsibility lands in the skill file’s wording as the three elements of a description: what it does, when it triggers, and when it does not trigger. The first two are self-explanatory; the third is the key — every member’s “does not trigger” section is a signpost pointing to its neighbors. Bian Que’s says “for skill-quality evaluation go to Darwin”; Hua Tuo’s says “for code review go to Bian Que, for evaluation and scoring go to Darwin”; Cangjie’s says “for evaluation and optimization go to Darwin, for merging go to Ou Yezi, for building character skills go to Nüwa”. With boundaries written at the door, routing never collides, and the main agent knows at a glance whom to hand the job to. Li Bai is written the same way: leaderboard scanning, book deconstruction, and memory sedimentation are not its job and get forwarded to story-long-scan, story-analyze, and story-learn respectively; unattended batch runs are not its job either and go to the short-story pipeline.

The Creation Roles: Cangjie and Nüwa

Cangjie manages “building general-purpose skills from nothing,” but its section 0 is not how to write — it is whether the thing should be a skill at all. That decision table is worth copying out: repeated and deterministic work (inputs, outputs, and steps all fixed) becomes a script, at a token cost tens of times lower than a skill; repeated work requiring model judgment becomes a skill; stable knowledge is sedimented into a documentation skill; new tooling or system-level capability calls for a plugin or MCP; one-off questions get answered directly. A skill is a thin shell around scripts — the shell handles “when to use it, how to call it, how to troubleshoot it,” and the real work lives in deterministic code. Li Bai’s own skeleton was built along Cangjie’s create flow — the implementation steps in its design document state this in black and white.

Nüwa manages “creating people” — distilling a particular person’s way of thinking into a runnable character skill. Her method is multi-agent research: six parallel subagents collect along six dimensions — works, dialogues, expressive style, third-party criticism, decision records, and timeline — and each dimension must be written to disk inside the skill’s directory (research that isn’t persisted equals research that never happened). Then she stops for human confirmation at three explicit checkpoints: research quality, the distillation result, and final delivery. The first rule of Nüwa’s counterexample list is that fabricating sources is flatly forbidden, and the list closes with a line I fully endorse: rather generate an honestly-labeled 60-out-of-100 skill than a 90 that looks perfect but is actually making things up.

The Review Roles: Bian Que, Hua Tuo, Gao Yao, and Yushi

Four figures stand along the review line, each covering a segment. Bian Que reviews code: a six-layer checklist (correctness, security, performance, error handling, readability, tests) judged mechanically item by item, producing findings ranked blocker, major, minor, nit, each with a location and a fix suggestion. What it explicitly does not do is as clear as what it does: report only, never fix code; skip style issues that a formatter could handle; write “none” outright for a layer with no findings; never output essay-style musings.

Hua Tuo reviews skills, and his core mental model is one sentence: an audit “finds defects,” it does not “assign scores” — scoring is Darwin’s job. His discipline has three layers. The first is genchi genbutsu (go and see for yourself): read only the actual files and run only the actual commands; when documentation and implementation disagree, the implementation wins. The second is the evidence standard: dispatch multiple cold-start subagents who never see each other, hunting for defects from different angles, and every candidate finding must carry a file, a line number, the original sentence, and a verification method. The third is the harshest — the falsification gate: once the candidate list is out, a separate independent subagent tries to knock down every item, and only the ones that survive go into the final list. His own measured numbers are blunt: roughly eighty percent of candidate defects “look plausible but don’t hold up.” Without this gate, the list drowns in false defects.

Gao Yao handles intent. When an instruction is ambiguous and involves high-risk operations, he first restates his understanding and stops for user confirmation before acting; for creative and feature tasks, a design comes first and work starts only after user approval. Yushi manages rules: before writing into AGENTS.md or the memory-rule layer, it automatically pre-checks four classes of conflict — new-versus-old contradictions, duplicate phrasing, hard-principle violations, scope mismatch — using a zero-token mechanical script as the first pass, escalating to semantic judgment only on a hit. One manages “understanding before acting,” the other “consistency before making rules”; both intercept accidents before they happen.

The Optimization and Fusion Roles: Darwin, Suiren, and Ou Yezi

Darwin handles skill evaluation and optimization: a nine-dimension scoring rubric — seven structural dimensions plus measured performance — with improvements made round by round on a git branch. One correction in his v2.1 says a lot about this family’s methodology: keep-or-revert decisions previously depended on absolute score improvements, until he discovered that the reviewing model’s scores carry about ±8 points of noise — enough to drown the real gain of a conservative edit — so he switched to paired adjudication: the same reviewer subagent compares the before and after versions within a single call (the reviewer’s own ruler is unsteady, but comparing two versions cancels the bias), plus an odd-number majority vote. And still the principle running through the whole family: the evaluator must be heterogeneous from the generator.

Beyond Darwin there is also an unattended evolution line (evolution-driver): the user sets acceptance criteria, and the loop runs automatically until they are met, capped at 500 rounds. The first thing it does at the door is check permissions — a skill must be explicitly marked evolvable in the ledger before automatic rewriting is allowed, and the default is deny. Evolution is a high-risk action; opt-in is the floor.

Suiren handles on-the-spot feedback: whenever you find a problem or think of an enhancement while using any skill, say it right there in three parts; small fixes land on the spot, and every change leaves a trace in the memory store. A skill’s problems only surface at the point of use — fail to capture them in the moment and they’re forgotten. Ou Yezi handles fusion: folding candidates from the external shelf into existing skills, with a verification gate at every step — the structure gate, the four functional checks, blind-review votes — and finally a double inspection by Hua Tuo and Bian Que; only passing all of it counts as done, under the slogan “enhanced, and nothing broken.” One confession while we’re here: traces of naming evolution are still visible along this line — the early skill-fusion and the later Ou Yezi are two names for the same role, with identical trigger words to this day; the unification of family names is itself still in progress.

The Library and Dispatch: Shiqu, Mozi, Lu Ban, and Huangdi

Shiqu is the librarian: registering skills into the library, tiered storage, maintaining the catalog index, deduplication, regression on change, retirement and archiving — a seven-character mantra covering collect, store, cite, inspect, protect, adjudicate, judge (收存引省护裁判), with the ledger as the single source of truth — an expired ledger equals a disorderly library. Mozi handles threat modeling: STRIDE enumeration, attack trees, mitigation mapping — structurally isomorphic to the Mohist defense of cities, “draw the city walls first, enumerate the attack methods, then build the fortifications” — and he stands alongside Bian Que (code review) and Hua Tuo (pre-installation checkup) as one third of the security-governance trio. Lu Ban manages the deepest layer, harness organization: how to build the “environment around the model” — memory, permissions, context, delegation, the skill directory — defined in one sentence: the layer of system that turns a bare model into a production-grade agent that can work long, safely, and under control.

Huangdi stands at the top as chief dispatcher. Any “I want to build something new” request first passes through a top-down elimination funnel: direct answer, built-in capability, script, skill, plugin, MCP — intercepted layer by layer, stopping at the first hit, always preferring the simpler form over the complex one. And once ownership is settled, Huangdi doesn’t just walk away — for a skill or a script, he orchestrates the quality loop of “build, review, repair”: Cangjie builds, Hua Tuo reviews skills, Bian Que reviews scripts; members stay single-purpose, coordination belongs to Huangdi, and no member’s skill file contains coordination flows. The dispatcher himself doesn’t overstep either — single responsibility extended up into the management layer.

How the Cast Serves the Novel Production Line

Back to the novel production line, to see how this crew turns around Li Bai. Build: Li Bai was constructed on Cangjie’s skeleton, with the design document written first and re-reviewed by another model (Kimi) before implementation — heterogeneous review starts at the design stage, not just at the code layer. Write: body-text generation belongs to the liyu service (a separate generation model); neither Li Bai nor any subagent holds the pen. The pre-writing instruction budget is hard-capped at no more than three items — in testing, a chapter with eight constraints actually scored lower than one with three; constraints belong in the service’s rule library, not piled into instructions.

Review is the segment with the densest hand-offs, three gates each minding its own layer. First, factual-and-canonical consistency belongs to liyu’s gates (G1 through G7): protocol parsing, reference validation (caught seven forged character IDs in actual testing), consistency (dead characters must not move again), unknown entities, blueprint appearances — this layer decides “accept or not.” Second, expression-layer discipline belongs to Li Bai’s local quantitative gates, pure text statistics, zero model calls: dash overuse gets the chapter rejected on the spot; a character count below the platform standard gets it rejected too. The enforcement of character count lives on the liyu generation side (auto-continuation when short, auto-compression when overlong), and Li Bai’s check is kept as the final line of defense — two layers of backstop for the same thing, redundancy by design. Third, judging goes to another model doing a cold read (one model generates, another judges; the judge routing is fixed — switching judges mid-run voids the data; testing showed the generating model systematically under-scores its own work, so self-evaluation is reference-only and never a release criterion). The book’s first three chapters additionally carry a human-review anchor: even when the cold read passes, the line stops and waits for human confirmation — the machine’s score is only a reference line.

Archive: the archival consistency checklist releases a book only when all four items pass — character count on target, chapters complete, candidate versions cleaned up, no pending revisions; the export format is baked into scripts and the body text is never altered; after assembly the book is tagged against the platform’s category system, one primary and seven secondary categories, with justifications required to cite actual content of the text and naming-accuracy subject to final user review; storage is single-point, and archiving triggers a backup along the way. Batch scenarios have their own division of labor: unattended one-click book assembly belongs to the short-story pipeline (duan-gushi), which shares the same liyu system and character-card pool as Li Bai — interactive creation is one role, batch runs another; even the “mode” is split into two skills.

Laying all these hand-offs side by side reveals three common threads: deliverable formats are explicit (the process is a JSON state machine where every step declares inputs, outputs, gates, and failure handling); acceptance criteria are explicit (mechanically checkable discipline is blocked by scripts, not left to prompt-level self-restraint); and key decisions stop for a human (checkpoints are hard gates, wording is not enough). What skills hand to each other is neither chat logs nor tacit understanding — it is structured artifacts and boundaries written at the door.

Why the Naming Follows Mythology

Because the mythical figures’ archetypal professions are themselves the job descriptions. Cangjie invented writing — builds skills; Nüwa created humans — builds character skills; Bian Que’s look-listen-ask-feel diagnosis — health checkups for code; Hua Tuo treating the ailment at its source — finding a skill’s disease; Gao Yao, the founding judge — intent confirmation and adjudication; Yushi the imperial censor impeaching wrongdoing — rule conflicts; the Shiqu Pavilion of the Han dynasty, where books were stored — the library; Suiren stealing fire — lighting up problems at the point of use; Mozi defending cities — threat defense; Ou Yezi forging swords — fusion and forging; Lu Ban building instruments — tooling organization; Huangdi the common sovereign — dispatch. Li Bai wrote poetry, so the novel line’s orchestrator is Li Bai — and he writes not a single word himself; in every post, the Poet Immortal is the one being cited.

Two practical payoffs of this naming scheme. First, memory anchors: the name is the responsibility — no need to remember which of “the code-review skill” and “the skill-audit skill” is which. Second, natural invocation: telling the main agent “have Bian Que look at this” flows more easily than issuing instructions against a string of functional English names. And there is a hidden constraint: once a name is a specific person, that “person” has only one pair of hands — asking Bian Que to fix code on the side sounds exactly like asking a surgeon to do stitches on the side; responsibility creep gets visibly awkward right in the name.

Not dogma, of course. The skill-guide and the evolution-driver never followed the mythology — useful beats tidy; and the renaming from skill-fusion to Ou Yezi shows the naming system itself evolving, with the role coming before the name.

Honest Boundaries

Three things, stated plainly. First, this post only covers each role’s responsibilities and hand-off style; each skill’s depth is defined by its own SKILL.md, and the polish level across the family varies widely. Second, implementation progress is uneven: Li Bai’s main line has been through end-to-end regression (book creation, outline, character registration, generation, gates, acceptance — the full chain tested), but items remain pending — the web-novel weighting layer of the review rubric is still iterating (second version TBD), the track-grouping field for genre cards is yet to be added, and foreshadowing-table pollution found in the test book gets cleaned up together after the book is finished. Third, the liyu service is a private dependency — anyone replicating this line needs to implement the server side themselves; most of the skills in the crew can be found verbatim in the open-source directory.

Closing Thoughts

The previous post ended with: those who write content and those who enforce discipline must be separated. This crew pushes that sentence one layer deeper — inside discipline enforcement there is division of labor too: builders only build, reviewers only review, optimizers only optimize, coordinators only coordinate; the library produces nothing and the judge hears no cases. Outfitting an AI pipeline with a mythological crew isn’t really about the names — it’s organizational design: roles have names, names have boundaries, and inside each boundary you can fit a neighbor’s name. Models will be replaced and prompts rewritten, but the organizing principle of “one role, one pair of hands” will outlive any implementation.