diff --git a/config/external-sources.lock.json b/config/external-sources.lock.json
index ddc12671..8b8e8973 100644
--- a/config/external-sources.lock.json
+++ b/config/external-sources.lock.json
@@ -33,8 +33,8 @@
"repo": "https://github.com/nextlevelbuilder/ui-ux-pro-max-skill.git",
"ref": "main",
"adapter": "claude-skill",
- "commit": "bc826e2267a36d98a2dcf5231e16c30ff546770f",
- "syncedAt": "2026-08-20T16:00:00Z"
+ "commit": "13179471f97162b3297558621a76682438caf017",
+ "syncedAt": "2026-08-24T16:00:00Z"
},
{
"id": "caveman",
@@ -51,8 +51,8 @@
"repo": "https://github.com/Leonxlnx/taste-skill.git",
"ref": "main",
"adapter": "skill-collection",
- "commit": "72e299530e2eb31ed8da06181bc19f6c18a00821",
- "syncedAt": "2026-08-22T16:00:00Z"
+ "commit": "ccbc15639c97057cbfcf32ecebc38ef716e4bb37",
+ "syncedAt": "2026-08-24T16:00:00Z"
},
{
"id": "shadcn",
@@ -60,8 +60,8 @@
"repo": "https://github.com/shadcn-ui/ui.git",
"ref": "main",
"adapter": "claude-skill",
- "commit": "ac60ef5c4db4265d71454dd9ecd3f93e255d7211",
- "syncedAt": "2026-08-23T16:00:00Z"
+ "commit": "b9938d94635fca7a4560449713b0b1ba87d77bc6",
+ "syncedAt": "2026-08-24T16:00:00Z"
},
{
"id": "frontend-slides",
@@ -96,8 +96,8 @@
"repo": "https://github.com/hugohe3/ppt-master.git",
"ref": "main",
"adapter": "claude-skill",
- "commit": "65bb2eca59a36270819caba377097910c4466c6e",
- "syncedAt": "2026-08-22T16:00:00Z"
+ "commit": "e2b4e6a7c43594a66fb477d00e18267ce50bbd93",
+ "syncedAt": "2026-08-24T16:00:00Z"
},
{
"id": "grill-me",
@@ -105,8 +105,8 @@
"repo": "https://github.com/mattpocock/skills.git",
"ref": "main",
"adapter": "skill-collection",
- "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
- "syncedAt": "2026-08-21T15:59:59Z"
+ "commit": "6654f6b60cd9d5be8b54c6fafe44346dabeb3b76",
+ "syncedAt": "2026-08-24T16:00:00Z"
},
{
"id": "next-skills",
@@ -114,8 +114,8 @@
"repo": "https://github.com/vercel/next.js.git",
"ref": "canary",
"adapter": "skill-collection",
- "commit": "cb463843e78506c6b79518af8125af05e6cbac77",
- "syncedAt": "2026-08-23T16:00:00Z"
+ "commit": "30e73d2d14803ff252638caa3d67f047a89e4bb5",
+ "syncedAt": "2026-08-24T16:00:00Z"
}
]
}
diff --git a/plugins/codex/plugins/grill-me/THIRD_PARTY_SOURCE.json b/plugins/codex/plugins/grill-me/THIRD_PARTY_SOURCE.json
index 3e50bbe3..73d1807f 100644
--- a/plugins/codex/plugins/grill-me/THIRD_PARTY_SOURCE.json
+++ b/plugins/codex/plugins/grill-me/THIRD_PARTY_SOURCE.json
@@ -2,8 +2,8 @@
"sourceId": "grill-me",
"repo": "https://github.com/mattpocock/skills.git",
"ref": "main",
- "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
+ "commit": "6654f6b60cd9d5be8b54c6fafe44346dabeb3b76",
"adapter": "skill-collection",
"sourcePath": "skills/productivity",
- "syncedAt": "2026-08-21T15:59:59Z"
+ "syncedAt": "2026-08-24T16:00:00Z"
}
diff --git a/plugins/codex/plugins/mcp-playwright/MCP_SOURCE.json b/plugins/codex/plugins/mcp-playwright/MCP_SOURCE.json
index 6698ca54..4b8b3f0a 100644
--- a/plugins/codex/plugins/mcp-playwright/MCP_SOURCE.json
+++ b/plugins/codex/plugins/mcp-playwright/MCP_SOURCE.json
@@ -3,5 +3,5 @@
"name": "playwright浏览器自动化操作",
"version": "20260605",
"keySource": "none",
- "syncedAt": "2026-08-23T16:01:48Z"
+ "syncedAt": "2026-08-24T16:01:54Z"
}
diff --git a/plugins/codex/plugins/next-skills/THIRD_PARTY_SOURCE.json b/plugins/codex/plugins/next-skills/THIRD_PARTY_SOURCE.json
index 6a7dd530..0c9c791a 100644
--- a/plugins/codex/plugins/next-skills/THIRD_PARTY_SOURCE.json
+++ b/plugins/codex/plugins/next-skills/THIRD_PARTY_SOURCE.json
@@ -2,8 +2,8 @@
"sourceId": "next-skills",
"repo": "https://github.com/vercel/next.js.git",
"ref": "canary",
- "commit": "cb463843e78506c6b79518af8125af05e6cbac77",
+ "commit": "30e73d2d14803ff252638caa3d67f047a89e4bb5",
"adapter": "skill-collection",
"sourcePath": "skills",
- "syncedAt": "2026-08-23T16:00:00Z"
+ "syncedAt": "2026-08-24T16:00:00Z"
}
diff --git a/plugins/codex/plugins/ppt-master/README.md b/plugins/codex/plugins/ppt-master/README.md
index a9ba62ab..0ea357b2 100644
--- a/plugins/codex/plugins/ppt-master/README.md
+++ b/plugins/codex/plugins/ppt-master/README.md
@@ -49,8 +49,8 @@ Thanks to [Kimi](https://www.kimi.com/code/?aff=ppt-master) for sponsoring this
> **Editable is already table stakes — what sets PPT Master apart is native depth.** It hands you a real PowerPoint: slide masters, native shapes, data-backed charts and tables — not flat text boxes, and not a filled-in template. It also does more than lay slides out nicely — it reasons the argument into shape first, then designs; and that native depth keeps **converging with PowerPoint itself**, adding more of its native capabilities release after release. In form, it's a workflow that runs inside any agent-capable AI tool: hand the AI your topic or material, and it generates on your machine — your data stays local, no platform or model lock-in. How it works and where the limits are → [Product Positioning](#product-positioning).
- Live Demo ·
- Examples ·
+ Live Demo ·
+ Examples ·
FAQ ·
Roadmap
@@ -62,42 +62,42 @@ Thanks to [Kimi](https://www.kimi.com/code/?aff=ppt-master) for sponsoring this
- Downloading any .pptx and opening it in PowerPoint is the fastest way to see what it can really do.
Flip through all examples online → · examples/ directory · Why PPT Master?
+ Downloading any .pptx and opening it in PowerPoint is the fastest way to see what it can really do.
Flip through all examples online → · Source repository · Why PPT Master?
---
@@ -126,7 +126,7 @@ Why you'd choose it, and where it isn't the right fit → [Why PPT Master](./doc
> ### This is a tool, not a wishing well
> `harness + model = agent` — PPT Master only owns the workflow; the model sets the ceiling. Recommended: **Kimi K3 (or Claude) with a large context window (~1M tokens) + AI image generation (`gpt-image-2` or Google `gemini-3.1-flash-image`)**; other models can run the pipeline, with a quality gap.
>
-> And don't expect a finished, perfect deck in one shot. The tool's value is taking most of the tedious work off your plate; the polishing that's left is yours — a natively editable deck exists precisely so you can keep working on it, not a flat image you can't touch. The cheaper the model, the more there is to do; if results disappoint, upgrade the model first, then check your usage against [Getting Started](./docs/getting-started.md) and the example projects.
+> And don't expect a finished, perfect deck in one shot. The tool's value is taking most of the tedious work off your plate; the polishing that's left is yours — a natively editable deck exists precisely so you can keep working on it, not a flat image you can't touch. The cheaper the model, the more there is to do; if results disappoint, upgrade the model first, then check your usage against [Getting Started](./docs/getting-started.md) and the [example projects](https://hugohe3.github.io/ppt-master-examples/).
---
@@ -369,7 +369,7 @@ PPT Master reads the current process environment first, then the first `.env` fo
| 📖 | [SKILL.md](./skills/ppt-master/SKILL.md) | Core workflow and rules |
| 📐 | [Canvas Formats](./skills/ppt-master/references/canvas-formats.md) | PPT 16:9, Xiaohongshu, WeChat, and 10+ formats |
| 🛠️ | [Scripts & Tools](./skills/ppt-master/scripts/README.md) | All scripts and commands |
-| 💼 | [Examples](./examples/README.md) | All example projects |
+| 💼 | [Examples](https://hugohe3.github.io/ppt-master-examples/) | All example projects |
| 🏗️ | [Technical Design](./docs/technical-design.md) | Architecture, design philosophy, why SVG |
| ❓ | [FAQ](./docs/faq.md) | Model selection, cost, layout troubleshooting, custom templates |
diff --git a/plugins/codex/plugins/ppt-master/THIRD_PARTY_SOURCE.json b/plugins/codex/plugins/ppt-master/THIRD_PARTY_SOURCE.json
index 7ef7cb0e..e667b105 100644
--- a/plugins/codex/plugins/ppt-master/THIRD_PARTY_SOURCE.json
+++ b/plugins/codex/plugins/ppt-master/THIRD_PARTY_SOURCE.json
@@ -2,8 +2,8 @@
"sourceId": "ppt-master",
"repo": "https://github.com/hugohe3/ppt-master.git",
"ref": "main",
- "commit": "65bb2eca59a36270819caba377097910c4466c6e",
+ "commit": "e2b4e6a7c43594a66fb477d00e18267ce50bbd93",
"adapter": "claude-skill",
"sourcePath": "skills/ppt-master",
- "syncedAt": "2026-08-22T16:00:00Z"
+ "syncedAt": "2026-08-24T16:00:00Z"
}
diff --git a/plugins/codex/plugins/ppt-master/skills/ppt-master/SKILL.md b/plugins/codex/plugins/ppt-master/skills/ppt-master/SKILL.md
index 7099e9b2..50d761ef 100644
--- a/plugins/codex/plugins/ppt-master/skills/ppt-master/SKILL.md
+++ b/plugins/codex/plugins/ppt-master/skills/ppt-master/SKILL.md
@@ -2,7 +2,7 @@
name: ppt-master
description: "多格式源文档到高质量 SVG 页面再导出 PPTX 的多阶段演示文稿生成工作流。"
metadata:
- version: "4.8.0"
+ version: "5.0.0"
copyright: "Copyright (c) 2025-2026 Hugo He"
license: "MIT"
official_repository: "https://github.com/hugohe3/ppt-master"
diff --git a/plugins/codex/plugins/ppt-master/skills/ppt-master/references/executor-structure.md b/plugins/codex/plugins/ppt-master/skills/ppt-master/references/executor-structure.md
index 63d6dfc9..d7fd3d68 100644
--- a/plugins/codex/plugins/ppt-master/skills/ppt-master/references/executor-structure.md
+++ b/plugins/codex/plugins/ppt-master/skills/ppt-master/references/executor-structure.md
@@ -16,16 +16,46 @@ the grammar does not select `Structure=yes` or create a geometry quota.
## 1. Relationship Atoms
-| Atom | Meaning | Encode with |
-|---|---|---|
-| `order` | Sequence, progression, or rank | Position, numbering, direction, shared path |
-| `link` | Dependency, exchange, influence, transition | Proximity/alignment when unmistakable; otherwise an edge |
-| `parent` | One unit governs or decomposes into children | Branching, indentation, nesting, scale |
-| `membership` | Units belong to a group, stage, lane, or region | Containment, shared field, band, repetition |
-| `contrast` | Peers, states, options, or positions compare | Shared baseline, opposing regions, parallel framing |
-| `overlap` | Units share a meaningful subset or duty | Intersecting regions plus a clear common area |
+**Mandatory — relationship → topology before contour**: For each active atom,
+resolve only the path, junctions, enclosure, field partition, shared region,
+scale change, and entry / endpoint that carry meaning. Adapt that topology to
+the actual units, text load, page role, and active visual system before
+selecting contours.
-Combine atoms as needed; never force a named business model. Numbers used only as labels do not create a chart. Value-derived position/length/angle/area/radius/width/color routes to [`executor-chart.md`](./executor-chart.md); row-header × column-header facts route to [`executor-table.md`](./executor-table.md). Qualitative lanes use this grammar, but date/duration-driven task-bar `x`/`width` is Gantt Chart geometry.
+| Atom | Meaning | Encode with | Generate topology from |
+|---|---|---|---|
+| `order` | Sequence, progression, or rank | Position, numbering, direction, shared path | One reading path: open / closed; straight / bent / stepped / switchback / coiled; level / rising / falling; constant / expanding / contracting; turns, milestones, endpoint |
+| `link` | Dependency, exchange, influence, transition | Proximity / alignment when unmistakable; otherwise an edge | Sources, targets, and junctions: direct, hub, chain, split, merge, exchange, or feedback; let the relationship determine the fewest necessary edges |
+| `parent` | One unit governs or decomposes into children | Branching, indentation, nesting, scale | Root, depth, and sibling groups: branch, indent, nest, radiate, or scale; let child roles set fan-out and weight |
+| `membership` | Units belong to a group, stage, lane, or region | Containment, shared field, band, repetition | Owning fields: enclose, band, lane, cluster, repeat, or nest; let content set field shape and occupancy |
+| `contrast` | Peers, states, options, or positions compare | Shared baseline, opposing regions, parallel framing | Shared invariants plus separation: one or more semantic axes / baselines, opposing or parallel fields, counterweight, divergence, or a before / after boundary |
+| `overlap` | Units share a meaningful subset or duty | Intersecting regions plus a clear common area | Exact exclusive / shared regions: paired, chained, or layered intersections; keep every owner and common area legible |
+
+**Reference — not a constraint**: `Generate topology from` names common
+transform axes rather than an exhaustive set. Combine, deform, or invent
+page-fit topologies from the active atoms; never recall a named diagram or
+reproduce a listed form by default.
+
+**Mandatory — combined-atom spatial relation before contour**: Combine atoms as
+needed; never force a named business model. When multiple atoms share one
+construct, resolve whether their topologies share a field, nest, run in
+parallel, cross orthogonally, or intersect. Orthogonal overlay applies when
+independent dimensions occupy one field, including but not limited to an
+`order` path across `membership` lanes and two independent `contrast`
+dimensions; preserve each atom's ownership and reading direction. The overlay
+never implies equal partitions.
+
+**Hard rule — no topology from balance alone**: Node count and text fit may
+change spacing, route, or wrap. They never justify equal shapes, gaps, or
+partitions, mirroring, radial symmetry, or closure that invents peer weight,
+centrality, reciprocity, or recurrence.
+
+Numbers used only as labels do not create a chart. Value-derived position,
+length, angle, area, radius, width, or color routes to
+[`executor-chart.md`](./executor-chart.md); row-header × column-header facts
+route to [`executor-table.md`](./executor-table.md). Qualitative lanes use this
+grammar, but date / duration-driven task-bar `x` / `width` is Gantt Chart
+geometry.
---
diff --git a/plugins/codex/plugins/ppt-master/skills/ppt-master/references/native-shape-authoring.md b/plugins/codex/plugins/ppt-master/skills/ppt-master/references/native-shape-authoring.md
index 83f17991..0be0f556 100644
--- a/plugins/codex/plugins/ppt-master/skills/ppt-master/references/native-shape-authoring.md
+++ b/plugins/codex/plugins/ppt-master/skills/ppt-master/references/native-shape-authoring.md
@@ -149,29 +149,38 @@ owned by the preserve/mirror round-trip contract.
- `chartX`, `chartStar`, or `chartPlus` as a substitute for native charts;
- logo, icon glyph, illustration, brand contour, or data-chart marks.
-### 2.1 Compound page geometry
+### 2.1 Topology assembly and compound page geometry
-**Trigger**: after the page or prototype's communication / slot job, composition
-anchors, and any applicable topology under
+**Trigger**: after the page or prototype's communication / slot job,
+composition anchors, and any applicable topology under
[`executor-structure.md`](./executor-structure.md) are resolved, but before
-writing coordinates, resolve the page-scale geometry move that best carries its
-background field, content zoning, focal hierarchy, or reading path. Apply §1's
-exact-fit decision and compare the useful lenses below. Before repeating stacked
-rectangles / rounded cards or uniform equal columns, compare a page-field,
-outline, nesting, or continuity construction and the relevant contour family's
-exact members. Readability of the first workable arrangement does not close this
-gate.
-This applies whether the per-page Structure result is `no` or `yes`; it never
-creates a decoration requirement.
+writing coordinates, run this gate at every active granularity. For
+`Structure=yes`, assemble each resolved topology without changing it, using
+[`topology-assembly.md`](./topology-assembly.md) as assembly and relative
+registration material; for every page, resolve the page-scale geometry move
+carrying its background field,
+content zoning, focal hierarchy, or reading path. Apply §1's exact-fit decision
+and compare the useful lenses below. Before repeating stacked rectangles /
+rounded cards or uniform equal columns, compare a page-field, outline, nesting,
+or continuity construction and the relevant contour family's exact members.
+Readability of the first workable arrangement does not close this gate. This
+never creates a decoration requirement.
| Pass | Action | Result |
|---|---|---|
-| Page job | Name the page-scale geometry move and its jobs: surface, boundary, focal mark, shared region, counterweight, or any source-backed direction / reveal. | One composition direction and a small set of functional zones; no shape names yet. |
-| Decompose | Separate visible content from geometric atoms. Identify which atoms need independent movement, paint, or reuse and which contour must become one object. | Editable siblings plus any explicit Boolean operand set. |
-| Select | Choose the contour family, then its exact member from the job, full native vocabulary, and edge / corner / opening behavior; retain the reader effect when the result is generic or undrawn. | Page-fit native atoms without syntax bias. |
-| Compose | Establish page frame, scale, z-order, and negative space with independent atoms. Keep text, images, icons, data marks, and non-merged accents outside Boolean operands. | One page-level geometry system, not a collection of unrelated decorations. |
+| Topology / page job | Retain the resolved topology and state its relationship duties; name the page-scale geometry move and its jobs: surface, boundary, focal mark, shared region, counterweight, or any source-backed direction / reveal. | Required relationship duties plus one composition direction and a small set of functional zones; no shape names yet. |
+| Decompose | Partition the resolved topology and visible content. Identify components needing independent editing, movement, paint, animation, or reuse; separately identify contour / region semantics that require one object or independently retained Boolean result paths. | Editable siblings plus any explicit Boolean operand set. |
+| Select | For each required component, choose the contour family, then its exact member from the job, full native vocabulary, and edge / corner / opening behavior; retain the reader effect when the result is generic or undrawn. | Page-fit native atoms without syntax bias. |
+| Compose | Assemble the resolved topology from its independent atoms, then establish page frame, scale, z-order, and negative space. Keep text, images, icons, data marks, and non-merged accents outside Boolean operands. | Relationship-faithful assembly inside one page-level geometry system, not unrelated decorations. |
| Materialize | Run the preset helper for each adopted preset. Run the Boolean helper only for contours that require Merge Shapes semantics, then replace those operands with its stdout paths. | Valid authoring SVG ready for native export. |
+**Reference — not a constraint**: At topology scale, compare independent pieces,
+one body with dividers, overlapping siblings, fitted joints, intentional gaps,
+and independently retained `fragment` regions. These are common assembly
+strategies rather than an exhaustive set. Choose from component independence
+and contour / region semantics; never map a topology name to a shape list or
+infer equal size or spacing.
+
**Composition lenses — not a checklist**:
| Lens | Use when it strengthens the resolved page |
@@ -432,15 +441,17 @@ reads correctly at slide scale.
### 7.3 Fragment as a modelling tool, not just a boolean
-`fragment` (§6) is the fastest way to build layered diagrams from one silhouette:
-lay evenly distributed bars across a triangle and fragment it into pyramid tiers;
-cross a circle with two bars for a quadrant wheel; slice an annulus radially for
-ring segments. Every piece inherits the parent contour, so the assembly stays
-perfectly registered — impossible to achieve by drawing the tiers separately.
+`fragment` (§6) can build registered layered diagrams from one silhouette:
+cross a triangle with topology-derived bars for pyramid tiers; cross a circle
+with two topology-derived bars for a quadrant wheel; slice an annulus radially
+for ring segments. These are construction examples rather than topology
+defaults or an exhaustive set. Every retained piece inherits the parent contour,
+so the assembly stays registered without independently redrawing its parts.
-Distribute the cutting bars with a constant step before fragmenting; uneven tiers
-read as a mistake rather than a hierarchy. Paint the resulting pieces with one
-gradient family per §7.1 so the stack reads as a single solid.
+Derive cutter count, position, and piece size from the resolved topology. Use a
+constant step and one §7.1 gradient family only when equal tier / segment weight
+and one-solid reading are semantic; otherwise preserve the required differences
+in geometry and paint.
### 7.4 Soft edges without the soft-edge effect
diff --git a/plugins/codex/plugins/ppt-master/skills/ppt-master/references/topology-assembly.md b/plugins/codex/plugins/ppt-master/skills/ppt-master/references/topology-assembly.md
new file mode 100644
index 00000000..5f81a7ca
--- /dev/null
+++ b/plugins/codex/plugins/ppt-master/skills/ppt-master/references/topology-assembly.md
@@ -0,0 +1,275 @@
+> See [`executor-structure.md`](./executor-structure.md) §1 for relationship → topology and [`native-shape-authoring.md`](./native-shape-authoring.md) §§1–2.1 for contour selection and materialization.
+
+# Topology Assembly Reference
+
+Generative material for turning one resolved qualitative topology into editable native-shape components with coherent relative registration before coordinates.
+
+**Load**: Default and Quick read this reference once with the fixed construction
+bundle before SVG authoring and reuse it for every `Structure=yes` assembly.
+
+**Hard rule — relative constraints, never copyable geometry**: State exact
+preset or primitive identities, semantic counts, inter-component relations, and
+only the relative geometry required to make the assembly hold together. Never
+provide coordinates, concrete sizes or ratios, adjustment values, points, path
+data, SVG fragments, copy, color, styling, page composition, or full-page
+frames. Materialize every adopted call fresh through
+[`native-shape-authoring.md`](./native-shape-authoring.md).
+
+**Mandatory — two-step assembly test**: Preserve the topology resolved by
+[`executor-structure.md`](./executor-structure.md); do not select or rename it
+here. Then decide in order:
+
+1. Split every piece that needs independent editing, movement, paint, animation, or reuse.
+2. From outline and region semantics, choose one continuous shape, one shape with dividers, stacked siblings, seamed pieces, overlapping siblings, or independently retained Boolean regions.
+
+**Mandatory — registration closure**: After the two-step test, resolve only the
+relative conditions that make the chosen pieces read as one construct: shared
+datum, center, taper, or contour; aligned endpoints and seams; fitted contact or
+intentional clearance; nesting margin; overlap depth; joint type; direction
+continuity; and cutters that fully cross the parent silhouette. A set of valid
+individual shapes is not an assembly until its required contacts and boundaries
+register.
+
+**Hard rule — no assembly lookup**: Never recall a paragraph as a named
+structure, resolve a key, or match the page to the nearest mechanism. Generate
+from the active atoms and the two-step test; adapt, combine, or invent calls and
+relative constraints even when no paragraph resembles the result.
+
+**Reference — not a constraint**: The mechanisms below are common generative
+material rather than an exhaustive set, ranking, recommendation, or allowed
+combination list. A primitive, another registered preset, necessary freeform,
+or no drawn carrier may still win the current contour comparison.
+
+**Hard rule — semantic counts, not balance**: Derive every call count from real
+units, runs, turns, boundaries, junctions, owners, or retained regions. A count
+never implies equal size, spacing, angle, weight, or symmetry. Closure,
+mirroring, centrality, taper, interlock, and contact require the relationship
+meaning already resolved upstream.
+
+**Hard rule — information-model boundary**: Value-derived position, length,
+width, area, angle, radius, or color remains Chart geometry; row-header ×
+column-header facts remain Table. The assemblies below carry only qualitative
+relationships.
+
+---
+
+## 1. `order`
+
+For independently owned stages on one directional path, call `chevron` once per
+stage and keep the calls as siblings. On a continuous handoff, register each
+tip into the next notch and keep the entry / exit direction coherent through
+the joint; let the tip enter far enough to close the carrier without occluding
+the next stage's independently owned interior. Preserve an intentional gap when
+the boundary is a pause, reset, or discontinuity. The per-stage split preserves
+independent edit, paint, animation, and reuse duties; continuity versus boundary
+semantics decides fitted interlock versus clearance. Stage bodies may vary with
+their duties while every adopted joint still fits.
+
+For a path that wraps and reverses, call `rightArrow` once per forward run,
+`leftArrow` once per return run, `downArrow` once per turn, and `roundRect` once
+per independently owned stop. Place successive runs on distinct parallel
+baselines; align each turn's entry with the preceding run endpoint and its exit
+with the next run entry so the path neither doubles back ambiguously nor jumps
+across a gap. Attach each stop to its owning run without covering the carrier's
+entry, exit, or turn joint. Stops split for independent duties; run and turn
+pieces split because each owns a distinct direction / continuation duty.
+Contact at a turn means continuation, while clearance means a stage break; run
+lengths and offsets follow the resolved path rather than a regular wrap.
+
+For recurrence with independently owned stages, call `blockArc` once per stage
+and seam the siblings into one closed reading path. Make every segment share one
+center and registered inner / outer contours; meet adjacent end faces on both
+contours so the ring has neither accidental steps nor overlaps. Segment spans
+may differ, but their sequence and seam direction must remain legible. Retain a
+gap only for a semantic reset. When recurrence is one indivisible duty, call one
+`circularArrow` instead. Stage independence decides one versus many pieces;
+recurrence and direction decide closure, while shared-center registration makes
+the segmented result one carrier rather than unrelated arcs.
+
+---
+
+## 2. `link`
+
+For a qualitative split or merge, call `roundRect` once per semantic source or
+target and `line` once per necessary edge. Call `ellipse` zero or one time for
+each junction: omit it when edges merely share a meeting point, and retain it
+when the junction is independently editable, reusable, or animatable. Terminate
+each edge on its node boundary rather than inside the node; make converging edge
+endpoints meet the same junction, preserve a collinear shared trunk when one
+exists, and separate branches soon enough that they do not read as one line.
+An apparent crossing must either remain visibly non-joining or receive a real
+semantic junction. Nodes, edges, and retained junctions split by ownership;
+junction and outline semantics decide an implied meeting, one visible node, or
+separate passing paths.
+
+For a two-way exchange owned as one relationship, call one `leftRightArrow`
+between two independently owned `roundRect` nodes. Register both arrow ends to
+the facing node boundaries and preserve one uninterrupted exchange corridor.
+When the two directions need independent editing, paint, animation, or reuse,
+call one `rightArrow` and one `leftArrow` as parallel siblings instead. Keep the
+two directional corridors distinct, align each endpoint to its own node port,
+and prevent either arrowhead from covering the other carrier or a node interior.
+Directional responsibility decides whether the edge splits; reciprocal-single-
+duty versus two owned transfers decides one contour or two, while endpoint and
+corridor registration preserves the exchange.
+
+---
+
+## 3. `parent`
+
+For enclosure hierarchy or nested bubbles, call `ellipse` once per unit that
+owns a visible boundary and nest each child inside its immediate parent. Keep
+all ellipses as independent siblings rather than unioning parent and child.
+Preserve a visible containment margin around every child, keep its complete
+boundary inside the parent, and prevent sibling interiors from touching unless
+another active atom requires contact or overlap. Deeper levels may move,
+contract, or cluster asymmetrically; they need only preserve unambiguous
+containment and enough parent field to remain perceptible. Independent node
+ownership requires separate edit, movement, paint, animation, and reuse;
+enclosure semantics requires nesting while preserving every outline.
+
+For an indented decomposition without explicit relationship edges, call
+`roundRect` once per independently owned node and `leftBrace` once for each
+parent whose child group needs a visible shared boundary. Register siblings to
+one depth datum, place the child group deeper than its parent, and make the brace
+span only that parent's actual children with its open side facing their shared
+entry edge. Nested braces must remain distinct and must not cross a node
+boundary. Nodes split for independent duties; the brace remains a separate
+shared ownership mark because one outline governs several children. Depth and
+group extent, not equal offsets or repeated widths, carry the hierarchy.
+
+---
+
+## 4. `membership`
+
+For independently owned qualitative lanes, call `rect` once per lane and
+`roundRect` once per member that needs a carrier. Keep lane fields as parallel
+siblings; make adjacent long boundaries share one seam when membership is
+continuous, or preserve a clear gap when the groups are separate fields. Keep
+each member's complete contour inside its owning lane with a visible nesting
+margin; cross a lane boundary only when the member truly has multiple ownership
+or changes owner. If all lanes form one indivisible field and only boundaries
+carry meaning, call one `rect` for the field and `line` once per semantic lane
+boundary instead. Independent lane / member duties require siblings; one-field
+semantics permits dividers. Lane width and occupancy follow responsibility, not
+uniform partitioning.
+
+For membership that needs a light grouping boundary rather than a closed field,
+call `leftBrace` once per group and `roundRect` once per independently owned
+member. Keep the brace separate, face its open side toward the members, span the
+complete member group but no adjacent group, and maintain clearance so neither
+the brace nor a nested brace touches a member contour. Members split for
+independent edit, movement, paint, animation, and reuse; one brace is the shared
+ownership mark because the group boundary itself is one duty. Member count does
+not require repeated contours, equal spacing, or equal weight.
+
+---
+
+## 5. `contrast`
+
+For opposing fields on one comparison baseline, call `rect` once per field when
+the sides need independent editing, movement, paint, animation, or reuse. Align
+the comparable anchors to a shared baseline and register the facing boundaries
+as parallel edges separated by either a semantic gap or one explicit `line`
+divider; do not let an incidental offset become a false rank. If the field is
+one indivisible duty and only the state boundary matters, call one `rect` plus
+one `line` at that boundary instead. Independent side responsibility decides
+two siblings versus one divided field; opposing-field semantics decides the
+facing joint. Shared framing and counterweight never require equal dimensions
+or mirrored content.
+
+For a tapered rank or support stack, call `trapezoid` once per independently
+owned tier and stack the siblings with semantic seams. Register all tier side
+edges to one shared taper, make each adjacent seam meet across the complete
+current width, and vary tier width monotonically in the rank direction without
+assuming equal change, height, or area. Do not substitute one `triangle` plus
+divider lines when tiers need independent paint or animation. If the whole
+stack is one duty, call one `triangle` plus one `line` per semantic tier
+boundary; make every divider cross the interior and terminate on both outer
+edges so no tier leaks into the next. If one registered outer silhouette and
+independently retained tier regions are both required, call one `triangle` plus
+one `rect` strip per tier region, make every strip fully cross the parent
+silhouette and meet the next strip without an accidental sliver, run `fragment`,
+and retain the required triangle-covered regions. Independent tier duty decides
+the split; continuous-outline versus retained-region semantics decides stacked
+siblings, dividers, or Boolean regions. Shared taper and complete crossings keep
+all three routes registered as one stack.
+
+---
+
+## 6. `overlap`
+
+When each owner must remain independently editable and the shared area needs no
+separate treatment, call `ellipse` once per owner and overlap the calls as
+siblings without Boolean materialization. Preserve enough of every complete
+owner boundary to identify it, make each intended common area substantial
+enough to read as a region rather than an accidental tangent, and avoid full
+containment unless subset meaning is active. Choose overlap order and depth so
+one owner does not erase another owner or create unintended micro-regions.
+Owner responsibility requires the split; outline semantics preserves each
+complete boundary, while the common area remains a consequence of overlap.
+Paired, chained, or layered ownership does not imply equal ellipses or symmetric
+intersection.
+
+When exclusive and shared regions need independent editing, paint, animation,
+or reuse, call `ellipse` once per owner, run `fragment` across the overlapping
+set, and retain every required exclusive / shared result as an independent
+shape. Register the owner overlaps before fragmenting so their crossings produce
+only the semantic regions; eliminate accidental tangencies, hidden owners, and
+unintended slivers rather than retaining them as topology. Region
+responsibility—not owner count alone—requires the further split; exact retained-
+region semantics requires `fragment` rather than ordinary siblings or
+`intersect`, which keeps only the common region. Retain no region merely to
+complete a symmetric pattern.
+
+---
+
+## 7. Combined atoms
+
+**Mandatory — compose active topologies, not reference paragraphs**: Generate
+each active atom's topology from its own relationship duties, then resolve how
+those topologies share a field, nest, run in parallel, cross orthogonally, or
+intersect. Preserve each atom's ownership and reading direction. Let one
+component carry several atoms only when its edit, movement, paint, animation,
+reuse, outline, and region duties never need to separate; otherwise keep the
+atom systems as registered siblings. Re-run the two-step test at every contact,
+crossing, shared boundary, and retained region. A shared field does not make one
+atom dominant, and authoring convenience never justifies merging them.
+
+For an actual `order` path crossing `membership` lanes, call `rect` once per
+independently owned lane, `roundRect` once per process unit, `line` once per
+necessary transition, and `line` once per semantic phase boundary. Keep all
+lane bands parallel and register the process axis orthogonally across them.
+Place each process unit fully inside its current owner's lane; let only a real
+responsibility transfer cross a lane seam, and terminate every transition on
+the process-unit boundaries rather than using a lane boundary as an edge.
+Phase boundaries must cross the lane field coherently and remain distinguishable
+from process transitions. If lane regions are one field duty, use one `rect`
+plus lane dividers instead of independent lane rectangles. Lane ownership and
+process-unit responsibility decide the splits; orthogonal registration keeps
+the two atom systems readable without implying equal bands, phases, or steps.
+
+For two independent `contrast` dimensions partitioning one field, call one
+`rect` plus one `line` per axis when only the axes carry meaning. Make both axes
+cross the complete field, keep them orthogonal, and let their intersection move
+with the semantic thresholds rather than centering it. When the four resulting
+regions need independent editing, movement, paint, animation, or reuse, call
+four `rect` siblings instead; tile them to one shared outer field with one
+continuous seam per axis, no accidental gaps or overlaps, and the same
+non-central intersection when required. Axis-only semantics chooses one body
+with dividers; region responsibility chooses four siblings. Orthogonality and
+continuous seams create one partition while unequal region extents remain
+legal.
+
+For a radial `parent` topology whose ancestry requires explicit `link` edges,
+call `ellipse` once per semantic node and `line` once per parent-child relation.
+Only after radial organization is resolved upstream, register depth to
+concentric bands around the actual root; the bands and sibling sectors may vary
+with role and content. Start and end every edge on node boundaries, keep each
+branch moving outward to the child's depth, and make shared branch junctions
+coincide only when the relations truly share a trunk. Nodes split for
+independent content and motion duties; edges remain separate because ancestry
+is a relation rather than a shared silhouette. Concentric registration makes
+depth legible, while root centrality, even fan-out, mirrored branches, and equal
+radial spacing remain forbidden unless the relationship itself requires them.
+
diff --git a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/batch_validate.py b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/batch_validate.py
index 0981fe57..72f65b8a 100644
--- a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/batch_validate.py
+++ b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/batch_validate.py
@@ -5,10 +5,8 @@ PPT Master - Batch Project Validation Tool
Checks the structural integrity and compliance of multiple projects at once.
Usage:
- python3 scripts/batch_validate.py examples
python3 scripts/batch_validate.py projects
python3 scripts/batch_validate.py --all
- python3 scripts/batch_validate.py examples projects
"""
import argparse
@@ -265,14 +263,12 @@ def build_parser() -> argparse.ArgumentParser:
description="Validate one or more PPT Master project directories.",
formatter_class=argparse.RawDescriptionHelpFormatter,
epilog="""Examples:
- python3 scripts/batch_validate.py examples
python3 scripts/batch_validate.py projects
- python3 scripts/batch_validate.py examples projects
python3 scripts/batch_validate.py --all
""",
)
parser.add_argument("directories", nargs="*", help="Directories to scan")
- parser.add_argument("--all", action="store_true", help="Validate examples and projects")
+ parser.add_argument("--all", action="store_true", help="Validate the default projects directory")
parser.add_argument("--export", action="store_true", help="Write a validation report")
parser.add_argument(
"--output",
@@ -290,7 +286,7 @@ def main(argv: list[str] | None = None) -> int:
validator = BatchValidator()
if args.all:
- directories = ['examples', 'projects']
+ directories = ['projects']
else:
directories = args.directories
diff --git a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/config.py b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/config.py
index 04820712..61ebd910 100644
--- a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/config.py
+++ b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/config.py
@@ -40,7 +40,6 @@ WORKFLOWS_DIR = PROJECT_ROOT / 'workflows'
# Repository root directory
REPO_ROOT = PROJECT_ROOT.parent.parent
-EXAMPLES_DIR = REPO_ROOT / 'examples'
PROJECTS_DIR = REPO_ROOT / 'projects'
# Template subdirectories
diff --git a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/docs/project.md b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/docs/project.md
index e04ea7bc..ddd91105 100644
--- a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/docs/project.md
+++ b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/docs/project.md
@@ -216,21 +216,20 @@ python3 scripts/project_utils.py
Batch-check project structure and compliance.
```bash
-python3 scripts/batch_validate.py examples
-python3 scripts/batch_validate.py examples projects
+python3 scripts/batch_validate.py projects
python3 scripts/batch_validate.py --all
-python3 scripts/batch_validate.py examples --export
+python3 scripts/batch_validate.py projects --export
```
-Use this for repository-wide health checks before release or cleanup.
+Use this for multi-project health checks before release or cleanup.
## `generate_examples_index.py`
-Rebuild `examples/README.md` automatically.
+Rebuild the examples `README.md` index. The example projects live in the separate
+[ppt-master-examples](https://github.com/hugohe3/ppt-master-examples) repository.
```bash
-python3 scripts/generate_examples_index.py
-python3 scripts/generate_examples_index.py examples
+python3 scripts/generate_examples_index.py /ppt-master-examples/examples
```
## `pptx_template_import.py`
diff --git a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/docs/svg-pipeline.md b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/docs/svg-pipeline.md
index 301fe117..03ef7533 100644
--- a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/docs/svg-pipeline.md
+++ b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/docs/svg-pipeline.md
@@ -729,14 +729,14 @@ Requirements:
Validate SVG technical compliance.
```bash
-python3 scripts/svg_quality_checker.py examples/project/svg_output/01_cover.svg
-python3 scripts/svg_quality_checker.py examples/project/svg_output
-python3 scripts/svg_quality_checker.py examples/project
-python3 scripts/svg_quality_checker.py examples/project --stage first-page
-python3 scripts/svg_quality_checker.py examples/project --stage final --json
-python3 scripts/svg_quality_checker.py examples/project --format ppt169
-python3 scripts/svg_quality_checker.py --all examples
-python3 scripts/svg_quality_checker.py examples/project --export
+python3 scripts/svg_quality_checker.py projects/project/svg_output/01_cover.svg
+python3 scripts/svg_quality_checker.py projects/project/svg_output
+python3 scripts/svg_quality_checker.py projects/project
+python3 scripts/svg_quality_checker.py projects/project --stage first-page
+python3 scripts/svg_quality_checker.py projects/project --stage final --json
+python3 scripts/svg_quality_checker.py projects/project --format ppt169
+python3 scripts/svg_quality_checker.py --all projects
+python3 scripts/svg_quality_checker.py projects/project --export
python3 scripts/svg_quality_checker.py path/to/template/templates --template-mode
```
@@ -806,7 +806,7 @@ Use this after SVG generation to inspect existing SVG geometry when manual compa
### `flatten_tspan.py`
```bash
-python3 scripts/svg_finalize/flatten_tspan.py examples//svg_output
+python3 scripts/svg_finalize/flatten_tspan.py projects//svg_output
python3 scripts/svg_finalize/flatten_tspan.py path/to/input.svg path/to/output.svg
```
diff --git a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/finalize_svg.py b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/finalize_svg.py
index 7156a5bc..0680cf23 100644
--- a/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/finalize_svg.py
+++ b/plugins/codex/plugins/ppt-master/skills/ppt-master/scripts/finalize_svg.py
@@ -24,7 +24,7 @@ Usage:
Examples:
python3 scripts/finalize_svg.py projects/my_project
- python3 scripts/finalize_svg.py examples/ppt169_demo --only embed-icons
+ python3 scripts/finalize_svg.py projects/ppt169_demo --only embed-icons
Processing options:
embed-icons - Expand project icons and static same-document 
