pi-maestro-flow 0.2.0

package/skills/scholar-review/SKILL.md

@@ -0,0 +1,227 @@
+---
+name: scholar-review
+description: "Systematic academic paper review workflow covering self-review before submission and rebuttal writing after receiving reviewer feedback. Triggers on \"review paper\", \"self-review\", \"write rebuttal\", \"respond to reviewers\", \"analyze review comments\", \"paper review\"."
+allowed-tools: Read Write Edit Bash Glob Grep WebFetch WebSearch AskUserQuestion TodoWrite
+---
+
+# Scholar Review
+
+A structured workflow for academic paper review and rebuttal. Covers two modes: (1) pre-submission self-review to identify and fix weaknesses before submitting, and (2) post-review rebuttal writing to respond professionally to reviewer feedback.
+
+## Pre-load (before execution)
+
+1. **Codebase docs**: If `.workflow/codebase/ARCHITECTURE.md` exists, read for project context
+2. **Specs**: `maestro load --type spec --category coding` — load coding conventions
+3. **Wiki knowledge**: `maestro search "academic writing research paper" --json` — top 5 entries as prior context
+4. All optional — proceed without if unavailable
+
+## Architecture Overview
+
+```
+                          scholar-review
+                               |
+                    [Preference Collection]
+                         /            \
+              Pre-Submission        Post-Review
+                   |              /     |      \
+            +-----------+   +--------+--------+---------+
+            | Phase 1   |   | Phase 2| Phase 3| Phase 4 |
+            | Self-     |   | Review | Response| Rebuttal|
+            | Review    |   | Analysis| Strategy| Writing|
+            +-----------+   +--------+--------+---------+
+                   |              \     |      /
+                   v               v    v    v
+            self-review-       rebuttal-response.md
+            report.md                  |
+                                       v
+                                 +-----------+
+                                 | Phase 5   |
+                                 | Revision  |
+                                 +-----------+
+                                       |
+                                       v
+                                 revised-paper
+```
+
+## Key Design Principles
+
+1. **Mode-driven execution**: Pre-submission triggers Phase 1 only; post-review triggers Phases 2-5 sequentially
+2. **Evidence-based review**: Every finding must reference specific sections, pages, or line numbers
+3. **Professional tone**: All rebuttal output follows academic tone guidelines (grateful, respectful, evidence-based)
+4. **Completeness**: Every reviewer comment must receive a response; no comment is skipped
+5. **Actionable output**: Each phase produces concrete artifacts, not abstract advice
+
+## Interactive Preference Collection
+
+Collect workflow preferences before dispatching to phases:
+
+```
+Ask the user:
+
+1. Review Stage:
+   - "Pre-submission self-review" → Execute Phase 1 only
+   - "Post-review rebuttal" → Execute Phases 2-5
+
+2. Paper Location:
+   - Path to paper file(s) or directory
+
+3. (If post-review) Reviewer Comments Location:
+   - Path to reviewer comments file(s)
+
+4. (If post-review) Target Venue:
+   - Conference/journal name (e.g., NeurIPS, ICML, ICLR, CVPR, ACL)
+   - "Other" with custom venue name
+
+5. Auto Mode:
+   - "Interactive (Recommended)" → Confirm at each phase transition
+   - "Auto" → Execute all applicable phases without confirmation
+
+Store as workflowPreferences:
+  - mode: "pre-submission" | "post-review"
+  - paperPath: string
+  - reviewCommentsPath: string (post-review only)
+  - targetVenue: string
+  - autoYes: boolean
+```
+
+## Execution Flow
+
+> **COMPACT DIRECTIVE**: Context compression MUST check TodoWrite phase status.
+> The phase currently marked `in_progress` is the active execution phase -- preserve its FULL content.
+> Only compress phases marked `completed` or `pending`.
+
+### Pre-Submission Mode
+
+```
+Phase 1: Self-Review
+  Ref: phases/01-self-review.md
+  Input: paperPath, targetVenue
+  Output: self-review-report.md
+  TodoWrite: Mark Phase 1 in_progress → completed
+```
+
+### Post-Review Mode
+
+```
+Phase 2: Review Analysis
+  Ref: phases/02-review-analysis.md
+  Input: reviewCommentsPath, paperPath
+  Output: review-analysis.md (classified comments with priorities)
+  TodoWrite: Mark Phase 2 in_progress → completed
+
+Phase 3: Response Strategy
+  Ref: phases/03-response-strategy.md
+  Input: review-analysis.md, paperPath
+  Output: response-strategy.md (strategy per comment)
+  TodoWrite: Mark Phase 3 in_progress → completed
+
+Phase 4: Rebuttal Writing
+  Ref: phases/04-rebuttal-writing.md
+  Input: response-strategy.md, paperPath, targetVenue
+  Output: rebuttal-response.md
+  TodoWrite: Mark Phase 4 in_progress → completed
+
+Phase 5: Revision
+  Ref: phases/05-revision.md
+  Input: rebuttal-response.md, paperPath
+  Output: revision-plan.md, tracked changes list
+  TodoWrite: Mark Phase 5 in_progress → completed
+```
+
+**Phase Reference Documents** (read on-demand when phase executes):
+
+| Phase | Document | Purpose | Compact |
+|-------|----------|---------|---------|
+| 1 | [phases/01-self-review.md](phases/01-self-review.md) | Pre-submission quality check | TodoWrite driven |
+| 2 | [phases/02-review-analysis.md](phases/02-review-analysis.md) | Parse and classify reviewer comments | TodoWrite driven |
+| 3 | [phases/03-response-strategy.md](phases/03-response-strategy.md) | Plan rebuttal strategy per comment | TodoWrite driven + sentinel |
+| 4 | [phases/04-rebuttal-writing.md](phases/04-rebuttal-writing.md) | Write structured rebuttal document | TodoWrite driven + sentinel |
+| 5 | [phases/05-revision.md](phases/05-revision.md) | Plan and track paper revisions | TodoWrite driven |
+
+**Compact Rules**:
+1. **TodoWrite `in_progress`** -> Preserve full content, do not compress
+2. **TodoWrite `completed`** -> May compress to summary
+3. **Sentinel fallback** -> Phases marked with sentinel contain compact sentinels; if only sentinel remains without full Step protocol, immediately `Read()` to recover
+
+## Core Rules
+
+1. **Read paper first**: Always read the full paper before any review or analysis
+2. **Classify before responding**: Never write rebuttals without completing review analysis and strategy
+3. **No skipped comments**: Every reviewer comment must have a response entry
+4. **Venue-aware tone**: Adjust strategy and emphasis based on target venue conventions
+5. **Preserve reviewer numbering**: Maintain original reviewer IDs and comment numbering throughout
+
+## Input Processing
+
+```
+User input → Structured format:
+
+PAPER: [path to paper files]
+MODE: [pre-submission | post-review]
+REVIEWS: [path to reviewer comments] (post-review only)
+VENUE: [target conference/journal]
+OUTPUT_DIR: [directory for generated documents]
+```
+
+## Data Flow
+
+```
+paperPath ──────────────────────────────────────────────────┐
+    │                                                        │
+    v                                                        │
+Phase 1: self-review-report.md                               │
+    (Pre-submission mode ends here)                          │
+                                                             │
+reviewCommentsPath ─── Phase 2: review-analysis.md ──────────┤
+                           │                                 │
+                           v                                 │
+                    Phase 3: response-strategy.md ───────────┤
+                           │                                 │
+                           v                                 │
+                    Phase 4: rebuttal-response.md ───────────┤
+                           │                                 │
+                           v                                 │
+                    Phase 5: revision-plan.md ────── paperPath
+```
+
+## TodoWrite Pattern
+
+### Phase Attachment (entering phase)
+```
+TodoWrite([
+  { id: "phase-N", task: "Phase N: [name]", status: "in_progress" },
+  { id: "phase-N-step-1", task: "  Step N.1: [name]", status: "pending" },
+  { id: "phase-N-step-2", task: "  Step N.2: [name]", status: "pending" }
+])
+```
+
+### Phase Collapse (exiting phase)
+```
+TodoWrite([
+  { id: "phase-N", task: "Phase N: [name] -- Done", status: "completed" },
+  { id: "phase-N+1", task: "Phase N+1: [name]", status: "in_progress" }
+])
+```
+
+## Error Handling
+
+1. **Paper not found**: Ask user to confirm paper path, retry once
+2. **Reviews not parseable**: Ask user to reformat or paste reviews directly
+3. **Phase failure**: Log error, ask user whether to retry or skip to next phase
+4. **Venue unknown**: Fall back to generic academic review conventions
+
+## Coordinator Checklist
+
+### Before Each Phase
+- [ ] Confirm input files exist and are readable
+- [ ] TodoWrite updated: current phase `in_progress`
+- [ ] Read phase document via `Ref:` marker
+
+### After Each Phase
+- [ ] Output file generated and saved
+- [ ] TodoWrite updated: current phase `completed`
+- [ ] If not autoYes, confirm with user before next phase
+
+### Post-Workflow
+- [ ] All output files listed for user
+- [ ] Summary of findings/actions presented

