baram2584/PDFToMD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

modify documents

Browse Source
This commit is contained in:
김경종
2026-05-08 17:03:40 +09:00
parent 73f955a8ce
commit a4dcfbdedc
23 changed files with 181 additions and 464 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.codex/skills/fixture-evaluation/SKILL.md
+6 -5
View File
@@ -12,11 +12,12 @@ Use this skill to turn local sample PDFs into a small, repeatable quality plan.
## Workflow
1. Read `PLAN.md` and `PROGRESS.md` first.
2. Inspect `samples/` only enough to understand fixture categories and filenames.
3. Map each fixture to risks: math, tables, multi-column reading order, figures/assets, Korean filenames, and metadata coverage.
4. Separate fast checks using mocked MinerU outputs from optional checks that require MinerU models, GPU, or long execution.
5. Define metrics for both JSON metadata and `<stem>.report.md`.
6. Update `PROGRESS.md` with fixture coverage and gaps.
2. Read `docs/WORKARCHIVE.md` when prior fixture coverage, verification, or sample conversion evidence is needed.
3. Inspect `samples/` only enough to understand fixture categories and filenames.
4. Map each fixture to risks: math, tables, multi-column reading order, figures/assets, Korean filenames, and metadata coverage.
5. Separate fast checks using mocked MinerU outputs from optional checks that require MinerU models, GPU, or long execution.
6. Define metrics for both JSON metadata and `<stem>.report.md`.
7. Update `PROGRESS.md` with fixture coverage and gaps.
## Guardrails
.codex/skills/math-markdown-review/SKILL.md
+6 -5
View File
@@ -12,11 +12,12 @@ Use this skill when Markdown output quality matters more than raw text extractio
## Workflow
1. Read `PLAN.md` and `PROGRESS.md` first.
2. Read `PRD.md` and `ARCHITECTURE.md` when output behavior, metadata, or reporting is affected.
3. Preserve project delimiter policy: inline math uses `$...$`; display math uses `$$...$$`.
4. Check asset links, table fallback behavior, heading/list interactions, and page boundary markers against Obsidian rendering assumptions.
5. Define warnings for low-confidence math, non-renderable LaTeX, broken asset links, table degradation, and reading-order uncertainty.
6. Ensure `.report.md` content is derived from metadata, not separate manual state.
2. Read `docs/WORKARCHIVE.md` when prior Markdown output, MathJax, or sample conversion evidence is needed.
3. Read `PRD.md` and `ARCHITECTURE.md` when output behavior, metadata, or reporting is affected.
4. Preserve project delimiter policy: inline math uses `$...$`; display math uses `$$...$$`.
5. Check asset links, table fallback behavior, heading/list interactions, and page boundary markers against Obsidian rendering assumptions.
6. Define warnings for low-confidence math, non-renderable LaTeX, broken asset links, table degradation, and reading-order uncertainty.
7. Ensure `.report.md` content is derived from metadata, not separate manual state.
## Checks
.codex/skills/mineru-research/SKILL.md
+6 -5
View File
@@ -12,11 +12,12 @@ Use this skill to verify MinerU 3.1.0 facts before changing project docs or plan
## Workflow
1. Read `PLAN.md` and `PROGRESS.md` first.
2. Read `PRD.md`, `ARCHITECTURE.md`, and `docs/KNOWLEDGEBASE.md` when the change affects product or architecture decisions.
3. Prefer official MinerU documentation, the MinerU GitHub repository, release notes, primary papers, and official dependency docs.
4. Verify time-sensitive facts with web research before updating docs.
5. Record source URLs and access dates in durable docs when the finding affects future implementation.
6. Update `PROGRESS.md` with the verified fact, unresolved uncertainty, and next action.
2. Read `docs/WORKARCHIVE.md` when prior MinerU setup, verification, or sample conversion evidence is needed.
3. Read `PRD.md`, `ARCHITECTURE.md`, and `docs/KNOWLEDGEBASE.md` when the change affects product or architecture decisions.
4. Prefer official MinerU documentation, the MinerU GitHub repository, release notes, primary papers, and official dependency docs.
5. Verify time-sensitive facts with web research before updating docs.
6. Record source URLs and access dates in durable docs when the finding affects future implementation.
7. Update `PROGRESS.md` with the verified fact, unresolved uncertainty, and next action.
## Constraints