@open-press/cli 0.3.0 → 0.5.0

package/template/skills/chinese-ai-writing-polish/SKILL.md

@@ -1,195 +0,0 @@
----
-name: chinese-ai-writing-polish
-description: Use when producing or editing Traditional Chinese professional content, especially business, product, proposal, report, pitch, website, documentation, or marketing copy that may contain AI-like sentence patterns, empty contrast phrasing, vague transformation slogans, exaggerated claims, or repetitive polished-but-thin language.
----
-
-# 中文 AI 語句避雷 Writing Skill
-
-這是一個 **portable writing skill**：可獨立使用，也可由 `openpress-writing` 載入。當輸出語言為繁體中文的專業內容時，本 skill 提供句型、用詞、表格文字、被動句、反向句的判斷規則。
-
-## 與其他 Skill 的關係
-
-- 在 open-press 文件中，由 `openpress-writing` 在繁體中文內容時載入。
-- 若同時載入多個 portable writing skill（如本 skill + `teaching-notes-writing`），衝突解決依 `openpress-writing` 內的優先順序。
-- 本 skill 不規範 open-press 的 source 路徑、CLI、驗證、輸出、部署或 style pack 套用流程；系統操作一律回到 `openpress` 分流，再由它決定是否交給其他 openpress-* skill。
-
-## 目標
-
-產出專業、可用、可交付的中文內容。優先保留事實、判斷、對象、行動與結果；避免用看似漂亮但資訊量低的 AI 腔句型填補內容。
-
-## 核心原則
-
-- 直接說明主張，不用戲劇化轉折包裝薄弱論點。
-- 用具體名詞、動詞、情境與結果取代抽象口號。
-- 每段只承擔一個重點：對象、問題、做法、效果要清楚。
-- 能量化就量化；不能量化就說清楚觀察依據。
-- 避免過度承諾。沒有證據時，不寫「最佳」「顛覆」「重新定義」「革命性」。
-- 寫給讀者要做的決策，不寫給文字本身好看。
-- 反向說法只作為少量 hook 使用；一般段落應直接說產品做了什麼，讓讀者第一秒掌握重點。
-- 表格文字要像表格，不要像段落。欄位名稱已經交代語意時，儲存格避免重複「驗證」「支援」「已完成」「用於」等附帶動詞，優先保留名詞、數據、狀態與結果。
-- 避免同一小節反覆提及相同主詞。段落開頭已建立產品、公司或創辦人時，後續句子可用「產品」「平台」「團隊」「這項規劃」承接，或在語意清楚時省略主詞。
-
-## 高風險 AI 腔句型
-
-| 避免句型 | 問題 | 改寫方向 |
-| --- | --- | --- |
-| 這不是 A，而是 B | 用對比製造深度，但常沒有新增資訊；若太常使用，讀者第一秒抓不到重點 | 直接說 B 的具體功能、價值或差異；只有在需要與差異很大的系統做對比時，才可作為 hook 使用 |
-| 不只是 A，更是 B | 結構老套，容易把兩個空泛名詞堆在一起 | 拆成「目前能做什麼」與「因此帶來什麼結果」 |
-| 把每一次的 A 都變成 B | 過度願景化，缺少執行機制 | 說明每次 A 發生時，系統或流程實際記錄、判斷、提醒、產出什麼 |
-| 讓 X 不再只是 Y | 轉折感強但資訊密度低 | 直接描述 X 現在新增的能力或使用情境 |
-| 從 A 到 B，全面升級 | 範圍過大，缺少可驗證細節 | 列出升級的項目、使用者感受到的變化、限制條件 |
-| 重新定義 A | 宣稱過大，通常無法證明 | 改成「改善 A 中的某個具體環節」 |
-| 打造一個有溫度的 A | 抽象且常見，難以落地 | 寫出哪個互動、回饋或服務讓使用者感受到差異 |
-| 賦能、賦予、開啟新篇章 | 商業套話，容易顯得空泛 | 改成「支援」「協助」「提供」「降低」「縮短」「提升」 |
-| 在這個快速變動的時代 | 開場空泛，與主題連結弱 | 直接進入讀者面臨的具體問題 |
-| 真正的 A，不是 B，而是 C | 像演講稿金句，不像專業說明 | 改成可被檢驗的判斷或標準 |
-| 每一個 A，都值得被 B | 情緒化且泛用 | 指出哪些 A 需要 B，以及原因 |
-| 透過 A，讓 B 更 C | 過度依賴「透過」「讓」串句 | 改成主詞明確的動作句：「A 會整理 B，並標示 C」 |
-| 讓 X 可以被／能被 Y | 被動句包裝，主詞與責任不清，容易寫成「讓資料能被使用」「讓問題可以被看見」這類空泛句 | 改成主詞明確的主動句：「系統整理 X，供 Y 使用」「教師可用 X 判斷 Y」 |
-| X 可以被／能被 Y | 過度使用被動語態，讀者難以判斷誰執行動作、產出什麼結果 | 改成「誰使用 X 做什麼」或「系統如何處理 X」 |
-
-## 改寫方法
-
-1. 找出句子的實際意思：這句話到底要說功能、差異、願景、成果，還是情緒？
-2. 刪掉套語骨架：移除「不是...而是...」「不只是...更是...」「把每一次...都變成...」。
-3. 補上具體資訊：誰在什麼情境下，做了什麼，得到什麼結果。
-4. 檢查證據強度：若沒有資料支持，就降低語氣，改成「有助於」「可協助」「目標是」。
-5. 用短句收斂：一句話只放一個主要判斷，避免連續堆疊抽象名詞。
-
-## 主詞延續規則
-
-中文商業文件不需要每一句都重複產品名或公司名。當小節標題、段落第一句或前一句已經建立主詞，後續句子應自然承接。
-
-| 避免寫法 | 問題 | 建議寫法 |
-| --- | --- | --- |
-| `QJudge 目前是一人公司……因此 QJudge 現階段雖然以一人公司形態推進……` | 同一資訊重複兩次，讀者會覺得段落在原地打轉 | 第一段交代現況，後段改寫為「現階段雖然團隊規模小，但產品不是孤立開發。」 |
-| `QJudge 的組織化不會……QJudge 會……QJudge 需要……` | 產品名過度重複，語氣僵硬 | `組織化不會……後續會……下一階段需要……` |
-| `本產品支援……本產品提供……本產品能夠……` | 每句都重啟主詞，段落節奏笨重 | 第一處保留產品名，後續用「系統」「平台」「功能」或直接接動作 |
-
-判斷標準：
-
-- 同一段出現同一產品名超過 2 次，先檢查是否可省略或替換。
-- 若前一句已明確說明主詞，下一句不要再用相同名詞開頭。
-- 主詞替換應服務清楚度，不要為了變化而使用模糊代稱；讀者會誤解時才保留完整主詞。
-- 結論句可回到產品名，但不應重複前文已講過的狀態或背景。
-
-## 表格文字規則
-
-表格的欄位名稱已經提供上下文，儲存格應減少完整句與重複動詞，讓讀者快速掃描。
-
-| 避免寫法 | 問題 | 建議寫法 |
-| --- | --- | --- |
-| 規模：`60 人受測` | 欄位已寫「規模」，`受測` 多餘 | `60 人` |
-| 已驗證能力：`驗證程式上機等特殊題型也能在線上完成作答與監考` | 欄位已寫「已驗證能力」，開頭再寫「驗證」重複 | `程式上機等特殊題型可在線上完成作答與監考` |
-| 平台開發狀態：`已支援正式課程建立考試` | 狀態欄已有「已上線」，備註再寫「已支援」冗餘 | `正式課程考試建立；多題型作答介面` |
-| 備註：`可用於考前到場簽到、身分確認與考生狀態整理` | `可用於` 不增加資訊 | `考前到場簽到、身分確認與考生狀態整理` |
-
-判斷標準：
-
-- 欄位叫「規模」時，儲存格只放數字與單位。
-- 欄位叫「狀態」時，儲存格只放狀態，不再補「目前」「已經」。
-- 欄位叫「能力」「功能」「備註」時，儲存格用名詞片語或短句，不用完整說明段。
-- 同一列若需要補充因果或限制，移到表格前後段落，不塞進儲存格。
-
-## 反向說法使用邊界
-
-「不是 A，而是 B」「不只是 A，更是 B」這類反向句，不應作為常規說明段落的開頭。它會先要求讀者理解一個被否定的對象，再等待真正主張出現，容易讓評審或讀者第一秒抓不到重點。
-
-可使用的情境：
-
-- **對比差異很大的系統**：例如需要說明 QJudge 與 LMS、Google Forms、一般題庫或 OJ 平台的根本差異。
-- **段落 hook**：用一句話打開對比，但下一句必須立刻接具體差異，例如功能、流程、資料、責任邊界或使用者行為。
-- **避免連續使用**：同一章節若已用過一次反向句，後續段落應改用正向敘述。
-
-不建議的情境：
-
-- **說明產品功能時**：直接寫系統要求使用者做什麼、系統記錄什麼、產出什麼結果。
-- **說明願景時**：直接寫未來要支援的題型、資料流或評量方式，不要用金句包裝。
-- **說明價值時**：直接寫降低多少人力、縮短哪個流程、保留哪些紀錄。
-
-判斷標準：如果刪掉「不是 A」後，句子仍然能直接說清楚 B 的功能或價值，就應該刪掉反向開頭。
-
-## 改寫範例
-
-### 例 1：產品定位
-
-避免：
-
-> 這不是一個解題平台，而是一個陪伴學生持續成長的學習夥伴。
-
-建議：
-
-> QJudge 會記錄學生的提交紀錄、錯誤類型與修正歷程，讓學生回看自己的卡點，也讓教師掌握班級常見問題。
-
-### 例 2：學習歷程
-
-避免：
-
-> 把每一次練習都變成成長的契機。
-
-建議：
-
-> 每次練習後，系統會保留題目、提交結果、錯誤訊息與修改紀錄，方便學生比較前後版本並整理弱點。
-
-### 例 3：商業提案
-
-避免：
-
-> 我們不只是提供工具，更是協助教育現場重新定義程式學習。
-
-建議：
-
-> 我們提供自動批改、作業派發、學習紀錄與班級分析，協助教師減少批改時間，並更早發現學生的共同錯誤。
-
-### 例 4：網站文案
-
-避免：
-
-> 在 AI 快速發展的時代，打造更智慧、更有溫度的學習體驗。
-
-建議：
-
-> 學生提交程式後，系統會即時回傳測資結果與錯誤提示；教師可在後台查看完成率、錯誤分布與個別進度。
-
-## 可用句型
-
-- `X 是給 [使用者] 在 [情境] 中完成 [任務] 的 [產品類型]。`
-- `[功能] 會在 [觸發時機] 自動 [動作]，供 [使用者] [具體行動]。`
-- `相較於 [既有做法]，[方案] 減少了 [成本或阻力]，並保留 [必要能力]。`
-- `這項設計解決的是 [具體問題]，不是泛稱的 [抽象願景]。`
-- `目前版本支援 [能力 A]、[能力 B]、[能力 C]；尚未涵蓋 [限制]。`
-- `若目標是 [決策或成果]，建議優先呈現 [證據或指標]。`
-
-## 用字偏好
-
-- 優先使用：支援、協助、提供、記錄、整理、比對、標示、提醒、降低、縮短、提升、追蹤、檢視。
-- 謹慎使用：打造、賦能、顛覆、革新、重新定義、全方位、沉浸式、無縫、前所未有、有溫度。
-- 避免連續使用抽象名詞：體驗、價值、願景、場景、生態系、解決方案、影響力。
-- 專業內容應使用繁體中文與台灣常用語感；避免不必要的簡體詞與翻譯腔。
-
-## 英文技術術語處理
-
-不要為了「全中文」而強硬翻譯英文技術術語。判斷標準：
-
-| 情境 | 處理方式 |
-| --- | --- |
-| 業界已普及、讀者一看就懂的英文詞 | 直接保留英文，例如 `edge case`、`spec`、`rubric`、`pipeline`、`SOP`、`KPI`、`API`、`OAuth` |
-| 存在更精準、不引起誤會的中文說法 | 用中文，例如「鑑別度」「採購週期」「監考流程」 |
-| 直譯結果晦澀或失準 | 用英文，或改寫情境描述（例：`edge case` 不要硬翻成「邊角案例」，可寫「教學現場的例外事件」或「平常想不到的特殊情境」） |
-| 同一份文件中已先出現英文原詞 | 後續沿用英文，不要混用兩種譯名 |
-
-判斷時優先看「讀者第一秒抓到意思」與「精準度」，而不是「中英文比例」。專業讀者（評審、業界）對常見英文術語的辨識度通常高於彆扭的直譯。
-
-## 交付前檢查
-
-- 是否出現「這不是...而是...」「不只是...更是...」「把每一次...都變成...」或其變體？
-- 是否出現「讓 X 可以被／能被 Y」「X 可以被／能被 Y」「資料被使用」這類被動包裝句？
-- 若使用反向說法，是否是為了和差異很大的系統做對比？下一句是否立刻接具體差異？
-- 每段是否至少有一個明確主詞與一個具體動作？
-- 形容詞是否能被證據支持？不能支持就刪掉或降級。
-- 是否用功能、流程、數據、限制取代口號？
-- 讀者看完是否知道下一步可以判斷、操作或相信什麼？
-
-## 使用規則
-
-當輸出中文內容時，先以本 Skill 掃描草稿。若草稿含有高風險 AI 腔句型，必須改寫為具體、可驗證、可交付的版本；除非使用者明確要求保留宣傳式、演講式或高度修辭化的語氣。