package/skills/scholar-thesis-docx/README.md

@@ -0,0 +1,111 @@
+# thesis-docx.skill
+
+[![License](https://img.shields.io/badge/license-MIT-16a34a)](./LICENSE)
+[![Word](https://img.shields.io/badge/Microsoft_Word-Recommended-185ABD)](#运行前提)
+[![Mermaid](https://img.shields.io/badge/Mermaid-Supported-0ea5e9)](#功能)
+
+**语言 / Language**：**中文** | [English](./README_EN.md)
+
+`thesis-docx` 是一个面向毕业论文 / 学位论文场景的 skill。
+
+它的重点不是“批量改 Word”，而是让 AI 在论文文档上按更稳的顺序工作：
+
+1. 先检查 Word 自动化环境  
+2. 先审计，再决定怎么改  
+3. 学校明确规定的格式严格执行  
+4. 学校没规定的格式默认保留现状  
+5. 最后导出 PDF 逐页复核
+
+## 功能
+
+- 修订 thesis / dissertation Word 文档
+- 统一正文、标题、图题注、表题注、参考文献等样式
+- 修复目录、页码、分节、交叉引用、图表编号
+- 生成基于真实材料的 Mermaid 图
+- 生成适合论文使用的代码片段或伪代码，LaTeX排版
+- 审计 OOXML 隐藏问题，例如：
+  - `styleId`
+  - `firstLineChars`
+  - `titlePg`
+  - REF 域显示值
+  - section 级页眉页脚引用
+
+## 运行前提
+
+- Windows 下建议安装桌面版 Microsoft Word
+- Python 脚本建议环境具备：
+  - `python-docx`
+  - `lxml`
+- Mermaid 渲染建议具备：
+  - Node.js
+  - `mmdc` 或可用的 `npx`
+
+## 快速开始
+
+```powershell
+# 1) 检查 Word COM/DOM 是否可用
+powershell -ExecutionPolicy Bypass -File scripts/check_word_com.ps1 -Json
+
+# 2) 先做 OOXML 审计
+python scripts/audit_docx_ooxml.py .\draft.docx --output_json .\draft.audit.json --output_txt .\draft.audit.txt
+
+# 3) 如有需要，先 dry-run 审计样式归一化
+powershell -ExecutionPolicy Bypass -File scripts/normalize_word_styles.ps1 -InputPath .\draft.docx -AuditOnly
+
+# 4) 真正修完后导出 PDF，逐页复核
+powershell -ExecutionPolicy Bypass -File scripts/export_word_pdf.ps1 -DocPath .\draft.docx -PdfPath .\draft.audit.pdf
+```
+
+## 使用原则
+
+- 先审计，再修复
+- 先修学校明确要求，再处理用户自定义要求
+- 不对未规定区域做“全局统一美化”
+- 图、代码、架构、流程都必须基于真实材料
+- 没做 PDF 逐页复核时，不应直接说“格式已全部完成”
+
+## 仓库结构
+
+```text
+.
+├── agents/
+├── SKILL.md
+├── scripts/
+├── references/
+├── examples/
+├── README.md
+├── README_EN.md
+└── LICENSE
+```
+
+## 关键文件
+
+- `SKILL.md`：主说明
+- `agents/openai.yaml`：界面集成元数据
+- `scripts/check_word_com.ps1`：检查 Word COM/DOM
+- `scripts/audit_docx_ooxml.py`：审计 DOCX / OOXML 隐藏问题
+- `scripts/normalize_word_styles.ps1`：批量样式归一化
+- `scripts/export_word_pdf.ps1`：导出 PDF 做逐页审计
+- `scripts/render_mermaid_figure.ps1`：渲染 Mermaid 图
+- `references/paper-format-workflow.md`：论文格式工作流
+- `references/failure-patterns-and-quality-gates.md`：高风险坑与质量门槛
+- `references/script-usage.md`：脚本使用说明
+
+## 安装
+
+```powershell
+git clone https://github.com/the-shy123456/thesis-docx.git
+```
+
+保持仓库目录完整即可，不需要拆文件。
+
+## Star 趋势
+
+[![Star History Chart](https://api.star-history.com/svg?repos=the-shy123456/thesis-docx&type=Date)](https://www.star-history.com/#the-shy123456/thesis-docx&Date)
+
+## License
+
+MIT
+## 社区
+
+- [LINUX DO 社区](https://linux.do)

package/skills/scholar-thesis-docx/README_EN.md

@@ -0,0 +1,108 @@
+# thesis-docx
+
+[![License](https://img.shields.io/badge/license-MIT-16a34a)](./LICENSE)
+[![Word](https://img.shields.io/badge/Microsoft_Word-Recommended-185ABD)](#runtime-requirements)
+[![Mermaid](https://img.shields.io/badge/Mermaid-Supported-0ea5e9)](#features)
+
+**Language**: [中文](./README.md) | **English**
+
+`thesis-docx` is a skill for thesis and dissertation Word workflows.
+
+Its purpose is not merely bulk formatting. The intended workflow is:
+
+1. check Word automation first  
+2. audit before editing  
+3. strictly enforce school-defined rules  
+4. preserve formatting that the school guide does not define  
+5. export to PDF and review page by page
+
+## Features
+
+- revise thesis / dissertation Word documents
+- normalize body text, headings, figure captions, table captions, and references
+- fix TOC, page numbers, sections, cross-references, and caption numbering
+- generate Mermaid figures from real source material
+- prepare thesis-friendly code excerpts or pseudocode
+- audit hidden OOXML issues such as:
+  - `styleId`
+  - `firstLineChars`
+  - `titlePg`
+  - REF field display text
+  - section-level header/footer references
+
+## Runtime Requirements
+
+- desktop Microsoft Word is strongly recommended on Windows
+- Python scripts typically expect:
+  - `python-docx`
+  - `lxml`
+- Mermaid rendering typically expects:
+  - Node.js
+  - `mmdc` or a usable `npx`
+
+## Quick Start
+
+```powershell
+# 1) Check Word COM/DOM availability
+powershell -ExecutionPolicy Bypass -File scripts/check_word_com.ps1 -Json
+
+# 2) Audit DOCX / OOXML first
+python scripts/audit_docx_ooxml.py .\draft.docx --output_json .\draft.audit.json --output_txt .\draft.audit.txt
+
+# 3) Dry-run style normalization first
+powershell -ExecutionPolicy Bypass -File scripts/normalize_word_styles.ps1 -InputPath .\draft.docx -AuditOnly
+
+# 4) Export to PDF for page-by-page review
+powershell -ExecutionPolicy Bypass -File scripts/export_word_pdf.ps1 -DocPath .\draft.docx -PdfPath .\draft.audit.pdf
+```
+
+## Working Rules
+
+- audit first, fix second
+- prioritize school rules over local preferences
+- do not globally normalize unspecified formatting
+- keep figures, architecture, and code grounded in real materials
+- do not claim completion before PDF-level review
+
+## Repository Layout
+
+```text
+.
+├── agents/
+├── SKILL.md
+├── scripts/
+├── references/
+├── examples/
+├── README.md
+├── README_EN.md
+└── LICENSE
+```
+
+## Key Files
+
+- `SKILL.md`: main instructions
+- `agents/openai.yaml`: UI-facing metadata
+- `scripts/check_word_com.ps1`: check Word COM/DOM availability
+- `scripts/audit_docx_ooxml.py`: audit hidden DOCX / OOXML issues
+- `scripts/normalize_word_styles.ps1`: batch style normalization
+- `scripts/export_word_pdf.ps1`: export PDF for page review
+- `scripts/render_mermaid_figure.ps1`: render Mermaid figures
+- `references/paper-format-workflow.md`: thesis formatting workflow
+- `references/failure-patterns-and-quality-gates.md`: common failure modes and quality gates
+- `references/script-usage.md`: script examples and usage notes
+
+## Installation
+
+```powershell
+git clone https://github.com/the-shy123456/thesis-docx.git
+```
+
+Keep the repository structure intact.
+
+## Star History
+
+[![Star History Chart](https://api.star-history.com/svg?repos=the-shy123456/thesis-docx&type=Date)](https://www.star-history.com/#the-shy123456/thesis-docx&Date)
+
+## License
+
+MIT

package/skills/scholar-thesis-docx/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: thesis-docx
+description: "Create, revise, and format thesis or dissertation Word documents with strict academic formatting control. Use when an AI agent needs to generate or revise thesis content, normalize Word styles, follow a school template, fix captions or page numbers or section levels, or produce evidence-based Mermaid figures and LaTeX-formatted code listings for a thesis document."
+---
+
+# Thesis DOCX
+
+## Overview
+
+Use this skill for thesis-oriented `.docx` work where content quality and
+format fidelity both matter. Prefer Microsoft Word desktop automation over
+WPS-like alternatives whenever the task involves batch formatting, styles,
+captions, pagination, tables of contents, or cross-references.
+
+This skill is designed to avoid the most common thesis-editing failure mode:
+the agent makes broad formatting changes too early, introduces new layout
+problems, and then forces the user to catch them one by one. The default
+behavior should therefore be:
+
+1. audit first,
+2. separate explicit school requirements from unspecified formatting,
+3. fix only what is justified,
+4. re-check page by page before claiming completion.
+
+## Pre-load (before execution)
+
+1. **Codebase docs**: If `.workflow/codebase/ARCHITECTURE.md` exists, read for project context
+2. **Specs**: `maestro load --type spec --category coding` — load coding conventions
+3. **Wiki knowledge**: `maestro search "thesis academic writing docx formatting" --json` — top 5 entries as prior context
+4. All optional — proceed without if unavailable
+
+## Workflow
+
+1. Check Microsoft Word and COM/DOM automation first.
+   - On Windows, run:
+   ```powershell
+   powershell -ExecutionPolicy Bypass -File scripts/check_word_com.ps1 -Json
+   ```
+   - If Word is missing, COM is unavailable, or DOM access fails:
+     - Stop the automation-heavy plan.
+     - Tell the user to install desktop Microsoft Word.
+     - Explain briefly that WPS or similar tools are likely to degrade layout
+       fidelity for thesis formatting.
+2. Read the user's real constraints before editing.
+   - Collect the thesis template, school formatting guide, screenshots,
+     existing document, sample pages, and any explicit chapter rules.
+   - If the user gave formal requirements, follow them strictly.
+   - If the user did not give requirements, do not invent school-specific
+     standards. Use conservative academic defaults and say that they are
+     defaults.
+   - Explicitly classify requirements into two buckets before editing:
+     - `must enforce`: school guide, template, user-confirmed style rules
+     - `preserve current state`: anything the school guide does not define
+3. Audit the DOCX / OOXML before risky bulk edits.
+   - Prefer `scripts/audit_docx_ooxml.py` before large-scale formatting.
+   - Use it to detect hidden indentation, section drift, stale REF display
+     text, and style-ID mismatches before deciding on a repair strategy.
+4. Standardize with styles, not scattered direct formatting.
+   - Reuse and repair existing styles whenever possible.
+   - Create missing styles only when no matching style exists.
+   - Keep body text, headings, figure captions, table captions, references,
+     abstract, and appendix styles separate and consistent.
+   - Before changing any style globally, inspect whether the document contains
+     direct paragraph formatting or OOXML overrides that will survive the style
+     change.
+5. Edit content only from user-provided facts.
+   - Expand, polish, or reorganize thesis text only within the user's topic,
+     evidence, codebase, notes, or source material.
+   - Do not invent experimental data, system structure, entities, or results.
+6. Generate figures only when the source material is sufficient.
+   - Use Mermaid for architecture diagrams, E-R diagrams, flow charts, state
+     diagrams, and similar thesis figures.
+   - Base every node, field, relation, and dependency on real materials from
+     the user, such as code, SQL schema, API docs, project docs, or the thesis
+     draft itself.
+   - If the materials are insufficient, refuse to fabricate the figure and ask
+     for the missing source information.
+7. Typeset code with LaTeX conventions when thesis code excerpts are needed.
+   - Keep only the code relevant to the argument.
+   - Preserve real identifiers from the user's code or design.
+   - Avoid synthetic filler code written only to look complete.
+8. Audit before you claim completion.
+   - Run a structure audit first: styles, sections, captions, references,
+     page number scheme, cross-references, hidden paragraph overrides.
+   - Then export the document to PDF from Word and review page by page.
+   - Only say the task is complete after the PDF-level audit passes or after
+     you clearly state the remaining manual visual checks.
+
+## Style Strategy
+
+- Treat styles as the single source of truth for formatting.
+- Prefer these logical style buckets:
+  - `Body Text`
+  - `Heading 1` / `Heading 2` / `Heading 3`
+  - `Figure Caption`
+  - `Table Caption`
+  - `References`
+  - `Abstract`
+  - `Keywords`
+  - `Appendix Title`
+- If the document already has equivalent styles, map to them and normalize
+  their font, spacing, indentation, and numbering behavior.
+- If direct formatting conflicts with styles, reduce the direct formatting and
+  bring the document back under style control.
+- Do not globally normalize sections that the school guide does not specify.
+  Examples of high-risk overreach:
+  - page header/footer redesign when the user only asked for headings
+  - changing code box appearance when the task is only about references
+  - normalizing table internals when the school guide does not regulate them
+- When a visual issue remains after style normalization, inspect hidden OOXML
+  state such as `firstLineChars`, numbering indentation, `titlePg`,
+  `differentFirstPageHeaderFooter`, REF field display text, and direct run
+  formatting.
+
+## Audit-First Discipline
+
+Before bulk editing, produce and internally follow a checklist like this:
+
+1. Which parts are explicitly regulated by the school guide?
+2. Which parts are user-defined house rules?
+3. Which parts are currently acceptable and must be preserved?
+4. Which problems are structural vs. visual-only?
+5. Which fixes can be done safely through styles?
+6. Which fixes require Word COM or OOXML-level patching?
+
+Do not say "finished" merely because a structural audit looks good. For thesis
+work, pagination and page-level rendering are part of correctness.
+
+## High-Risk Pitfalls
+
+Read `references/failure-patterns-and-quality-gates.md` before large-scale
+formatting work. In particular, guard against:
+
+- style names that look correct but map to the wrong style IDs
+- paragraph-level direct formatting that overrides the intended style
+- `firstLineChars` or numbering indentation creating invisible extra indents
+- TOC fields or cross-reference fields showing stale display text
+- section-level first-page settings causing missing headers or page numbers
+- Word vs. WPS differences for table row height, vertical alignment, and code
+  box title clipping
+- punctuation normalization that accidentally rewrites DOI, URLs, code, or
+  English references
+
+## Visual Review Rule
+
+For school-format-sensitive thesis work, final verification should prefer this
+order:
+
+1. Word COM/DOM structural checks
+2. Word export to PDF
+3. page-by-page PDF review
+4. only then final delivery language
+
+If page rendering cannot be verified, say so explicitly instead of implying the
+ formatting is fully validated.
+
+## Figure Rules
+
+- Use Mermaid when a thesis figure is needed and the structure can be traced to
+  real source material.
+- Keep the diagram academically neutral and concise.
+- Avoid decorative labels, chatty callouts, and speculative entities.
+- Match the user's terminology unless it conflicts with the real materials.
+- Read `references/figure-and-code-rules.md` before generating diagrams.
+
+## Code Listing Rules
+
+- Prefer LaTeX-oriented code presentation when the thesis includes code
+  listings.
+- Keep the listing faithful to the actual code.
+- Trim non-essential boilerplate when it does not support the thesis argument.
+- If the user requests a specific LaTeX package or listing style, follow it.
+
+## Resource Guide
+
+- `scripts/check_word_com.ps1`
+  - Detect whether Microsoft Word desktop and COM/DOM automation are available.
+- `scripts/audit_docx_ooxml.py`
+  - Audit DOCX styles, direct indentation, section settings, numbering, and REF
+    field behavior before making risky formatting changes.
+- `scripts/normalize_word_styles.ps1`
+  - Batch-normalize thesis body text, Heading 1-3, figure captions, and table
+    captions through Word COM automation.
+- `scripts/export_word_pdf.ps1`
+  - Export the current thesis document to PDF through Word COM for page-level
+    review.
+- `scripts/render_mermaid_figure.ps1`
+  - Render Mermaid source into thesis-ready SVG, PNG, or PDF figure assets.
+- `references/paper-format-workflow.md`
+  - Read for the standard Word thesis formatting workflow.
+- `references/figure-and-code-rules.md`
+  - Read before generating Mermaid figures or LaTeX code listings.
+- `references/failure-patterns-and-quality-gates.md`
+  - Read before large-scale formatting or before claiming the thesis is fully
+    checked.
+- `references/script-usage.md`
+  - Read for command examples and config file conventions.
+
+## Final Checks
+
+- Confirm the document is still style-driven after edits.
+- Confirm captions, numbering, page breaks, and table of contents are coherent.
+- Confirm cross-references display the current target labels, not stale field
+  text.
+- Confirm section settings do not silently remove page headers or page numbers
+  from first pages.
+- Confirm references are formatted according to the school rules and that
+  punctuation normalization did not damage DOI or English references.
+- Confirm every diagram and code block is grounded in user-provided material.
+- Export to PDF and inspect every page before saying the format is complete.
+- If Word automation or PDF verification was unavailable, explicitly warn that
+  layout fidelity was not guaranteed.