@open-press/cli 0.3.0 → 0.6.0

package/template/skills/openpress-diagram-drawing/SKILL.md

@@ -1,44 +0,0 @@
----
-name: openpress-diagram-drawing
-description: Use when drawing or revising open-press document diagrams, especially concept diagrams, comparison figures, process states, data-structure nodes, pointers, arrows, before/after states, linked lists, stacks, queues, trees, or memory relationship figures.
----
-
-# open-press Diagram Drawing
-
-This skill owns diagram semantics, not visual skin. It decides what the diagram should show and what text belongs inside the figure.
-
-## Core Rule
-
-Draw the relationship, not the explanation.
-
-Figure bodies may contain only spatially meaningful information: object labels, pointer names, field names, axes, legends, short state labels, node values, `NULL`, and operation-order labels.
-
-Move reasons, warnings, edge cases, teaching commentary, and interpretation into surrounding prose or captions.
-
-## Responsibilities
-
-- Choose whether a concept needs a diagram, table, code block, or prose.
-- Define nodes, links, arrows, states, labels, and before/after relationships.
-- Keep figure text lean and connected to position or direction.
-- Prevent diagrams from containing answers, production notes, or caption-like sentences.
-
-## Boundaries
-
-- `openpress` owns validation/render command choice and the source/generated boundary.
-- `openpress-design` owns visual skin, typography, CSS, and component implementation.
-- `openpress-writing` owns the surrounding explanation and caption wording.
-- `teaching-notes-writing` (loaded via `openpress-writing`) owns learner-facing practice flow.
-
-## Workflow
-
-1. Identify the diagram job: comparison, process state, relationship snapshot, before/after, operation sequence, traversal trace, or data representation.
-2. Choose the surface:
-   - diagram for links, ownership, direction, state changes;
-   - table for dense comparisons or many trace rows;
-   - code block for exact syntax.
-3. Draw from semantics first; let style follow.
-4. Check whether the diagram can be understood without explanatory sentences inside the visual.
-
-## When To Read References
-
-- Read `references/diagram-patterns.md` for linked-list, circular-list, doubly-list, stack, queue, polynomial, sparse-structure, and tree drawing patterns.

package/template/skills/openpress-diagram-drawing/references/diagram-patterns.md

@@ -1,93 +0,0 @@
-# Diagram Patterns
-
-## Figure Text
-
-Keep text inside a figure only when it anchors something spatial:
-
-| Keep Inside | Move To Prose |
-| --- | --- |
-| `Before`, `After`, `插入前`, `插入後` | reasons a step matters |
-| `first`, `top`, `prev`, `curr`, `next`, `NULL` | warnings and edge cases |
-| field names, axis labels, legends | figure numbering or caption prose |
-| short role labels | answers or hidden hints |
-
-## Vocabulary
-
-| Item | Draw As |
-| --- | --- |
-| data node | box split into fields |
-| singly linked node | `data | next`, arrow leaves `next` |
-| doubly linked node | `prev | data | next`, forward and backward lanes separated |
-| header/dummy node | normal node with `head` or `dummy` role |
-| external pointer | label with arrow to a node |
-| field link | arrow from field to target node |
-| traversal | pointer labels moving between states |
-| `NULL` | terminal label or terminator mark |
-
-## Linked List Patterns
-
-Basic list:
-
-- Draw each node as `data | next`.
-- Last `next` points to `NULL`.
-- Use `first`, `data`, `next`, and `NULL` as figure labels.
-
-Insert after:
-
-- Use two aligned states: `p -> q` and `p -> x -> q`.
-- If showing update order, number only changed links:
-  1. `x->next = q`
-  2. `p->next = x`
-
-Delete after:
-
-- Use two aligned states: `p -> q -> r` and `p -> r`.
-- If the removed node remains visible, ghost it or mark it removed.
-
-Reverse:
-
-- Show `prev`, `curr`, and `next` as pointer labels, not data nodes.
-- Use a short sequence or table for repeated iterations.
-
-## Circular And Doubly Linked Lists
-
-Circular return links should look intentional:
-
-- route return links outside the node group;
-- avoid diagonal clutter over labels;
-- for one-node circular lists, draw a small self-loop.
-
-When using `last` as the entry pointer, show both `last` and `last->next`.
-
-Doubly linked lists:
-
-- separate forward and backward lanes;
-- insertion between `x` and `y` shows four relationships:
-  - `p->prev = x`
-  - `p->next = y`
-  - `x->next = p`
-  - `y->prev = p`
-
-## Stack, Queue, Polynomial, Sparse, Tree
-
-Linked stack:
-
-- `top` points to the first node.
-- push is insert-at-front; pop is remove-at-front.
-
-Linked queue:
-
-- `front` points to the next node to delete.
-- `rear` points to the last node.
-- show both when the invariant depends on both.
-
-Polynomial and sparse structures:
-
-- use tables for dense coefficient arrays or matrix positions;
-- use diagrams only for stored nonzero nodes.
-
-Trees:
-
-- label parent/child relationships clearly;
-- use traversal diagrams only when node order or pointer movement is the point;
-- avoid turning a tree diagram into a paragraph.