package/template/skills/claude-document/SKILL.md

@@ -1,66 +0,0 @@
----
-name: claude-document
-description: Use when starting or applying a warm Claude-like A4 document style pack for polished notes, briefs, specs, research summaries, learning material, or structured working documents.
----
-
-# Claude Document
-
-An open-press style pack for Claude-like working documents: warm paper, generous fixed pages, deep blue-gray headings, serif display titles, structured tables, concise figures, and calm editorial rhythm.
-
-This is a **local style pack**. It is not an Anthropic brand package and should not imply official Claude or Anthropic affiliation.
-
-## Visual Signature
-
-- **Surface**: A4 fixed pages with a warm paper texture and subtle vertical rhythm.
-- **Type**: serif display headings, sans body text, monospace code.
-- **Color**: deep blue-gray ink, muted blue labels, warm hairlines, restrained block backgrounds.
-- **Content components**: tables, figure captions, code blocks when needed, optional full-page chapter openers.
-- **Pagination**: fixed page ratio; overflow is a content/component problem, not a reason to let pages grow.
-
-## Suitable For
-
-- polished working notes;
-- product briefs, specs, and research summaries;
-- learning material and internal documentation;
-- public documents that need a calm, Claude-like editorial surface.
-
-## Not Suitable For
-
-- marketing landing pages;
-- slide decks or 16:9 talks without changing page geometry tokens;
-- dashboards or interactive app documentation.
-
-## Related Packs
-
-- `editorial-monograph` — hairline-driven, more formal long-form (whitepapers, monographs, academic-leaning). Choose it when the document is heavier and needs IBM-Carbon-style restraint instead of warm Claude tone.
-
-## Apply To A Workspace
-
-Use `openpress` to initialize a workspace with pack name `claude-document`. This skill only defines the pack's visual scope and starter content; `openpress` owns the command surface and validation workflow.
-
-After applying, use `openpress` for source-boundary and command decisions. Typical editable source areas are:
-
-- `document/index.tsx` — cover, TOC shell, back cover, metadata;
-- `document/chapters/**/*.mdx` — content;
-- `document/theme/tokens.css` — color, typography, spacing, page geometry;
-- `document/design.md` — public style contract that future agents follow.
-
-Content rules (table captions, figure numbering, etc.) live in `openpress-writing`; this skill does not redefine them.
-
-## Do / Don't
-
-Do:
-
-- Keep figures focused on one concept, decision, or relationship.
-- Prefer semantic figures, tables, and concise prose over decorative blocks.
-- Keep chapter openers optional and use them only when major sections benefit from a book-like divider.
-
-Don't:
-
-- Put private names, customer data, deployment secrets, or project-specific author data in the starter.
-- Shrink text below readable print size to hide overflow.
-- Add large decorative gradients, dark sci-fi backgrounds, or brand-heavy visual noise.
-
-## Deep Rules
-
-The detailed rules live in `starter/document/design.md`. Once the pack is copied into a workspace, that file becomes the project-level design contract for both users and agents.

