/project-docs

name: pmstudio-init
description: Use when starting a new project, onboarding to an existing product, or setting up a documentation ecosystem for any initiative. Scaffolds the standard document set, folder structure, project memory, and doc-sync config. Works for software products, consulting engagements, platform implementations, and governance programs.
domain: pm

Project Docs — Standard Document Ecosystem

Purpose

Every project needs the same core set of interconnected documents. This skill scaffolds a complete documentation ecosystem from day one so that:

• Nothing gets lost between meetings, decisions, and deliverables
• Every document has a clear owner, purpose, and update trigger
• The doc-sync watcher can automatically detect when documents go stale
• New team members can onboard by reading the folder structure alone

When to Use

• `/project-docs init` — Scaffold a new project from scratch
• `/project-docs init --type consulting` — Use consulting template (meetings-heavy)
• `/project-docs init --type product` — Use product template (PRD-heavy)
• `/project-docs init --type implementation` — Use implementation template (vendor + config)
• `/project-docs audit` — Check an existing project against the standard and report gaps

The Standard Document Set

Every project should have these **16 document types** organized in **6 categories**. Not every project needs all 16 — the skill asks which ones apply and only scaffolds what's needed. Documents 11-16 are generated on demand via dedicated slash commands in the `pm-ops` skill category.

Category 1: Source of Truth (Root Documents)

These are authoritative — all other documents derive from them.

| # | Document | File Pattern | Purpose | Update Trigger | |---|----------|-------------|---------|----------------| | 1 | **PRD / Requirements** | `PRD/` or `Requirements/` | What we're building and why | Decisions, research findings, stakeholder feedback | | 2 | **Project Memory** | `CLAUDE.local.md` | AI context — architecture, decisions, recent changes | Every session (auto-maintained) |

Category 2: Source Documents (Inputs)

Raw inputs that feed the root documents. These are append-only — never edited after creation.

| # | Document | File Pattern | Purpose | Update Trigger | |---|----------|-------------|---------|----------------| | 3 | **Meeting Notes** | `Meeting-Notes/YYYY-MM-DD-Name.md` | Decisions, action items, context from calls | After every meeting | | 4 | **Research** | `Research/Topic-Name.md` | Deep dives, competitive analysis, technical research | As needed | | 5 | **Source Documents** | `Source-Documents/` | Contracts, emails, vendor docs, screenshots | When received |

Category 3: Derived Documents (Outputs)

Generated from root + source documents. These go stale and need syncing.

| # | Document | File Pattern | Purpose | Update Trigger | |---|----------|-------------|---------|----------------| | 6 | **Presentation / Deck** | `Presentations/Name-vN.html` | Stakeholder-facing summary | PRD changes, new meetings, new decisions | | 7 | **PRD Presentation** | `PRD/PRD-Presentation.html` | Slide version of PRD for reviews | PRD changes | | 8 | **Architecture Map** | `Architecture/` | System diagrams, data flows, integration maps | Design decisions, technical research | | 9 | **ARB Review** | `ARB/` | Architecture Review Board presentation (Coco Inc 11-slide format) | Architecture changes, pre-go-live |

Generate with: `/arb-review` — auto-populates from PRD + architecture + project registry data.

Category 4: Operational Documents

Living documents that track ongoing state.

| # | Document | File Pattern | Purpose | Update Trigger | |---|----------|-------------|---------|----------------| | 10 | **Verification / Audit** | `Verification/` | Data verification, gap analysis, compliance checks | Before milestones | | 11 | **Stakeholder Directory** | `Data/Stakeholder-Directory.xlsx` | Contact list with roles, groups, ownership | New people mentioned in meetings | | 12 | **Change Log** | `Change-Log.md` | Running log of product/platform changes (config, users, modules) | After every change | | 13 | **NFR Tracker** | `.nfr-status.json` | Cross-cutting readiness dashboard — tracks status of all document types | Continuous |

Generate with: `/change-log` (init or append) and `/nfr-tracker` (audit readiness).

Category 5: Compliance & Resilience

Required for production systems. Generated on demand as go-live approaches.

| # | Document | File Pattern | Purpose | Update Trigger | |---|----------|-------------|---------|----------------| | 14 | **DR Plan** | `Operations/DR-Plan.md` | Disaster Recovery — RTO/RPO targets, failover, manual fallbacks | Pre-go-live, annually | | 15 | **IRP** | `Operations/IRP.md` | Incident Response Plan — severity matrix, escalation, SOX implications | Pre-go-live, annually | | 16 | **Recovery Plan** | `Operations/Recovery-Plan.md` | Step-by-step restoration runbooks per failure scenario | After DR + IRP created |

Generate with: `/dr-plan` → `/irp` → `/recovery-plan` (in dependency order).

Category 6: Communications

Templates for stakeholder announcements. Generated on demand.

| Document | File Pattern | Purpose | Generate With | |----------|-------------|---------|---------------| | **Stakeholder Comms** | `Comms/Stakeholder-Comms.html` | Pre-filled templates: go-live, status, onboarding, incident, SteerCo | `/stakeholder-comms` |

The Dependency Graph

Meeting Notes ──┬──→ PRD ──────────→ PRD Presentation
                │     │
Research ───────┤     ├──→ Main Presentation
                │     │
Source Docs ────┘     ├──→ Architecture Map
                      │
                      ├──→ /arb-review (ARB presentation)
                      │
                      ├──→ /dr-plan ────→ /recovery-plan
                      │
                      ├──→ /irp ────────→ /recovery-plan
                      │
                      ├──→ /change-log (appen