Verve-PM Verve-PM ← All Resources
AI-SHIPR

Team Setup with Cloud

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.

Jump to your tool
Start here - Shared Information The folder structure and the one ownership rule. Applies to every tool below. Read it first even if you already know which one you are using.
The split that decides everything: Google Drive and SharePoint are file systems, so they mount at a path and Claude reads them directly. Confluence and Notion are not, so they become the place people edit while a small local mirror stays the thing Claude reads. Same structure either way, one extra command in the second case.
🗂
Section 1
Shared Information

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.

Use Google Shared Drive (not My Drive) or SharePoint Team Site (not OneDrive personal). Both are org-owned and mount at a consistent path regardless of who is logged in.
AI-SHIPR-ORG/ ← root of the shared drive vp/ ← VP's full AI-SHIPR workspace shared/ ← GLOBAL LAYER - VP writes, all PMs read Vision.md Strategy.md OKRs.md Strategic-Bets.md Portfolio-Roadmap.md Constraints.md R-Relationships/Team/ ← Roster, PM profiles, 1:1 logs Settings.md ← team_mode: lead CLAUDE.md A-AI/ ← includes Portfolio-Strategist + Team-Manager Learning.md pm-alice/ ← Alice's full AI-SHIPR workspace CLAUDE.md ← reads ../vp/shared/ first, then local Settings.md ← team_mode: individual S-Strategy/ ← Alice's product strategy H-Hypotheses/ I-Initiatives/ P-Proof/ R-Relationships/ I-Information/ A-AI/ Learning.md pm-bob/ ← same structure as pm-alice ...
The ownership rule: Only the VP writes to vp/shared/. Each PM writes only to their own folder. No PM edits another PM's folder or the shared layer.
Two routes to this structure, and most people want the first. If the lead ran the setup wizard, the download is this structure: 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.

When the VP updates 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.
🟢
Section 2
Google Drive Setup

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.

