@cyber-dash-tech/revela 0.18.4 → 0.18.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cyber-dash-tech/revela",
-  "version": "0.18.4",
+  "version": "0.18.5",
   "description": "OpenCode plugin for trusted narrative artifacts from local sources, research, and evidence",
   "type": "module",
   "main": "./index.ts",

package/plugins/revela/.mcp.json

@@ -2,7 +2,7 @@
   "mcpServers": {
     "revela": {
       "command": "npx",
-      "args": ["-y", "@cyber-dash-tech/revela@0.18.4", "mcp"]
+      "args": ["-y", "@cyber-dash-tech/revela@0.18.5", "mcp"]
     }
   }
 }

package/plugins/revela/mcp/revela-server.ts

@@ -283,7 +283,7 @@ const tools = [
     inputSchema: objectSchema({
       workspaceRoot: stringProp("Optional workspace root."),
       file: requiredStringProp("Workspace-relative or absolute HTML deck path."),
-      bridge: enumProp(["codex-exec"], "Prompt bridge for browser Comment and Apply Fix interactions."),
+      bridge: enumProp(["codex-exec"], "Prompt bridge for browser saved-comment Apply interactions."),
       openBrowser: booleanProp("Whether the tool should open the browser itself. Defaults to true when omitted."),
     }, ["file"]),
   },

package/plugins/revela/skills/revela-export/SKILL.md

@@ -7,6 +7,23 @@ description: Export Revela deck artifacts from Codex to PDF, PPTX, or PNG.
 
 Use this skill when the user asks to export a Revela deck.
 
+## Contract
+
+- Export converts generated HTML decks to PDF, PPTX, or per-slide PNG files.
+- The target deck should be export-ready before export.
+- If the latest visible QA result has hard errors, repair them before treating the deck as export-ready.
+
+## Preconditions
+
+- A target `decks/*.html` file exists.
+- The requested format is `pdf`, `pptx`, or `png`.
+- Latest QA should have no hard errors.
+
+## Inputs
+
+- HTML deck path.
+- Export format: `pdf`, `pptx`, or `png`.
+
 ## Workflow
 
 1. Resolve the target HTML deck path.
@@ -15,6 +32,18 @@ Use this skill when the user asks to export a Revela deck.
 4. For per-slide PNG files, call `revela_export_png`.
 5. Report output path(s), slide count, or export errors.
 
+## Outputs
+
+- PDF path.
+- PPTX path.
+- Per-slide PNG directory/path list.
+- Slide count or export error.
+
+## Must Not
+
+- Do not claim a deck with hard QA errors is export-ready.
+- Do not silently ignore browser launch, screenshot, PDF, PPTX, or PNG export failures.
+
 `revela_run_deck_qa`, `revela_export_pdf`, `revela_export_pptx`, and `revela_export_png` may launch a browser. In sandboxed Codex sessions, request user-approved command escalation when the browser cannot start inside the default sandbox.
 
-Post-write hooks and explicit QA tools surface Artifact QA failures. If the latest visible QA result has hard errors, repair them before treating the deck as export-ready.
+Post-write hooks and explicit QA tools surface Artifact QA failures.

package/plugins/revela/skills/revela-helper/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: revela-helper
+description: Explain Revela, inspect the current Revela workspace status, and report active design/domain guidance in Codex.
+---
+
+# Revela Helper
+
+Use this skill when the user asks what Revela is, what the current workspace state is, which design or domain is active, which Revela capabilities are available, or what the next step should be.
+
+## Contract
+
+- This is a read-only helper and orientation surface.
+- It may inspect runtime, design, domain, and workspace artifact status.
+- It must not perform research, write files, create `deck-plan.md`, generate decks, open Review UI, or export artifacts.
+- Keep the answer short and operational.
+
+## Preconditions
+
+- None. This skill can run in any workspace.
+
+## Inputs
+
+- User questions about Revela, current status, active design/domain, or next workflow step.
+- Optional workspace context such as existing `researches/`, `deck-plan.md`, `decks/*.html`, and `assets/`.
+
+## Required Tools
+
+1. Call `revela_doctor` to inspect the running Revela runtime and workspace.
+2. Call `revela_design_list` to identify the active design and available designs.
+3. Call `revela_domain_list` to identify the active domain and available domains.
+4. Use `revela_design_read` or `revela_domain_read` only when the user asks for design/domain detail or when a concise summary is needed to recommend the next workflow.
+
+## Output
+
+Report:
+
+- What Revela does: trusted, traceable, deck-first decision artifacts from local materials, research, data, and user intent.
+- Runtime/version status from `revela_doctor`.
+- Active design and active domain.
+- Workspace artifact status: whether `researches/`, `deck-plan.md`, `decks/*.html`, and `assets/` appear available.
+- Recommended next step: `revela-research`, `revela-make-deck`, `revela-review`, or `revela-export`.
+
+## Must Not
+
+- Do not write or patch files.
+- Do not do external web research.
+- Do not generate or repair `deck-plan.md`.
+- Do not generate, review, patch, or export deck artifacts.

