@open-press/cli 0.3.0 → 0.5.0

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

@@ -1,51 +0,0 @@
----
-name: openpress-design
-description: Use when designing or revising open-press visual systems, page rhythm, print/PDF-safe CSS, figure/table/chart presentation, covers, style packs, or document component recipes.
----
-
-# open-press Design
-
-open-press design owns the **workspace visual system** — the CSS and components that live in a user's `document/` after a pack has been initialized. It decides how the document looks while keeping fixed-layout, mobile, and PDF output stable.
-
-## Responsibilities
-
-- Choose typography, color, spacing, page rhythm, covers, figures, tables, and chart treatment.
-- Edit `document/theme/`, `document/design.md`, and `document/components/` in a workspace.
-- Decide when dense prose should become a reusable visual component.
-- Keep `document/design.md` public-readable so users and agents can review the same rules.
-- Preserve React reader output as the public reading surface; PDF is an export artifact.
-
-## Boundaries (by path, not by topic)
-
-| Path | Owner |
-| --- | --- |
-| `document/theme/`, `document/components/`, `document/design.md` (workspace) | **this skill** |
-| `skills/<pack>/starter/document/theme/`, `…/components/`, `…/design.md` (upstream pack) | `openpress-style-pack-contributor` |
-| `engine/`, `src/` (framework rendering) | framework agents only |
-
-Other domain skills:
-
-- `openpress-writing` owns claims, prose, audience, and captions as language.
-- `openpress-diagram-drawing` owns diagram semantics; this skill owns visual skin.
-- `openpress-deploy` owns public release.
-
-Source paths follow `openpress` > Source Boundary.
-
-## Hard Rules
-
-- Avoid uncontrolled overflow into headers, footers, or fixed pages.
-- Do not depend on local-only fonts when public, iPad, or PDF-stable output matters.
-- Keep page-surface CSS, generic patterns, and component CSS in their owning layers.
-
-## Workflow
-
-1. Read `document/design.md` before changing theme or components.
-2. Edit source CSS/components only (see `openpress` > Source Boundary).
-3. Use `openpress` to choose validation depth.
-4. For renderer-sensitive changes, ask `openpress` which render/inspect/local-review verification is needed before declaring the design ready.
-
-## When To Read References
-
-- Read `references/theme-and-components.md` before moving CSS layers, extracting components, changing `document/design.md`, or localizing page-surface defaults.
-- Read `references/pdf-safe-css.md` before changing fixed page geometry, print behavior, or overflow-sensitive CSS.
-- Read `references/responsive-fixed-layout.md` before changing mobile, tablet, zoom, spread, or responsive behavior.

package/template/skills/openpress-design/references/pdf-safe-css.md

@@ -1,29 +0,0 @@
-# PDF-Safe CSS Notes
-
-Use this reference when editing open-press CSS that affects fixed pages, PDF output, or renderer stability.
-
-## Prefer
-
-- fixed page geometry;
-- container-relative type scales;
-- explicit image dimensions or max dimensions;
-- `break-inside: avoid` only for blocks that must stay together;
-- table and figure captions outside the media object;
-- CSS variables for theme values.
-
-## Avoid
-
-- viewport-width type for fixed-format content;
-- uncontrolled `position: absolute` near footer/header;
-- large nested cards;
-- transform-based layout where measurement matters;
-- SVG text for document copy unless the visual must be one fixed asset;
-- mobile RWD changes that alter canonical PDF layout.
-
-## PDF Export
-
-PDF output is an export artifact. Do not embed the browser's built-in PDF viewer as the primary open-press reading surface; it introduces a second toolbar, second page model, and inconsistent navigation. The deployed reader should remain open-press-owned DOM.
-
-## Design Skill Boundary
-
-PDF-safe does not mean visually conservative. It means the chosen design must survive measurement, pagination, and rendering.

package/template/skills/openpress-design/references/responsive-fixed-layout.md