package/template/skills/openpress-document-hierarchy/SKILL.md

@@ -1,81 +0,0 @@
----
-name: openpress-document-hierarchy
-description: Use when planning, restructuring, or extending a open-press long-form document, handout, textbook, study guide, reference manual, or course note that needs a stable H1/H2/H3/H4 semantic hierarchy, table of contents depth, reader outline depth, chapter grouping, appendix placement, or multi-unit document structure.
----
-
-# open-press Document Hierarchy
-
-This skill owns the **document skeleton**: visible heading levels, formal TOC depth, reader outline depth, chapter grouping, and appendix placement. It does not own prose, visual style, figure design, or component implementation.
-
-## When To Enter This Skill
-
-`openpress-writing` is the default entry point for content work. Route here when the work involves any of:
-
-- Adding or removing an H2 chapter, or splitting one chapter into two.
-- Promoting / demoting headings across H2 / H3 / H4.
-- Changing TOC depth or reader outline depth.
-- Reorganizing appendices, or deciding what becomes an appendix vs an inline section.
-- Auditing H4 granularity (too many vs too few sub-sections).
-
-Hand back to `openpress-writing` once the structure is settled — prose, captions, exercises, and explanation order are not this skill's job.
-
-Use `openpress` for CLI inspection, source search, and validation. This skill decides the heading model; it does not decide the command surface.
-
-## Hierarchy Contract
-
-Map document content to headings by semantic role:
-
-| Level | Meaning | open-press behavior |
-| --- | --- | --- |
-| `#` | Whole document title only | Use on cover or document identity; do not use inside normal content files |
-| `##` | Formal chapter / document unit | Enters the formal TOC; starts a major reader section |
-| `###` | Major topic group inside a chapter | Enters the formal TOC; use for concepts readers should scan before reading |
-| `####` | Concrete algorithm, operation, theorem, variant, or worked procedure | Enters reader outline/bookmarks; normally stays out of the formal TOC |
-| Body blocks | Concept, table, figure, pseudocode, code, trace, practice | Do the explanation work; do not encode hierarchy by font size alone |
-
-When a document becomes a full book or multi-unit reference, avoid promoting every algorithm to `##`. A stable long-form document usually has few H2 chapters, several H3 topic groups, and many H4 implementation items.
-
-## H4 Granularity
-
-Use H4 for a complete teachable unit, not for every local teaching block.
-
-- Keep one H4 when the blocks share the same operation, invariant, or algorithm.
-- Merge adjacent H4s when one only adds the table, figure, trace, pseudocode, or C-like code for the same topic.
-- Do not make repeated local `小測驗` headings into H4; use a bold paragraph or exercise block unless the whole section is an assessment chapter.
-- Prefer 3-7 H4 items under one H3. If an H3 needs many more, first check whether the H3 should split or whether the H4s are too granular.
-- Keep terminology natural for programming topics. Use names such as `Linked List`, `Linked Queue`, `Header Node`, or `BST` when those are clearer than forced translation.
-
-## Authoring Workflow
-
-1. Identify the whole document scope from the user request and existing metadata.
-2. Choose H2 chapters first. For source material already organized by chapters or units, one source chapter usually becomes one H2, such as `CH4 Linked List`, `CH5 Tree`, `CH6 Graph`, `CH7 Sorting`.
-3. Group each H2 into H3 topic groups that belong in the public TOC.
-4. Move named algorithms, operations, theorem items, and implementation variants to H4.
-5. Merge H4s that only separate conceptual explanation from the worked trace or implementation of the same operation.
-6. Keep explanations, edge cases, teaching notes, and reasons in body prose, tables, figures, or code blocks.
-7. Put internal planning, style-pack rules, and agent guidance in `skills/`, `memory/`, or `document/design.md`, not in public chapter MDX.
-8. When hierarchy changes also affect explanation order, exercise design, captions, or student-facing wording, hand that part back to `openpress-writing` and the appropriate portable writing skill.
-
-## File Strategy
-
-open-press scans `document/chapters/<NN-slug>/content/*.mdx` in chapter/file order. Chapter directories are durable editing units; file boundaries inside a chapter are editing boundaries, not necessarily book hierarchy boundaries.
-
-- A long H2 chapter may span multiple files.
-- Only the first file of that chapter needs the `##` heading.
-- Later files in the same chapter may start with `###` or `####`.
-- Use filename prefixes for ordering, not for visible hierarchy.
-- Frontmatter `title:` is an editor/source label; visible book structure is defined by Markdown headings.
-
-## Data Structures Notes
-
-When the document is a data structures note, read `references/data-structures-outline.md` for the preferred H2/H3/H4 model. Treat it as structure memory, not public content.
-
-## Completion Check
-
-Before finishing a structure pass:
-
-- use `openpress` for source scanning, validation, export, or render commands;
-- inspect headings and confirm the semantic structure matches the intended H2/H3/H4 model;
-- confirm public TOC is not overloaded with H4-level algorithm names;
-- confirm reader outline H4s are not dominated by tiny code fragments, figure labels, or repeated quiz labels;
-- confirm H2 chapters can scale when new units are added.

