Skill detail

style-clone

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 s

Why we recommend it: Builds new course pages inside an imported deck's design by copying layouts and rewriting content element by element to match the original style.

MatchPossibleRecommended for Teachers
SourceTHU-MAIC/​OpenMAICExternal source
Reported installsNot reportedPopularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
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
Read the full source on GitHub (opens external page)
Context

Related work