@@ -1,48 +0,0 @@
-# Responsive Fixed-Layout Notes
-
-Use this reference when editing open-press styles that affect mobile, tablet, zoom, spread mode, or responsive behavior.
-
-## Core Principle
-
-open-press pages have canonical page geometry. Responsive behavior should scale the page and surrounding workspace, not re-author the document for every viewport.
-
-A deployed open-press reader should stay DOM-rendered and open-press-owned. Do not embed the browser PDF viewer to solve responsive problems; that adds a second reader UI and breaks the intended workspace model.
-
-## Page Rules
-
-- Keep one canonical width/height ratio for each page.
-- Use CSS variables for page dimensions and derive scale from the available stage size.
-- On narrow viewports, show one page at a time and scale the page down.
-- On wide viewports, spread mode may show two pages if both fit without clipping.
-- Preserve page order, anchors, bookmarks, figure indexes, and page numbers across breakpoints.
-- do not reflow document copy into a different editorial structure on mobile.
-
-## SVG Rules
-
-- Inline SVG charts must keep a stable `viewBox` and use CSS `aspect-ratio` that matches that viewBox.
-- SVG figures should use `display: block`, `max-width: 100%`, `height: auto`, and `overflow: visible`.
-- Scale the SVG as one fixed graphic within the canonical page; do not reflow labels, legends, or axes per breakpoint.
-- External SVG assets used through `<img>` should be constrained like other images: fixed frame, `object-fit: contain`, and explicit max dimensions.
-
-## Workspace Rules
-
-- The React open-press workbench shell may be responsive: side panels can collapse, navigation can become denser, and controls may hide secondary metadata.
-- The document page itself should not change its typography hierarchy, captions, table structure, or figure composition just because the viewport changed.
-- If text becomes too small on mobile, prefer pinch/zoom or horizontal-safe page scaling over rewriting the document layout.
-- Keep a single scroll owner per viewport mode. Avoid nested vertical scrollbars between body, stage, and page.
-
-## Avoid
-
-- viewport-width font sizing inside fixed pages;
-- mobile-specific page content order;
-- breakpoints that alter canonical page pagination;
-- iframe-based PDF readers as the central stage;
-- CSS transforms that leave hit targets, bookmarks, or scroll sync using stale geometry.
-
-## Acceptance Checklist
-
-- Desktop, tablet, and mobile all show the same page count.
-- Bookmark clicks land on the same logical page across breakpoints.
-- Figures and tables retain captions and do not overflow.
-- The page is scaled or positioned by the workspace, not redesigned by the viewport.
-- There is no embedded browser PDF toolbar inside the open-press reader.

package/template/skills/openpress-design/references/theme-and-components.md

@@ -1,77 +0,0 @@
-# Theme And Component Boundaries
-
-## Theme Layers
-
-Use theme layers by responsibility:
-
-| Layer | Owns |
-| --- | --- |
-| `document/theme/tokens.css` | variables only: colors, fonts, type scale, spacing, chart colors, shared numeric tokens |
-| `document/theme/fonts.css` and `fonts/` | font-face sources copied to `/openpress/fonts.css` and `/openpress/fonts/` |
-| `document/theme/base/` | global page contract, typography, figures, tables, captions, TOC, print safeguards |
-| `document/theme/page-surfaces/` | whole-page layouts such as cover, TOC, optional chapter openers, back cover, divider pages |
-| `document/theme/patterns/` | reusable document-wide class patterns |
-| `document/theme/shell/` | exported reader controls around the document |
-| `document/components/<name>/style.css` | instance-scoped component CSS |
-
-Do not put page-surface or component-specific CSS in `base/typography.css`.
-
-## Component Extraction
-
-Prefer React components when a visual block has structured sub-elements, repeats with different props, or would otherwise become a large inline HTML island.
-
-Component shape:
-
-```txt
-document/components/ComponentName.tsx
-document/components/ComponentName/
-  index.tsx       # default-exported React component
-  style.css       # optional component-scoped CSS
-```
-
-Use PascalCase component names so MDX can call them directly:
-
-```mdx
-<ProcessDiagram title="Deploy flow" steps={["Validate", "Render", "Deploy"]} />
-```
-
-Props live in TypeScript types or interfaces next to the component. Do not add sidecar renderer, schema, data, or custom element bridge files.
-
-Keep image grids inline when pagination owns their page-break behavior. Do not extract foundational page surfaces such as cover/back-cover/chapter-opener unless the design system does it as a coordinated React page-surface change.
-
-## Page Surface Chrome
-
-The renderer owns page chrome policy. Theme CSS should style the contract, not invent per-document footer hacks:
-
-| Page kind | Theme surface | Footer |
-| --- | --- | --- |
-| `cover` | `page-surfaces/cover.css` | off |
-| `toc` | `page-surfaces/toc.css` | off |
-| `chapter-opener` | `page-surfaces/chapter-opener.css` when the pack supports book-like dividers | off |
-| `content` | `base/typography.css` and patterns/components | on |
-| `back-cover` | `page-surfaces/back-cover.css` | off |
-
-Use `.reader-page.no-footer .page-frame` for layout rows when a surface has no footer. Do not leave empty footer text or hide meaningful generated page numbers with one-off selectors.
-
-## Design Document Source
-
-`document/design.md` is a single public-readable design brief. It should describe the same theme the document actually uses:
-
-- typography hierarchy and scale;
-- cover, TOC, optional chapter-opener, chapter, and back-cover direction;
-- paragraphs, lists, quotes, callouts;
-- image, image-grid, chart, table, caption, and dense-content stress cases.
-
-Caption wording and numbering belong to `openpress-writing` and the renderer. Design may style `figcaption`, `caption`, and `[data-openpress-caption]`, but should not require authors to maintain figure/table numbers or duplicate caption text inside visuals.
-
-Do not create a second hidden design brief unless the user explicitly asks for a sandbox.
-
-## Localization Defaults
-
-open-press engine does not embed a complete language system. Audit these per document:
-
-- frontmatter `title:` on cover, TOC, and back cover;
-- `theme/tokens.css` font stacks;
-- `theme/base/typography.css` chapter and section numbering rules.
-
-Workbench UI strings in `src/openpress/` are application UI and belong to framework work, not document styling.

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.