docs: Google Slides integration design spec

[yourbuddyconner]

Summary

Design spec (no code changes) for a new slides.* tool namespace inside @valet/plugin-google-workspace, covering 13 v1 actions across four capability groups to close the Slides-blindness gap:

• Read (5): read_presentation, list_slides, get_slide, get_presentation_info, get_speaker_notes
• Comments (6): list_comments, get_comment, add_comment, reply_to_comment, resolve_comment, delete_comment
• Write (5): replace_all_text, replace_slide_text, insert_text_box, duplicate_slide, delete_slide
• Create (2): create_presentation, create_from_template

Motivation

Keisha's 2026-07-13 #proj-valet request — stitch together slide-level Granola call notes + slide comments + deck content into actionable revisions. Also closes the twice-asked "how do I make slides" gap (Carey, Akshar) from the H1 docs audit.

Today Valet is blind to Google Slides beyond drive.list_files and lossy drive.download_file exports — zero structured read, zero write, zero comment access.

Scope

• Ships inside existing @valet/plugin-google-workspace (no new package)
• Adds one OAuth scope: https://www.googleapis.com/auth/presentations (forces re-consent on next Google reconnect)
• Files: new slides-actions.ts + slides-helpers.ts + skills/google-slides.md; minor edits to actions.ts, provider.ts, labels-guard.ts, workspace-output-schemas.ts
• Estimated ~4 days of focused engineering effort

Full details in docs/specs/2026-07-13-google-slides-integration-design.md.

Approval requested

Sign-off needed from:

• @yourbuddyconner (Conner Swann) — plugin-google-workspace de facto owner, Applied AI direction
• @xBalbinus (Xiangan He) — Engineering-vertical Valet co-owner
• Sam Ebstein — manager review, since this is Platform-team-adjacent surface

[github-actions]

Preview deployment: https://pr-114.dev-valet-turnkey-client.pages.dev

[xBalbinus]

Design reads as sound and idiomatic. No new package, the action structure mirrors the existing docs/sheets surface, comments reuse the Drive Comments API exactly as docs.list_comments does, and the 13-action scope with explicit non-goals is a sensible v1 cut.

One design-level item worth resolving before sign-off: §5 adds auth/presentations to WORKSPACE_SCOPES, which forces every Google-connected user — including those who never touch Slides — to re-consent, and until they do slides.* fails with an opaque 401/403 and no in-product reconnect nudge (the plan leans on a Slack post). Google supports incremental authorization — requesting the scope only when a slides.* action first runs — which avoids the blanket re-consent and the silent-failure window. Worth weighing that alternative, or at least adding a reconnect affordance driven by the scope error.

Smaller: the naming table sets the slide parameter as slideObjectId, but the list_slides / get_slide return shapes use id. Aligning the write param with the read output on one key would save callers a mental hop.