package/plugins/revela/skills/revela-make-deck/SKILL.md

@@ -1,32 +1,110 @@
 ---
 name: revela-make-deck
-description: Plan and generate Revela deck artifacts in Codex from deck-plan files and source-linked materials.
+description: Plan and generate Revela HTML deck artifacts in Codex from researches, workspace materials, active design, and deck-plan files.
 ---
 
 # Revela Make Deck
 
-Use this skill when the user asks to plan, make, generate, or update a Revela deck.
+Use this skill when the user asks to plan, make, generate, or update a Revela deck. This skill owns both the Plan phase (`deck-plan.md`) and the Render phase (`decks/*.html`).
 
-## Source Authority
+## Contract
 
 - Deck execution planning comes from canonical `deck-plan.md`.
 - Local materials, material reviews, `researches/`, `assets/`, and user intent provide source context.
+- Active/requested design tools define valid layouts, slots, components, nesting hints, and HTML writing rules.
+- Active/requested domain guidance may inform communication framing, but it is not source evidence.
 - Generated artifacts live under `decks/*.html`.
 - Do not require a Narrative Vault before planning or generating a deck.
+- Do not skip `deck-plan.md` for normal deck generation.
 
-## Workflow
+## Preconditions
 
-1. For planning requests, inspect local materials/reviews/research, then write or repair `deck-plan.md` directly. Do not use structured upsert tools for normal plan authoring.
-2. Call `revela_design_list`, `revela_design_read` with `section: "rules"`, and `revela_design_inventory` before selecting layouts/components; use the returned layout slots and component nesting hints in `deck-plan.md`.
-3. Call `revela_read_deck_plan` after writing or repairing `deck-plan.md`. If diagnostics report layout, slot, component, `children`, or `sourceLinks` issues, patch the Markdown directly and call `revela_read_deck_plan` again.
-4. Call `revela_read_deck_plan` before HTML generation and follow the current projection. Read `htmlWritingBatches` from the result before any HTML write. `revela_read_deck_plan` is QA/diagnostics, not a writer.
-5. For new HTML files, call `revela_create_deck_foundation`.
-6. Before patching slide HTML, read the specific layouts/components with `revela_design_read_layout` and `revela_design_read_component`; fetch chart rules before ECharts.
-7. Patch slides into the foundation between Revela slide markers. Preserve positive 1-based `data-slide-index` values. Every slide must have exactly one direct `.slide-canvas` child.
-8. Generate one `htmlWritingBatches` entry at a time. A single HTML write/edit/apply_patch may add or rewrite at most 5 slide sections. If a chapter is longer than 5 slides, use the consecutive batch parts returned by `revela_read_deck_plan`.
-9. Keep the HTML valid after each write.
-10. After every HTML write, call `revela_run_deck_qa` and repair hard errors before review or export.
+- Recommended: source-linked `researches/**/*.md` and reviewed workspace materials exist.
+- If research is thin, the user may explicitly ask to continue with limited materials; then record source limitations in `deck-plan.md`.
+- An active or user-requested design must be readable.
+
+## Inputs
+
+- `researches/**/*.md`
+- Reviewed workspace materials and material review records.
+- `assets/`
+- User deck objective, audience, and constraints.
+- Existing `deck-plan.md` when present.
+- Active/requested design and optional active/requested domain.
+
+## Required Design Tools
+
+Before Plan phase authoring:
+
+1. Call `revela_design_list`.
+2. Call `revela_design_read` with `section: "rules"` for the active/requested design.
+3. Call `revela_design_inventory`.
+
+Before Render phase HTML writing:
+
+1. Call `revela_read_deck_plan`.
+2. Read the returned `htmlWritingBatches`.
+3. Call `revela_design_read_layout` for each layout used in the current batch.
+4. Call `revela_design_read_component` for each component used in the current batch.
+5. Fetch chart rules before creating or modifying ECharts.
+
+## Plan Phase
+
+Use this phase when the user asks for a plan, outline, deck-plan, or when a make request lacks a valid `deck-plan.md`.
+
+1. Inspect local materials, material reviews, existing research findings, assets, and user intent.
+2. Read active/requested domain guidance only as framing context; never cite it as evidence.
+3. Use design inventory to choose valid layouts, slots, components, and component nesting.
+4. Write or repair `deck-plan.md` directly. Do not use structured upsert tools for normal plan authoring.
+5. Call `revela_read_deck_plan` after writing or repairing `deck-plan.md`.
+6. If diagnostics report layout, slot, component, `children`, or `sourceLinks` issues, patch the Markdown directly and call `revela_read_deck_plan` again.
 
 ## Deck Plan Requirements
 
