Update to Google Comment Responder

{
  "description": "Reusable workflow for responding to existing document comment threads. Use when Codex needs to scan comments on one or more documents, filter by configurable markers such as `AGENT:`, draft concise replies, post replies only to eligible existing threads, resolve threads only when asked, avoid deleting comments, and verify writeback. Works as a generic workflow for Google Drive comments or any connector/API that exposes comment threads, authors, status, replies, and pagination.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 203
    }
  ],
  "name": "google-comment-responder",
  "skill_md_contents": "---\nname: google-comment-responder\ndescription: Reusable workflow for responding to existing document comment threads. Use when Codex needs to scan comments on one or more documents, filter by configurable markers such as `AGENT:`, draft concise replies, post replies only to eligible existing threads, resolve threads only when asked, avoid deleting comments, and verify writeback. Works as a generic workflow for Google Drive comments or any connector/API that exposes comment threads, authors, status, replies, and pagination.\n---\n\n# Google Comment Responder\n\n## Overview\n\nUse this skill to run a configurable comment responder without embedding any person-, company-, document-, or project-specific IDs. Treat all targets, author filters, markers, evidence sources, and write rules as per-run configuration gathered from the user request, local instructions, or an explicit config file.\n\nTreat eligible comments as another input surface for Codex. Once a thread passes the configured eligibility filters, interpret the latest eligible comment as the user's request and execute it with the same resources and instruction hierarchy available in an ordinary Codex prompt: user request, local instruction files such as `AGENTS.md`, memory, configured skills, connected apps/tools, documents, repositories, prior notes, and any explicit resources. Do not limit the answer to the target document unless the request or policy says to.\n\n## Required Configuration\n\nBefore reading or writing comments, identify these settings:\n\n- Target files: stable file IDs, URLs, or exact paths. Prefer stable IDs over names when available.\n- Comment tool: the connector/API that can list, reply to, resolve, or read back comments.\n- Eligibility marker: labels such as `AGENT:`, `BOT:`, `REVIEW:`, or another requested string.\n- Author filter: if no author name is provided, try to infer it from all available resources before asking. Use connector metadata such as `author.me: true`, a `whoami` result, the authenticated profile/email, document comment authors, local instructions, explicit config, or other provided context. If the author is still unknown or ambiguous, ask before replying. The user or config can adjust this later, including allowing multiple authors.\n- Status filter: usually unresolved and non-deleted threads only.\n- Skip markers: phrases such as `do not respond`, `ignore`, or any user-specified exclusion.\n- Evidence sources: all available resources that would normally be available for the same Codex prompt, including documents, attachments, repositories, memory, local instructions such as `AGENTS.md`, configured skills/tools, prior notes, and current comments. For factual asks, prefer live primary sources and use memory or prior notes as leads rather than final evidence when verification is practical.\n- Surrounding context: nearby document text around each comment anchor, quote, slide, cell, or section.\n- Write policy: draft-only, post replies, resolve after replying, or report-only.\n- Output format: counts, replied thread IDs, skipped reasons, and unresolved blockers.\n\nIf a required setting is missing and a reasonable default would risk writing the wrong comment, ask one concise question before posting.\n\n## Generic Config Shape\n\nUse this shape when the user asks to save or describe a reusable responder:\n\n```yaml\ntargets:\n  - id: \"<stable-file-id-or-url>\"\n    type: \"<doc|sheet|slide|file|other>\"\n    label: \"<human-readable-label>\"\neligibility:\n  marker: \"AGENT:\"\n  author_filter:\n    default: \"running_user\"\n    infer_if_missing: true\n    allowed_authors: []\n    ask_if_unknown: true\n    allow_multiple_authors: true\n  unresolved_only: true\n  non_deleted_only: true\n  skip_markers:\n    - \"do not respond\"\n    - \"ignore\"\nwrite_policy:\n  mode: \"draft-then-post\"\n  reply_to_existing_threads_only: true\n  allow_resolve: false\n  allow_delete: false\npagination:\n  page_size: 100\n  require_exhaustive_scan: true\nverification:\n  reread_after_write: true\n  report_thread_ids: true\ncontext:\n  read_surrounding_text: true\n```\n\nDo not ship a config with real private file links unless the user explicitly asks for a project-specific responder.\n\n## Workflow\n\n1. Read the task rules.\n   - Read the user request and any local instruction file that applies to the current workspace.\n   - Treat each eligible comment as the task prompt for that thread, subject to the configured filters and write policy.\n   - Use the same instruction hierarchy and available resources that Codex would use for a normal user prompt, including memory, `AGENTS.md`, local instructions, tools, skills, files, connected apps, and explicitly provided resources.\n   - Let explicit user instructions decide scope and write policy.\n   - Do not add project-specific memory to reusable workflows unless the user asks for a project-specific plugin.\n\n2. Confirm the tool can do the job.\n   - Use the native connector/API for the target file system when possible.\n   - Make sure it can list comments, inspect thread status, write replies, and reread threads.\n   - If it cannot create native anchors, do not create new top-level inline comments. Existing-thread replies are usually okay.\n\n3. Read every in-scope comment thread.\n   - Fetch every target in scope.\n   - Use the connector's supported page size; if unknown, use 100 or lower.\n   - Keep paging each target until the continuation token is empty or `null`.\n   - If a comment page appears clipped or truncated, rerun with smaller pages and keep paging before deciding the scan is complete.\n   - Preserve thread IDs, comment IDs, authors, timestamps, quoted text, anchors, resolved/deleted status, and existing replies.\n\n4. Keep only eligible threads.\n   - Keep existing threads that match the configured marker.\n   - Apply the status, deletion, author, and skip-marker filters.\n   - If no author name or filter is provided, infer the intended author from all available resources before asking. In Google Drive comment data, prefer `author.me: true` when present; otherwise use connector identity/profile data such as display name or email, local instructions, explicit config, document comment authors, or other provided context.\n   - If the author is still unknown or ambiguous after checking available resources, ask the user which author or authors to include before replying.\n   - Allow the user or config to override the default author filter with one or more explicit allowed authors.\n   - Check prior replies before drafting so already-answered threads are not duplicated.\n   - Treat a thread as answered when a later non-deleted reply already satisfies the latest eligible ask, even if the thread is still unresolved.\n   - Because some comment APIs post agent replies as the authenticated user, decide whether a prior reply answers the thread from reply content, timestamp, and action, not author identity alone.\n\n5. Understand each eligible comment.\n   - Use the comment text as the source of truth for what needs answering.\n   - Read surrounding document context before drafting: anchored or quoted text, nearby paragraph, slide, cell range, heading, or section.\n   - Use all available resources that would normally be available for the same request in Codex, not only the target document.\n   - Prefer primary or attached sources over broad search. For requests asking for examples, links, source locations, or current facts, actively look up the specific artifact instead of answering generically.\n   - State uncertainty plainly when evidence is incomplete.\n   - If no reliable evidence is available, either draft an uncertainty reply or ask the user, depending on the write policy.\n\n6. Draft all replies first.\n   - Prepare every reply before posting any of them.\n   - Keep replies short, direct, and scoped to the comment.\n   - Use one reply per thread unless a small follow-up is needed to fix rendering or a broken link.\n   - Do not edit the document body unless the user separately asks for body edits.\n\n7. Write only the allowed updates.\n   - Reply to existing eligible threads only.\n   - Do not delete comments unless the user explicitly asks to delete them.\n   - Resolve threads only when the user asks to resolve, clean up, close, or mark handled.\n   - If resolving after replying, use the resolve action so the comment history stays preserved.\n\n8. Verify the writeback.\n   - Reread every written thread.\n   - Confirm the reply text, thread ID, and final status.\n   - If a write failed or readback is unavailable, report that as incomplete.\n\n9. Report what happened.\n   - Include the number of target files fully scanned.\n   - Include the number of eligible threads found.\n   - List replied thread IDs, or say that no replies were posted.\n   - Summarize skipped threads by reason, such as resolved, deleted, author mismatch, skip marker, already answered, or blocked by missing evidence/tool access.\n   - Say whether pagination reached the end for every target.\n   - Say whether writeback was verified.\n\n## Reply Style\n\n- Prefix every drafted or posted comment reply with `CODEX:`. If a reply already starts with `CODEX:`, do not add a second prefix.\n- Keep replies concise and useful inside the thread.\n- Answer the latest ask, not every historical aside in the thread.\n- When a reply references a file, document, comment thread, issue, PR, source, or other linkable artifact, include the link using the target system's supported formatting. Do not add unrelated links just to increase link count.\n- Prefer plain visible URLs when the comment system mangles rich formatting.\n- Do not over-explain the workflow in the comment reply itself.\n\n## Safety Rules\n\n- Never infer target files from a similar prior project when the current task gives different targets.\n- Never call setup, configuration, or partial search a completed responder run.\n- Never silently skip an eligible thread because evidence is inconvenient. Report the blocker or draft an uncertainty reply according to policy.\n- Never reuse a continuation token from another target or a prior scan.\n- Never answer comments outside the configured marker and author filters.\n- Never delete comment content as a substitute for resolving or replying.\n\n## Verification Checklist\n\nBefore the final response, confirm:\n\n1. Every target reached the end of pagination or the incomplete target is named.\n2. Only eligible existing threads were answered.\n3. No comment was deleted unless explicitly requested.\n4. No document body edits were made unless explicitly requested.\n5. All posted replies were reread successfully, or failures are named.\n6. The final report includes counts, replied thread IDs, skipped reasons, and remaining blockers.\n"
}