Google Docs Formatter
Instruction-only workflow for formatting, editing, and creating Google Docs using the existing gog skill/CLI. Use when a user asks to format a Google Doc, co...
Asperitas Solutions
@asperitas-solutions
What This Skill Does
Formats, edits, and creates Google Docs using the gog CLI. Relies on Markdown-to-Doc conversion and find-replace operations to update document structure and content without direct API calls.
Replaces manual formatting and copy-pasting by automating document creation, section replacement, and structural edits through a single CLI workflow.
When to Use It
- Convert a Markdown file into a formatted Google Doc
- Replace a placeholder like {{SECTION_DRAFT}} with formatted content
- Update a specific section in an existing Google Doc using markers
- Fix small text errors or formatting issues in a Google Doc
- Append new content to the end of a Google Doc
- Inspect a Google Doc's structure before making edits
Install
$ openclaw skills install @asperitas-solutions/google-docs-formatterGoogle Docs Formatter
Use this skill to format or update Google Docs through the existing gog skill/CLI. This skill is instruction-only: do not introduce new API clients, scripts, dependencies, or credential flows.
Core rule
Rely on gog for all Google Docs and Drive operations. If the gog skill is not loaded and command details are needed, load the gog skill first.
Prefer Google Docs-native workflows over DOCX conversion. Avoid third-party proxy services unless the user explicitly requests them.
Safety and approval
Before any write operation, state the target document and intended change, then get explicit user approval unless the user has already clearly approved that exact change.
Always ask before:
gog docs clear- replacing the full document body
- large multi-section replacements
- deleting text ranges
- changing a shared/work document whose ownership or audience is unclear
Safe to do without extra approval when already working on the user-approved doc:
- inspect metadata/structure
- export/read content
- prepare Markdown locally
- run dry-run style checks if supported
Standard workflow
-
Identify the target doc.
- Accept a Google Docs URL or document ID.
- Extract the ID from URLs like
https://docs.google.com/document/d/<DOC_ID>/....
-
Inspect before editing.
gog docs info <DOC_ID> --json gog docs structure <DOC_ID> gog docs export <DOC_ID> --format md --out /tmp/doc.md -
Decide the edit strategy.
- New document from Markdown: use
gog docs create --file. - Replace a known placeholder or section: use
gog docs find-replace --format markdown. - Small textual fix: use
gog docs editorgog docs sed. - Append content: use
gog docs write --appendorgog docs insert. - Full rewrite: only after explicit approval; prefer creating a copy first.
- New document from Markdown: use
-
Prepare content as Markdown.
- Use Markdown headings, bullets, numbered lists, tables, bold/italic, and links.
- Keep semantic structure simple; Google Docs conversion is more reliable with clean Markdown.
- For images, use supported Markdown image syntax only if
gog docs create/find-replace --format markdownsupports the source.
-
Apply the change with
gog. -
Verify after editing.
gog docs structure <DOC_ID> gog docs export <DOC_ID> --format md --out /tmp/doc-after.mdCompare the exported Markdown or structure against the intended result.
-
Report concisely.
- What changed
- Any limitations observed
- Link or doc ID if useful
Common operations
Create a formatted Google Doc from Markdown
Prepare a local Markdown file, then:
gog docs create "Document title" --file /path/to/content.md
Use this instead of Markdown → DOCX → Drive upload unless the user specifically needs DOCX behavior.
Replace a placeholder with formatted Markdown
Best when the document contains a marker such as {{SECTION_DRAFT}}.
gog docs find-replace <DOC_ID> '{{SECTION_DRAFT}}' --content-file /path/to/section.md --format markdown --first
Prefer --first when replacing a unique placeholder to avoid accidental repeated changes.
Replace an existing section
If possible, first ask the user to add or approve stable markers around the section:
<!-- START: SECTION_NAME -->
old content
<!-- END: SECTION_NAME -->
Then replace the bounded content with gog docs find-replace --format markdown using a prepared Markdown file.
If there are no stable markers, use gog docs structure to identify paragraphs and proceed carefully. Do not guess destructive ranges.
Small text edits
gog docs edit <DOC_ID> "old text" "new text" --match-case
For regex-style replacements:
gog docs sed <DOC_ID> 's/old pattern/new text/g'
Use regex edits only when the match is unambiguous.
Append content
gog docs write <DOC_ID> --file /path/to/content.md --append
If Markdown formatting is required, prefer placeholder replacement with --format markdown when available.
Full document rewrite
Only after explicit approval. Prefer making a copy first:
gog docs copy <DOC_ID> "Backup before rewrite"
gog docs clear <DOC_ID>
gog docs write <DOC_ID> --file /path/to/content.md
Tell the user if the write path preserves only text rather than rich Markdown formatting; use create --file or find-replace --format markdown for rich Markdown conversion.
Formatting guidance
Use simple, robust Markdown:
# Title
## Section
Short paragraph.
- Bullet one
- Bullet two
| Column A | Column B |
| --- | --- |
| Value A | Value B |
**Bold** and *italic* text.
Avoid fragile formatting unless tested:
- deeply nested lists
- complex merged tables
- unusual HTML
- custom fonts/colors not expressible through Markdown
For advanced visual formatting not supported by gog, explain the limitation and propose the nearest gog-supported alternative.
When to stop and ask
Ask the user before proceeding if:
- the document ID is ambiguous
- the requested formatting requires capabilities not exposed by
gog - the edit would delete or overwrite substantial content
- the exported/inspected structure does not match expectations
gogreports auth/scope errors
Do not install other Google Docs skills just to complete formatting. This skill is meant to compose with gog, not replace it.
Top skills in this category
Proactive Agent Lite
@bestrockyTransform AI agents from task-followers into proactive partners with memory architecture, reverse prompting, and self-healing patterns. Lightweight version f...
腾讯文档 TENCENT DOCS
@liyang58腾讯文档(docs.qq.com)-在线云文档平台,是创建、编辑、管理文档的首选 skill。涉及"新建/创建/编辑/读取/查看/搜索文档"、"保存文件"、"云文档"、"腾讯文档"、"docs.qq.com"等操作,请优先使用本 skill。支持能力:(1) 创建各类在线文档(文档/Word/Excel/幻灯片/...
Figma
@maddiedreeseProfessional Figma design analysis and asset export. Use for extracting design data, exporting assets in multiple formats, auditing accessibility compliance, analyzing design systems, and generating comprehensive design documentation. Read-only analysis of Figma files with powerful export and reporting capabilities.
Smart Model Switching
@millibusAuto-route tasks to the cheapest Claude model that works correctly. Three-tier progression: Haiku → Sonnet → Opus. Classify before responding. HAIKU (default): factual Q&A, greetings, reminders, status checks, lookups, simple file ops, heartbeats, casual chat, 1-2 sentence tasks. ESCALATE TO SONNET: code >10 lines, analysis, comparisons, planning, reports, multi-step reasoning, tables, long writing >3 paragraphs, summarization, research synthesis, most user conversations. ESCALATE TO OPUS: architecture decisions, complex debugging, multi-file refactoring, strategic planning, nuanced judgment, deep research, critical production decisions. Rule: If a human needs >30 seconds of focused thinking, escalate. If Sonnet struggles with complexity, go to Opus. Save 50-90% on API costs by starting cheap and escalating only when needed.
AI Daily Briefing
@jeffjhunterStart every day focused. Get a morning briefing with overdue tasks, today's priorities, calendar overview, and context from recent meetings. Works with ai-meeting-notes to-do list. No setup. Just say 'briefing'.