Template Extractor is a systematic reverse-engineering tool that extracts precise design specifications from existing documents (DOCX, PPTX, XLSX, PDF) to enable pixel-perfect recreation. Unlike visual inspection which leads to "close enough" approximations, this skill unpacks document file structures and parses their underlying XML to extract exact font sizes, color hex codes, spacing values, and layout configurations.
The skill generates two critical outputs: (1) a code-level technical specification with exact measurements and values, and (2) an AI-ready prompt that enables any language model to recreate documents in that exact style. This dual-output approach ensures both machine precision and human comprehension.
By validating extracted templates through test recreation and visual comparison, Template Extractor guarantees that generated specifications are accurate and actionable, eliminating the guesswork and iteration cycles typical of manual document formatting.
When to Use
Use When:
User provides a sample document (DOCX, PPTX, XLSX, or PDF) and wants to replicate its formatting exactly
User needs to create a reusable document style guide from an existing file without manual measurement
User wants to generate an AI prompt that enables consistent document generation across multiple files
User needs to standardize document formatting across a team by extracting a reference template
User is migrating from one document system to another and needs precise format specifications
User wants to create a branded document generator that matches corporate style guides
User needs to audit existing documents to document their design specifications
User wants to ensure document formatting consistency without manually measuring fonts and spacing
Do Not Use:
User wants to create a document from scratch without a reference template (use doc-generator or pptx-generation instead)
User only needs to convert document formats without preserving exact styling (use standard conversion tools)
User wants to improve or modify existing formatting rather than replicate it exactly
User is working with handwritten documents or non-digital formats (no structured data to extract)
User needs real-time document editing rather than specification extraction
User's priority is content extraction rather than format specification
Core Principles
Principle 1: Systematic Extraction Over Visual Guessing
Human visual inspection of documents leads to approximations: "that looks like 14pt" or "probably Arial". Template Extractor treats documents as ZIP archives containing structured XML, unpacking them to access authoritative sources like styles.xml, theme1.xml, and document.xml. This approach extracts definitive values rather than best guesses.
Why This Matters: A "close enough" color (#333333 vs #1F1F1F) creates subtle inconsistency that compounds across documents. A 1pt font size difference (11pt vs 12pt) changes readability and layout flow. Manual inspection cannot reliably detect these differences, but XML parsing provides ground truth.
In Practice:
Unpack DOCX/PPTX/XLSX files as ZIP archives to access internal XML structure
Parse word/styles.xml for exact heading and body text specifications
Extract word/theme/theme1.xml for color scheme definitions (hex values, not visual approximations)
Read word/document.xml for page layout settings (margins, orientation, dimensions)
Convert OOXML units (half-points, twips, EMUs) to standard measurements using precise formulas
Extract embedded media files (logos, images) from word/media/ directories
For PDFs, use metadata extraction and text analysis to identify fonts and spacing patterns
Principle 2: Dual Output (Specification + Prompt)
Template Extractor generates two complementary artifacts: a technical specification for developers/designers who need exact measurements, and an AI replication prompt for language models that will generate documents in this style. This separation serves distinct audiences while ensuring both receive accurate, actionable information.
Why This Matters: Developers need machine-readable values ("font: Calibri 11pt, line-height: 1.15, margin-top: 0pt, margin-bottom: 8pt") while AI systems need natural language instructions with embedded precision ("Use Calibri 11pt for body text with 1.15 line spacing. Add 8pt spacing after each paragraph."). A single output cannot optimize for both use cases.
List formatting (bullet styles, indentation, spacing)
Implementation notes for edge cases and quirks
Output 2 (AI_PROMPT.md): Natural language generation instructions
Imperative directives ("Create documents with these exact settings:")
Critical warnings ("CRITICAL: Use these exact fonts and sizes - no substitutions")
Usage context for each design element ("Primary color: #0078D4 for headings and accents")
Quality checklist to validate output ("Verify all colors use exact hex values")
Common mistake warnings ("Do NOT approximate colors - use exact hex codes")
Principle 3: Verification Through Recreation
Extraction accuracy is validated by using the generated specification to recreate a test document, then comparing it visually and structurally to the original. This closes the loop and ensures specifications are not just theoretically correct but practically actionable.
Why This Matters: Specifications can be technically accurate but incomplete, omitting critical details that only become apparent during recreation. A color scheme might be extracted perfectly, but if table border rules are missing, the recreated document will differ visibly. Verification through recreation catches these gaps before specifications are used in production.
In Practice:
Generate a test document using the AI_PROMPT.md instructions
Compare side-by-side with the original using visual diff tools
Check font rendering, color matching, spacing consistency, and layout alignment
Validate that embedded assets (logos, images) are correctly positioned and sized
Test with multiple content samples to ensure template generalizes beyond the original
Document any discrepancies in TEMPLATE_SPEC.md implementation notes
Iterate on specifications until recreation achieves >95% visual fidelity
Workflow
Phase 1: Document Analysis
Objective: Identify document type and unpack file structure to access underlying XML and assets.
Page size: Letter (8.5x11"), A4, or custom dimensions
Orientation: Portrait or landscape
Margins: Top, bottom, left, right (inches or cm)
Headers & Footers
Header content: Text, logo, page numbers
Header height: Distance from top (inches)
Footer content: Text, page numbers, date
Footer height: Distance from bottom (inches)
Different first page: Yes/no
Structure
Section Organization
Number of main sections: Typical structure
Section dividers: Lines, spacing, page breaks
Numbering scheme: 1.0, 1.1, 1.1.1 or I, A, 1, a
Content Blocks
Introduction/overview placement
Conclusion/summary placement
Sidebar/callout box styling
Tables
Structure
Header row: Background color, text color, font weight
Border style: Solid, none, partial (which sides)
Border color: Hex code
Border width: Pixels or points
Cell padding: Top, right, bottom, left
Content
Header text: Font, size, alignment
Cell text: Font, size, alignment
Alternating row colors: Yes/no, colors if yes
Lists
Bullet Lists
Bullet style: Disc, circle, square, custom character
Bullet color: Same as text or different hex code
Indentation: First level, nested levels
Spacing: Between items (pt)
Numbered Lists
Number style: 1, a, i, roman numerals
Number formatting: Period, parenthesis, none
Indentation: First level, nested levels
Branding Elements
Logo
Filename and format extracted: e.g., logo.png, logo.svg
Dimensions: Width x height (px or inches)
Position: Page location (header, title page, footer, etc.)
Margins: Space around logo (inches)
Placement on: Every page, first page only, specific pages
Brand Colors
Match to palette: Ensure brand colors documented in color system
Specific usage rules: Logo colors vs accent colors vs functional colors
Special Elements
Callout/Info Boxes
Background color: Hex code
Border: Style (solid/dashed), color (hex), width (px), radius (px)
Padding: Internal spacing (pt)
Icon: Type, color, position (if applicable)
Dividers/Lines
Style: Solid, dashed, dotted
Color: Hex code
Width: Points or pixels
Spacing: Above and below (pt)
Code/Technical Blocks (if applicable)
Font family: Monospace choice (e.g., Consolas, Courier New)
Background color: Hex code
Border styling: Style, color, width
Syntax highlighting scheme: Colors for keywords, strings, comments
Document Metadata
Document title styling: Font, size, color, position
Author/date placement and styling
Version/revision styling
Confidentiality markings: If present, font, color, position
Measurement Conversion Reference
OOXML half-points to points: divide by 2
Example: <w:sz w:val="24"/> = 12pt
OOXML twips to points: divide by 20
Example: <w:spacing w:after="200"/> = 10pt
OOXML EMUs to inches: divide by 914400
Example: 914400 EMUs = 1 inch
Points to pixels (at 96 DPI): multiply by 1.333
Example: 12pt = 16px
Common Anti-Patterns
Anti-Pattern
Problem
Solution
Visual Estimation
Guessing colors/fonts from appearance leads to inaccuracy. "That looks like 14pt Arial" may actually be 13pt Calibri, causing subtle but compounding inconsistency.
Always extract from XML source files. Use styles.xml for fonts, theme1.xml for colors. Convert OOXML units precisely.
Skipping Verification
Generated templates may drift from original due to missing specifications or ambiguous instructions. Without testing, errors only surface in production.
Always verify by recreation and visual comparison. Generate test document using AI_PROMPT.md, compare side-by-side, iterate until >95% fidelity.
Missing Assets
Forgetting to extract logos/images breaks branding and layout. Even if specifications are perfect, missing media ruins output.
Check word/media/, ppt/media/, xl/media/ directories in all unpacked documents. Copy all files to assets/ and document in ASSETS.md.
Unit Conversion Errors
OOXML uses half-points, twips, and EMUs. Forgetting conversions leads to 2x font sizes, incorrect margins.
Use conversion formulas: half-points ÷ 2, twips ÷ 20, EMUs ÷ 914400. Validate converted values against visual inspection.
Ignoring Edge Cases
First page headers, section breaks, and linked styles have special behavior. Assuming uniform formatting causes inconsistency.
Document all variations in TEMPLATE_SPEC.md implementation notes. Test recreation with multi-page, multi-section documents.
Incomplete Color Extraction
Extracting only theme colors misses table borders, callout backgrounds, and special element styling.
Use extraction checklist to systematically capture core palette AND functional colors. Check every visual element.
Approximating Measurements
Rounding margins to "about 1 inch" or spacing to "roughly 10pt" compounds across pages.
Extract and document exact values. Use original OOXML values, not rounded approximations.
Single-Sample Testing
Verifying with only the original content hides template generalization issues. New content may break layout.
Test recreation with multiple content samples: different lengths, varied structure, additional tables/lists. Ensure template generalizes.
Forgetting Fallback Fonts
Primary font may not be available on all systems. No fallback causes browser/OS substitution, ruining design.
Document font stack with fallbacks: "Calibri, Arial, Helvetica, sans-serif". Test on systems without primary font.
Mixing RGB and Hex
Inconsistent color notation causes confusion. Hex in some places, RGB in others leads to translation errors.
Standardize on hex for all color specifications. Include RGB as reference in tables, but use hex as primary.
Automation Script
The scripts/extract_template.py Python helper automates the extraction workflow for Office documents:
Usage:
python scripts/extract_template.py <document_path> <output_dir>
# Example
python scripts/extract_template.py company_report.docx ./extracted_template
What It Does:
Detects document type (DOCX/PPTX/XLSX)
Unpacks ZIP structure to output_dir/unpacked/
Extracts theme colors from theme1.xml
Extracts theme fonts (major/minor)
Extracts style definitions from styles.xml (DOCX)
Extracts page settings from document.xml (DOCX)
Copies media assets to output_dir/assets/
Generates extraction_results.json with all extracted data
Prints summary with key findings
Output Structure:
extracted_template/
├── unpacked/ # Full ZIP contents
├── assets/ # Copied media files
├── extraction_results.json # Raw extraction data
└── [manual step: create TEMPLATE_SPEC.md and AI_PROMPT.md]
Next Steps After Script:
Review extraction_results.json for raw data
Inspect unpacked/ directory for detailed XML
Check assets/ for logos and images
Use extraction data to complete TEMPLATE_SPEC.md using Output 1 template
Generate AI_PROMPT.md using Output 2 template
Run Phase 5 verification
Limitations:
Does not generate final Markdown outputs (manual step required)
PDF support limited to metadata extraction
Complex table styles may need manual review
Conditional formatting (Excel) not fully captured
Conclusion
Template Extractor transforms document reverse-engineering from a manual, error-prone guessing process into a systematic, verifiable workflow. By unpacking file structures and parsing XML directly, it provides ground-truth specifications that enable pixel-perfect recreation without iteration cycles.
The dual-output approach (technical specification + AI prompt) ensures both developers and AI systems have actionable, precise instructions tailored to their needs. The verification phase closes the loop, validating that specifications are not just theoretically correct but practically usable.
This skill is essential for teams needing document consistency across multiple files, for migrating formatting between systems, and for creating reusable branded document generators. By eliminating guesswork and manual measurement, it accelerates document production while guaranteeing visual fidelity.
Use this skill whenever precision matters more than approximation - when "close enough" is not acceptable and exact replication is required.
Related Skills
doc-generator: Generates documents from scratch using specifications (complementary - uses Template Extractor output)
