name: file-drive-connector-config description: Reference for how the organization's file drive connector (SharePoint or Google Drive) is configured, so retrieval against it lands on the right documents instead of scattershot results. Use this skill whenever a query touches the shared file drive — searching for a document, pulling a file, asking "where does X live", "what folder is Y in", "do we have a doc on Z", building a path, scoping a search to a folder, troubleshooting why a search missed an obvious file, or onboarding anyone (human or agent) to how the drive is laid out. Also trigger before any connector call that needs a folder ID, drive ID, or path, and any time a file search returns junk or comes up empty when it shouldn't — the fix is usually a scoping or naming convention documented here. Do NOT use for general web search, for non-drive data sources, or for editing the documents themselves.

File Drive Connector Configuration

This skill is the map of the shared file drive. Read it before searching, fetching, or reasoning about where documents live. A connector finds relevant documents easily only when the searcher already knows the drive's shape — the folder hierarchy, the naming conventions, the canonical IDs, and the scoping tricks that turn a vague query into a precise hit. That knowledge lives here so nobody has to rediscover it.

The single biggest cause of bad file search is searching the whole drive when you could have scoped to one folder. The second biggest is guessing at folder names instead of using the canonical ones below. This skill fixes both.

1. Platform and access

State which connector backs the drive and how it's reached.

• Platform: [SharePoint | Google Drive | other]
• Connector / MCP server: [name of the connector, e.g. the search and fetch tools available]
• Primary drive / site name: [human-readable name]
• Drive ID: [canonical drive or site ID — the root handle every path hangs off of]
• Auth model: [how access is granted — org-wide, per-user, service account]
• Read/write posture: [read-only for retrieval, or writeable]

Keep IDs in this skill, not hardcoded across other skills or scripts. When an ID changes, it changes in one place.

2. Folder hierarchy

Document the top-level structure. The goal is that anyone reading this can predict where a document lives without searching.

Use a tree, and for each meaningful folder give: its purpose, its canonical name (spelled exactly as it appears in the drive), and its folder ID if the connector needs one to scope a search.

[Root]/
├── [Top-Level Folder A]/        — purpose; folder ID: [...]
│   ├── [Subfolder A1]/          — purpose
│   └── [Subfolder A2]/          — purpose
├── [Top-Level Folder B]/        — purpose; folder ID: [...]
└── [Top-Level Folder C]/        — purpose; folder ID: [...]

For each top-level area, answer:

• What goes here (and what does NOT — boundaries prevent both misfiling and missed searches)
• Canonical name exactly as it appears, including spacing, casing, and punctuation
• Folder ID if the connector supports scoped search by ID

3. Canonical folder IDs

A flat lookup table of the IDs a connector needs to scope a search to a folder. This is the section people will copy from most. Keep it exact — IDs are case-sensitive and a single wrong character fails silently or returns nothing.

| Folder (canonical name) | Folder ID | |---|---| | [Folder name] | [ID] | | [Folder name] | [ID] | | [Folder name] | [ID] |

Only list IDs you have verified. A wrong ID here is worse than a missing one, because it sends searches confidently into the void. If you don't have an ID, leave it blank and say so rather than guessing.

4. Naming conventions

Connectors match on filenames and folder names as much as content. If files follow a predictable pattern, a search can target it. Document the conventions actually in use:

• File naming pattern: [e.g. [Entity] - [DocType] - [YYYY-MM-DD]] — describe each component
• Folder naming pattern: [e.g. one folder per entity at a fixed path]
• Date format: [the format dates appear in, so date-bounded searches work]
• Versioning convention: [how versions are marked — v2, FINAL, dates — so the search lands on the current one]
• Known inconsistencies: [places where the convention is NOT followed, so a searcher knows when to broaden]

The point of this section is to let a searcher construct a query that matches the actual strings on disk, not the strings they imagine.

5. How to find things (the retrieval playbook)

This is the operational core. Translate common request types into the right connector move.

Scope before you search

Whole-drive search is the last resort, not the first. If the query implies a folder, resolve to that folder's ID (Section 3) and scope the search to it. Scoped search is faster, cleaner, and far less likely to return noise.

Request → move mapping

| When the user wants... | Do this | |---|---| | A document in a known area | Scope search to that folder's ID, then keyword search | | A document for a specific entity | Resolve the entity's folder path (Section 4 convention), then list or search inside it | | "Do we have anything on X" | Whole-drive keyword search, then narrow by folder once you see where hits cluster | | A specific file by name | Search the filename pattern directly (Section 4) | | The latest version of something | Search the folder, then apply the versioning convention (Section 4) to pick the current file |

Query construction

• Use the canonical names and patterns from Sections 2 and 4, not paraphrases.
• Keep keyword queries to the distinctive content nouns. Drop filler words the indexer won't have indexed on.
• If a first search misses, reformulate with different terms or a tighter folder scope — don't repeat the same query.

Fetching

Once a search returns a hit, fetch by the connector's file handle (ID or path), not by re-searching. [Note the connector's fetch tool and what identifier it needs.]

6. Troubleshooting

Symptoms and their usual causes. Most "the search is broken" reports are actually scoping or naming mismatches.

| Symptom | Likely cause | Fix | |---|---|---| | Search returns nothing for a file you know exists | Wrong folder scope, or query used a paraphrase instead of the canonical name | Broaden to whole-drive, then check the name against Section 4 | | Search returns too much noise | No folder scope | Scope to the relevant folder ID (Section 3) | | Connector errors on a folder ID | ID is stale, mistyped, or case-wrong | Verify against Section 3; re-confirm the ID if it's changed | | Hits cluster in an unexpected folder | A naming/filing inconsistency (Section 4) | Note it in Section 4 so the next searcher knows | | Access denied | Auth scope (Section 1) | Confirm the connector has access to that area |

If a folder ID appears wrong and you can't verify the correct one, say so plainly rather than working around it silently — a stale map is the root cause of most retrieval failures, and the fix is to update this skill.

7. Maintenance

This skill is only as good as it is current. Update it whenever:

• A top-level folder is added, renamed, or moved
• A folder ID changes
• A naming convention changes or a new inconsistency is discovered
• The connector, drive ID, or auth model changes

When something changes, fix it here first, then anywhere downstream. One source of truth for the drive's shape.