@laitszkin/apollo-toolkit 3.14.9 → 3.15.0

package/CHANGELOG.md

@@ -2,6 +2,13 @@
 
 All notable changes to this repository are documented in this file.
 
+## [v3.15.0] - 2026-05-16
+
+### Changed
+
+- Move all skill templates from `references/` directories into skill-local `assets/` directories for clearer separation between reference docs and template files.
+- Update all internal references (SKILL.md, README.md, agents/openai.yaml, create-specs CLI tool) to point to the new `assets/` paths.
+
 ## [v3.14.9] - 2026-05-16
 
 ### Fixed

package/archive/SKILL.md

@@ -25,4 +25,4 @@ description: 將已完成的spec歸檔到 `docs/archive/` 下。當你需要將s
 
 ## 參考資料索引
 
-- `references/templates/readme.md`：README.md 模板
+- `assets/templates/readme.md`：README.md 模板

package/codex/codex-memory-manager/README.md

@@ -20,7 +20,7 @@ Persist durable user preferences from recent Codex conversations into reusable,
 ├── LICENSE
 ├── agents/
 │   └── openai.yaml
-├── references/
+├── assets/
 │   └── templates/
 │       └── memory-file.md
 ├── scripts/
@@ -57,7 +57,7 @@ apltk sync-codex-memory-index --agents-file ~/.codex/AGENTS.md --memory-dir ~/.c
 Use the bundled memory template when creating or refactoring category files:
 
 ```bash
-sed -n '1,200p' references/templates/memory-file.md
+sed -n '1,200p' assets/templates/memory-file.md
 ```
 
 ## License

package/codex/codex-memory-manager/SKILL.md

@@ -70,7 +70,7 @@ apltk extract-codex-conversations --lookback-minutes 1440
 - Prefer wording that captures a reusable choice pattern such as `Prefer X when Y` or `Do not do Z when Q`.
 - Strip or generalize project-specific nouns, module names, branch names, issue numbers, and niche scenario labels unless they are required to explain the durable preference.
 - Keep evidence notes concise and factual; they should justify the preference without turning the memory file into a project log.
