Report To Google Doc logo

Report To Google Doc

Community
ahang1598
report-to-google-doc

Narrow conversion skill. Invoke only when the user explicitly asks to convert an existing local or blob-hosted HTML analytics report into a Google Doc, DOCX, or shareable document.

Overview

Publisherahang1598
Repositorydoubao-workbuddy-qwenwork-skills
Skill namereport-to-google-doc
Stars
90
Forks
35
Bundled files
14
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 14 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by ahang1598 on GitHub. Read the source before you install it.

Installation

Install the Report To Google Doc AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/ahang1598/doubao-workbuddy-qwenwork-skills/tree/main/chatgpt/plugins/openai-curated-remote/data-analytics/0.2.8-13ceeea1f599/skills/build-report/report-to-google-doc
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/ahang1598/doubao-workbuddy-qwenwork-skills.git /tmp/doubao-workbuddy-qwenwork-skills
mkdir -p .claude/skills
cp -r /tmp/doubao-workbuddy-qwenwork-skills/chatgpt/plugins/openai-curated-remote/data-analytics/0.2.8-13ceeea1f599/skills/build-report/report-to-google-doc .claude/skills/report-to-google-doc
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Report To Google Doc in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Report To Google Doc on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Report To Google Doc is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Report To Google Doc

Use this skill only when the user explicitly needs a shareable Google Drive document from an existing HTML analytics report. The source must be an HTML report: a local file, a downloaded blob-hosted report, or a report produced by $build-report HTML mode with the portable builder. This skill does not convert a live MCP app report directly.

The expected path is HTML -> DOCX -> Drive upload. It is acceptable for Drive to host the upload as a DOCX-backed viewer file rather than a native Google Docs MIME type. Do not use the old Google Docs batch-update request path.

Workflow

  1. Resolve the HTML report.

    Use an absolute local path. If the user provides a remote report, retrieve it first and pass the local HTML file to the helper. If the file is a sign-in page, redirect page, or tiny stub, stop and obtain the real report.

  2. Run the bundled helper.

    bash
    python3 <REPORT_TO_GOOGLE_DOC_SKILL_DIR>/scripts/report_to_google_doc_plan.py \
      /absolute/path/to/report.html \
      --out-dir /tmp/report_to_google_doc_plan

    Omit --render-workers on the normal path. Only pass a worker count after benchmarking the same report family locally. If dependencies are missing, use a local virtual environment with beautifulsoup4, pillow, and python-docx; cairosvg or headless Playwright are optional renderers.

  3. Inspect helper outputs.

    Required outputs:

    • skeleton.txt: source text with stable placeholders
    • manifest.json: parsed headings, tables, callouts, lists, styles, links, and rendered visual inventory
    • preflight_checks.json: source, width, DOCX, and rendered-image checks
    • report.docx: generated local Word document
    • docx_upload_plan.json: compact upload instructions
    • placeholder_queries.json: source mapping debug labels

    Do not upload until preflight_checks.json has status: "passed" with zero errors. Warnings must either be fixed or called out in the handoff.

  4. Upload the DOCX.

    json
    mcp__codex_apps__google_drive._upload_file({
      "file_uri": "/tmp/report_to_google_doc_plan/report.docx",
      "file_name": "Report Name.docx",
      "mime_type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
    })

    Treat the returned Drive URL as the deliverable. Do not attempt to force native Google Docs conversion, and do not fall back to _batch_update_document.

  5. Validate the uploaded result.

    Confirm the uploaded file is readable and non-empty. Compare uploaded text against the source inventory: title, section headings, executive summary or answer callout, caveats, recommendations, source notes, and source links. Inspect the local report.docx structure when available: heading counts, lists, tables, hyperlink relationships, and image relationships should match manifest.json.

  6. Hand off the link.

    Return the Drive/Docs URL and, when useful, the local DOCX path or source HTML path. Connector success alone is not enough; the handoff is complete only after the uploaded file and local DOCX structure have been checked against the source report. Keep routine check and preflight details in support artifacts. Do not list internal checks in the user-facing handoff unless a check failed, was unavailable, or produced a user-relevant caveat.

