Where the files live when a VP and multiple PMs share one AI-SHIPR system. Shared concepts that apply to any provider, then a full guide for Google Drive, Microsoft 365, Confluence, and Notion.
For who fills which worksheet, in what order, and what happens when a PM leaves - see Team Rollout: Who Fills What.
AI-SHIPR runs on local files. Claude Code reads from a folder on your machine - which means every team member needs access to the same files from their own computer.
A shared, organisation-owned cloud drive (not personal storage) is the right tool because it mounts at a consistent path on every machine. All members see the same folder structure at the same relative path - so Claude's file references work identically for everyone.
Personal storage does not work - it includes the username or company name in the path, which differs per machine.
vp/shared/. Each PM writes only to their own folder. No PM edits another PM's folder or the shared layer.
vp/ plus a ready pm-<name>/ for every person listed, each holding a complete framework copy with Settings.md pre-set and its own START-HERE. Unzip it into the shared surface and the per-person install steps below are already done. Nobody should download a separate framework zip on top of it - that overwrites the personalisation, and a copy unzipped outside the shared surface cannot see ../vp/shared/ at all. The per-person steps below are the manual route, for installing by hand.
The entire system works conflict-free as long as one rule holds:
No PM ever edits vp/shared/
Only the VP writes to the global layer. PMs read it. PMs write only to their own folder.
Cloud drive permissions (Viewer / read-only on vp/shared/) enforce this technically. But communicating it explicitly to the team matters too - the structure should be understood, not just imposed.
vp/shared/OKRs.md, every PM gets the updated OKRs in their next Claude session automatically. No distribution needed. No manual copy-paste. This is the compounding effect the structure enables.
Google Shared Drive (not a personal Drive) is the right tool because it mounts at a consistent path on every machine via Google Drive for Desktop. All members see the same folder structure at the same relative path - so Claude's file references work identically for everyone.
Personal Google Drive does not work for this - it includes the username in the path, which differs per machine.
AI-SHIPR-ORG (or your company name). This creates the organization-owned root.
AI-SHIPR-ORG/ straight into the Shared Drive; vp/ is already inside it with the framework in place.
Manual route: inside the Shared Drive, create a vp/ folder. Download your AI-SHIPR zip, extract it into vp/. This is your complete AI-SHIPR instance.
shared/ layer
Inside vp/, shared/ is the global layer and holds six files: Vision.md, Strategy.md, OKRs.md, Strategic-Bets.md, Portfolio-Roadmap.md, Constraints.md.
You do not write these by hand. Running Populate-Strategy on your filled Setup Worksheet generates all six. Review what it produces, and run OKR-Partner on OKRs.md before the team reads it, since the worksheet collects metrics and bets rather than formal OKRs.
vp/Settings.md and confirm (the wizard sets this for you):
team_mode: lead
This activates the Portfolio-Strategist and Team-Manager agents.
vp/CLAUDE.md by hand. That is no longer needed. The framework's Session Start protocol branches on team_mode by itself: in lead it reads shared/, every ../pm-*/S-Strategy/ for the portfolio view, and R-Relationships/Team/, before any local file.
If you added that line to an older install, leave it or delete it. It is a duplicate now, not a conflict.
Mac: cd ~/Google\ Drive/Shared\ drives/AI-SHIPR-ORG/vp && claude
Windows: cd "G:\Shared drives\AI-SHIPR-ORG\vp" && claude
AI-SHIPR-ORG drive will appear in your Google Drive.
Mac: ~/Google Drive/Shared drives/AI-SHIPR-ORG/pm-[yourname]/
Windows: G:\Shared drives\AI-SHIPR-ORG\pm-[yourname]\
pm-[yourname]/ folder already holds the framework, a pre-set Settings.md and a personal START-HERE.md. Open that file and follow it. Do not ask for a separate framework zip; installing one on top overwrites your setup.
Manual route: the lead sends you the AI-SHIPR zip. Extract it into your pm-[yourname]/ folder. Do not extract it anywhere else - the relative paths depend on sitting inside the Shared Drive structure, and a copy in your Downloads folder cannot see ../vp/shared/. It will not error, it will just answer without your org's strategy.
team_mode: in individual it reads ../vp/shared/ before any local file and flags anything in your strategy that conflicts with the org layer.
Settings.md and confirm (the wizard sets this for you):
team_mode: individual
This keeps the lead-mode agents (Portfolio-Strategist, Team-Manager) inactive for PMs.
Setup-Worksheet.md in your folder and answer the questions about your product. Then in Claude Code, run:
Run Populate Strategy based on the Setup Worksheet I filled in
Claude will generate your product strategy files, automatically aligned with the org-level strategy it read from ../vp/shared/.
Mac: cd ~/Google\ Drive/Shared\ drives/AI-SHIPR-ORG/pm-[yourname] && claude
Windows: cd "G:\Shared drives\AI-SHIPR-ORG\pm-[yourname]" && claude
Always launch Claude Code from your own folder - not from the root or another PM's folder.
~/Google Drive/Shared drives/AI-SHIPR-ORG/
ls ~/Google\ Drive/Shared\ drives/AI-SHIPR-ORG/
You should see vp/ and the PM folders listed.
G:\Shared drives\AI-SHIPR-ORG\
dir "G:\Shared drives\AI-SHIPR-ORG"
You should see vp and the PM folders listed.
cd "G:\Shared drives\AI-SHIPR-ORG\pm-[yourname]"
claude
pm-[name]/ folder → Share → add only that PM → role: Contributor. They will not see other PM folders unless explicitly shared.
vp/shared/ → Share → add all PM emails → role: Viewer. PMs can read but not edit the global strategy files.
vp/ (1:1 logs, PM profiles, VP learning log) with PMs. Those stay VP-only.
If your organisation runs on Microsoft 365, use SharePoint instead of Google Shared Drive - not OneDrive personal. OneDrive personal has the same path problem as Google My Drive. SharePoint is organisation-owned, shared across the team, and mounts locally through the OneDrive sync client that is already installed on most Windows machines.
AI-SHIPR-ORG (or your company name). This creates the organisation-owned root, equivalent to a Google Shared Drive.
vp/ folder and all pm-[name]/ folders. Wizard route: already done, just unzip your download here. Manual route: extract the AI-SHIPR zip into vp/. Create the vp/shared/ subfolder and fill in the strategy files.
vp/shared/.
vp/Settings.md, set team_mode: lead. Then launch Claude from your VP folder:
Mac: cd ~/OneDrive\ -\ [Company]/AI-SHIPR-ORG/vp && claude
Windows: cd "C:\Users\[you]\OneDrive - [Company]\AI-SHIPR-ORG\vp" && claude
Mac: ~/OneDrive - [Company]/AI-SHIPR-ORG/pm-[yourname]/
Windows: C:\Users\[you]\OneDrive - [Company]\AI-SHIPR-ORG\pm-[yourname]\
Wizard route: already done. Manual route: extract the AI-SHIPR zip into this folder. Update CLAUDE.md and Settings.md exactly as in the Google Drive guide (PM Setup, Steps 5–6) - the instructions are identical.
Mac: cd ~/OneDrive\ -\ [Company]/AI-SHIPR-ORG/pm-[yourname] && claude
Windows: cd "C:\Users\[you]\OneDrive - [Company]\AI-SHIPR-ORG\pm-[yourname]" && claude
OneDrive - Acme Corp), so it differs between organisations. But all relative paths inside the folder - ../vp/shared/ - resolve identically regardless of what comes before them. Nothing in CLAUDE.md needs to change between Google and Microsoft setups.
Confluence is a wiki and documentation platform, not a file system. Unlike Google Drive or SharePoint, it does not mount as a local folder on your machine - so Claude Code cannot read Confluence pages directly as local files.
The right approach is a mirror model: Confluence is where people edit, a small local folder is what Claude reads, and one sync command pulls the first into the second. vp/shared/ becomes a per-machine cache instead of a mounted folder. AI-SHIPR itself needs no changes - ../vp/shared/ still resolves, and the session-start read is still a plain file read that works offline.
Sync in one direction only, and key it on page IDs. One editing surface, one source of truth. Maintaining the wiki page and the .md file separately looks cheap - thirty seconds each - but they drift, and within a month nobody knows which copy is true. Keying on IDs rather than page titles matters because renaming a page is normal behaviour and must never silently orphan a file.
CLAUDE.md, Settings.md, Governance.md and A-AI/ - that is code, it moves by pull request, and it arrives by git pull. Neither belongs in the other's channel.vp/shared/OKRs.md is rewritten from the page. Nobody hand-edits the local copy - if someone does, the next sync overwrites it, which is the correct outcome and a useful signal that the edit went to the wrong place.OKRs), it is trivial to keep them in sync.A page called PM Alice assumes the person outlasts the product. In practice it is the other way round. Three kinds of content live for three different lengths of time:
| Content | Lives as long as | Where it belongs |
|---|---|---|
| Vision, strategy, OKRs, bets, constraints | the company | Shared Strategy |
| Product strategy, personas, glossary, decision log | the product | Product Workspaces |
| PM profile, PM voice, coaching log, 1:1 notes | the person | the PM's own machine, and VP Workspace |
Person-keyed pages give the middle row the wrong lifetime. When Alice leaves, years of product reasoning sits inside a page named after someone who no longer works there.
Reallocation breaks it before departure does. Alice owns two products above. The day Billing Portal moves to Bob, a page called PM Alice has to be surgically split and every inbound link rechecked. Keyed by product, that same reorg is one property change on one page. Reorgs are far more common than resignations, so this is the case that bites first.
The rule: churn should be a property change, not a page move. Give each product page these properties, and let page permissions follow Owner so a handover is one field rather than a permissions rebuild.
| Property | Why |
|---|---|
Owner | The current PM. The field that absorbs all churn |
Previous owners | Who to ask about a decision made two years ago |
Last reviewed | Blank it on handover. A new owner has not reviewed anything yet |
Status | Active / Paused / Retired. A retired product keeps its decision log |
pm-alice/ is an installation - it holds that PM's Settings.md, their own PM-Profile.md, their session history, and it is meant to die when the laptop goes back. The wiki is the record, and the record outlives every installation.AI-SHIPR (or your product org name). Set it as a team space so it is visible to all invited members.
Vision, Strategy, OKRs, Strategic Bets, Portfolio Roadmap, Constraints. Fill them in with your current strategy content.
.md files in vp/shared/.
vp/CLAUDE.md, add a note so Claude reminds you:
After updating any file in vp/shared/, remind me to update the
corresponding Confluence page in the Shared Strategy section.
AI-SHIPR space will appear in your Confluence sidebar under Spaces.
../vp/shared/ - Confluence is the human layer for the same content.
Owner to yourself. Create child pages that mirror your AI-SHIPR folders: Strategy, Initiatives, Hypotheses, Decisions. Keep these in sync with your local .md files.
pm-[name]/ and run bash setup.sh once. Claude Code reads the local files, never Confluence directly.
vp/shared/
This pulls the six Shared Strategy pages down into your local mirror. Re-run it whenever the VP says the org context moved. Never hand-edit vp/shared/ - the next sync overwrites it.
Owner + VP. Access follows the Owner property, so a handover is one field change rather than a permissions rebuild. This mirrors the folder-level permissions in Google Drive and SharePoint.
vp/shared/OKRs.md is rewritten from that page → Claude reads it at session start. One source, one direction, and a visible diff every time the org context moves.
AI-SHIPR runs on local files. At session start, Claude Code reads a fixed list of files in a fixed order - with team_mode: individual that list begins with ../vp/shared/. That guaranteed read is the whole mechanism. It is why org context compounds instead of being pasted into prompts by hand.
Google Drive and SharePoint were never the point. They were one way to make those paths resolve identically on every machine. Notion has no file path at all - there is no way for Claude Code to read a Notion page the way it reads a file.
Replacing the file read with a live Notion lookup means swapping a guaranteed read for a search: it costs tokens every session, adds latency, and breaks offline. So Notion can absolutely be the shared surface. It cannot be the runtime.
CLAUDE.md, Settings.md, Governance.md and A-AI/ - that is code, it moves by pull request, and it arrives by git pull. Neither belongs in the other's channel.Every org page needs an Owner and a Last reviewed value, and in Notion those are database properties. Loose pages cannot carry them, which quietly kills the staleness check before you have written a line of content.
Owner property. The reasoning is in Section 4.02, and it applies identically here.
Add a Sync-Context skill to the shared repo so every machine gets it on clone. It reads a page-ID map, fetches each page, and writes the markdown mirror.
Context-Index.md file in the repo root, mapping page ID to target filename. If it is missing, stop - never fall back to searching Notion by page name.page_id, owner, last_reviewed and today's sync date into each file.last_reviewed older than 90 days is stale context. An empty owner is unowned context - the worse of the two, and usually means a PM left and the product was never reassigned.Context-Index.md lives in the repo and not in Notion. The sync has to read it before it can make any Notion call, so keeping it in Notion is circular. It also changes rarely, and a change to it is a change to the contract between the two systems - worth seeing in a pull request.?.Product Context teamspaceThen the Org Context database with the three properties above, and its six rows.Org Context and Templates. See Section 5.06.Product Workspaces databaseOne row per product, with Owner set to the PM who runs it.Context-Index.md in the repo, and commit.team_mode: leadIn your own Settings.md.Context-Index.md and the Sync-Context skill.pm-[name]/Run bash setup.sh once, and confirm team_mode: individual in Settings.md./sync-contextThis populates your local vp/shared/ mirror. Re-run it whenever the VP says the org context moved.Product Workspaces - the one where their name sits in Owner.Owner property. Then moving a product between PMs is one field change rather than a permissions rebuild - which is the whole reason these pages are keyed by product.CLAUDE.md, Settings.md, Governance.md, A-AI/, and any PM's working folders. Those are runtime, and runtime belongs in git and on the machine. Nor does regulated or personal data belong in the context layer - keep it out of both surfaces.AI-SHIPR Workshop by Yaniv Yaakubovich