diff --git a/plugins/google-docs/skills/google-docs/SKILL.md b/plugins/google-docs/skills/google-docs/SKILL.md index f627be7f..2b4f84e1 100644 --- a/plugins/google-docs/skills/google-docs/SKILL.md +++ b/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 diff --git a/plugins/google-docs/skills/google-docs/references/hyperlinks-and-entities.md b/plugins/google-docs/skills/google-docs/references/hyperlinks-and-entities.md new file mode 100644 index 00000000..7d3b58ed --- /dev/null +++ b/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. diff --git a/plugins/google-docs/skills/google-docs/references/template-matching-and-tables.md b/plugins/google-docs/skills/google-docs/references/template-matching-and-tables.md new file mode 100644 index 00000000..bcfc411f --- /dev/null +++ b/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. diff --git a/plugins/google-docs/skills/google-docs/references/visual-qa.md b/plugins/google-docs/skills/google-docs/references/visual-qa.md new file mode 100644 index 00000000..9014bef1 --- /dev/null +++ b/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. diff --git a/plugins/google-slides/skills/google-slides-import-presentation/SKILL.md b/plugins/google-slides/skills/google-slides-import-presentation/SKILL.md index 27acaa78..439d7c2c 100644 --- a/plugins/google-slides/skills/google-slides-import-presentation/SKILL.md +++ b/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. diff --git a/plugins/google-slides/skills/google-slides-template-migration/SKILL.md b/plugins/google-slides/skills/google-slides-template-migration/SKILL.md index 8c1a5b22..77509689 100644 --- a/plugins/google-slides/skills/google-slides-template-migration/SKILL.md +++ b/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 diff --git a/plugins/google-slides/skills/google-slides-template-surgery/SKILL.md b/plugins/google-slides/skills/google-slides-template-surgery/SKILL.md index a95d153f..c4093c17 100644 --- a/plugins/google-slides/skills/google-slides-template-surgery/SKILL.md +++ b/plugins/google-slides/skills/google-slides-template-surgery/SKILL.md @@ -5,6 +5,17 @@ description: Perform structural rework in connected Google Slides decks. Use whe # Google Slides Template Surgery +## 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 template-surgery work. +- MUST NOT switch to Atlas, if available, for structural edits when the Slides connector exists. +- If the connector path truly cannot perform the needed structural edit, STOP and report that plainly. Do not finish the job in Atlas. +- A malformed batch or wrong object ID is not permission to abandon the connector path. + +Use the Google Slides connector for all reads, thumbnails, and structural edits. This is mandatory. Do not use Atlas, if available, for normal template-surgery work when the connector supports the operation. + Use this skill for structural Google Slides cleanup. This is the escalation path after normal visual iteration fails to converge. Start with local slide fixes first. Escalate to template surgery only when one of these is true: @@ -24,6 +35,7 @@ Confirm the runtime exposes: - `batch_update` If any of those are missing, stop and explain that the deck cannot be safely restructured from Codex. +Do not replace missing connector structure-editing support with ad hoc Atlas, if available, manipulation. Do not "save the run" by switching to Atlas. ## Workflow @@ -31,6 +43,7 @@ If any of those are missing, stop and explain that the deck cannot be safely res - Inventory slide types, repeated layouts, title patterns, image-heavy slides, and broken outliers. - Fetch the target slide structure with `get_slide` before writing. - Use live object IDs only. Never guess them. +- Keep the whole workflow grounded in connector state rather than Atlas state. 2. Decide whether to patch or rebuild. - Patch in place when the slide has the right elements but the geometry is bad. @@ -52,11 +65,14 @@ If any of those are missing, stop and explain that the deck cannot be safely res ## Structural Rules +- Connector-first is mandatory. Do not leave the connector path for normal template-surgery work. +- Do not treat one malformed structural batch as proof that the connector cannot perform template surgery. - Prefer duplicating a clean slide pattern over endlessly mutating a broken one. - Prefer deleting or replacing redundant elements over stacking new ones on top of old ones. - Preserve user content by default. Structural cleanup is not permission to rewrite the narrative. - Keep batches reversible. If the slide gets worse after a pass, correct the structure before adding more edits. - If repeated edits are failing, stop and explain what constraint is blocking clean automation. +- If the needed structural edit truly cannot be done through the connector, stop and say so plainly instead of finishing the job in Atlas. ## Common Surgery Cases diff --git a/plugins/google-slides/skills/google-slides-visual-iteration/SKILL.md b/plugins/google-slides/skills/google-slides-visual-iteration/SKILL.md index 15432cad..17579157 100644 --- a/plugins/google-slides/skills/google-slides-visual-iteration/SKILL.md +++ b/plugins/google-slides/skills/google-slides-visual-iteration/SKILL.md @@ -5,9 +5,19 @@ description: Iteratively improve connected Google Slides visuals. Use when the u # Google Slides Visual Iteration +## 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 visual diagnosis, thumbnails, and edits. +- MUST NOT switch to Atlas, if available, for normal slide cleanup, visual verification, or iterative editing when the Slides connector exists. +- If the connector path truly cannot perform the required edit or verification step, STOP and report that plainly. Do not continue the slide edits in Atlas. +- A bad payload, stale state, or wrong object target is not permission to abandon the connector path. + Use this skill for existing or newly imported Google Slides decks when the user wants visual cleanup, not just content edits. Prefer the connected Google Slides workflow over generic slide-generation skills when the task is about improving a real Slides deck. +Use the Google Slides connector for all slide reads, thumbnails, and edits. This is mandatory. Do not use Atlas, if available, for normal visual-iteration work when the connector supports the task. ## Required Tooling @@ -20,6 +30,8 @@ Confirm the runtime exposes the Google Slides actions you need before editing: If the user wants to bring in a local `.pptx`, also confirm `import_presentation`. If a dedicated visual-iteration tool exists in the runtime, use it. Otherwise, emulate the loop with `get_slide_thumbnail` plus direct Google Slides edits. +If a needed connector capability is missing, say so explicitly instead of silently switching to Atlas, if available. +Verify with a minimal representative connector call before concluding that the capability is missing. Do not hallucinate connector failure because one payload or target was wrong. ## Default Approach @@ -30,6 +42,7 @@ If a dedicated visual-iteration tool exists in the runtime, use it. Otherwise, e 2. Read structure before editing. - Use `get_presentation` or `get_presentation_text` to identify slide order, titles, and object IDs. - Use `get_slide` on the target slide before the first write so you have the current element structure and IDs. +- Keep the iteration grounded in connector reads, not Atlas inspection. 3. Start with a thumbnail. - Call `get_slide_thumbnail` first. @@ -111,9 +124,12 @@ The Slides connector exposes raw `batch_update` requests. That means: ## Failure Policy +- Connector-first is mandatory. Do not leave the connector path for normal visual diagnosis, editing, or verification work. +- A failed payload, stale state, or wrong object target is not evidence that the connector lacks the capability. - If the thumbnail action is unavailable, say that visual verification is blocked and fall back to structural cleanup only if the user still wants that. - If the runtime lacks the Slides edit action, stop and say the deck can be diagnosed but not corrected from Codex. - If repeated passes do not improve the slide, stop and explain what remains subjective or structurally constrained. +- Do not "save the run" by moving the slide edits into Atlas. That is a launch-blocking failure, not an acceptable workaround. ## Example Prompts diff --git a/plugins/google-slides/skills/google-slides/SKILL.md b/plugins/google-slides/skills/google-slides/SKILL.md index 4e118bce..780e6d9f 100644 --- a/plugins/google-slides/skills/google-slides/SKILL.md +++ b/plugins/google-slides/skills/google-slides/SKILL.md @@ -5,10 +5,22 @@ description: Inspect, create, import, summarize, and update Google Slides presen # Google Slides +## 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 normal Google Slides tasks. +- MUST NOT use Atlas, if available, to create, edit, inspect, verify, import, or migrate a Google Slides deck when the Slides connector exists. +- MUST NOT claim the connector cannot edit the deck without first proving that with a minimal live connector read or write. +- If the connector path truly cannot perform the required action, STOP and report the limitation plainly. Do not continue the deck-editing work in Atlas. +- Finishing a normal Google Slides task in Atlas after the connector path failed is a launch-blocking failure. + ## Overview Use this skill as the default entrypoint for Google Slides work. Stay here for deck search, summaries, light content edits, and new presentation creation. Route to a narrower sibling skill only when the task is specifically import, visual cleanup, structural repair, or template migration. +Use the Google Slides connector for all deck lookup, reading, creation, import, and editing work. This is mandatory. Do not use Atlas, if available, for normal Google Slides work. If the runtime exposes the Slides connector, deck creation and editing must stay on the connector path. + ## Required Tooling Confirm the runtime exposes the relevant Google Slides actions before editing: @@ -20,11 +32,15 @@ Confirm the runtime exposes the relevant Google Slides actions before editing: - `import_presentation` when starting from a local `.ppt`, `.pptx`, or `.odp` - `get_slide_thumbnail` when visual verification matters +If one of those connector capabilities is missing, say that explicitly. Do not switch to Atlas, if available, as a convenience fallback. +Do not infer missing connector capability from one failed request shape or one bad attempt. Verify with a minimal connector read or write first. A hallucinated "the connector cannot edit Slides" claim is a serious failure. + ## Workflow 1. Identify the target presentation. - If the user names a deck but does not provide a URL, search for it first. - If the user provides a local presentation file, tell the user you are importing it into native Google Slides first, then use [google-slides-import-presentation](../google-slides-import-presentation/SKILL.md). +- Use connector discovery and connector reads as the source of truth for deck identity. 2. Read before writing. - Use `get_presentation` or `get_presentation_text` to capture slide order, titles, and overall structure. @@ -63,15 +79,23 @@ Confirm the runtime exposes the relevant Google Slides actions before editing: - After creating a new slide or applying layout-heavy changes, immediately verify that no text, shape, image, or color band extends beyond the slide boundary. If the editor would require horizontal or vertical scrolling to see the whole slide, or if the lowest text sits in the bottom safety margin, treat that as a failure and fix it before moving on. - When supplying `objectId` values in `batch_update`, use valid Google Slides IDs that are 5-50 characters long and start with an alphanumeric character or `_`. Prefer descriptive IDs like `slide02`, `slide02_title`, or `slide02_body`; do not use very short IDs like `s2` or `i0`. - If you need to create a slide and edit its placeholders in the same `batch_update`, create the slide with valid placeholder ID mappings first, then reference those placeholder IDs in later requests in the same batch. +- Stay inside the connector workflow for writes and verification. Do not route a normal Slides task through Atlas, if available, just to inspect or edit the deck. ## Write Safety +- NEVER move a normal Slides 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 deck editing in Atlas after a successful connector read or write. +- Connector-first is mandatory. Do not use Atlas, if available, for normal slide creation, editing, layout changes, inspection, or verification. +- Do not treat a bad payload, bad object ID, or bad write-control request as proof that the connector is unavailable. +- If the connector can perform the first representative edit in this run, keep the remainder of the deck-editing workflow on the connector path. - Preserve slide order, titles, body text, charts, notes, and supporting evidence unless the user asks for a change. - Use live object IDs from the current deck state. Never guess IDs or request shapes. - Before deleting slides, rewriting multiple slides, or changing the layout pattern across a section, state exactly which slides will change and what kind of change you are about to make. - Do not promise pixel-perfect fidelity when importing Office formats into Google Slides. - When creating a new deck, default to readable structure plus visible color treatment, not a bare text dump. - Never leave text boxes, shapes, or header bands hanging outside the slide frame unless they are intentional full-bleed elements sized exactly to the slide edges. +- If the required Slides connector 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 deck in Atlas. That is a launch-blocking failure, not an acceptable workaround. ## Output