package/template/skills/editorial-monograph/SKILL.md

@@ -1,73 +0,0 @@
----
-name: editorial-monograph
-description: Use when starting or applying a quiet, hairline-driven A4 editorial style pack for long-form monographs, reports, proposals, whitepapers, product specs, or academic documents.
----
-
-# Editorial Monograph
-
-A document style for **嚴肅長文**——日系簡約 + IBM Carbon hairline 風格的衍生，適合產品提案書、白皮書、研究報告、規格文件等需要 A4 印製、章節結構清楚、長段閱讀的場合。
-
-This is a **style-pack skill**: it ships SKILL rules plus a runnable `starter/` document workspace (React/MDX entry, theme, design doc, sample chapters). Use `openpress` to initialize a workspace with pack name `editorial-monograph`; this skill does not own the command surface.
-
-## Visual Signature
-
-- **Type**: serif 章首（Noto Serif TC / Source Han Serif TC）+ sans body（IBM Plex Sans / PingFang TC）
-- **Lines**: 1px hairline + dotted underline for links；不用 box-shadow / gradient
-- **Color**: 黑白灰主體 + 三色 status accent（warn / success / info）+ chart palette（gold / coral / dark）
-- **Layout**: A4 固定版面、章首占整頁、TOC 帶頁碼但不顯示 footer、可選章節 mini cover、figure / table 自動編號
-- **Chapter numbering**: default `01 / 02 / 2.1`（pagination + CSS `::before`）；可改 `一、二、（一）` 或 `Chapter 1 / §1.1`，token 與 selector 在 starter 內 `theme/base/typography.css` 與 `design.md` 的 Typography Scale / Chapter & Section Numbering 段
-
-## Suitable For
-
-- product proposal / business plan
-- whitepaper / spec / requirements doc
-- academic monograph / long-form research report
-- editorial-format business report
-
-## Not Suitable For
-
-- slide deck（請改 page-geometry tokens 至 16:9 或另用 deck-oriented style pack）
-- poster / one-pager
-- marketing landing page
-
-## Related Packs
-
-- `claude-document` — warmer paper, Claude-like rhythm. Choose it when the document is closer to a working brief / spec / note than a formal monograph.
-
-## Apply To A Workspace
-
-Use `openpress` to initialize a target workspace with this pack. Then:
-
-1. Fill `title` / `subtitle` / `organization` in `openpress.config.mjs` and `document/index.tsx`.
-2. Ask `openpress` to choose the validation/export/render commands needed to confirm the workspace is healthy.
-3. Use `openpress` for the source-boundary decision; typical editable source areas are `document/chapters/**/*.mdx` for content, `document/index.tsx` for cover/TOC/back-cover, and `document/theme/tokens.css` for visual tokens.
-
-Content rules (table captions, figure numbering, etc.) live in `openpress-writing`; this skill does not redefine them.
-
-## Do / Don't
-
-**Do:**
-
-- 換 brand color：改 `tokens.css` 內 `--openpress-chart-gold` 或新增 `--openpress-brand-accent`
-- 換字體：改 `--openpress-font-serif` / `--openpress-font-body` 的字體棧；需要跨 mobile / iPad 穩定時，同步更新 `theme/fonts.css` 載入 webfont，不要只靠 `local(...)`
-- 加新 page kind（divider / appendix-cover）：在 `theme/page-surfaces/` 新增 CSS；已有 `chapter-opener` 可作書籍/教材章節 mini cover
-- 換編號樣式（一、二、 or §1.1）：改 `theme/base/typography.css` 的 `::before content`，搭 `@counter-style`
-- 改 page 尺寸（B5 / Letter / 投影片）：改 `tokens.css` 的 `--openpress-page-width` / `--openpress-page-height` / `--openpress-page-margin`
-
-**Don't:**
-
-- 不要把 inline emphasis color 改成自由色票（破壞語意系統）；新狀態色票要先補 `--openpress-status-*` token 再用
-- 不要在 `theme/base/typography.css` 內放單一 chart / specimen 的 CSS（那是 `document/components/<name>/` 的責任）
-- 不要為了 dense 內容把字級縮太小；A4 body 正文不應低於 9.5pt
-- 不要把 hairline 改成 2px 以上實線；style pack 的氣質就靠線細
-
-## 深入設計規則
-
-editorial-monograph 不單獨維護一份 reference/ 文件——所有規格都寫在 `starter/document/design.md` 內，跟著 starter 一起拷貝到 workspace 後變成該專案的 design document：
-
-- 第 1 節 風格目標與使用場景 — 目標 / 適用場景 / 角色定義
-- 第 2 節 Tokens — typography / color / spacing / page geometry / inline emphasis / chapter & section numbering
-- 第 3 節 Components — page surfaces / text components / tables / figures / charts
-- 第 4 節 CSS 權責
-
-Agent 套用 skill 後，這份檔案就成為該專案 `document/design.md` 的內容；之後 user 想客製，直接改 design.md，不用回頭改 skill。

