WIP gdocs and gslides updates

plugins/google-docs/skills/google-docs/SKILL.md

@@ -5,31 +5,89 @@ description: Summarize and revise connected Google Docs. Use when the user asks
 
 # Google Docs
 
+## Critical Rules
+
+- YOU MUST USE CONNECTORS IF THEY ARE AVAILABLE.
+- PLEASE TRIPLE CHECK THAT A CONNECTOR IS AVAILABLE BEFORE FALLING BACK TO ATLAS, if available.
+- MUST use the Google Docs connector for normal Google Docs tasks.
+- MUST NOT use Atlas, if available, to create, edit, format, rewrite, place images in, or fill a Google Doc when the Docs connector exists.
+- MUST NOT claim the connector is read-only, unavailable, or broken without first proving that with a minimal live connector write and readback.
+- If the connector path truly cannot perform the task, STOP and report the limitation plainly. Do not continue the document-writing work in Atlas.
+- Finishing a Google Docs task in Atlas after the connector path failed is a launch-blocking failure.
+
 ## Overview
 
 Use this skill to turn document content into clear summaries, revision plans, and structured edits. Read the document first, preserve its organization, and distinguish between summarizing, rewriting, and directly editing content.
 
+Use the Google Docs connector for all document lookup, reading, creation, copying, and editing work. This is mandatory. Do not use Atlas, if available, for normal Google Docs work. If the runtime exposes the Docs connector, document authoring and editing must stay on the connector path.
+
+If the target doc is a template and the user wants edits, fill-in, or a generated deliverable, create or attach to a copy first and edit the copy rather than mutating the template itself.
+
 ## Preferred Deliverables
 
 - Document briefs that summarize purpose, structure, and missing or weak sections.
 - Revision plans that show which headings or sections will change and why.
 - Rewritten passages that preserve the surrounding structure and audience.
+- Edited template copies that preserve the source template while producing a clean destination document.
+
+## Required Tooling
+
+Confirm the runtime exposes the relevant Google Docs connector actions before editing:
+- `search_documents` when the user does not provide a target doc URL or ID
+- `get_document_text`
+- `get_document`
+- `batch_update`
+- `create_document` when making a new destination doc
+- a connector path for copy/duplicate when editing from a template
+- `get_tables` when table structure or styling matters
+
+If a needed capability is missing from the connector, say that clearly. Do not switch to Atlas, if available, just because it feels familiar, because the connector workflow takes more steps, or because one request failed.
+
+Do not infer that the connector is read-only, missing, or broken from friction, one failed request shape, or uncertainty about a tool wrapper. Verify with a minimal connector pilot write and readback first. A hallucinated "connector is read-only" claim is a serious failure.
 
 ## Workflow
 
-1. Read the document structure before writing. Capture the title, major headings, important sections, and any existing style or organization that should be preserved.
-2. Decide whether the request is a summary, a targeted edit, or a broader rewrite. If the scope is unclear, summarize the current state before proposing changes.
-3. For larger edits, present a revision plan before applying changes. Make the intended section-level updates easy to review.
-4. Preserve the document's structure while drafting. Keep headings, section order, and existing intent unless the user asks for a reorganization.
-5. If the user asks for a revision but not direct editing, default to a proposed rewrite or section-by-section plan.
-6. Only apply major rewrites or destructive edits when the user has clearly requested them.
+1. Identify the exact destination document through the connector.
+- If the user gives only a title or keywords, search for the doc instead of asking for a full URL.
+- If the source is a template and the user wants an edited deliverable, make a copy first and treat that copy as the working destination.
+
+2. Read the document structure before writing.
+- Capture the title, major headings, important sections, tables, and any existing style or organization that should be preserved.
+- When the document has tabs, resolve the correct tab and keep using it for reads and writes.
+- If this is a template-fill task, identify the canonical output shape before drafting: existing answer cells, peer tables, status chips, mentions, smart chips, dropdowns, and other structured elements are part of the document contract, not cosmetic details.
+
+3. Decide whether the request is a summary, a targeted edit, or a broader rewrite.
+- If the scope is unclear, summarize the current state before proposing changes.
+- For larger edits, present a revision plan before applying changes.
+
+4. Preserve the document's structure while drafting.
+- Keep headings, section order, and existing intent unless the user asks for a reorganization.
+- If the user asks for a revision but not direct editing, default to a proposed rewrite or section-by-section plan.
+
+5. For template fidelity, tables, and structured controls, read [template-matching-and-tables](./references/template-matching-and-tables.md).
+
+6. For hyperlinks, mentions, chips, and dropdown preservation, read [hyperlinks-and-entities](./references/hyperlinks-and-entities.md).
+
+7. For visually sensitive docs, perform a rendered QA pass before handoff. Read [visual-qa](./references/visual-qa.md).
+
+8. Only apply major rewrites or destructive edits when the user has clearly requested them.
 
 ## Write Safety
 