-Every normal deck plan should include Cover, Table of Contents, and Closing. Use 3-5 chapter headings, explicit slide ranges, and `---` slide separators under `## Slides`. Each slide block should have slide-local metadata followed by `#### Content Plan`, `#### Source Links` for materials/findings/assets/URLs, and `#### Design Plan` for layout, component plan, visual intent, placement notes, and render notes. Use unresolved inputs, source limitations, and user review notes instead of AI-authored caveat/risk judgement. Use `box.children` when multiple child components support one semantic idea; do not duplicate the same child as both nested and top-level.
+Every normal deck plan should include Cover, Table of Contents, and Closing. Use 3-5 chapter headings, explicit slide ranges, and `---` slide separators under `## Slides`.
+
+Each slide block must include:
+
+- Slide title and role when relevant.
+- `#### Content Plan`
+- `#### Source Links` for materials, findings, assets, URLs, and caveats.
+- `#### Design Plan`
+- Selected layout from design inventory.
+- Component plan using component names from design inventory.
+- Valid slots from the selected layout.
+- Valid component nesting hints, including `box.children` when multiple child components support one semantic idea.
+- Unresolved inputs, source limitations, and user review notes instead of AI-authored caveat/risk judgement.
+
+Do not duplicate the same child as both nested and top-level.
+
+## Render Phase
+
+Use this phase when the user asks to make, generate, render, or update an HTML deck.
+
+1. Call `revela_read_deck_plan` before HTML generation and follow the current projection.
+2. Read `htmlWritingBatches` before any HTML write. `revela_read_deck_plan` is QA/diagnostics, not a writer.
+3. For new HTML files, call `revela_create_deck_foundation`.
+4. Generate one `htmlWritingBatches` entry at a time.
+5. A single HTML write/edit/apply_patch may add or rewrite at most 5 slide sections.
+6. If a chapter is longer than 5 slides, use the consecutive batch parts returned by `revela_read_deck_plan`.
+7. Patch slides into the foundation between Revela slide markers.
+8. Preserve positive 1-based `data-slide-index` values.
+9. Every slide must have exactly one direct `.slide-canvas` child.
+10. Keep the HTML valid after each write.
+11. After every HTML write, call `revela_run_deck_qa` and repair hard errors before continuing, review, or export.
+
+## Outputs
+
+- Plan-only request: `deck-plan.md`.
+- Make/render request: `deck-plan.md` and `decks/*.html`.
+- QA status and unresolved source/design limitations.
+
+## Must Not
+
+- Do not skip `deck-plan.md` for normal decks.
+- Do not use design inventory names, slots, or components that were not returned by the active/requested design tools.
+- Do not use a slot that does not belong to the selected layout.
+- Do not patch more than 5 slide sections in one HTML write.
+- Do not invent source links, quotes, URLs, page references, caveats, or licenses.
+- Do not write remote image candidates directly into deck HTML; save them as workspace assets first.
+- Do not require a Narrative Vault.

package/plugins/revela/skills/revela-research/SKILL.md

@@ -1,29 +1,71 @@
 ---
 name: revela-research