package/template/skills/openpress/SKILL.md

@@ -1,114 +0,0 @@
----
-name: openpress
-description: Use when operating a open-press workspace or framework checkout through CLI commands, discovering project status, validating/exporting/rendering/PDF output, inspecting structure/issues, searching or safely replacing source text, managing pending @openpress-comment markers, or deciding which open-press skill owns a task.
----
-
-# open-press Core
-
-open-press owns the tool surface and delivery boundaries. **Use this skill first** when the task involves the CLI, workspace status, generated output, or deciding which specialist skill should take over.
-
-This skill is also the **single source of truth** for the source vs generated boundary. Other skills reference this section instead of re-listing paths.
-
-## Responsibilities
-
-- Choose safe open-press CLI commands.
-- Define the canonical source vs framework vs generated path boundary (see below).
-- Inspect workspace state before broad edits.
-- Open and manage the local workbench review loop.
-- Manage `@openpress-comment` markers (list, apply, resolve, clear).
-- Route domain work to the owning skill.
-- Require verification before declaring output ready.
-
-## Skill Routing
-
-open-press skills fall into three categories:
-
-1. **System operation skills**: how to operate open-press itself. `openpress` is the main entry point; lifecycle helpers cover init, update, and deploy.
-2. **Writing skills**: content strategy, suggested skeletons, language, tone, genre rules. They do not own CLI commands or validation depth.
-3. **Style pack skills**: reusable visual starters under `skills/<pack>/starter/`. They do not own workspace operation.
-
-| Skill | Owns |
-| --- | --- |
-| `openpress` | CLI, inspect/search/replace, source/generated boundary, validation/export/render/PDF command choice, `@openpress-comment` operations, skill routing |
-| `openpress-init` | First-time intake conversation, style-pack recommendation, metadata gathering, running `init`, handing off to writing/design |
-| `openpress-update` | Release upgrade flow: pulling new framework, CHANGELOG-driven migrations, post-upgrade verification |
-| `openpress-writing` | Reader-facing content, narrative, captions, factual boundaries, portable writing skill loading |
-| `openpress-document-hierarchy` | H1/H2/H3/H4 model, TOC depth, reader outline, appendix placement |
-| `openpress-design` | Workspace visual system: `document/theme/`, `document/components/`, PDF-safe layout |
-| `openpress-diagram-drawing` | Diagram semantics: nodes, arrows, labels, states, figure text |
-| `openpress-deploy` | Deploy config, preflight, dry run, public publish confirmation |
-| `openpress-style-pack-contributor` | Bundled packs under `skills/<pack>/starter/` (the upstream design, not workspace consumption) |
-| Portable writing skills (`chinese-ai-writing-polish`, `teaching-notes-writing`, …) | Language, tone, genre, learner-facing rules. Loaded via `openpress-writing` |
-
-## Source Boundary (canonical)
-
-Edit source, not generated output. **This list is the single authoritative version**; other skills link here.
-
-| Layer | Paths | Edit? |
-| --- | --- | --- |
-| Workspace source | `openpress.config.mjs`, `document/index.tsx`, `document/chapters/`, `document/design.md`, `document/theme/`, `document/components/`, `document/media/` | yes — domain skills |
-| Skill / pack source | `skills/<pack>/SKILL.md`, `skills/<pack>/starter/**`, other skill files under `skills/` | yes — `openpress-style-pack-contributor` for packs; skill maintainers for own skill |
-| Framework | `engine/`, `src/`, `tests/`, `docs/superpowers/`, `vite.config.ts`, `tsconfig.json`, `index.html` | yes — framework agents only |
-| Generated | `public/openpress/`, `dist-react/`, `.deploy/`, `.openpress/` | **never hand-edit** |
-
-If a workspace lacks `document/index.tsx`, run `node engine/cli.mjs migrate-to-react` before broad structural rewrites.
-
-If `memory/AGENTS.md` exists, read it before framework-level `AGENTS.md`; it usually marks a downstream document workspace where `document/` is git-ignored project content, not source you commit upstream.
-
-## Workflow
-
-1. Orient: read `AGENTS.md`, `memory/AGENTS.md` if present, and the relevant specialist skill.
-2. Inspect before broad edits with `inspect --json`, `search --json`, or `rg`.
-3. Route domain work to the owning skill instead of duplicating its rules.
-4. Edit only source paths in the owning area (see boundary table).
-5. Verify with the narrowest command that proves the claim.
-
-## Starting A New Workspace
-
-Route to `openpress-init` for the intake conversation. The CLI itself is:
-
-```bash
-node engine/cli.mjs init <target> --skill <pack-name>
-```
-
-Style packs are auto-discovered from `skills/<pack>/SKILL.md` where `starter/` exists.
-
-## Updating An Existing Workspace
-
-Route to `openpress-update` for release-driven upgrades.
-
-## @openpress-comment Operations
-
-Pending `@openpress-comment` markers are source markers, not UI-only notes. Apply them as small source edits close to the marker, then remove the marker only after the comment is resolved or explicitly cleared.
-
-Scope:
-
-- List, apply, resolve, clear markers.
-- Edit only the source file containing the marker (paths follow the Source Boundary table above).
-- Route domain-heavy rewrites to the owning skill (writing / hierarchy / design / diagram).
-- Do not rewrite unrelated sections while resolving one comment.
-
-Operations:
-
-| Need | Action |
-| --- | --- |
-| See pending comments | `rg "@openpress-comment" document -n` |
-| Apply one comment | Edit nearby source, then delete that marker line |
-| Clear one without applying | Delete that marker line only after the user asks |
-| Clear all comments | Use the comments tab or delete all marker lines only after explicit confirmation |
-| Comment is ambiguous | Ask for clarification and leave the marker in place |
-
-After applying, run `npm run openpress:validate`; also run `npm run openpress:render` when layout, visual output, or React/MDX structure changed.
-
-Common mistakes: do not clear a marker just because it was read; do not batch unrelated rewrites under one comment.
-
-## When To Read References
-
-- Read `references/cli-commands.md` when choosing commands, using search/replace, or explaining verification depth.
-- Read `references/local-review.md` when opening the workbench, using Document/Design System/Project views, or coordinating visual review before export/deploy.
-
-## Safety Rules
-
-- Preview broad replacements before applying them.
-- Do not publish without explicit user confirmation naming the target (handled by `openpress-deploy`).
-- Do not claim render, PDF, or deploy readiness without fresh command output.