Standards

  • Preserve every section, headline claim, metric card, metric definition, source note, chart takeaway, recommendation, caveat, and link from the HTML report.
  • Preserve semantic formatting: headings, paragraphs, inline bold/emphasis, inline code, positive/negative colors, links, lists, callouts, metric-card grids, tables, notes, captions, and charts.
  • Use DOCX-native structures wherever practical: headings, paragraphs, tables, bullets/numbered lists, links, inline images, paragraph shading, table cell shading, and text styles.
  • Keep the report text column readable. Tables, charts, rendered table grids, screenshots, and visual blocks must not exceed the DOCX page text width.
  • Preserve charts as inline images rendered from the portable reader's source visual or builder-generated semantic chart-data representation, aligned to the same left edge as text and tables. A chart with missing bars, missing legend swatches, or all-black/all-white marks fails validation even if the DOCX contains an image object.
  • Preserve multi-column report blocks. A two-column grid made only of titled mini-tables can remain a two-column rendered image capped to the text width; mixed two-column blocks with narrative text, pills, callouts, or non-table panels should preserve that content natively instead of dropping it.
  • Do not expose customer-level details or sensitive links that were intentionally omitted from a sanitized report.
  • Do not write Google Docs batch-update artifacts such as seed_requests.json, remote_write_plan.json, or all_requests*.json.

Repairs

Use these fixes when validation exposes a conversion issue:

ProblemFix
Heading is regular weightFix the DOCX writer heading style or explicit run bolding.
Blank line after title or headingDelete spacer paragraphs; skeletons should emit \n, not \n\n, after headings.
Body paragraphs have too much spaceDelete literal blank paragraphs and set modest style spacing.
Table/image too wideSet table columns or image width to the DOCX text column width.
Chart has labels but missing barsInline SVG class styles or use a headless screenshot before inserting.
Two-column table group is flattenedTreat the grid as one layout block with mini-table titles preserved.
Executive summary, metric cards, or section is missingFix parser inventory before upload.
Chart overlaps tableInsert the image on its own paragraph after the table.
Chart duplicatedRemove the extra image; keep exactly one source-order copy.
Inline bold/code/color missingFix manifest range splitting in the DOCX writer.
Source links show raw URLsReplace with native linked labels or native bullets using HTML link text.

Local Checks

bash
python3 -m py_compile <REPORT_TO_GOOGLE_DOC_SKILL_DIR>/scripts/report_to_google_doc_plan.py
python3 <REPORT_TO_GOOGLE_DOC_SKILL_DIR>/scripts/report_to_google_doc_plan.py \
  /absolute/path/to/report.html \
  --out-dir /tmp/report_to_google_doc_plan_smoke
jq '.status, .summary' /tmp/report_to_google_doc_plan_smoke/preflight_checks.json
test -f /tmp/report_to_google_doc_plan_smoke/report.docx
test -f /tmp/report_to_google_doc_plan_smoke/docx_upload_plan.json
git diff --check -- plugins/data-analytics/skills/build-report/report-to-google-doc

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Report To Google Doc AI skill do?

Narrow conversion skill. Invoke only when the user explicitly asks to convert an existing local or blob-hosted HTML analytics report into a Google Doc, DOCX, or shareable document.

Why use Report To Google Doc on TypingMind?

Because you install it once and use it with any model. Report To Google Doc is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Report To Google Doc in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/ahang1598/doubao-workbuddy-qwenwork-skills/tree/main/chatgpt/plugins/openai-curated-remote/data-analytics/0.2.8-13ceeea1f599/skills/build-report/report-to-google-doc. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Report To Google Doc?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Report To Google Doc?

As many as you like. As long as a model supports skills, you can use Report To Google Doc with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Report To Google Doc AI skill free?

It is published on GitHub by ahang1598. Check the repository for licensing terms. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