-description: Research source-linked findings for a Revela deck plan while preserving explicit source boundaries.
+description: Research workspace materials and public sources for a Revela deck objective, using active domain guidance and saving source-linked findings.
 ---
 
 # Revela Research
 
-Use this skill when the user asks to research missing deck inputs, gather public support, save findings, or find source-linked examples/assets for a deck.
+Use this skill when the user asks to start from a goal, inspect local materials, research missing inputs, gather public support, save findings, or find source-linked examples/assets for a deck.
 
 ## Contract
 
-- Research output is saved under `researches/**/*.md` for deck-plan use.
-- Do not bind findings into a Narrative Vault or canonical evidence graph.
-- Do not create deck artifacts during research.
+- Research is the source-preparation workflow for Codex Revela.
+- Research output is saved under `researches/**/*.md` for later `deck-plan.md` use.
+- Local materials are only usable after direct text review or extracted read-view review.
+- Active/requested domain guidance informs audience, decision framing, claim standards, evidence expectations, objection/risk interpretation, and research-gap priority.
+- Domain guidance is not evidence and must never be cited as proof for factual claims.
+- Do not create `deck-plan.md`, deck artifacts, a Narrative Vault, or canonical evidence bindings during research.
 - Do not invent URLs, quotes, page references, numbers, caveats, or licenses.
 
-## Workflow
+## Preconditions
+
+- The user provides at least one of: objective, topic, audience, decision/action, source materials, or deck intent.
+- If intent is unclear, inspect the workspace first and ask only the smallest missing high-impact questions.
+
+## Inputs
+
+- User objective, constraints, audience, decision/action, and language preference when available.
+- Workspace materials, extracted material read views, existing `researches/**/*.md`, existing `deck-plan.md`, and `assets/`.
+- Active or user-requested domain guidance.
+- Optional external public sources when needed and allowed.
+
+## Required Tool Order
+
+1. Call `revela_domain_list`.
+2. Call `revela_domain_read` for the active domain or user-requested domain.
+3. Call `revela_prepare_local_materials`.
+4. For Office/PDF sources, read the provided `allowedReadPath` / `read_view_path`; if missing, call `revela_extract_document_materials`.
+5. Read original text/Markdown/CSV files or extracted read views before treating a material as usable.
+6. Call `revela_record_material_review` for each reviewed Office/PDF source.
+7. Call `revela_check_material_intake` before reporting research readiness.
+8. Use external research only for public facts, user-authorized questions, or gaps not covered by local materials.
+9. Save useful findings with `revela_research_save`.
 
-1. Inspect material intake status, material review files, existing `researches/**/*.md`, and `deck-plan.md` when present.
-2. Identify the smallest research tasks needed for the deck objective: market facts, benchmarks, examples, source quotes, images/logos/screenshots, or caveats.
-3. Use external research only for public facts or user-authorized questions.
-4. Save useful findings with `revela_research_save`.
-5. Each finding should include source URL/path, quote/snippet, what it supports, what it does not support, caveat, date checked, and optional image leads.
-6. If a finding is context only, label it as context and do not present it as proof.
+## Finding Requirements
 
-## Report
+Each saved finding should include:
 
-- Start with `Research: completed`.
-- List saved findings paths, source limitations, unresolved inputs, and whether `/revela plan --deck` can proceed.
+- Source URL or workspace path.
+- Quote/snippet or explicit note when no exact quote is available.
+- What it supports.
+- What it does not support.
+- Caveat or limitation.
+- Date checked.
+- Optional image/logo/screenshot leads with known source and license/attribution status.
+
+If a finding is context only, label it as context and do not present it as proof.
+
+## Outputs
+
+- `researches/{topic}/{filename}.md`
+- Material review records for reviewed Office/PDF sources.
+- Source limitations and unresolved gaps.
+- A clear statement of whether `revela-make-deck` can proceed or whether more research is needed.
+
+## Must Not
+
+- Do not generate `revela-narrative/`.
+- Do not write `deck-plan.md`.
+- Do not write `decks/*.html`.
+- Do not bind findings into a Narrative Vault or canonical evidence graph.
+- Do not treat domain guidance as source evidence.

package/plugins/revela/skills/{revela-review-deck → revela-review}/SKILL.md

@@ -1,21 +1,42 @@
 ---