Use Google Workspace Shared Drive, not "My Drive". Shared Drives are organization-owned and mount at a consistent path regardless of who is logged in.
  • 1
    Create the Shared Drive In Google Drive, click Shared drives in the left sidebar → New → name it AI-SHIPR-ORG (or your company name). This creates the organization-owned root.
  • 2
    Download and install Google Drive for Desktop Download from drive.google.com/drive/download. Install, sign in with your Google Workspace account. The Shared Drive will appear on your machine as a mounted drive.
  • 3
    Create the VP folder and download AI-SHIPR Wizard route: skip. Unzip 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.
  • 4
    The 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.
  • 5
    Enable Lead Mode in Settings.md Open vp/Settings.md and confirm (the wizard sets this for you): team_mode: lead This activates the Portfolio-Strategist and Team-Manager agents.
  • 6
    Nothing to add to CLAUDE.md Earlier versions asked you to paste a reading instruction into 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.
  • 7
    Open Claude Code from your VP folder In Terminal (Mac) or Command Prompt (Windows), navigate to your VP folder and launch Claude: Mac: cd ~/Google\ Drive/Shared\ drives/AI-SHIPR-ORG/vp && claude Windows: cd "G:\Shared drives\AI-SHIPR-ORG\vp" && claude
  • 1
    Accept the Shared Drive invitation The VP invites each PM to the Shared Drive with the right permissions (see Section 05). Accept the invitation - the AI-SHIPR-ORG drive will appear in your Google Drive.
  • 2
    Download and install Google Drive for Desktop Download from drive.google.com/drive/download. Install and sign in. The Shared Drive will mount automatically on your machine.
  • 3
    Locate your personal folder on the mounted drive Your folder already exists - the VP created it for you. Navigate to it: Mac: ~/Google Drive/Shared drives/AI-SHIPR-ORG/pm-[yourname]/ Windows: G:\Shared drives\AI-SHIPR-ORG\pm-[yourname]\
  • 4
    Check your folder, or extract into it Wizard route: nothing to download. Your 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.
  • 5
    Nothing to add to CLAUDE.md Earlier versions asked you to paste a reading instruction in by hand. The framework now does it from team_mode: in individual it reads ../vp/shared/ before any local file and flags anything in your strategy that conflicts with the org layer.
  • 6
    Set team_mode to individual in Settings.md Open your 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.
  • 7
    Fill in your Setup Worksheet and run Populate Strategy Open 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/.
  • 8
    Open Claude Code from your PM folder to work 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.
  • 1
    Download Google Drive for Desktop Go to drive.google.com/drive/download and download the Mac version.
  • 2
    Install Open the downloaded .dmg file and drag Google Drive to your Applications folder. Launch it.
  • 3
    Sign in with your Google Workspace account A browser window will open. Sign in - use the same account the VP invited to the Shared Drive.
  • 4
    Choose streaming mode (recommended) In Google Drive preferences, set sync to Stream files - files stay in the cloud and sync on access. This prevents filling your local disk.
  • 5
    Find the Shared Drive on your Mac Open Finder. In the sidebar under Locations, you will see Google Drive. Inside it, open Shared drivesAI-SHIPR-ORG. Your full path: ~/Google Drive/Shared drives/AI-SHIPR-ORG/
  • 6
    Verify the path in Terminal ls ~/Google\ Drive/Shared\ drives/AI-SHIPR-ORG/ You should see vp/ and the PM folders listed.
  • 1
    Download Google Drive for Desktop Go to drive.google.com/drive/download and download the Windows installer.
  • 2
    Install Run the installer (.exe). It will install and launch automatically. Sign in with your Google Workspace account.
  • 3
    A new drive letter appears Google Drive is assigned a drive letter (default: G:). It appears in File Explorer under This PC. You can change the letter in Google Drive settings if needed.
  • 4
    Find the Shared Drive Open File Explorer → G:\Shared drivesAI-SHIPR-ORG. Your full path: G:\Shared drives\AI-SHIPR-ORG\
  • 5
    Verify in Command Prompt dir "G:\Shared drives\AI-SHIPR-ORG" You should see vp and the PM folders listed.
  • 6
    Note for Claude Code paths on Windows When launching Claude Code, use the full Windows path with the drive letter: cd "G:\Shared drives\AI-SHIPR-ORG\pm-[yourname]" claude
Role Shared Drive access Folder write access Read access
VP Product Manager vp/ including shared/ All PM folders + vp/shared/
Each PM Contributor Their own pm-[name]/ only Their own folder + vp/shared/
Permission Setup - Step by Step
  • 1
    Add the VP as Manager of the Shared Drive In the Shared Drive → Manage members → add VP email → role: Manager. Managers can add members and set folder-level permissions.
  • 2
    Add each PM as Contributor to the Shared Drive In the Shared Drive → Manage members → add PM email → role: Contributor. Contributors can edit files in folders they have access to.
  • 3
    Restrict each PM to their own folder only Right-click each pm-[name]/ folder → Share → add only that PM → role: Contributor. They will not see other PM folders unless explicitly shared.
  • 4
    Share vp/shared/ as read-only with all PMs Right-click vp/shared/ → Share → add all PM emails → role: Viewer. PMs can read but not edit the global strategy files.
  • 5
    Keep the rest of vp/ private Do not share the rest of vp/ (1:1 logs, PM profiles, VP learning log) with PMs. Those stay VP-only.
Important: Google Drive folder-level permissions are only available in Shared Drives (not personal My Drive). This is another reason Shared Drive is required for this setup.
🔵
Section 3
Microsoft 365 Setup

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.

