duc01226/easyplatform10 files

Docx To Markdown

[Document Processing] Use when you need to convert Microsoft Word ( DOCX) files to Markdown with GFM support (tables, images, code blocks).

Specification
Skill ID
duc01226/easyplatform/docx-to-markdown
Publisher
duc01226
Repository
easyplatform
Installs
0
Files
10
Synced
Sep 23, 2026
How to use it

Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.

duc01226/easyplatform/docx-to-markdownInstalls these files
  • SKILL.md
  • package-lock.json
  • package.json
  • scripts/convert.cjs
  • scripts/lib/converter.cjs
  • scripts/lib/html-to-markdown.cjs
  • scripts/lib/output-handler.cjs
  • tests/converter.test.cjs
  • tests/run-tests.cjs
  • tests/test-framework.cjs

What this skill tells the agent

Codex compatibility note: - Invoke repository skills with $skill-name in Codex; this mirrored copy rewrites legacy Claude /skill-name references. - Task tracker mandate: BEFORE executing any workflow or skill step, create/update task tracking for all steps and keep it synchronized as progress changes. - User-question prompts mean to ask the user directly in Codex. - Ignore Claude-specific mode-switch instructions when they appear. - Strict execution contract: when a user explicitly invokes a skill, execute that skill protocol as written. - Subagent authorization: when a skill is user-invoked or AI-detected and its protocol requires subagents, that skill activation authorizes use of the required spawn_agent subagent(s) for that task. - Do not skip, reorder, or merge protocol steps unless the user explicitly approves the deviation first. - For workflow skills, execute each listed child-skill step explicitly and report step-by-step evidence. - If a required step/tool cannot run in this environment, stop and ask the user before adapting.

<!-- CODEX:PROJECT-REFERENCE-LOADING:START -->

Codex Project-Reference Loading (No Hooks)

Codex uses static project-reference loading instead of runtime-injected project docs. When coding, planning, debugging, testing, or reviewing, open project docs explicitly using this routing.

Always read:

  • docs/project-config.json (project-specific paths, commands, modules, and workflow/test settings)
  • docs/project-reference/docs-index-reference.md (routes to the full docs/project-reference/* catalog)
  • docs/project-reference/lessons.md (always-on guardrails and anti-patterns)

Missing/stale context route: If docs/project-config.json, the docs index, lessons.md, CLAUDE.md, AGENTS.md, or any task-required reference doc is missing or stale, auto-run $project-init or the narrow setup route ($project-config, $docs-init, $scan-all, $scan --target=<key>, $claude-md-init) before ordinary project-specific work. If Codex mirrors or AGENTS.md are missing/stale, ask the user to run $sync-codex; do not auto-run it.

Situation-based docs:

  • Project structure/architecture/tech-stack/deployment/setup (any layer — backend, frontend, or infra): project-structure-reference.md
  • Backend/CQRS/API/domain/entity changes: backend-patterns-reference.md, domain-entities-reference.md
  • Frontend/UI/styling/design-system: frontend-patterns-reference.md, scss-styling-guide.md, design-system/README.md
  • Spec authoring, docs/specs/ pathing, or TC format: feature-spec-reference.md, spec-system-reference.md, spec-principles.md
  • Behavior/public-contract changes or spec-test-code sync: workflow-spec-test-code-cycle-reference.md plus the spec docs above
  • Derived spec indexes/ERDs/reimplementation guides: spec-system-reference.md and source Feature Specs under docs/specs/
  • Integration test implementation/review: integration-test-reference.md
  • E2E test implementation/review: e2e-test-reference.md
  • Code review/audit work: code-review-rules.md plus domain docs above based on changed files

Do not read all docs blindly. Start from docs-index-reference.md, then open only relevant files for the task.

<!-- CODEX:PROJECT-REFERENCE-LOADING:END -->

Quick Summary

Goal: Convert Microsoft Word (.docx) files to Markdown with GFM support (tables, images, formatting).

Workflow:

  1. Install -- Ensure pandoc is available (required dependency)
  2. Convert -- Run pandoc with GFM output format and image extraction
  3. Clean -- Post-process markdown for consistency

Key Rules:

  • Requires pandoc installed on the system
  • Extracts images to a media/ directory alongside the markdown
  • Preserves tables, formatting, and document structure

Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).

docx-to-markdown

Convert Microsoft Word (.docx) files to Markdown format with GitHub-Flavored Markdown support.

Installation Required

This skill requires npm dependencies. Run one of the following:

# Option 1: Install via ClaudeKit CLI (recommended)
ck init  # Runs install.sh which handles all skills

# Option 2: Manual installation
cd .claude/skills/docx-to-markdown
npm install

Dependencies: mammoth, turndown, turndown-plugin-gfm

Quick Start

# Basic conversion
node .claude/skills/docx-to-markdown/scripts/convert.cjs --input ./document.docx

# Specify output path
node .claude/skills/docx-to-markdown/scripts/convert.cjs -i ./doc.docx -o ./output.md

# Preserve images to folder
node .claude/skills/docx-to-markdown/scripts/convert.cjs -i ./doc.docx --images ./images/

CLI Options

OptionShortDescriptionDefault
--input-iInput DOCX file path(required)
--output-oOutput markdown file path{input}.md
--imagesDirectory for extracted imagesinline base64
--help-hShow help message

Features

  • GFM Tables: Properly converts Word tables to markdown tables
  • Images: Extracts embedded images (base64 inline or to folder)
  • Lists: Ordered and unordered lists preserved
  • Code Blocks: Monospace text converted to code blocks
  • Links: Hyperlinks preserved
  • Headings: Heading levels maintained
  • Cross-OS: Works on Windows, macOS, Linux

Conversion Pipeline

DOCX → mammoth → HTML → turndown → Markdown

The two-stage conversion (DOCX→HTML→MD) follows mammoth's official recommendation for best results.

Output

Returns JSON on success:

{
    "success": true,
    "input": "/path/to/input.docx",
    "output": "/path/to/output.md",
    "stats": {
        "images": 3,
        "tables": 2,
        "headings": 5
    }
}

Limitations

  • Complex layouts (columns, text boxes) may not preserve structure
  • Merged table cells produce basic markdown tables
  • Comments and track changes are stripped
  • Some formatting (fonts, colors) lost in conversion

[IMPORTANT] Use task tracking to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.

<!-- SYNC:ai-mistake-prevention -->

AI Mistake Prevention — Failure modes to avoid on every task: Re-read files after context changes. Context compaction, resume, or long-running work can make memory stale; verify current files before acting. Verify generated content against source evidence. AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing. Check downstream references before deleting or renaming. Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first. Trace the full impact chain after edits. Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done. Verify ALL affected outputs, not just the first. One green check is not all green checks; validate every output surface the change can affect. Assume existing values are intentional — ask WHY before changing OR flagging one as a defect. Before changing or reporting a constant, limit, flag, cutoff, wording, or pattern, read nearby context and history, the CALLER's ordering, and 2+ sibling call sites of the same convention. A doc stating WHAT without WHY is missing rationale, not proof of a missing guard. Surface ambiguity before acting — don't pick silently. Multiple valid interpretations require an explicit question or stated assumption with risk.

Use this skill in a project

Open any RiverX project, search the Skills panel for duc01226/easyplatform/docx-to-markdown, and install it in one click.

Use this skill