-name: revela-review-deck
-description: Review Revela deck artifacts in Codex for technical validity and targeted deck edits.
+name: revela-review
+description: Open the Revela Review UI or read deck diagnostics for generated HTML deck artifacts in Codex.
 ---
 
-# Revela Review Deck
+# Revela Review
 
 Use this skill when the user asks to review, diagnose, QA, or refine a generated Revela deck.
 
+## Contract
+
+- Review is the post-artifact surface for generated `decks/*.html`.
+- A plain review request opens the Review UI.
+- Diagnostics are read explicitly when the user asks for QA details, export readiness, or no-GUI output.
+- Review UI is QA + Leave Comment / Apply. Insight/Inspect is removed from the public Review path.
+
+## Preconditions
+
+- A target `decks/*.html` file exists.
+- If multiple deck candidates exist and the user did not specify one, choose the most recent or most clearly requested deck and state the choice.
+
+## Inputs
+
+- HTML deck path.
+- Optional user review/refine intent.
+
 ## Workflow
 
 1. Resolve the target `decks/*.html` file from the user request or unambiguous workspace state.
 2. For a plain review request, call `revela_review_deck_open` and let the tool open the browser by default.
 3. Use `revela_review_deck_read`, normally with `format: "markdown"`, only when the user explicitly asks for diagnostics, QA details, export readiness, or no-GUI output.
-4. Review UI is QA + Comment/Apply Fix. Insight/Inspect is removed.
-5. Do not call `revela_run_deck_qa` separately for a normal Review UI open.
-6. Pure visual/layout/export fixes may patch artifacts directly when the user asks for a change, but read active design rules first with `revela_design_read` using `section: "rules"`.
-7. Content changes that affect the deck argument should update `deck-plan.md` first, then remake the deck.
+4. Do not call `revela_run_deck_qa` separately for a normal Review UI open.
+5. Pure visual/layout/export fixes may patch artifacts directly when the user asks for a change, but read active design rules first with `revela_design_read` using `section: "rules"`.
+6. Content changes that affect the deck argument should update `deck-plan.md` first, then remake the deck.
+
+## Outputs
+
+- Review UI URL/open state.
+- Or Markdown/JSON diagnostics and current readiness summary.
 
 ## QA Notes
 

package/plugins/revela/skills/revela-design/SKILL.md