+- NEVER move a normal Google Docs task into Atlas just because the connector path feels annoying, unfamiliar, slower, or more verbose.
+- NEVER treat a single failed request as permission to abandon the connector path.
+- NEVER complete the actual document authoring in Atlas after a successful connector read or write.
+- Use connector reads and writes as the source of truth. Do not route the task through Atlas, if available, for normal document creation, writing, formatting, image placement, hyperlinking, or template fill work.
+- If the working source is a template, protect the original by editing a copy.
+- Prove the connector write path early. For document creation or template-fill work, make a small connector-authored write and verify it before doing the main authoring work.
+- Treat a browser-corrupted template as evidence that the Atlas path is fragile, not as permission to abandon the template shape.
+- Do not treat a failed request payload, a stale revision ID, or an incorrect write-control shape as connector unavailability. Fix the payload and retry through the connector.
+- If the connector pilot write succeeds, the remainder of the document authoring must stay on the connector path. Do not move the document-writing path into Atlas afterward.
 - Preserve exact section names, links, dates, and structured content from the source document unless the user asks to change them.
 - Treat long-form rewrites, deletions, and restructuring as explicit actions that should be clearly scoped.
 - If a request could be satisfied with either comments, a revision plan, or direct edits, state which path you are taking.
 - If the document has multiple sections with similar themes, identify the exact target section before editing.
+- If the required connector write capability truly is unavailable in this run, stop and say so plainly instead of completing the write through Atlas. Do not "save the run" by finishing the doc in Atlas. That is a launch-blocking failure, not an acceptable workaround.
 
 ## Output Conventions
 
@@ -38,6 +96,9 @@ Use this skill to turn document content into clear summaries, revision plans, an
 - When presenting rewrites, label the affected section so the user can compare old and new structure easily.
 - Keep rewritten text aligned with the existing audience and purpose unless the user asks to change tone or format.
 - When summarizing, lead with the main purpose of the document and then list the most important sections or unresolved gaps.
+- When editing from a template, say whether you worked in the original or in a copy. Default to calling out the copied destination.
+- For template-fill work, call out whether the final result preserved the original template structure and any existing structured controls.
+- For visually sensitive docs, call out that you performed a rendered visual check before handoff.
 
 ## Example Requests
 

plugins/google-docs/skills/google-docs/references/hyperlinks-and-entities.md

@@ -0,0 +1,11 @@
+# Hyperlinks And Entities
+
+Read this file when the document includes source links, appendix/reference sections, mentions, chips, dropdowns, or other semantic inline entities.
+
+- Use readable linked labels instead of raw pasted URLs unless the template explicitly requires visible raw URLs.
+- If content includes a URL that is meant to be a source or reference, convert it into an actual hyperlink instead of leaving it as plain text.
+- Apply links after the final text is in place. Re-read the document and resolve the exact visible label range before styling it as a hyperlink.
+- Link the full intended phrase, especially inside tables. Partial-link formatting is a failure.
+- In appendix or reference sections, do not leave naked URLs when a readable source label would work. The visible text should be human-readable and clickable.
+- Preserve existing `@` mentions, smart chips, dropdowns, and similar semantic inline entities when editing nearby text.
+- Do not silently downgrade a mention, chip, or dropdown into an ordinary hyperlink or plain text label.

plugins/google-docs/skills/google-docs/references/template-matching-and-tables.md