package/template/skills/openpress/references/cli-commands.md

@@ -1,31 +0,0 @@
-# open-press CLI Commands
-
-Prefer package scripts in the framework checkout. Use direct `node engine/cli.mjs ...` when a downstream workspace lacks scripts or when a command has no script wrapper.
-
-| Need | Command |
-| --- | --- |
-| Top-level usage | `node engine/cli.mjs --help` |
-| Migrate legacy Markdown workspace to React/MDX | `node engine/cli.mjs migrate-to-react . --dry-run` |
-| Validate structure and delivery gates | `npm run openpress:validate` |
-| Export source to open-press JSON | `npm run openpress:export` |
-| Build React reader | `npm run openpress:render` |
-| Open local workbench | `npm run dev` |
-| Preview production build | `npm run openpress:preview` |
-| Generate PDF | `npm run openpress:pdf` |
-| Inspect structure/issues as JSON | `node engine/cli.mjs inspect . --json` |
-| Search public source text | `node engine/cli.mjs search . "<query>" --json` |
-| Search all workspace source classes | `node engine/cli.mjs search . "<query>" --json --scope all` |
-| List pending inspector comments | `rg "@openpress-comment" document -n` |
-| Preview replacement without writing | `node engine/cli.mjs replace . "<from>" "<to>" --json` |
-| Apply replacement after preview | `node engine/cli.mjs replace . "<from>" "<to>" --apply` |
-| Dry-run deploy workflow | `npm run openpress:deploy:dry-run` |
-| Publish after confirmation | use `openpress-deploy` |
-
-Command notes:
-
-- `search` and `replace` default to `--scope content`.
-- Add `--scope all` to also include `document/design.md`, component, media, and theme source.
-- Add `--case-sensitive` only when casing matters.
-- `replace` previews by default and writes only with `--apply`.
-- `replace` does not touch code blocks unless `--include-code` is provided.
-- Per-command `--help` is not implemented yet; use top-level usage and command error messages.