@@ -1,46 +0,0 @@
----
-name: revela-design
-description: Use Revela design guidance in Codex for deck planning and artifact generation.
----
-
-# Revela Design
-
-Use this skill when the user asks about Revela designs or when generating deck HTML.
-
-## Workflow
-
-1. Call `revela_design_list` to inspect installed designs.
-2. Call `revela_design_read` with `section: "rules"` before writing or patching `decks/*.html`; this records the Codex hook context required for deck writes.
-3. Call `revela_design_inventory` before authoring or repairing `deck-plan.md` so planned layout names, slots, component names, and nesting hints come from the active design. Write slide plan Markdown directly, then call `revela_read_deck_plan` for diagnostics.
-4. Read required details with `revela_design_read_layout` and `revela_design_read_component` before writing slide HTML that uses those layouts/components.
-5. When the user asks to switch designs for future work, call `revela_design_activate` with the requested design name, then read the active design again.
-6. For one-off deck generation with a requested design, read that design by name, call `revela_design_inventory` with that name, and pass `designName` to `revela_create_deck_foundation` without changing active design unless the user asked to switch.
-7. Use the current simplified built-in design grammar: `box`, `text-panel`, `media`, `echart-panel`, `data-table`, `steps`, `roadmap-horizontal`, `roadmap-vertical`, `hero`, `stat-card`, `quote`, `toc`, `page-number`, and `brand-watermark`.
-8. Fetch chart/design guidance before creating ECharts or complex layouts.
-9. Do not invent unsupported component names.
-
-Deck HTML must keep exactly one direct `.slide-canvas` child inside every `<section class="slide" ...>`; place `.page` or layout containers inside `.slide-canvas`, not directly under `.slide`.
-
-Design changes are visual/artifact-level unless they change claim meaning, evidence boundaries, decision, or recommendation.
-
-## Inventory-First Planning
-
-Deck planning uses design vocabulary before HTML. Inspect the inventory, choose a valid layout for each slide, and choose valid component names for each planned element. Every top-level component plan must use a `slot` returned by the selected layout's inventory entry, plus a non-empty kebab-case `position` such as `left-top`, `left-middle`, `right-bottom`, `center`, or `overlay-top-right`.
-
-Use `box` as the semantic container when several child components support one idea. Put children under `box.children`; do not repeat those child components as separate top-level component plan entries. `hero` is fullbleed-only, while `page-number` and `brand-watermark` are utilities.
-
-Use `placementNote` for natural-language placement detail when slot and position are not enough. Slot and position are planning anchors; before HTML generation, fetch the actual layout/component definitions and implement the final structure with the design's CSS and markup.
-
-## Creating Or Editing Designs
-
-When the user asks to create a new design, use `starter` as the default base design unless they specify another base. Interview the user before saving anything: collect visual references such as images, webpages, brands, decks, or text descriptions, plus must-have and must-avoid constraints. Summarize the design brief and visual schema, then wait for the user to confirm before creating files.
-
-After confirmation, read the base design with `revela_design_read`. Generate complete `DESIGN.md` and complete `preview.html` content, then call `revela_design_draft_create` to save a workspace-local draft under `.revela/drafts/designs/<name>/`. Always call `revela_design_draft_validate` after draft creation or overwrite. The direct registry tools `revela_design_create` and `revela_design_validate` remain available for existing workflows, but Codex design authoring should use the draft workflow before install.
-
-Install the draft globally only after the user confirms the validated draft should be installed. Call `revela_design_draft_install` to copy the draft into the user-level design registry. If a user-level design already exists, pass `overwrite: true` only after the user confirms replacement. In sandboxed Codex sessions, the install step may require permission to write Revela user config under `~/.config/revela`.
-
-`DESIGN.md` must include frontmatter with `name`, `description`, `author`, and `version`, plus valid marker blocks for `@design:foundation`, `@design:rules`, at least one `@layout`, and at least one `@component`.
-
-`preview.html` must be self-contained and directly openable in a browser. Every `<section class="slide">` must include `slide-qa` and exactly one direct `.slide-canvas` child. Every direct `.slide-canvas` is the fixed 1920px x 1080px export surface and must use explicit CSS with `width: 1920px` and `height: 1080px`; `.slide` may remain a viewport/navigation wrapper. Include a cover slide with `data-slide-role="cover"`, a closing slide with `data-slide-role="closing"`, and a visible sample for every `@component:*` using `data-preview-component="<component-name>"`.
-
-Do not automatically activate a newly created design. Do not automatically activate a newly installed design. Report the draft path, installed path when installed, and tell the user they can activate it with `revela_design_activate`.

package/plugins/revela/skills/revela-domain/SKILL.md

@@ -1,30 +0,0 @@
----
-name: revela-domain
-description: Use or switch Revela domain guidance in Codex for init, research, and deck planning work.
----
-
-# Revela Domain
-
-Use this skill when the user asks about Revela domains, wants domain-specific narrative guidance, asks to switch the active domain, or asks to create a new domain.
-
-## Workflow
-
-1. Call `revela_domain_list` to inspect installed domains and the active domain.
-2. Call `revela_domain_read` for the active or requested domain.
-3. When the user asks to switch domains for future narrative work, call `revela_domain_activate` with the requested domain name, then read the active domain again.
-4. Use domain guidance for audience, decision, claim framing, objections, risks, and research-gap interpretation.
-5. Do not treat domain guidance as evidence, source material, or proof for factual claims.
-
-Domain changes are narrative-framing preferences. They do not rewrite existing claims, evidence boundaries, artifacts, or deck plans unless the user asks for those updates.
-
-## Creating Or Editing Domains
-
-When the user asks to create a new domain, interview the user before saving anything. Collect the communication context, typical audience, decisions, claim patterns, evidence expectations, common objections, risks, research-gap heuristics, terminology to use, and terminology to avoid. Summarize the domain brief, then wait for the user to confirm before creating files.
-
-After confirmation, generate complete `INDUSTRY.md` content and call `revela_domain_draft_create` to save a workspace-local draft under `.revela/drafts/domains/<name>/`. Always call `revela_domain_draft_validate` after draft creation or overwrite.
-
-Install the draft globally only after the user confirms the validated draft should be installed. Call `revela_domain_draft_install` to copy the draft into the user-level domain registry. If a user-level domain already exists, pass `overwrite: true` only after the user confirms replacement. In sandboxed Codex sessions, the install step may require permission to write Revela user config under `~/.config/revela`.
-
-`INDUSTRY.md` must include frontmatter with `name`, `description`, `author`, and `version`, followed by concrete narrative guidance for audience framing, decision framing, claim standards, evidence expectations, objection/risk handling, and research-gap interpretation.
-
-Do not automatically activate a newly installed domain. Report the draft path, installed path when installed, and tell the user they can activate it with `revela_domain_activate`.