Concept Google Microsoft
Org-owned shared folder Shared Drive SharePoint Team Site
Sync client Google Drive for Desktop OneDrive (built into Windows, free on Mac)
Mac path ~/Google Drive/Shared drives/AI-SHIPR-ORG/ ~/OneDrive - [Company]/AI-SHIPR-ORG/
Windows path G:\Shared drives\AI-SHIPR-ORG\ C:\Users\...\OneDrive - [Company]\AI-SHIPR-ORG\
Folder permissions Drive UI → Share → Viewer / Contributor SharePoint UI → Share → View / Edit
The folder structure, ownership rules, and CLAUDE.md instructions are identical to the Google Drive setup. The only difference is the sync client and the local path format.
  • 1
    Create a SharePoint Team Site In Microsoft 365, go to SharePoint+ Create siteTeam site. Name it AI-SHIPR-ORG (or your company name). This creates the organisation-owned root, equivalent to a Google Shared Drive.
  • 2
    Create the folder structure in the Documents library Inside the site's Documents library, create the 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.
  • 3
    Sync to your local machine In SharePoint, open the Documents library → click Sync. The OneDrive app opens and begins syncing the site to your machine. The folder appears in Finder / File Explorer under OneDrive – [Company Name].
  • 4
    Set permissions In SharePoint, right-click each folder → Share → set View / Edit access per role. The VP has Edit on all. Each PM has Edit on their own folder only, View on vp/shared/.
  • 5
    Enable Lead Mode and open Claude Code Open 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
  • 1
    Accept the SharePoint site invitation The VP invites each PM to the SharePoint site via email. Accept the invitation - the site becomes accessible in your Microsoft 365 account.
  • 2
    Install OneDrive (Mac only - already built into Windows) On Mac, download OneDrive from the App Store or from microsoft.com/onedrive. Sign in with your Microsoft 365 account.
  • 3
    Sync the SharePoint folder to your machine Open the SharePoint site in the browser → Documents → click Sync. The folder syncs locally and appears under OneDrive – [Company Name].
  • 4
    Navigate to your PM folder and extract AI-SHIPR 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.
  • 5
    Open Claude Code from your PM folder Mac: cd ~/OneDrive\ -\ [Company]/AI-SHIPR-ORG/pm-[yourname] && claude Windows: cd "C:\Users\[you]\OneDrive - [Company]\AI-SHIPR-ORG\pm-[yourname]" && claude