package/template/skills/openpress/references/local-review.md

@@ -1,43 +0,0 @@
-# Local Review
-
-open-press local review is the human feedback loop before PDF or public deploy.
-
-## Workflow
-
-```bash
-npm run openpress:export
-npm run dev
-```
-
-Use the URL printed by Vite. It is usually:
-
-```txt
-http://127.0.0.1:5173/?dev=1
-```
-
-If `5173` is occupied, use the fallback port reported by the dev server.
-
-## Workbench Views
-
-- **Document**: reader-facing document.
-- **Design System**: visual rules and specimens.
-- **Project**: source inventory, components, media, and status.
-
-After source edits:
-
-```bash
-npm run openpress:export
-npm run openpress:validate
-```
-
-For renderer-sensitive visual, bookmark, or layout changes, also run:
-
-```bash
-npm run openpress:render
-```
-
-## Safety Rules
-
-- A local preview is not deploy approval.
-- Do not hand-edit generated output to fix preview issues.
-- If preview is blank or stale, inspect export status, dev server output, and browser console before changing source content.

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

@@ -1,69 +0,0 @@
----
-name: openpress-deploy
-description: Use when preparing, configuring, checking, staging, or publishing a open-press document to public hosting, especially Cloudflare Pages, deploy setup, deploy buttons, deploy status, public release checks, or safe deployment workflow.
----
-
-# open-press Deploy
-
-open-press deploy owns the public-release gate. Use it only when the user asks to configure, inspect, dry-run, or publish a open-press document.
-
-## Responsibilities
-
-- Inspect deploy config in `openpress.config.mjs`.
-- Check target adapter, staging source, project name, and confirmation settings.
-- Run deploy preflight and dry runs.
-- Keep secrets out of source files.
-- Require explicit confirmation before publishing.
-- Report public URL and PDF URL after successful deploy.
-
-## Boundaries
-
-- `openpress` owns generic CLI usage, non-deploy validation, local review, and the source/generated boundary.
-- `openpress-writing` and `openpress-design` own document content and visual readiness.
-- This skill owns public target confirmation and deploy execution.
-
-## Public Deploy Rule
-
-Never publish without a clear confirmation that names the target project.
-
-Good confirmation shape:
-
-```txt
-This will publish the current open-press build to Cloudflare Pages project `<projectName>` from `<deploy.source>`.
-Do you want me to deploy now?
-```
-
-## Preflight
-
-Before real deploy, run the commands that prove the output is ready:
-
-```bash
-npm run openpress:export
-npm run openpress:validate
-npm run openpress:render
-npm run openpress:pdf
-```
-
-Also scan public-facing source for unfinished markers:
-
-```bash
-rg "\\[TODO:|\\[FIX:|\\[DRAFT:" document/chapters document/design.md
-```
-
-## Deploy Commands
-
-Dry run:
-
-```bash
-npm run openpress:deploy:dry-run
-```
-
-Publish after explicit confirmation:
-
-```bash
-npm run openpress:deploy -- --confirm
-```
-
-## When To Read References
-
-- Read `references/cloudflare-pages.md` when creating or repairing Cloudflare Pages config, project setup, Wrangler auth expectations, or UI deploy-button behavior.