package/plugins/revela/skills/revela-init/SKILL.md

@@ -1,31 +0,0 @@
----
-name: revela-init
-description: Initialize a Revela deck-first workspace in Codex from local source materials and material reviews.
----
-
-# Revela Init
-
-Use this skill when the user asks to start Revela, initialize the workspace, ingest local materials, or prepare source inputs for a deck.
-
-## Product Contract
-
-- Init prepares local source material intake; it does not create a Narrative Vault.
-- Durable deck-first state is local material intake, material review files, `researches/`, `deck-plan.md`, `assets/`, and `decks/*.html`.
-- Scan results prove only that files exist. A material is usable only after its direct text or extracted read view has been reviewed.
-- Do not invent quotes, source paths, URLs, page references, caveats, licenses, or artifact coverage.
-
-## Workflow
-
-1. Call `revela_prepare_local_materials` first. Treat the result as an intake registry and task list.
-2. For Office/PDF sources, read `allowedReadPath` / `read_view_path`; if missing, call `revela_extract_document_materials`.
-3. Prefer local source materials first: Markdown, text, CSV, PDFs, Office files, existing `researches/`, `deck-plan.md`, `assets/`, and `decks/`.
-4. After reading extracted material views, call `revela_record_material_review` for each considered Office/PDF source.
-5. Call `revela_check_material_intake` before the final report and surface scanned-but-unreviewed, unsupported, failed, or text-only limitations.
-6. Ask only high-impact intent questions: audience, objective, decision/action, scope, language, source priority, or whether public research is allowed.
-7. End with an intake report: local materials found, read views reviewed, material reviews recorded, source limitations, captured user intent, and next command.
-
-## Report
-
-- Recommend `/revela research` when public/source support is still needed.
-- Recommend `/revela plan --deck` when enough local/research inputs exist.
-- Do not ask for layout, visual style, output path, export format, or approval during init.

package/plugins/revela/skills/revela-upgrade/SKILL.md

@@ -1,33 +0,0 @@
----
-name: revela-upgrade
-description: Guide Revela Codex plugin upgrade, update, version, and reinstall requests while checking the running runtime version first.
----
-
-# Revela Upgrade
-
-Use this skill when the user asks how to upgrade, update, reinstall, or check the version of the Revela Codex plugin.
-
-## Workflow
-
-1. Call `revela_doctor` first to inspect the currently running Revela runtime version.
-2. Report the current runtime version from doctor output. Do not check the latest version online unless the user explicitly asks you to look it up.
-3. Explain that the Codex Git marketplace ref and `.mcp.json` npm runtime pin are published together for the same Revela release.
-4. If the user wants a fixed release, guide them through removing the installed plugin, removing the marketplace entry, adding the desired release tag, then adding the plugin again:
-
-```bash
-codex plugin remove revela@revela
-codex plugin marketplace remove revela
-codex plugin marketplace add https://github.com/cyber-dash-tech/revela --ref vX.Y.Z
-codex plugin add revela@revela
-```
-
-5. If the user already tracks a branch or movable ref, guide them through upgrading the marketplace clone, then re-adding the plugin:
-
-```bash
-codex plugin marketplace upgrade revela
-codex plugin add revela@revela
-```
-
-6. Tell the user to start a new Codex thread after upgrading so Codex reloads the Revela skills, MCP tools, hooks, and runtime pin.
-
-Do not run `codex plugin remove`, `codex plugin marketplace remove`, `codex plugin marketplace add`, `codex plugin marketplace upgrade`, or `codex plugin add` unless the user explicitly asks you to perform the upgrade or reinstall.