-- Use the normalized structure from `references/templates/memory-file.md` inside each memory file:
+- Use the normalized structure from `assets/templates/memory-file.md` inside each memory file:
 
 ```md
 # User Memory - Engineering Workflow
@@ -140,4 +140,4 @@ apltk sync-codex-memory-index \
 
 Load only when needed:
 
-- `references/templates/memory-file.md`
+- `assets/templates/memory-file.md`

package/deep-research/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: deep-research
+description: >-
+    對特定內容進行深度搜索；
+    使用場景：在互聯網上查找資訊
+---
+
+## 目標
+
+在互聯網上深度搜索並查找需要的資訊，並驗證資訊正確性。
+
+## 驗收條件
+
+- 生成了包含所需資訊的完整deep research report。
+- deep research report 的內容已經被驗證並確認屬實
+
+## 工作流程
+
+### 1. 網絡搜索
+
+理解用戶需求。並調用外部工具，在互聯網上進行全面的搜索，盡可能獲得詳細的資訊。
+如果用戶需要查找的程式碼相關內容，且該技術棧、代碼庫是開源代碼倉庫，你需要將其 clone 到臨時目錄之中，並深入閱讀相關代碼從而給出最準確的回答。
+如果外部環境允許調用 subagents，建議通過並行調度 subagents 來完成搜索、閱讀等工作。
+
+### 2. 報告生成
+
+整理並通過網絡搜索驗證所有獲得的資訊，並製作一份全面的報告。
+你需要引用相關官方文檔或代碼片段佐證報告內容。

package/dist/lib/tools/create-specs.js

@@ -119,7 +119,7 @@ Options:
     }
     // Resolve template directory
     const sourceRoot = context.sourceRoot || node_path_1.default.resolve(__dirname, '..', '..', '..');
-    const templateDirRaw = parsed['template-dir'] || node_path_1.default.join(sourceRoot, 'spec', 'references', 'templates');
+    const templateDirRaw = parsed['template-dir'] || node_path_1.default.join(sourceRoot, 'spec', 'assets', 'templates');
     const templateDir = node_path_1.default.resolve(templateDirRaw);
     if (!node_fs_1.default.existsSync(templateDir)) {
         stderr.write(`Error: Template directory not found: ${templateDir}\n`);

package/docs-project/SKILL.md

@@ -30,4 +30,4 @@ description: >-
 根據上一步找到的所有遺漏或項目文檔與實際代碼脫節之處，制定文檔更新策略。使用模板之中所規範的格式，重寫項目文檔，並移除除必要文檔（如 `CHANGELOG.md`, `CONTRIBUTION.md` ）外的舊有說明文檔。
 
 ## 參考資料
-- `references/templates/standardized-docs-template.md` - 三類文檔的目標結構、分類規則與清理檢查表。
+- `assets/templates/standardized-docs-template.md` - 三類文檔的目標結構、分類規則與清理檢查表。

package/init-project-html/SKILL.md

@@ -30,7 +30,7 @@ description: 當你需要為項目初始化架構圖時，使用此技能。
 
 - `references/TEMPLATE_SPEC.md`：atlas 欄位、列舉和 CLI 寫入形狀速查表。
 - `references/definition.md`: 功能模塊和子模塊的詳細定義。
-- `references/architecture-page.template.html`: 模板html。
+- `assets/architecture-page.template.html`: 模板html。
 - `references/architecture.css`: 風格模板。
 - `sample-demo/`：完整示例輸出，用於理解基礎 atlas 的最終形態。
 - `apltk architecture --help` - cli 工具的指引指令。

package/lib/tools/create-specs.ts

@@ -125,7 +125,7 @@ Options:
 
   // Resolve template directory
   const sourceRoot = context.sourceRoot || path.resolve(__dirname, '..', '..', '..');
-  const templateDirRaw = (parsed['template-dir'] as string) || path.join(sourceRoot, 'spec', 'references', 'templates');
+  const templateDirRaw = (parsed['template-dir'] as string) || path.join(sourceRoot, 'spec', 'assets', 'templates');
   const templateDir = path.resolve(templateDirRaw);
 
   if (!fs.existsSync(templateDir)) {

package/novel-to-short-video/README.md

@@ -7,7 +7,7 @@ This skill will:
 - Select exactly one highest-impact, high-tension core segment from the novel
 - Ensure the selected segment forms a complete mini-story that works standalone
 - Keep one meaningful unresolved hook at the end to sustain curiosity
-- Create a pre-production plan first using `references/plan-template.md` (`docs/plans/<date>-<chapter>.md`)
+- Create a pre-production plan first using `assets/plan-template.md` (`docs/plans/<date>-<chapter>.md`)
 - Start image/voice/render steps only after explicit user approval of the plan
 - Generate a loop-closure narration script (opening and ending call back to each other)
 - Ensure `<project_dir>/roles/roles.json` exists before prompt generation; reuse existing roles and append only missing roles (schema in `references/roles-json.md`)
@@ -29,8 +29,9 @@ novel-to-short-video/
 ├── SKILL.md
 ├── agents/
 │   └── openai.yaml
+├── assets/
+│   └── plan-template.md
 ├── references/
-│   ├── plan-template.md
 │   └── roles-json.md
 ├── README.md
 └── LICENSE
@@ -52,7 +53,7 @@ novel-to-short-video/
 - One segment maps to one full video (segment-to-video 1:1)
 - Story is standalone (clear setup/conflict/turn/outcome) with one unresolved ending question
 - Plan file is created first: `<project_dir>/docs/plans/<YYYY-MM-DD>-<chapter_slug>.md`
-- Plan uses `references/plan-template.md`, and all placeholders are removed after filling
+- Plan uses `assets/plan-template.md`, and all placeholders are removed after filling
 - Role registry file: `<project_dir>/roles/roles.json` (shared between short-form and long-form workflows, reuses existing roles, appends only missing roles; schema in `references/roles-json.md`)
 - Ending line and final visuals tie back to the opening for loop closure
 - Beat-level effects are applied (`hook / escalation / climax / loop-closure`) with controlled intensity to avoid harming subtitle readability

package/novel-to-short-video/SKILL.md

@@ -57,7 +57,7 @@ If critical inputs are missing, ask concise follow-up questions.
   - `<project_dir>/docs/plans/<YYYY-MM-DD>-<chapter_slug>.md`
 - `chapter_slug` should come from the chapter name/number and be filesystem-safe.
 - Build the plan content from template file:
-  - `references/plan-template.md`
+  - `assets/plan-template.md`
 - The plan markdown must include:
   - selected highlight segment details,
   - narration script and beat-level timing for the full video,
@@ -215,7 +215,7 @@ Before finishing, verify all conditions:
 - exactly 1 highest-impact highlight segment selected
 - selected segment is understandable as a standalone mini-story
 - plan markdown exists in `docs/plans/` with date + chapter naming
-- plan content starts from `references/plan-template.md`
+- plan content starts from `assets/plan-template.md`
 - plan markdown includes the selected segment, beat/script details, standalone-story check, lingering-question design, and segment image generation list
 - plan markdown includes a beat-level special-effects map plus intensity guardrails
 - all bracketed placeholders/guidance are removed from the final filled plan

package/novel-to-short-video/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Novel to Short Video"
   short_description: "Turn the best novel segment into a looping 50-60s short video"
-  default_prompt: "Use $novel-to-short-video to extract the single most compelling segment from my novel, ensure it forms a self-contained mini-story while ending with lingering curiosity, create a plan markdown from references/plan-template.md under docs/plans with date+chapter naming, include beat-level audience-focus effects and a 3-4 chars/second narration pacing target in the plan, wait for my approval, then ensure <project_dir>/roles/roles.json exists first (create it if missing using references/roles-json.md), reuse existing role prompts, and only append missing roles before generating prompts/images, then generate storyboard images and voiceover, validate narration speed in 3-4 chars/second before render, and render a 50-60 second looping short video with controlled special effects while keeping the Remotion project editable."
+  default_prompt: "Use $novel-to-short-video to extract the single most compelling segment from my novel, ensure it forms a self-contained mini-story while ending with lingering curiosity, create a plan markdown from assets/plan-template.md under docs/plans with date+chapter naming, include beat-level audience-focus effects and a 3-4 chars/second narration pacing target in the plan, wait for my approval, then ensure <project_dir>/roles/roles.json exists first (create it if missing using references/roles-json.md), reuse existing role prompts, and only append missing roles before generating prompts/images, then generate storyboard images and voiceover, validate narration speed in 3-4 chars/second before render, and render a 50-60 second looping short video with controlled special effects while keeping the Remotion project editable."

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@laitszkin/apollo-toolkit",
-  "version": "3.14.9",
+  "version": "3.15.0",
   "description": "Apollo Toolkit npm installer for managed skill copying across Codex, OpenClaw, and Trae.",
   "license": "MIT",
   "author": "LaiTszKin",

package/spec/SKILL.md

@@ -38,12 +38,16 @@ description: 當你需要將用戶模糊的複雜需求拆解成有嚴格實作
 使用 `test-case-strategy` 這個技能，為任務制定基於測試的驗收條件，確保每一個任務在完成之後都能夠被驗證。
 同時，為需求制定驗收條件，確保用戶需求能夠被測試清晰地驗收、檢驗成果。
 
-### 5. 使用 `apltk` cli 工具協助完成 spec
+### 5. 查找開發文檔
+
+在開始撰寫 spec 之前，你需要先使用 `deep-research` 這個技能，按照當中的指引查找滿足用戶需求所需外部依賴的官方文檔或源代碼，確保後續實作階段的產出符合外部規範。
+
+### 6. 使用 `apltk` cli 工具協助完成 spec
 
 使用 cli 工具，產生 spec 的模板。將你的完整計劃填入到模板之中。
 如果該 spec 設計超過三個模塊，則需要創建 batch spec。
 
-### 6. 使用 `apltk` cli 工具協助完成 spec architecture diff
+### 7. 使用 `apltk` cli 工具協助完成 spec architecture diff
 
 通過 cli 工具生成完整的 architecture diff 讓用戶審閱本次 spec 的架構設計。
 
@@ -59,13 +63,13 @@ description: 當你需要將用戶模糊的複雜需求拆解成有嚴格實作
 ## 參考資料
 
 - `apltk create-specs` — spec 模板產生器 CLI 工具（TypeScript handler 取代原本的 Python create-specs）。
-- `references/templates/spec.md` - `spec.md` 的綁定模板。
-- `references/templates/tasks.md` - `tasks.md` 的綁定模板。
-- `references/templates/checklist.md` - `checklist.md` 的綁定模板。
-- `references/templates/contract.md` - `contract.md` 的綁定模板。
-- `references/templates/design.md` - `design.md` 的綁定模板。
-- `references/templates/coordination.md` - batch root 的 coordination 模板。
-- `references/templates/preparation.md` - batch root 的前置工作模板。
+- `assets/templates/spec.md` - `spec.md` 的綁定模板。
+- `assets/templates/tasks.md` - `tasks.md` 的綁定模板。
+- `assets/templates/checklist.md` - `checklist.md` 的綁定模板。
+- `assets/templates/contract.md` - `contract.md` 的綁定模板。
+- `assets/templates/design.md` - `design.md` 的綁定模板。
+- `assets/templates/coordination.md` - batch root 的 coordination 模板。
+- `assets/templates/preparation.md` - batch root 的前置工作模板。
 - `references/TEMPLATE_SPEC.md` - `apltk` cli工具相關格式指引。
 - `apltk create-specs --help` - spec生成相關cli工具的指引命令
 - `apltk architecture --help` - 架構圖生成相關cli工具的指引命令

package/spec/agents/openai.yaml

@@ -2,7 +2,7 @@ interface:
   display_name: "spec"
   short_description: "Generate shared feature spec, task, and checklist docs before coding"
   default_prompt: >-
-    Use $spec to create or update single-spec plans under docs/plans/<date>/<change_name>/ or parallel batches under docs/plans/<date>/<batch_name>/<change_name>/ with shared coordination.md and, only when specs cannot be parallel-safe without prior shared work, minimal non-business preparation.md; treat references/templates/*.md as binding format; member specs assume preparation finished—do not duplicate preparation tasks; surface collisions early and resolve ownership via coordination.md; fill BDD in spec.md; integrate $test-case-strategy into tasks/checklists.
+    Use $spec to create or update single-spec plans under docs/plans/<date>/<change_name>/ or parallel batches under docs/plans/<date>/<batch_name>/<change_name>/ with shared coordination.md and, only when specs cannot be parallel-safe without prior shared work, minimal non-business preparation.md; treat assets/templates/*.md as binding format; member specs assume preparation finished—do not duplicate preparation tasks; surface collisions early and resolve ownership via coordination.md; fill BDD in spec.md; integrate $test-case-strategy into tasks/checklists.
     **Critical layering:** design.md + contract.md are higher-level guiding context only (architecture + cite-backed external truth; coarse INT-### / EXT-### anchors). tasks.md MUST be the ONLY enumerated runnable queue with path-level edits and verification hooks—derive tasks FROM spec + design + contract WITHOUT mirroring checklist rows into design/contract; optionally cite INT/EXT on task lines for traceability—never duplicate task choreography inside design.md or contract.md.
     **Architecture overlay + diff:** When the spec touches atlas surface (feature/sub-module, edges, function/variable rows, dataflow, errors), declare proposed-after state ONLY via `apltk architecture --spec <spec_dir> …`. **Exact verbs/flags: ALWAYS `apltk architecture --help`.** Single-spec plans write `<spec_dir>/architecture_diff/atlas/` + rendered HTML under `<spec_dir>/architecture_diff/`. Batch plans resolve any member `--spec` path to the shared batch-root `architecture_diff/` beside `coordination.md`, so the whole batch keeps one architecture diff. NEVER hand-author `architecture_diff/**`.
     Completion standard for atlas work: every intended cross-feature edge, every feature-to-feature relationship, and every sub-module relationship in scope must be expressed precisely through the CLI output — not left implicit in prose. After mutations: `render --spec`, `validate --spec` (must be OK pre-approval). **`apltk architecture diff`** opens the paginated before/after viewer over all `docs/plans/**/architecture_diff/` vs base `resources/project-architecture/` — run it when atlas changed; verify modified/added/removed pairing and confirm the rendered graph contains the full intended relationship set.

package/video-production/README.md

@@ -14,7 +14,7 @@ A Codex skill for long-form video production (more than 10 minutes) that follows
 - Uses Remotion best practices to compose and render final output.
 - Requires timeline animation for long videos to improve audience retention.
 - Asks interactive clarifying questions when key information is missing (for example subtitle style, target duration, chapter pacing, and animation style).
-- Creates `<project_dir>/docs/long-video-plans/<YYYY-MM-DD>-<content_name>.md` from `references/plan-template.md` before generation and waits for user confirmation.
+- Creates `<project_dir>/docs/long-video-plans/<YYYY-MM-DD>-<content_name>.md` from `assets/plan-template.md` before generation and waits for user confirmation.
 - Uses a compact plan template with only four sections: meta data, reference text, images needed, and animation plan.
 - Defaults to one long-form video unless the user explicitly requests multi-episode output.
 - Preserves the Remotion project by default for later edits.
@@ -56,7 +56,7 @@ Return absolute paths for:
 
 - `SKILL.md` - workflow and execution rules
 - `agents/openai.yaml` - display metadata and default prompt
-- `references/plan-template.md` - pre-generation plan markdown template
+- `assets/plan-template.md` - pre-generation plan markdown template
 - `references/roles-json.md` - recurring-role schema for `roles.json`
 
 ## Quick Start

package/video-production/SKILL.md

@@ -136,7 +136,7 @@ Before generating images/audio/subtitles/video:
 
 - create directory `<project_dir>/docs/long-video-plans/` if missing
 - create a plan file named `<YYYY-MM-DD>-<content_name>.md`
-- load the reference template at `references/plan-template.md`
+- load the reference template at `assets/plan-template.md`
 - copy the template into the plan file first, then fill it
 - use local date for `YYYY-MM-DD`; sanitize `content_name` for filename safety
 - keep this long-video plan location separate from short-video plans (`<project_dir>/docs/plans/`)

package/video-production/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Video Production"
   short_description: "Generate 16:9 long-form videos with plan confirmation, fresh images, and timeline animations"
-  default_prompt: "Use $video-production to produce long-form videos (more than 10 minutes) by following user instructions. For text inputs, extract a coherent long-form story arc, split it into timed chapters, and keep final output at 16:9 (default 1920x1080). Before generating or updating prompts, detect recurring roles and ensure <project_dir>/roles/roles.json exists first (create it if missing using references/roles-json.md), then reuse existing role prompt skeletons and generate new role entries only for undefined roles using the supported JSON prompt schema. Do not reuse previously generated storyboard pictures; generate fresh storyboard images for each run unless the user supplies external assets. If required details are missing, ask interactive clarifying questions first (for example target duration, chapter pacing, subtitle style, voice, animation style, or role prompt source). Before any generation starts, create a plan markdown at <project_dir>/docs/long-video-plans/<YYYY-MM-DD>-<content_name>.md from references/plan-template.md with only these sections: meta data, reference text, images needed to be generated, and animation plan for audience retention. In the reference text section, refer to source locations only and do not embed full long text. Replace all square-bracket placeholders with concrete content, remove placeholder/instruction text, and then wait for explicit user confirmation. Do not ask whether output should be single or multi-episode; infer from the user request (default to single unless episodes are explicitly requested). Use docs-to-voice when audio/subtitles are missing and remotion-best-practices for final assembly. The final render must include timeline animations to maintain audience focus. Keep the Remotion workspace and ensure its .gitignore excludes dependency/build/cache artifacts (such as node_modules/) so git repositories stay clean."
+  default_prompt: "Use $video-production to produce long-form videos (more than 10 minutes) by following user instructions. For text inputs, extract a coherent long-form story arc, split it into timed chapters, and keep final output at 16:9 (default 1920x1080). Before generating or updating prompts, detect recurring roles and ensure <project_dir>/roles/roles.json exists first (create it if missing using references/roles-json.md), then reuse existing role prompt skeletons and generate new role entries only for undefined roles using the supported JSON prompt schema. Do not reuse previously generated storyboard pictures; generate fresh storyboard images for each run unless the user supplies external assets. If required details are missing, ask interactive clarifying questions first (for example target duration, chapter pacing, subtitle style, voice, animation style, or role prompt source). Before any generation starts, create a plan markdown at <project_dir>/docs/long-video-plans/<YYYY-MM-DD>-<content_name>.md from assets/plan-template.md with only these sections: meta data, reference text, images needed to be generated, and animation plan for audience retention. In the reference text section, refer to source locations only and do not embed full long text. Replace all square-bracket placeholders with concrete content, remove placeholder/instruction text, and then wait for explicit user confirmation. Do not ask whether output should be single or multi-episode; infer from the user request (default to single unless episodes are explicitly requested). Use docs-to-voice when audio/subtitles are missing and remotion-best-practices for final assembly. The final render must include timeline animations to maintain audience focus. Keep the Remotion workspace and ensure its .gitignore excludes dependency/build/cache artifacts (such as node_modules/) so git repositories stay clean."

package/deep-research-topics/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 LaiTszKin
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

package/deep-research-topics/README.md

@@ -1,43 +0,0 @@
-# Deep Research Topics
-
-`deep-research-topics` is a reusable research skill for producing evidence-based topic deliverables.
-
-It helps an agent:
-
-1. Understand and scope a research request.
-2. Break the topic into concrete research questions.
-3. Perform deep research with authoritative sources.
-4. Read workspace files to match the existing writing style.
-5. Produce a final file in PDF by default, or Word/slides output when requested.
-
-## Dependency skills
-
-- `pdf`: default output format
-- `doc`: optional Word output when requested
-- `slides`: optional slide output when requested
-
-## Language behavior
-
-- Default output language: Chinese
-- If the user requests another language, follow the user request.
-- If the workspace already has a dominant language and the user does not override it, follow the workspace language.
-- Use characters and formatting that are safe for Chinese or mixed CJK output.
-
-## Repository layout
-
-- `SKILL.md`: trigger rules, workflow, and dependency contract
-- `agents/openai.yaml`: agent-facing metadata
-
-## Typical use cases
-
-Use this skill for:
-
-- topic briefings
-- background research memos
-- literature scans
-- competitive or landscape research
-- decision-support reports
-
-## License
-
-MIT. See `LICENSE`.

package/deep-research-topics/SKILL.md

@@ -1,80 +0,0 @@
----
-name: deep-research-topics
-description: "Research specific topics deeply and turn them into evidence-based deliverables. Use when users need a structured research report, briefing, background memo, literature scan, or decision-support document grounded in authoritative sources. Default to PDF output, but switch to DOCX or PPTX when the user explicitly asks for those formats."
----
-
-# Deep Research Topics
-
-## Dependencies
-
-- Required: none.
-- Conditional: `pdf` by default, `doc` when Word output is requested, and `slides` when slides are requested.
-- Optional: none.
-- Fallback: If the required output skill is unavailable, stop and report the missing dependency instead of inventing another export path.
-
-## Standards
-
-- Evidence: Prioritize authoritative sources, verify time-sensitive claims, and keep traceable notes for important facts.
-- Execution: Define research questions, inspect workspace style, draft the content, then hand off to exactly one output skill unless multiple formats are explicitly requested.
-- Quality: Distinguish verified facts from analysis or inference and call out limitations, conflicts, or stale data explicitly.
-- Output: Deliver a polished research file with clear sections, citations, dates, and source links.
-
-## Required Workflow
-
-1. Understand the request
-   - Identify the research goal, target audience, decision context, time range, geography, and required depth.
-   - Extract explicit deliverable requirements such as format, sections, length, and citation expectations.
-2. Break the topic into research questions
-   - Define the topic boundary and key terms.
-   - Split the work into the main subtopics, competing views, recent developments, supporting data, and open questions.
-   - Turn vague requests into a concrete research checklist before drafting.
-3. Perform deep research
-   - Prioritize authoritative sources: official documentation, government or regulator materials, academic papers, standards bodies, company filings, and well-established institutions.
-   - Use secondary reporting only to triangulate, summarize, or discover primary sources.
-   - Verify time-sensitive facts with current sources and record publication dates.
-   - Keep traceable notes for claims, metrics, dates, and citations.
-4. Read workspace files before writing
-   - Inspect relevant files in the current workspace to learn the existing language, tone, terminology, heading structure, table style, and citation pattern.
-   - Reuse established structure and vocabulary when a clear house style already exists.
-   - If no relevant files exist, use a clean evidence-first structure.
-5. Decide output language and character compatibility
-   - Default to Chinese.
-   - If the user explicitly requests another language, follow the user request.
-   - Otherwise, if the workspace already has a dominant language, follow that language for consistency.
-   - Use characters, punctuation, and fonts that are safe for Chinese or mixed CJK output. Avoid unusual glyphs that commonly break in PDF, DOCX, or PPTX rendering.
-6. Draft the deliverable
-   - Include an executive summary or research overview.
-   - Organize findings by research question or subtopic.
-   - Distinguish verified facts from analysis or inference.
-   - Include citations, dates, and source links for important claims.
-   - State limitations, unresolved questions, and conflicts in the evidence when they exist.
-7. Hand off to the selected output skill
-   - Use `pdf` by default.
-   - Switch to `doc` or `slides` only when requested or clearly required by the workspace convention.
-   - Preserve headings, tables, citations, and appendix material during the handoff.
-   - If the selected output skill is `pdf`, require PDF visual QA before completion:
-     - open the rendered PDF locally
-     - capture temporary screenshots from representative pages
-     - inspect layout, spacing, glyph rendering, tables, and dense text blocks
-     - regenerate if the visual result is wrong or unattractive
-     - delete all temporary QA screenshots after the final PDF passes inspection unless the user explicitly asks to keep them
-
-## Source Quality Rules
-
-- Prefer primary and authoritative sources over commentary.
-- Use multiple high-quality sources when the claim is important or contested.
-- Do not guess when evidence is incomplete.
-- Call out uncertainty, disagreement, or stale data explicitly.
-- Keep citations specific enough that another agent can trace them quickly.
-
-## Output Expectations
-
-The final deliverable should usually contain:
-
-1. Title and scope
-2. Executive summary
-3. Research questions or evaluation framework
-4. Findings by section
-5. Evidence and citations
-6. Implications, recommendations, or next steps when requested
-7. Limitations or open questions

package/deep-research-topics/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Deep Research Topics"
-  short_description: "Research a topic deeply and deliver a file-backed briefing"
-  default_prompt: "Use $deep-research-topics to understand the user's research goal, break the topic into concrete research questions, gather high-credibility and authoritative sources, inspect relevant workspace files for language and style consistency, and produce a polished deliverable in PDF by default or DOCX/PPTX when the user requests those formats."