@@ -0,0 +1,22 @@
+# Template Matching And Tables
+
+Read this file when the task involves template-fill work, document-native formatting, or table creation/editing.
+
+## Template Matching
+
+- Match the nearest true peer content, not a generic Docs default.
+- Before inserting a new heading, body block, or table, inspect nearby peer content and capture the local baseline: heading level, font family, body sizing, emphasis pattern, spacing, and table treatment.
+- If the template uses structured containers such as tables, cells, or form-like sections, preserve that structure unless the user explicitly asks for a reformatted rewrite.
+- Do not flatten a template-driven control into plain text. Status chips, dropdowns, mentions, smart chips, and similar structured elements should stay structured.
+- If the current write path cannot safely recreate a structured control, preserve the existing control and edit around it rather than silently replacing it with raw text.
+- Treat visible mismatch in headings, tables, links, inline entities, or template container shape as a failed output that still needs repair.
+
+## Tables
+
+- Match the nearest comparable table in the document before inventing a new pattern.
+- Prefer copying the nearest comparable section or table structure in the document as the style baseline. New text and tables should disappear into the template rather than looking newly generated.
+- If the template already contains the target table or answer cell, fill that structure instead of appending a parallel draft somewhere else.
+- Unless the user or template clearly wants something else, new tables must have a visibly colored header row, fully bold header text, and alternating white/light-gray body rows. The default header fill should be baby blue.
+- Keep tables compact and readable. If a schema feels cramped, reduce column count instead of squeezing the page.
+- Do not create a foreign-looking standalone table when a nearby peer table already establishes the right border treatment, fills, widths, or typography.
+- If a table still looks plain, unstyled, or inconsistent with the rest of the document, keep fixing it before handoff.

plugins/google-docs/skills/google-docs/references/visual-qa.md

@@ -0,0 +1,17 @@
+# Visual QA
+
+Read this file when formatting quality matters, especially for templates, briefs, handoff docs, or docs with tables, images, appendix content, or structured controls.
+
+## Verification Loop
+
+- After creation or major edits, inspect the rendered document rather than trusting the write requests alone.
+- Prefer connector-native reads for structure and content verification, but also visually render the document when formatting quality matters.
+- If connector reads are not enough to judge visual quality, Atlas, if available, may be used only to open the finished doc and capture screenshots for visual inspection. Do not use Atlas to do the document authoring.
+- If the rendered document shows ugly tables, missing link styling, broken spacing, flattened structured controls, or other visual drift, iterate and fix those issues before handoff.
+
+## Failure Conditions
+
+- Treat visible formatting drift as a real failure. If headings, labels, tables, links, or body text do not look native to the document, keep fixing them before handoff.
+- Treat missing hyperlink styling as a real failure when the document is supposed to contain links.
+- Treat a plain, unfilled, or unbolded table header as a real failure unless the surrounding document clearly uses that style intentionally.
+- If a source document already contains mentions, chips, status controls, or other structured inline entities, verify they are still present and semantically intact before handoff.

plugins/google-slides/skills/google-slides-import-presentation/SKILL.md

@@ -5,10 +5,21 @@ description: Import a local `.ppt`, `.pptx`, or `.odp` file into Google Slides,
 
 # Google Slides Import Presentation
 
+## Critical Rules
+
+- YOU MUST USE CONNECTORS IF THEY ARE AVAILABLE.
+- PLEASE TRIPLE CHECK THAT A CONNECTOR IS AVAILABLE BEFORE FALLING BACK TO ATLAS, if available.
+- MUST use the Google Slides connector to import the file into native Google Slides.
+- MUST NOT use Atlas, if available, as a substitute import path or as a way to keep editing the original local file.
+- If import truly is unavailable, STOP and say so plainly. Do not continue by editing the source file in Atlas.
+- Finishing this import flow in Atlas instead of native Google Slides is a failure.
+
 ## Overview
 
 Use this skill when the source material is a presentation file rather than an existing Google Slides deck. The goal is to create a native Google Slides copy first, then continue work on the imported deck.
 
+Use the Google Slides connector for the import and all follow-on deck reads. This is mandatory. Do not use Atlas, if available, for import or post-import inspection when the connector supports the task.
+
 ## Required Tooling
 
 Confirm the runtime exposes:
@@ -17,6 +28,7 @@ Confirm the runtime exposes:
 - `get_slide_thumbnail` when visual verification matters
 
 If `import_presentation` is unavailable, stop and say the file cannot be converted into native Google Slides from Codex.
+Do not replace a missing connector import path with Atlas, if available, editing of the original file. Do not "save the run" by working in Atlas on the source file instead.
 
 ## Workflow
 
