[Day 12 of 30] Keep Your PMS in GitHub So Your Team Can Share One Backbone

Each person builds their own PMS. A shared repo lets you work as one team.

The situation

This series is about building your PMS, your personal management system: the prompts, workflows, and structure that compound over 30 days. In a company, several people might each be building their own PMS the same way. The risk is that everyone ends up with a different structure, different prompts, and no single place to align. You want each person to keep their own system and their private data, but you also want the team to run on a shared resource so you are not reinventing the wheel in every corner. The fix is to put that shared layer in one place that everyone can use and improve: a GitHub repo.

---

The 1% upgrade

Keep the shared part of your PMS in a GitHub repo. By “shared” we mean: the structure (how you organize prompts, checklists, templates), the actual prompts and checklists that do not contain confidential data, and any skill packs the whole team can reuse.

Each colleague keeps building their own PMS: their vault, their private notes, their local config. But they pull from the same repo for the common backbone. So you get one shared resource in GitHub and many individual PMS instances that use it.

Private data (meeting notes, project names, credentials) never goes in the repo. It stays only on each person’s machine.

The team functions as one because they share structure and artifacts, not because they share one login or one database.

---

A concrete split: what goes in the repo, what stays local

In the repo (shared backbone) use a simple layout everyone can clone:

• prompts/ – Prompt templates the team reuses: daily plan, meeting prep, “turn notes into action plan,” “draft a one-pager from a brief.” No project names or client context inside.

• checklists/ – Short lists of “what good looks like” when you review something: e.g. “Before we call a PRD done, we check X, Y, Z” or “A user story must have acceptance criteria and a test idea.” Same list for everyone, so you and the AI both know what to check.

• skills/ – Skill-pack text for agents: role, goals, constraints, edge cases. Anything that defines how the AI should behave, without secrets or paths to your machine.

• templates/ – Note templates: meeting note, project brief, one-pager. Structure only, no real content.

• MCP setup – The repo can hold the setup for each MCP server your team uses (the code or config needed to connect to Calendar, Granola, Work, Gmail, etc.). Then each teammate clones the repo, runs install once, and has the same set of tools. Credentials and tokens stay out of the repo; each person adds those locally after clone.

• README – Describes how to use the repo. One short note: this repo is our team’s PMS backbone; put here only what everyone can use; never add names, credentials, or client data.

Inside prompts, checklists, and skills you can split by role or function: e.g. subfolders or tags for product, sales, marketing, ops. That way product managers pull from one set, sales from another, and the repo still stays one backbone for the whole team.

Only on your machine (private) keep everything that is yours or sensitive:

• Your vault content (real meeting notes, real project and people data). The list below is only an example from Day 1; you can extend it or replace it with any folder structure that fits you:

  • 00-Inbox

  • 01-Projects

  • 02-Areas (People, Companies)

  • 03-Resources

  • 04-Archives

• Your tasks and plans (your backlog and goals) - wherever you keep them (e.g. in Inbox, a tasks file, or a dedicated folder you added yourself)

• Your config (never commit these):

  • .env

  • API keys, tokens

• Your MCP data - the data each tool reads or writes stays only on your machine (calendar, email, transcripts, backlog). The MCP setup (config, code) lives in the repo so the team shares the same tools; only the data is private:

  • Calendar events (Day 3)

  • Email (Day 4)

  • Meeting transcripts, e.g. Granola (Day 6)

  • Jira, Confluence, or Linear - issues, pages, backlog (Day 8)

Summary:

• Repo (shared): structure, reusable prompts, checklists, and skills. Same for everyone who clones it.

• Local (private): your data and credentials. Never in the repo.

• How it works: Your AI (or scripts) load prompts and skills from the repo, and context (notes, tasks, calendar, email) from your machine. One backbone, many private instances.

---

Which use cases are shared vs private (when you use MCPs)

Same idea applied to the tools you plug into your PMS. The use case (what we do with the tool) can be shared; the data the tool touches stays private.

Shared (put in the repo): The prompt or workflow that uses the tool. For example: “Before a meeting, run meeting prep: pull attendees from calendar, pull last meetings with each person from Granola, summarize in one note.” That instruction and any prompt text go in prompts/ or skills/. So Calendar MCP, Granola MCP, and Jira/Confluence/Linear: the way the team uses them (daily plan, meeting prep, creating issues from a PRD) is shared; the prompts that define those flows live in the repo.

Private (never in the repo): The data each MCP reads or writes. Your calendar and events. Your meeting transcripts (Granola). Your email (Gmail).

So:

• Shared = “we use Linear to create issues from a PRD; here is the prompt”;

• Private = your Linear workspace and issues.

• Shared = “we use Calendar for daily plan; here is the flow”;

• Private = your calendar. That way the team aligns on how they use each tool, while each person keeps their own data.

Optional: team-shared data. Sometimes the team wants to put certain data in the repo so everyone can use it. For example, a sales team working on leads might keep a shared folder of meeting transcripts in the repo. Anyone who missed a call can pull context from that folder. So “shared” can mean not only prompts and workflows but also data the team has agreed to treat as internal and non-confidential. You decide together what belongs in the repo and what stays only on each person’s machine.

---

10-minute action

Step 1: Create the repo on GitHub

1. Go to github.com and sign in.

2. Click New (or the + in the top right → New repository).

3. Name the repo (e.g. pms-backbone or team-pms-shared). Choose Private if only your team should see it.

4. Leave “Add a README file” unchecked if you will create it with Cursor; or check it to start from a non-empty repo.

5. Click Create repository.

Step 2: Clone the repo and add the backbone with Cursor

1. Clone the repo to your machine: copy the repo URL from GitHub (e.g. https://github.com/yourname/pms-backbone.git), then in a terminal (in Cursor: Terminal → New Terminal) run: git clone <URL> in the folder where you want it (e.g. next to your vault or inside it).

2. Open the cloned folder in Cursor (File → Open Folder and select the repo folder).

3. In Cursor chat, paste a prompt like this:

   “Create a folder pms-shared/ in this repo. Inside it add one file: a short prompt or checklist we can reuse as a team (e.g. from Day 3 or Day 8 of the 1% PMS series - meeting prep or a small workflow). In the repo root create or update README.md with one sentence: This repo is our team’s PMS shared backbone; put here only what everyone can use; keep private data out. Do not add any real meeting notes, names, or credentials.”

4. After Cursor creates the folder and files, ask it to commit and push. In chat, paste for example:

   “Commit all changes in this repo and push to the remote. Write a short commit message that describes what was added. Run the git commands from the repo root.”

   Your shared backbone is now on GitHub.

Step 3: How a colleague gets the PMS from this repo

1. Send them the repo link (e.g. https://github.com/yourname/pms-backbone).

2. They clone the repo: git clone <repo-URL> on their machine (e.g. into a folder they use as their PMS or next to their vault).

3. They open that folder in Cursor. Their AI can now read prompts and checklists from pms-shared/. Their private data (inbox, projects, .env) stays in their own vault or folders; they do not put it in this repo.

4. To contribute: they add one artifact (e.g. a prompt or checklist) to pms-shared/, commit, push, and optionally open a pull request so you can review before merging.

You now have one shared backbone on GitHub and a clear path for others to use it and extend it without touching each other’s private data.

What to do next

Reply with what use cases you want to see next (e.g. how to share a specific workflow, how your team handles leads or transcripts), and any public rules or data policies your team already has that we haven’t covered. I will tailor the next posts to that.