Google Drive Doc Synthesis

Google Drive Doc Synthesis

Use this skill when a WorkUnit contains staged Google Drive content from docs/**.

Role

Each WorkUnit is one Google Doc plus its metadata. Read the assigned raw files, then write a small set of durable wiki entries that capture reusable organizational knowledge. Write final memory directly; do not write candidates.

Required Workflow

1. Read the WorkUnit notes and rawFiles list. Document content lives in page.md; metadata.json holds title, path, url, modified time, and Drive folder context.
2. For each assigned doc, call read_raw_file, or read_raw_span for oversized docs when the notes specify a span.
3. Search wiki_search for existing pages that overlap the WorkUnit topics. Prefer updating an existing page over creating a duplicate.
4. Use context_evidence_search, context_evidence_read, and context_evidence_neighbors when indexed document chunks would help reconcile related facts. Pass chunkId and documentId values verbatim as returned by the evidence tools.
5. Write durable business knowledge with wiki_write. Aim for a small number of high-quality pages per doc. Include rawPaths with the exact Google Drive raw files that support each page.
6. If a doc references warehouse, dbt, Looker, Metabase, or MetricFlow objects, you may verify them with discover_data, entity_details, sql_execution, sl_discover, or sl_read_source, but Google Drive docs are knowledge-only in v1. Do not create semantic-layer sources under the gdrive connection.
7. For every deleted raw path in the Eviction Set, call eviction_list, decide retention, then emit_eviction_decision. Do this even when no wiki write is needed.

What To Capture

Capture durable, reusable company knowledge:

• policies, workflows, process rules, ownership conventions, and operating procedures
• product definitions, business terminology, and organizational guidance
• source-of-truth statements, caveats, conflict notes, and supersession guidance
• cross-system aliases that connect doc terminology to warehouse, dbt, Looker, Metabase, or MetricFlow names

Skip noisy or transient content:

• brainstorming notes with no durable rule
• task lists, meeting scheduling details, and time-bounded status updates
• duplicate docs with no new fact
• shallow summaries that add no reusable policy or definition

Quality

Prefer fewer, stronger entries. Every wiki entry must cite at least one Google Doc using its title or path and last modified date when available. When evidence conflicts, write a conflict note inside the wiki page rather than choosing silently.

If one doc covers several related ideas, synthesize the shared durable rules instead of writing one thin page per paragraph. For oversized spans, read only the assigned span unless the WorkUnit explicitly asks for neighboring context.