@@ -27,6 +39,7 @@ If `import_presentation` is unavailable, stop and say the file cannot be convert
 2. Import the presentation.
 - Use `import_presentation` to create a new native Google Slides deck.
 - If the user gives a destination title, use it. Otherwise keep the imported title.
+- Treat the imported Google Slides deck as the editable copy. Do not keep editing the original Office file path.
 
 3. Read the imported deck.
 - Capture the resulting presentation ID or URL, slide count, and major slide titles.
@@ -43,6 +56,10 @@ If `import_presentation` is unavailable, stop and say the file cannot be convert
 
 ## Rules
 
+- NEVER keep editing the original Office file in Atlas when the task is to work in Google Slides.
+- NEVER treat one failed import attempt as permission to abandon the connector path.
+- Connector-first is mandatory for import and verification. Do not use Atlas, if available, as a substitute import path or post-import editing path.
+- Do not interpret one failed import attempt, wrapper mismatch, or request-shape error as proof that import is impossible.
 - Treat import as conversion into a new native Google Slides deck, not in-place editing of the original file.
 - Preserve source slide order and content by default.
 - Do not promise perfect fidelity for animations, transitions, SmartArt, or other Office-specific features.

plugins/google-slides/skills/google-slides-template-migration/SKILL.md

@@ -5,6 +5,17 @@ description: Migrate a Google Slides deck onto a target template. Use when the u
 
 # Google Slides Template Migration
 
+## Critical Rules
+
+- YOU MUST USE CONNECTORS IF THEY ARE AVAILABLE.
+- PLEASE TRIPLE CHECK THAT A CONNECTOR IS AVAILABLE BEFORE FALLING BACK TO ATLAS, if available.
+- MUST use the Google Slides connector for migration work.
+- MUST NOT migrate by manually rebuilding or emulating the deck in Atlas, if available, when the Slides connector exists.
+- If the connector path truly cannot perform the required migration step, STOP and report that plainly. Do not finish the migration in Atlas.
+- A failed migration batch is not permission to abandon the connector path.
+
+Use the Google Slides connector for all source/template lookup, slide duplication, reads, thumbnails, and writes. This is mandatory. Do not use Atlas, if available, for migration work when the connector supports it.
+
 Use this skill when the user has:
 - a source deck whose content should be kept
 - a target template deck whose visual system should be adopted
@@ -23,12 +34,15 @@ Confirm the runtime exposes:
 - `batch_update`
 
 If the user is starting from a local `.pptx`, also confirm `import_presentation`.
+If required connector actions are missing, say so explicitly before considering any fallback path.
+Verify with a minimal representative connector action before concluding that a required action is missing. Do not hallucinate connector failure because one request shape was wrong.
 
 ## Core Workflow
 
 1. Identify the two decks.
 - Source deck: the content to preserve.
 - Template deck: the company deck or branded presentation whose layout language should be reused.
+- Use connector search and connector reads to resolve both decks before touching either one.
 
 2. Read both decks before editing.
 - Build a slide inventory for the source deck.
@@ -43,6 +57,7 @@ If the user is starting from a local `.pptx`, also confirm `import_presentation`
 4. Duplicate from the template, not from the source.
 - Prefer duplicating the closest matching template slide and then adapting it.
 - Do not try to “convert” the old slide in place when a clean template pattern already exists.
+- Treat the template as a source for reusable slides through the connector workflow, not as something to manually emulate in Atlas, if available.
 
 5. Port content into the duplicated template slide.
 - Replace title and body text.
@@ -58,11 +73,14 @@ If the user is starting from a local `.pptx`, also confirm `import_presentation`
 
 ## Migration Rules
 
+- Connector-first is mandatory. Do not use Atlas, if available, to migrate slides that the connector can read, duplicate, and edit.
+- A failed batch shape or bad object reference is not evidence that the connector lacks migration support.
 - The template is the source of truth for layout, margins, hierarchy, and decorative style.
 - The source deck is the source of truth for content.
 - Preserve content by default; do not silently drop claims, bullets, data, or charts just to make the slide fit.
 - When a source slide is denser than the template pattern allows, split the content across multiple template-based slides.
 - Keep the migration deterministic. One source slide should map to one explicit template archetype or a deliberate split.
+- If the required migration capability truly is unavailable, stop and say so plainly instead of finishing the migration in Atlas. That workaround is not acceptable.
 
 ## Preferred Strategy