package/template/skills/openpress-deploy/references/cloudflare-pages.md

@@ -1,51 +0,0 @@
-# Cloudflare Pages Deploy
-
-## Config Shape
-
-Write confirmed deploy settings into `openpress.config.mjs`:
-
-```js
-deploy: {
-  adapter: "cloudflare-pages",
-  source: ".deploy/<name>",
-  projectName: "<cloudflare-pages-project>",
-  commitDirty: false,
-  requiresConfirmation: true,
-}
-```
-
-Prefer an explicit `deploy.projectName`. If it is missing, ask the user to confirm the project name before writing config or creating a Cloudflare Pages project.
-
-## Setup Workflow
-
-1. Discover the workspace and load open-press config.
-2. Confirm the document is intended for public hosting.
-3. Inspect deploy config and derive the target:
-   - use explicit `deploy.projectName`;
-   - otherwise use a user-confirmed slug;
-   - do not invent and write a public target silently.
-4. Ask whether to create a new Cloudflare Pages project or use an existing one.
-5. Verify Wrangler auth outside source control.
-6. Run dry run before real deploy.
-
-If creating a new project, ask before running:
-
-```bash
-npx wrangler pages project create <projectName> --production-branch main
-```
-
-## Secrets
-
-Do not write API tokens or secrets into open-press config, Markdown, `design.md`, or skill files.
-
-## UI Deploy Button Contract
-
-A UI deploy button is a review surface over the CLI workflow. It should:
-
-- show target, source, and status before publishing;
-- block when `deploy.projectName` is missing;
-- require confirmation before posting to the deploy endpoint;
-- call the same CLI-backed deploy path;
-- show success URL, PDF URL, failure output, and dirty status.
-
-It must not create a second hidden deployment behavior.