Use when a project has linked documentation artifacts (PRDs, presentations, meeting notes, architecture maps) that must stay synchronized. Detects which source files changed, identifies downstream documents needing updates, reads new content, and proposes specific edits with diffs before applying. Also use when a .sync-report.md exists in the project or user says "process sync report".
npx skills add https://github.com/coco-research/coco --skill pmstudio-sync
Maintains consistency across a documentation ecosystem where one source change (e.g., a new meeting note) should cascade updates to multiple downstream documents (PRD, presentation, project memory).
This is NOT a background watcher. This skill is the Claude-side processor that:
The persistent detection layer runs outside Claude Code via /project-sync init:
| Component | Path | Purpose |
|-----------|------|---------|
| Orchestrator | ~/.claude/scripts/project-sync-orchestrator.sh | Email search + file detection + report generation |
| launchd agent | ~/Library/LaunchAgents/com.claude.project-sync.<name>.plist | Background scheduler (every 2 hours) |
| State dir | ~/.claude/state/<project-name>/ | Logs, timestamps, cached config (outside OneDrive) |
Each project needs .sync-watch.json in its root:
{
"project_name": "My Project",
"watch_dirs": ["docs/meeting-notes", "docs/research"],
"target_docs": {
"tier1": [
{
"path": "docs/PRD.html",
"name": "Product Requirements",
"update_from": ["meeting-notes", "research"],
"what": "Requirements, user stories, decisions"
}
],
"tier2": [
{
"path": "docs/presentation.html",
"name": "Stakeholder Deck",
"update_from": ["meeting-notes"],
"what": "Stakeholder updates, timeline changes"
}
]
},
"ignore_patterns": [".*", "*.tmp", "~$*"],
"file_types": [".md", ".html", ".docx", ".xlsx", ".pdf"]
}
When you start a Claude Code session in a watched project with pending changes:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SYNC WATCHER ► 3 new/modified file(s) detected
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Say "process sync report" to review and apply updates.
/doc-sync — check for changes now and process/doc-sync path/to/new-file.md — process a specific source fileprocess sync report — process a pending .sync-report.mdIf .sync-report.md exists: Read it — it lists all changed files with timestamps.
If no report (manual invocation):
!`bash ~/.claude/scripts/project-sync-orchestrator.sh "$(pwd)"`
Then read the generated .sync-report.md (written to project root or ~/.claude/state/<project-name>/sync-report.md).
If a specific file was passed as $ARGUMENTS: Use that file as the sole source.
If no changes detected: Report "All documents are in sync." and stop.
For each new/modified file detected:
.docx, .xlsx, .pptx, .pdf) — note them but don't read. Tell user: "Binary file detected — paste key content or convert to text.".md, .html) in fullFor each source file, extract:
- NEW STAKEHOLDERS: Name, Role, Email, Group
- NEW DECISIONS: What was decided, by whom, date, impact
- NEW REQUIREMENTS: Functional/non-functional, priority, acceptance criteria
- NEW ACTION ITEMS: Owner, deadline, status
- NEW ARCHITECTURE: Design changes, module updates, integration changes
- NEW RISKS: Description, impact, mitigation
- VERSION CHANGES: What changed from previous version
Read .sync-watch.json to determine which target docs need which types of updates.
For each target doc in tier1 and tier2:
update_from patternsPresent a structured proposal — DO NOT edit anything yet:
## Sync Proposal
### Source: Meeting-Notes-2026-03-17.md
**New content extracted:**
- 2 new stakeholders (Jane Doe, John Smith)
- 1 decision (moved go-live to Q4)
- 3 action items
### Updates Needed:
**1. PRD.html** (Tier 1)
- Section 05 Stakeholders: Add Jane Doe (Tax Director), John Smith (IT Lead)
- Section 12 Timeline: Update go-live from Q3 → Q4
- Change log: Add v1.1 entry
- [Show exact diff preview for each change]
**2. Presentation.html** (Tier 1)
- Slide 7 (Team): Add 2 stakeholder cards
- Slide 12 (Timeline): Update milestone date
- [Show exact diff preview]
**3. CLAUDE.local.md** (Tier 1)
- Recent Changes: Add dated entry
- [Show exact content to append]
**4. Stakeholder-Directory.xlsx** (Tier 2)
- SKIP — binary file, manual update needed
Ask user:
For each approved target:
After all edits applied:
.sync-report.md (consumed)_temp/.last-sync-check timestampCLAUDE.local.md Recent Changes section with a dated entry summarizing what was synced━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DOC SYNC ► COMPLETE ✓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Source files processed: 3
Documents updated: 4
✓ PRD.html — 3 edits (stakeholders, timeline, changelog)
✓ Presentation.html — 2 edits (team slide, timeline)
✓ CLAUDE.local.md — 1 edit (recent changes)
⚠ Stakeholder-Directory.xlsx — skipped (binary)
Manual follow-up needed:
- Update Stakeholder-Directory.xlsx with 2 new contacts
old_string matching. Never rewrite entire files..sync-watch.json in the project root (use template above)/project-sync init to set up the launchd cron job.sync-report.md when changes are detectedFor complex projects, document the update cascade in .sync-watch.json:
Meeting Notes ──→ PRD ──→ PRD Presentation
│ │
├──→ Main Presentation ←──┘
│
└──→ CLAUDE.local.md ←── (all changes)
This ensures that when a meeting note creates a PRD change, and that PRD change should also update the presentation, the full cascade is handled in one sync pass.
Prepare meeting materials with Notion context and Codex research; use when gathering context, drafting agendas/pre-reads, and tailoring materials to attendees.
> This skill generates, creates, or builds brand voice guidelines from source materials. It should be used when the user asks to "generate brand guidelines", "create a style guide", "extract brand voice", "create guidelines from calls", "consolidate brand materials", "analyze my sales calls for brand voice", "build a brand playbook from documents", "synthesize a voice and tone guide", or uploads brand documents, transcripts, or meeting recordings for brand analysis. Also triggers when the user has a discovery report and wants to convert it into actionable guidelines.
Prepares meeting materials by gathering context from Notion, enriching with Claude research, and creating both an internal pre-read and external agenda saved to Notion. Helps you arrive prepared with comprehensive background and structured meeting docs.
Share a Google Docs document with edit access and email collaborators the link.
> Lightweight NDA, MSA, and vendor contract review for SMBs without legal on staff. Reads contracts from local files, Gmail attachments, or DocuSign envelopes; flags non-standard terms; explains risks in plain English; and outputs a marked-up redline as a separate DOCX. Use when the user says "review this contract," "what am I signing," "red flags," "flag any concerns," "check the payment terms," or uploads/forwards a contract or legal agreement.
Search across all connected sources in one query. Trigger with "find that doc about...", "what did we decide on...", "where was the conversation about...", or when looking for a decision, document, or discussion that could live in chat, email, cloud storage, or a project tracker.
Check the status of existing agreements with a vendor across all connected systems — CLM, CRM, email, and document storage — with gap analysis and upcoming deadlines. Use when onboarding or renewing a vendor, when you need a consolidated view of what's signed and what's missing (MSA, DPA, SOW), or when checking for approaching expirations and surviving obligations.
Ingest supplied source material into an Obsidian vault with provenance and claim tracking: pasted text, files staged in the selected vault's inbox or .raw archive, or explicitly approved URLs. Use for a single source or bounded batch, not for saving an assistant answer. Triggers: ingest, ingest this file, ingest this URL, process this source, read and file this source, batch ingest, ingest these sources.
Take coco-research/pmstudio-sync from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.