package/template/skills/openpress-document-hierarchy/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "open-press Document Hierarchy"
-  short_description: "Plan and revise long-form open-press heading hierarchy"
-  default_prompt: "Use this skill to structure a open-press long-form document into H2 chapters, H3 topic groups, and H4 algorithms, procedures, or worked items."

package/template/skills/openpress-document-hierarchy/references/data-structures-outline.md

@@ -1,115 +0,0 @@
-# Data Structures Document Outline
-
-Use this outline when expanding a open-press document from one data-structure topic into a full data structures note. Keep it as authoring memory; do not copy it into public pages as an internal plan.
-
-## Heading Model
-
-- `## CH4 Linked List`
-  - `### List、Node 與 Pointer`
-  - `### Singly Linked List`
-    - `#### Insert`
-    - `#### Delete`
-    - `#### Search`
-    - `#### Reverse`
-    - `#### Concatenate`
-  - `### Linked Stack 與 Linked Queue`
-    - `#### Linked Stack push / pop`
-    - `#### Linked Queue add / delete`
-  - `### Circular Linked List 與 Header Node`
-    - `#### first / last entry design`
-    - `#### Circular delete`
-    - `#### Header Node operations`
-    - `#### Josephus problem`
-  - `### Polynomial 與 Sparse Matrix`
-    - `#### Polynomial add`
-    - `#### Polynomial multiply`
-    - `#### Sparse matrix representation`
-  - `### Doubly Linked List`
-    - `#### Insert`
-    - `#### Delete`
-    - `#### Circular Doubly Linked List`
-  - `### Practice`
-
-Keep chapter-local exercises and mock quizzes inside `### Practice` unless the assessment is large enough to become its own chapter. When the document grows into a multi-chapter book, prefer one of these patterns:
-
-- chapter-local practice inside each H2 chapter;
-- a global `## Practice` chapter for cumulative exercises;
-- a global `## Answer Appendix` chapter with H3 groups per source chapter.
-
-- `## CH5 Tree`
-  - `### Tree Theorems`
-    - `#### Theorem 1`
-    - `#### Theorem 2`
-    - `#### Theorem 3`
-  - `### Traversal`
-    - `#### Recursive traversal`
-    - `#### Non-recursive traversal`
-    - `#### Level-order traversal`
-  - `### Heap`
-    - `#### insert heap`
-    - `#### delete heap`
-  - `### Binary Search Tree`
-    - `#### BST search`
-    - `#### BST insert`
-    - `#### BST delete`
-    - `#### Copy tree`
-    - `#### Verify equal trees`
-    - `#### Count nodes`
-    - `#### Count leaves`
-  - `### AVL Tree`
-    - `#### Left rotate`
-    - `#### Right rotate`
-    - `#### AVL insert`
-    - `#### AVL delete`
-  - `### Expression Conversion`
-    - `#### Infix to prefix`
-    - `#### Infix to postfix`
-
-- `## CH6 Graph`
-  - `### DFS 與 BFS`
-    - `#### DFS`
-    - `#### DFS non-recursive`
-    - `#### BFS`
-  - `### Minimum Spanning Tree`
-    - `#### Kruskal`
-    - `#### Cycle detection by mask`
-    - `#### Union and Find`
-    - `#### Prim`
-  - `### Shortest Path`
-    - `#### Single-source shortest path Dijkstra`
-    - `#### All pairs shortest paths`
-  - `### Transitive Closure`
-
-- `## CH7 Sorting`
-  - `### Elementary Sorts`
-    - `#### Selection sort`
-    - `#### Bubble sort`
-    - `#### Insertion sort`
-  - `### Quick Sort`
-    - `#### Recursive quick sort`
-    - `#### Non-recursive quick sort`
-  - `### Merge Sort`
-    - `#### Recursive merge sort`
-    - `#### Non-recursive merge sort`
-  - `### Heap Sort`
-
-- `## Appendix A: C/C++ Programming Notes`
-  - `### Pointer Basics`
-  - `### Arrays and Strings`
-  - `### Function Parameters`
-
-Keep C/C++ syntax and programming-language refreshers in an appendix when they are reused across multiple data-structure chapters. Do not attach them to `CH4 Linked List` unless the note is intentionally a single-chapter handout.
-
-## Teaching Block Pattern
-
-For an H4 algorithm/procedure, prefer this order:
-
-1. Problem statement with input and output.
-2. Data representation or invariant.
-3. Pseudocode.
-4. Worked trace or diagram.
-5. C-like implementation.
-6. Complexity and common mistake.
-7. One practice prompt when useful.
-
-Keep these blocks inside the same H4 when they teach the same operation. For example, a trace table and the final C-like code for `Polynomial add` should not become separate H4 headings unless they are genuinely different topics.