Role Site access Folder write access Read access
VP Product Site Owner / Edit vp/ including shared/ All PM folders + vp/shared/
Each PM Edit (folder-scoped) Their own pm-[name]/ only Their own folder + vp/shared/ (View)
Note: SharePoint folder-level permissions require breaking permission inheritance. Right-click the folder → Manage accessStop inheriting permissions, then set the specific access. This is the equivalent of Google Drive's per-folder sharing.
The relative path still works. The company name appears in the absolute path (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.
🔷
Section 4
Atlassian Confluence Setup

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.

Layer Where it lives Who reads it
Editing surface Confluence space Humans - VP, PMs, stakeholders
Context runtime vp/shared/ local mirror, refreshed by the sync Claude Code
System runtime Git repo, cloned to each machine Claude Code
Two runtimes, because they change at different speeds. Context runtime is vision, OKRs and bets - humans rewrite it, it moves weekly, and it arrives by sync. System runtime is 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.
The VP edits the OKRs page in Confluence and says so. Everyone runs the sync, and 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.
AI-SHIPR Space (Confluence) Shared Strategy ← VP writes, all PMs view Vision Strategy OKRs Strategic Bets Portfolio Roadmap Constraints VP Workspace ← VP only Team Roster 1:1 Notes PM Profiles Product Workspaces ← one page per PRODUCT, not per person Scheduling Assistant ← Owner: Alice Billing Portal ← Owner: Alice Partner API ← Owner: Bob ...
Mirror the AI-SHIPR folder structure in Confluence page names. When a page and a local file share the same name (e.g., OKRs), it is trivial to keep them in sync.
Key the product pages to the product, never to the person

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:

ContentLives as long asWhere it belongs
Vision, strategy, OKRs, bets, constraintsthe companyShared Strategy
Product strategy, personas, glossary, decision logthe productProduct Workspaces
PM profile, PM voice, coaching log, 1:1 notesthe personthe 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.

PropertyWhy
OwnerThe current PM. The field that absorbs all churn
Previous ownersWho to ask about a decision made two years ago
Last reviewedBlank it on handover. A new owner has not reviewed anything yet
StatusActive / Paused / Retired. A retired product keeps its decision log
The local folder stays person-keyed, and that asymmetry is deliberate. 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.
  • 1
    Create the Confluence Space In Confluence, click SpacesCreate spaceBlank space. Name it AI-SHIPR (or your product org name). Set it as a team space so it is visible to all invited members.
  • 2
    Create the Shared Strategy section Under the space home, create a parent page called Shared Strategy. Under it, create child pages: Vision, Strategy, OKRs, Strategic Bets, Portfolio Roadmap, Constraints. Fill them in with your current strategy content.
  • 3
    Create a local drive alongside Confluence Set up your AI-SHIPR local folder using Google Drive, SharePoint, or a local path as described in Sections 2–3. Confluence does not replace the local files - it is the human-readable companion. Paste the strategy content from Confluence into the corresponding .md files in vp/shared/.
  • 4
    Add a sync reminder to your workflow At the top of 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.
  • 5
    Invite the team Go to Space Settings → Permissions. Add each PM with View access to the full space. Individual page-level restrictions (below) will limit write access to the right sections.
  • 1
    Accept the space invitation The VP invites each PM to the Confluence space. Accept - the AI-SHIPR space will appear in your Confluence sidebar under Spaces.
  • 2
    Read the Shared Strategy pages Navigate to Shared Strategy and read Vision, OKRs, and Constraints before starting any planning work. These are the same documents Claude reads from ../vp/shared/ - Confluence is the human layer for the same content.
  • 3
    Create a page for each product you own Under Product Workspaces, create one parent page per product (e.g., Scheduling Assistant), not one page named after you. Set 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.
  • 4
    Set up your local AI-SHIPR folder Install AI-SHIPR into pm-[name]/ and run bash setup.sh once. Claude Code reads the local files, never Confluence directly.
  • 5
    Run the sync to populate 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.
  • 6
    Publish upward before each reconciliation Paste your Vision, Strategic Bets and Personas into the product page you own, so the VP can read across the team. This is a deliberate copy-paste, not a sync - see Team Rollout, Phase 3.
Role Space access Page edit access Read access
VP Product Space Admin All pages All pages
Each PM View + Edit (page-scoped) The product pages where they are Owner Shared Strategy + their own section
Permission Setup - Step by Step
  • 1
    Set space-level View access for all PMs Space Settings → Permissions → add each PM with Can view. This gives read access to the whole space by default.
  • 2
    Restrict the Shared Strategy section to VP edit only Open the Shared Strategy parent page → ⋯ More actionsPage restrictions → set Edit: VP only. PMs will be able to read but not modify strategy pages.
  • 3
    Give each PM Edit access to their own section Open each product page → Page restrictionsEdit: that product's 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.
  • 4
    Keep VP Workspace restricted Set the VP Workspace parent page restriction to View + Edit: VP only. 1:1 notes and PM profiles stay private.
Cloud vs. Data Center: Page restrictions work the same way in Confluence Cloud and Confluence Data Center. In Data Center, Space Administrators can also manage permissions via group membership in addition to individual users.
Confluence is where people edit, the local mirror is what Claude reads. The VP updates the OKRs page → everyone runs the sync → 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.
Section 5
Notion Setup

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.

LayerWhere it livesWho reads it
Editing surfaceNotion teamspaceHumans - VP, PMs, stakeholders
Context runtimevp/shared/ local mirror, refreshed by the syncClaude Code
System runtimeGit repo, cloned to each machineClaude Code
Two runtimes, because they change at different speeds. Context runtime is vision, OKRs and bets - humans rewrite it, it moves weekly, and it arrives by sync. System runtime is 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.
What this buys you. No Workspace or 365 dependency and no drive to mount, so no path differences between Mac and Windows. One editing surface the team already lives in. A session start that behaves identically every time, offline included. And a visible diff each time the org context moves.
Start the access request now. The Notion connector needs workspace-level approval, and in a regulated org security will review it before it is switched on. That is the long pole. Everything else on this page is an afternoon.
Product Context ← one teamspace Org Context ← a DATABASE, 6 rows. VP edits, team views Vision Strategy OKRs Strategic Bets Portfolio Roadmap Constraints Templates ← PRD, Ticket, Spec, Personas, UI guidelines Product Workspaces ← a DATABASE, one row per PRODUCT Scheduling Assistant ← Owner: Alice Billing Portal ← Owner: Alice Partner API ← Owner: Bob
Databases, not loose pages

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.

PropertyTypeWhy it exists
NameTitleMatch the target filename so humans can follow it. The sync maps by page ID, so a rename cannot break anything
OwnerPersonA context page with no named owner rots. This is who you ask
Last reviewedDateWritten into the markdown front matter, so Claude can flag stale context instead of quoting a six-month-old OKR with full confidence
Product Workspaces is keyed by product, never by person - one row per product with the PM in an Owner property. The reasoning is in Section 4.02, and it applies identically here.
How to write inside these pages
UseAvoid
Headings, paragraphs, bulletsToggles - content inside them can be dropped
Simple tablesSynced blocks, linked databases inside a page
Plain textCallouts carrying meaning the text does not
Inline linksColumns
Rule of thumb: if the page would still read correctly pasted into a plain text file, it will sync correctly. The sync flattens the page, and anything clever in the layout is lost on the way out.

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.

  • 1
    Read the page-ID mapA 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.
  • 2
    Fetch each page by IDThrough the Notion connector. If a fetch fails, report it and continue - never write a partial or empty file over a good one.
  • 3
    Flatten to markdown and write front matterCarry page_id, owner, last_reviewed and today's sync date into each file.
  • 4
    Report, and flag two conditions loudlylast_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.
Why 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.
Getting a page ID: open the page, Copy link, and take the 32-character hex string at the end of the URL - after the page name, before any ?.
One direction, with one exception at birth. Sync is Notion → local, always. The exception: Populate-Strategy first generates the org files on the VP's machine, and the VP publishes that first version up into Notion by hand. After that, local → Notion never happens again for those six files.
  • 1
    Create the Product Context teamspaceThen the Org Context database with the three properties above, and its six rows.
  • 2
    Fill in the org contextThis is the part that actually matters. The plumbing is easy; the content is the work.
  • 3
    Set permissionsView-only for the team on Org Context and Templates. See Section 5.06.
  • 4
    Create the Product Workspaces databaseOne row per product, with Owner set to the PM who runs it.
  • 5
    Record the page IDsAdd each ID and its target filename to Context-Index.md in the repo, and commit.
  • 6
    Set team_mode: leadIn your own Settings.md.
PRDs stay where they are. Do not migrate a live PRD database into the context layer and do not mirror it wholesale - they change constantly, and a stale mirror of a live PRD is worse than no mirror. Pull only the PRD in play at the start of a session, and publish it back the way you do today.
  • 1
    Clone the shared repoIt holds the AI-SHIPR runtime, the templates, Context-Index.md and the Sync-Context skill.
  • 2
    Install AI-SHIPR into pm-[name]/Run bash setup.sh once, and confirm team_mode: individual in Settings.md.
  • 3
    Connect the Notion connector in Claude CodeEach machine authenticates separately. Notion's own permissions decide what each person can see.
  • 4
    Run /sync-contextThis populates your local vp/shared/ mirror. Re-run it whenever the VP says the org context moved.
  • 5
    Then fill your Setup WorksheetIn that order, on purpose - see the tip below.
Step 5 comes after step 4 deliberately. Strategy generated after Claude has read the org context comes out already aligned with it, instead of needing to be reconciled afterwards. Reconciliation after the fact is a rewrite, not a review.
Only the VP touches the six org pages. A PM edits exactly one row in Product Workspaces - the one where their name sits in Owner.
PageVPEach PM
Org ContextCan editCan view
TemplatesCan editCan view - changes go through a pull request on the repo
Product WorkspacesCan edit, all rowsCan edit the rows where they are Owner
Let access follow the 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.
Say the rule out loud, do not only configure it. The structure holds better when the team understands why they cannot edit the org context than when they discover it.
What never goes into Notion: 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

Workshop Info All Resources Contact verve-pm.com