/style-clone

name: style-clone
title: "名师复刻"
description: Building a new course inside someone else's deck — import the deck as a library of layouts, then produce each page of the new course by copying the layout that fits it and rewriting that copy's content element by element, so the result reads as though the original author made it. Use when the session has an imported deck (or a `.pptx` to import) and the ask is to teach new material in its design — its palette, its typography, its way of dividing a page. Not for a straight import that must stay slide-for-slide identical to the file (that is `pptx-import`), and not for extracting how a teacher speaks from a recording or handout (that is `teacher-style-clone`, which supplies the voice while this one supplies the look; the two compose).

Cloning a deck's style

The user has a deck by someone whose slides are worth copying. Your job is to produce **new pages that look like that deck made them** — its palette, its typography, its background treatment, its way of dividing a page — while the teaching content on those pages is entirely new. New content in the old style is the whole point of this mode, not the exception.

The route is **copy, then refine**. For every page in the new course you pick the source layout that fits it, `duplicate_scene` that layout, and rewrite the copy's content element by element. The design is preserved because you copied it, not because you described it.

Generation is not an alternative for a **copied page**. `generate_scene` re-rolls a page from its outline entry and draws in the house look, and no free-text slot on it overrides that: a real run that wrote the source deck's exact hex values and font names into `materialFacts` on every page produced pages where those values appear **zero** times. Describing a style to a generator does not transfer it. Copying the element tree does.

The learner-facing name for this mode is 「名师复刻」. Never show the learner the machinery — no talk of templates, clones or source pages. They should just see a course that looks like it came from one hand.

Why this works now

Copy-then-refine failed the first time it was tried, and the reason was the editing tools, not the approach. The only content editor then was a whole-block text setter, and 35 of one run's 44 edits went through it: each one replaced a block wholesale and flattened everything inside it, so a title's size and colour left with its words, contrast pairs came apart, and tables that resisted editing were shipped still carrying the old subject's text.

Those lossy ops are gone from the agent surface. What replaced them is an element-level, full-fidelity seam of three parts:

• **`read_stage` with `path:/scenes/<order|id>` and `detail:"source"`** returns the page's exact persisted JSON —

`background`, each text element's `defaultColor` and `defaultFontName`, the inline `color` / `font-size` / `font-family` inside its `content` HTML, shape fills, and exact geometry. It is your fidelity source *and* your address space: the paths you read are the paths you write.

• **`patch_stage`** writes **one scene-root JSON Pointer path** with `op:"set"`

or `op:"remove"`. `/content/canvas/elements/0/content` replaces one text element's rich-text HTML and touches nothing else on the page; a `<span>` keeps its colour and size while its words change. Address the leaf, and everything you did not name keeps the value you copied.

• **`add_element`** (a complete, id-less element JSON, id assigned by the server)

and **`delete_element`** are the only ways the element set changes — a patch may not add, remove, rename or retype an element, which is exactly the guard that keeps a borrowed design intact.

So **one atomic patch is the entry point for every content rewrite**, whatever the element is — a paragraph at `/content/canvas/elements/3/content`, a shape's label at `/content/canvas/elements/3/text/content`, a table cell at `/content/canvas/elements/5/data/0/0/text`, a code line at `/content/canvas/elements/9/lines/1/content`, a formula's `latex`, a chart's label. There is no per-type editor to hunt for and no growing list of per-type operations: read the source JSON, find the path that holds the words, write that path. **`slide-dsl` is the field manual** — which field holds the words in each of the ten element types, the pointer rules, what values are legal, which field the renderer reads when two disagree, and what the renderer really does with the HTML you write.

Two guarantees are what make this trustworthy on someone else's design: **a rejected patch changes nothing** (a bad path, an unknown field or unsafe HTML fails loud with the page exactly as it was), and **nothing is normalised** — no colour, font or theme value is rewritten toward a house palette. The deck's look survives because the tool has no opinion about it.

`stage-design` governs the build of the stage this produces, and `curriculum-planner` governs a series of them; both still apply, and this skill shapes only how the pages get their look. `page-clone` carries the per-page mechanics of the loop in Step 4 — read it before the first page. `slide-dsl` is the field-level truth about the JSON you are patching, `slide-craft` is the design law any page still has to satisfy, and `pro-editing` is loaded mid-run when a refined page comes out broken.

What finishing a turn means here

Getting the deck in and reading it are **preparation, and preparation is not a result**. A real run read the skills, imported a 36-page reference deck, and ended its turn on 「已确认当前课堂已保存 36 页原始课件……我不会覆盖这些页面」 — the layout library ready, the user's own course **not one page written**. The user asked for a lesson and got an inventory of someone else's.

A turn ends in exactly one of three states:

• **the new course moved a real step** — at least the next planned page copied

with `duplicate_scene` and refined, persisted, not merely chosen;

• **`ask_user` is waiting** on a decisio