package/template/skills/openpress-init/SKILL.md

@@ -1,84 +0,0 @@
----
-name: openpress-init
-description: Use when the user wants to start a new open-press project, set up a fresh document workspace, pick a style pack for a new document, bootstrap a new proposal/whitepaper/teaching-note/spec/book, or run the first-time initialization conversation before any content is written.
----
-
-# open-press Init
-
-This skill owns the **conversation that happens before `openpress init` runs**. Its job is to gather the minimum context needed to pick the right style pack and fill the right metadata, then hand off to downstream skills.
-
-It does not own writing, design, hierarchy, or deploy decisions — those belong to their specialist skills and only come into play after init completes.
-
-## When To Enter
-
-Activate when the user says any of:
-
-- "新開一個 open-press 專案 / 文件"
-- "start a new open-press doc / project"
-- "我想寫一份 [提案 / 白皮書 / 論文 / 講義 / spec / 報告 / 書]"
-- "幫我起手"
-- Any request that implies an empty target directory and no chosen pack yet.
-
-Do **not** activate when the workspace already has `document/` populated. In that case route to the appropriate domain skill instead.
-
-## Required Intake Questions
-
-Ask these before running `init`. Batch them; do not ask one at a time.
-
-| Question | Used to decide |
-| --- | --- |
-| 文件類型（提案 / 白皮書 / 論文 / 教學講義 / 工作筆記 / brief / spec / 書 / 其他） | Style pack recommendation, hierarchy expectation |
-| 目標讀者（內部團隊 / 客戶 / 學生 / 學術 / 公眾） | Tone register, portable skill triggers |
-| 主要語言（繁體中文 / English / 雙語） | Whether `chinese-ai-writing-polish` will load downstream |
-| 規模（單頁 brief / 多章長文 / 完整書 / 系列課程） | Style pack fit, chapter scaffold |
-| Metadata: `title` / `subtitle` / `organization` / `author` | Written directly into `openpress.config.mjs` and `document/index.tsx` |
-
-If the user already supplied any of these in the request, do not re-ask — only ask the gaps.
-
-## Optional Questions (Ask Only When Relevant)
-
-- 是否需要 PDF 輸出（默認需要，僅在使用者明確只要 web 時跳過 PDF preflight）
-- 是否預定公開部署（會引入 `openpress-deploy` 後續流程）
-- 目標完成日期（影響後續工作節奏建議，不影響 init 本身）
-
-## Style Pack Recommendation
-
-Map answers to pack choice:
-
-| 文件類型 + 規模 | 建議 pack |
-| --- | --- |
-| 提案書 / 白皮書 / 論文 / spec / 規格 / 多章長文 | `editorial-monograph` |
-| 工作筆記 / brief / 研究摘要 / 教學講義 / 內部備忘 / 單頁到中等長度 | `claude-document` |
-| 兩者邊界模糊時 | 給使用者兩個選項，附簡短差異描述（hairline vs warm paper），讓使用者選 |
-
-當未來有更多 pack 時，更新這張表並同步 `openpress-style-pack-contributor`。
-
-## Workflow
-
-1. Read the user's opening message; extract any answers already given.
-2. Ask only the **missing** intake questions in one batch.
-3. Confirm style pack choice with one sentence of rationale (e.g. 「多章長白皮書 → 建議 `editorial-monograph`，hairline 風格適合長段閱讀」).
-4. Run init via `openpress`:
-   ```bash
-   node engine/cli.mjs init <target> --skill <pack>
-   ```
-   `<target>` defaults to current workspace when empty; ask if unsure.
-5. Fill metadata: edit `openpress.config.mjs` (title/subtitle/organization/author) and the same fields in `document/index.tsx` cover props.
-6. Run `node engine/cli.mjs validate <target>` to confirm the workspace is healthy.
-7. Hand off:
-   - Tell the user what to edit next (`document/chapters/`, `document/index.tsx`, `document/theme/tokens.css`).
-   - Name which downstream skill will pick up next requests: writing → `openpress-writing`, design → `openpress-design`, structure → `openpress-document-hierarchy`, deploy → `openpress-deploy`.
-   - If 語言 is 繁體中文, mention that `chinese-ai-writing-polish` will load automatically during writing.
-   - If 文件類型 is 教學講義, mention that `teaching-notes-writing` will load.
-
-## Boundaries
-
-- `openpress` owns the `init` CLI itself and the source/generated boundary. This skill asks the questions; `openpress` runs the command.
-- `openpress-style-pack-contributor` owns designing new packs. This skill only consumes existing packs.
-- `openpress-writing` / `openpress-design` / `openpress-document-hierarchy` take over after init completes.
-
-## Do Not
-
-- Do not run `init` before metadata is gathered. An empty workspace with `[TODO]` placeholders in cover is a worse starting state than a 30-second intake conversation.
-- Do not pick a style pack for the user when the answer is ambiguous; offer the two candidates.
-- Do not start writing content during init. Hand off cleanly.

package/template/skills/openpress-style-pack-contributor/SKILL.md

@@ -1,62 +0,0 @@
----
-name: openpress-style-pack-contributor
-description: Use when contributing, designing, creating, reviewing, or improving a open-press style pack, especially the visual philosophy, starter workspace, design doc, theme tokens, page surfaces, components, and validation for skills/<pack>/starter.
----
-
-# open-press Style Pack Contributor
-
-This skill owns **bundled style packs at the source** — everything under `skills/<pack>/`. A style pack is an opinionated document design system plus a runnable starter workspace. Use `openpress` for the exact init, validate, export, render, and scratch-workspace commands.
-
-The split with `openpress-design` is by path, not by topic:
-
-- `skills/<pack>/starter/document/…` → this skill (upstream, ships to every new workspace).
-- `document/…` in an end-user workspace → `openpress-design` (downstream, one project's local edits).
-
-## Responsibilities
-
-- Define one clear visual philosophy for the pack.
-- Edit only `skills/<pack>/` unless the framework lacks a generic capability.
-- Provide a runnable `starter/` that the system-level `openpress` skill can initialize into a fresh target.
-- Keep starter `design.md` public-readable.
-- Preserve portable typography contracts: `theme/tokens.css` names `--openpress-font-*` tokens, `theme/fonts.css` loads faces, and `local(...)` alone is not enough for stable public output.
-- Validate the pack through a scratch workspace (do not overwrite the user's current `document/`).
-
-## Boundaries
-
-- `openpress` owns CLI command choice and the source/generated boundary table.
-- `openpress-design` owns the same visual concerns but in workspace `document/`, not pack `starter/`.
-- `openpress-writing` owns starter content prose and factual boundaries.
-
-## Pack Layout
-
-```txt
-skills/<pack>/
-  SKILL.md            # visual signature, suitable-for, do/don't
-  starter/
-    openpress.config.mjs
-    document/
-      index.tsx
-      chapters/
-      design.md
-      theme/
-      components/
-      media/
-```
-
-Do not put generated output, private content, customer data, secrets, or deployment artifacts in a style pack.
-
-## Workflow
-
-1. Define intended document types, readers, and visual philosophy.
-2. Keep the pack narrow; one pack should not serve every tone or industry.
-3. Build or update `starter/`.
-4. Ask `openpress` to choose and run the scratch-workspace validation workflow.
-5. Ask `openpress` for broader framework checks only when shared code changes.
-
-## Cross-Pack Discovery
-
-When adding a new pack, also update sibling pack SKILLs that overlap in audience so users can choose between them. Each pack SKILL should at minimum list its **suitable / not suitable** scope.
-
-## When To Read References
-
-- Read `references/starter-contract.md` for starter file responsibilities, typography portability, validation expectations, and review checklist.

package/template/skills/openpress-style-pack-contributor/references/starter-contract.md

@@ -1,49 +0,0 @@
-# Style Pack Starter Contract
-
-## Starter Responsibilities
-
-| Path | Responsibility |
-| --- | --- |
-| `starter/openpress.config.mjs` | root marker that points at `document/openpress.config.mjs` |
-| `starter/document/index.tsx` | React document entry: config plus cover, TOC, and back-cover shell JSX |
-| `starter/document/chapters/` | minimal coherent MDX chapters; optional chapter opener files |
-| `starter/document/design.md` | single public-readable design brief (style positioning, tokens, components, CSS responsibilities) |
-| `starter/document/theme/` | CSS tokens, fonts, base typography, page surfaces, patterns, shell rules, print safeguards |
-| `starter/document/theme/fonts.css` | font-face imports or self-hosted font rules |
-| `starter/document/theme/fonts/` | optional self-hosted `.woff2` files |
-| `starter/document/components/` | reusable structured visual units |
-| `starter/document/media/` | assets safe to ship with the pack |
-
-The engine discovers a style pack by the presence of `starter/`.
-
-Page surfaces are optional by document type. A report-focused pack can ship only cover, TOC, chapter, and back cover styling. A book/manual/teaching pack may also include `starter/document/theme/page-surfaces/chapter-opener.css` plus optional `chapter.tsx` opener exports. Chapter openers must be optional starter content, not a required page in every new workspace.
-
-## Typography Portability
-
-Style packs own typography:
-
-- `theme/tokens.css` names font tokens and fallback stacks.
-- `theme/fonts.css` loads actual font faces.
-- `theme/fonts/` stores self-hosted files when the pack must work without a CDN.
-
-Do not rely on `local(...)` alone for public, mobile, iPad, or PDF-stable output. If a pack uses system fonts, document that output is not pixel-identical across devices.
-
-## Validation Expectations
-
-Validate through a scratch workspace, but do not define the command sequence in this style-pack reference. Use `openpress` for init, validate, export, render, PDF, and broader framework check commands.
-
-Run PDF only when `openpress` determines the scratch workspace has the required app/runtime files. Run broader framework checks only when shared code changes.
-
-## Review Checklist
-
-Before calling the pack ready, confirm:
-
-- one narrow, describable visual philosophy;
-- portable typography policy;
-- starter renders without missing assets or fonts;
-- `openpress` can initialize and validate the pack through the current system-level workflow;
-- dense paragraphs, tables, figures, captions, and long headings remain readable;
-- starter Markdown tables demonstrate `<TableCaption>...</TableCaption>` instead of legacy prose markers or hand-written table numbers;
-- PDF output does not overflow fixed pages when PDF validation is available;
-- `design.md` teaches users and agents how to review the pack;
-- no private content, customer data, tokens, or deploy secrets are included.

package/template/skills/openpress-update/SKILL.md

@@ -1,88 +0,0 @@
----
-name: openpress-update
-description: Use when updating or upgrading an existing open-press workspace to a newer framework release, pulling new engine/runtime changes, applying release migration notes, or handling breaking changes between versions.
----
-
-# open-press Update
-
-This skill owns the **release update flow** for an existing workspace: pulling new framework code, applying migration notes, handling breaking changes, and verifying nothing broke.
-
-It does not own first-time setup (that is `openpress-init`) and does not own content/design changes (those are domain skills).
-
-## When To Enter
-
-Activate when the user says any of:
-
-- "升級 open-press / 更新到最新版"
-- "update open-press / upgrade to latest"
-- "拉新版的 engine"
-- "看一下這版有什麼破壞性改動"
-- After the user pulls a new git tag and asks to verify the workspace still works.
-
-## Pre-Flight Check
-
-Before touching anything, confirm:
-
-1. **Workspace state is clean**: `git status` shows no uncommitted document changes that an upgrade might overwrite.
-2. **Current version is known**: read `package.json` `version` field; compare to target version.
-3. **CHANGELOG has been read**: locate the project's CHANGELOG (currently in `docs/superpowers/specs/` migration notes; future: top-level `CHANGELOG.md`). Identify every breaking change between current and target version.
-
-If any of these are missing, surface to the user before proceeding.
-
-## Current Update Surface (pre-`core/`)
-
-Until the `core/` folder restructure ships (tracked in `docs/superpowers/specs/2026-05-21-open-press-template-and-skill-init.md`), framework code lives intermixed with workspace code in this repo. Update means:
-
-1. `git pull` (or merge / rebase the new framework tag).
-2. `npm install` to refresh dependencies.
-3. `npm run typecheck` — first signal of API-shape breakage.
-4. `npm test` — second signal of behavior breakage.
-5. `npm run openpress:validate && npm run openpress:render` against current `document/`.
-6. For each failure, check the CHANGELOG entry for the breaking change and apply the documented migration.
-
-## Future Update Surface (post-`core/`)
-
-When `core/` exists (planned, see spec):
-
-1. Backup user-edited escape-hatch files under `src/` (workspace overrides via vite alias).
-2. Overwrite `core/` wholesale from the new release.
-3. Re-apply codemods listed in the release migration notes.
-4. Verify with `typecheck` + `test` + `validate` + `render`.
-
-This skill will own the codemod runner once it exists.
-
-## Breaking Change Handling
-
-For each breaking change in the CHANGELOG:
-
-| Change type | Action |
-| --- | --- |
-| Renamed identifier (e.g. `BaseReportPage` → `BaseContentPage`) | grep workspace for old name; rewrite at every callsite |
-| Removed export | grep workspace; ask user if replacement is acceptable |
-| Changed function signature | typecheck will surface; fix per release notes |
-| CSS class rename | grep `document/theme/` and `document/components/`; rewrite |
-| Config schema change | edit `openpress.config.mjs` per release notes |
-| Markdown / MDX directive change | grep `document/chapters/`; rewrite per release notes |
-
-If a breaking change has no documented migration in the CHANGELOG, **stop and ask the user** — do not improvise.
-
-## Workflow
-
-1. Pre-flight (clean tree, version delta, CHANGELOG read).
-2. Pull the new code.
-3. Run `typecheck` / `test` / `validate` / `render` in that order; stop at the first failure.
-4. For each failure: find the CHANGELOG entry, apply the migration, re-run the failing command.
-5. After all gates pass, run `npm run openpress:pdf` to sanity-check PDF output.
-6. Report to the user: starting version, ending version, list of migrations applied, anything that needed manual intervention.
-
-## Boundaries
-
-- `openpress` owns the CLI and the source/generated boundary. This skill uses those commands.
-- `openpress-deploy` is **not** part of update; do not auto-deploy after a successful update.
-- Domain skills (`openpress-writing` / `openpress-design`) handle non-mechanical content rewrites that the user wants to do alongside the upgrade.
-
-## Do Not
-
-- Do not skip CHANGELOG reading. An undocumented breaking change is a sign to stop, not a sign to guess.
-- Do not bundle new feature work with an update. Land the update first, commit, then start new work.
-- Do not run `--force` overwrites on workspace files. If a file conflicts, surface it.