diff --git a/.codex/skills-index.json b/.codex/skills-index.json
index 88ed857..c5c7f72 100644
--- a/.codex/skills-index.json
+++ b/.codex/skills-index.json
@@ -3,7 +3,7 @@
   "name": "claude-code-skills",
   "description": "Production-ready skill packages for AI agents - Marketing, Engineering, Product, C-Level, PM, and RA/QM",
   "repository": "https://github.com/alirezarezvani/claude-skills",
-  "total_skills": 186,
+  "total_skills": 188,
   "skills": [
     {
       "name": "contract-and-proposal-writer",
@@ -1031,6 +1031,12 @@
       "category": "project-management",
       "description": "Atlassian Jira expert for creating and managing projects, planning, product discovery, JQL queries, workflows, custom fields, automation, reporting, and all Jira features. Use for Jira project setup, configuration, advanced search, dashboard creation, workflow design, and technical Jira operations."
     },
+    {
+      "name": "meeting-analyzer",
+      "source": "../../project-management/meeting-analyzer",
+      "category": "project-management",
+      "description": "Analyzes meeting transcripts and recordings to surface behavioral patterns, communication anti-patterns, and actionable coaching feedback. Use this skill whenever the user uploads or points to meeting transcripts (.txt, .md, .vtt, .srt, .docx), asks about their communication habits, wants feedback on how they run meetings, requests speaking ratio analysis, mentions filler words or conflict avoidance, or wants to compare their communication across time periods. Also trigger when users mention tools like Granola, Otter, Fireflies, or Zoom transcripts. Even if the user just says \"look at my meetings\" or \"how do I come across in meetings\" \u2014 use this skill."
+    },
     {
       "name": "scrum-master",
       "source": "../../project-management/scrum-master",
@@ -1043,6 +1049,12 @@
       "category": "project-management",
       "description": "Senior Project Manager for enterprise software, SaaS, and digital transformation projects. Specializes in portfolio management, quantitative risk analysis, resource optimization, stakeholder alignment, and executive reporting. Uses advanced methodologies including EMV analysis, Monte Carlo simulation, WSJF prioritization, and multi-dimensional health scoring. Use when a user needs help with project plans, project status reports, risk assessments, resource allocation, project roadmaps, milestone tracking, team capacity planning, portfolio health reviews, program management, or executive-level project reporting \u2014 especially for enterprise-scale initiatives with multiple workstreams, complex dependencies, or multi-million dollar budgets."
     },
+    {
+      "name": "team-communications",
+      "source": "../../project-management/team-communications",
+      "category": "project-management",
+      "description": "Write internal company communications \u2014 3P updates (Progress/Plans/Problems), company-wide newsletters, FAQ roundups, incident reports, leadership updates, status reports, project updates, and general internal comms. Use this skill any time the user asks to draft, edit, or format something meant for internal audiences. Trigger on keywords like \"3P\", \"weekly update\", \"newsletter\", \"FAQ\", \"internal comms\", \"status report\", \"company update\", \"team update\", \"incident report\", or any request to summarize work for leadership, teammates, or the broader company. Even casual requests like \"write my update\" or \"summarize what my team did this week\" should trigger this skill."
+    },
     {
       "name": "capa-officer",
       "source": "../../ra-qm-team/capa-officer",
@@ -1159,7 +1171,7 @@
       "description": "Product management and design skills"
     },
     "project-management": {
-      "count": 6,
+      "count": 8,
       "source": "../../project-management",
       "description": "Project management and Atlassian skills"
     },
diff --git a/.codex/skills/meeting-analyzer b/.codex/skills/meeting-analyzer
new file mode 120000
index 0000000..420e8cd
--- /dev/null
+++ b/.codex/skills/meeting-analyzer
@@ -0,0 +1 @@
+../../project-management/meeting-analyzer
\ No newline at end of file
diff --git a/.codex/skills/team-communications b/.codex/skills/team-communications
new file mode 120000
index 0000000..0d686df
--- /dev/null
+++ b/.codex/skills/team-communications
@@ -0,0 +1 @@
+../../project-management/team-communications
\ No newline at end of file
diff --git a/docs/skills/project-management/index.md b/docs/skills/project-management/index.md
index ff1ca93..be7d1f2 100644
--- a/docs/skills/project-management/index.md
+++ b/docs/skills/project-management/index.md
@@ -1,13 +1,13 @@
 ---
 title: "Project Management Skills — Agent Skills & Codex Plugins"
-description: "7 project management skills — project management agent skill and Claude Code plugin for sprints, Jira, and Confluence. Works with Claude Code, Codex CLI, Gemini CLI, and OpenClaw."
+description: "9 project management skills — project management agent skill and Claude Code plugin for sprints, Jira, and Confluence. Works with Claude Code, Codex CLI, Gemini CLI, and OpenClaw."
 ---
 
 <div class="domain-header" markdown>
 
 # :material-clipboard-check-outline: Project Management
 
-<p class="domain-count">7 skills in this domain</p>
+<p class="domain-count">9 skills in this domain</p>
 
 </div>
 
@@ -41,6 +41,12 @@ description: "7 project management skills — project management agent skill and
 
     Master-level expertise in Jira configuration, project management, JQL, workflows, automation, and reporting. Handles ...
 
+-   **[Meeting Insights Analyzer](meeting-analyzer.md)**
+
+    ---
+
+    > Originally contributed by maximcoding(https://github.com/maximcoding) — enhanced and integrated by the claude-skill...
+
 -   **[Project Management Skills](project-management.md)**
 
     ---
@@ -59,4 +65,10 @@ description: "7 project management skills — project management agent skill and
 
     Strategic project management for enterprise software, SaaS, and digital transformation initiatives. Provides portfoli...
 
+-   **[Internal Comms](team-communications.md)**
+
+    ---
+
+    > Originally contributed by maximcoding(https://github.com/maximcoding) — enhanced and integrated by the claude-skill...
+
 </div>
diff --git a/docs/skills/project-management/meeting-analyzer.md b/docs/skills/project-management/meeting-analyzer.md
new file mode 100644
index 0000000..c7909a0
--- /dev/null
+++ b/docs/skills/project-management/meeting-analyzer.md
@@ -0,0 +1,266 @@
+---
+title: "Meeting Insights Analyzer — Agent Skill for PM"
+description: "Analyzes meeting transcripts and recordings to surface behavioral patterns, communication anti-patterns, and actionable coaching feedback. Use this. Agent skill for Claude Code, Codex CLI, Gemini CLI, OpenClaw."
+---
+
+# Meeting Insights Analyzer
+
+<div class="page-meta" markdown>
+<span class="meta-badge">:material-clipboard-check-outline: Project Management</span>
+<span class="meta-badge">:material-identifier: `meeting-analyzer`</span>
+<span class="meta-badge">:material-github: <a href="https://github.com/alirezarezvani/claude-skills/tree/main/project-management/meeting-analyzer/SKILL.md">Source</a></span>
+</div>
+
+<div class="install-banner" markdown>
+<span class="install-label">Install:</span> <code>claude /plugin install pm-skills</code>
+</div>
+
+
+> Originally contributed by [maximcoding](https://github.com/maximcoding) — enhanced and integrated by the claude-skills team.
+
+Transform meeting transcripts into concrete, evidence-backed feedback on communication patterns, leadership behaviors, and interpersonal dynamics.
+
+## Core Workflow
+
+### 1. Ingest & Inventory
+
+Scan the target directory for transcript files (`.txt`, `.md`, `.vtt`, `.srt`, `.docx`, `.json`).
+
+For each file:
+- Extract meeting date from filename or content (expect `YYYY-MM-DD` prefix or embedded timestamps)
+- Identify speaker labels — look for patterns like `Speaker 1:`, `[John]:`, `John Smith  00:14:32`, VTT/SRT cue formatting
+- Detect the user's identity: ask if ambiguous, otherwise infer from the most frequent speaker or filename hints
+- Log: filename, date, duration (from timestamps), participant count, word count
+
+Print a brief inventory table so the user confirms scope before heavy analysis begins.
+
+### 2. Normalize Transcripts
+
+Different tools produce wildly different formats. Normalize everything into a common internal structure before analysis:
+
+```
+{ speaker: string, timestamp_sec: number | null, text: string }[]
+```
+
+Handling per format:
+- **VTT/SRT**: Parse cue timestamps + text. Speaker labels may be inline (`<v Speaker>`) or prefixed.
+- **Plain text**: Look for `Name:` or `[Name]` prefixes per line. If no speaker labels exist, warn the user that per-speaker analysis is limited.
+- **Markdown**: Strip formatting, then treat as plain text.
+- **DOCX**: Extract text content, then treat as plain text.
+- **JSON**: Expect an array of objects with `speaker`/`text` fields (common Otter/Fireflies export).
+
+If timestamps are missing, degrade gracefully — skip timing-dependent metrics (speaking pace, pause analysis) but still run text-based analysis.
+
+### 3. Analyze
+
+Run all applicable analysis modules below. Each module is independent — skip any that don't apply (e.g., skip speaking ratios if there are no speaker labels).
+
+---
+
+#### Module: Speaking Dynamics
+
+Calculate per-speaker:
+- **Word count & percentage** of total meeting words
+- **Turn count** — how many times each person spoke
+- **Average turn length** — words per uninterrupted speaking turn
+- **Longest monologue** — flag turns exceeding 60 seconds or 200 words
+- **Interruption detection** — a turn that starts within 2 seconds of the previous speaker's last timestamp, or mid-sentence breaks
+
+Produce a per-meeting summary and a cross-meeting average if multiple transcripts exist.
+
+Red flags to surface:
+- User speaks > 60% in a 1:many meeting (dominating)
+- User speaks < 15% in a meeting they're facilitating (disengaged or over-delegating)
+- One participant never speaks (excluded voice)
+- Interruption ratio > 2:1 (user interrupts others twice as often as they're interrupted)
+
+---
+
+#### Module: Conflict & Directness
+
+Scan the user's speech for hedging and avoidance markers:
+
+**Hedging language** (score per-instance, aggregate per meeting):
+- Qualifiers: "maybe", "kind of", "sort of", "I guess", "potentially", "arguably"
+- Permission-seeking: "if that's okay", "would it be alright if", "I don't know if this is right but"
+- Deflection: "whatever you think", "up to you", "I'm flexible"
+- Softeners before disagreement: "I don't want to push back but", "this might be a dumb question"
+
+**Conflict avoidance patterns** (requires more context, flag with confidence level):
+- Topic changes after tension (speaker A raises problem → user pivots to logistics)
+- Agreement-without-commitment: "yeah totally" followed by no action or follow-up
+- Reframing others' concerns as smaller than stated: "it's probably not that big a deal"
+- Absent feedback in 1:1s where performance topics would be expected
+
+For each flagged instance, extract:
+- The full quote (with surrounding context — 2 turns before and after)
+- A severity tag: `low` (single hedge word), `medium` (pattern of hedging in one exchange), `high` (clearly avoided a necessary conversation)
+- A rewrite suggestion: what a more direct version would sound like
+
+---
+
+#### Module: Filler Words & Verbal Habits
+
+Count occurrences of: "um", "uh", "like" (non-comparative), "you know", "actually", "basically", "literally", "right?" (tag question), "so yeah", "I mean"
+
+Report:
+- Total count per meeting
+- Rate per 100 words spoken (normalizes across meeting lengths)
+- Breakdown by filler type
+- Contextual spikes — do fillers increase in specific situations? (e.g., when responding to a senior stakeholder, when giving negative feedback, when asked a question cold)
+
+Only flag this as an issue if the rate exceeds ~3 per 100 words. Below that, it's normal speech.
+
+---
+
+#### Module: Question Quality & Listening
+
+Classify the user's questions:
+- **Closed** (yes/no): "Did you finish the report?"
+- **Leading** (answer embedded): "Don't you think we should ship sooner?"
+- **Open genuine**: "What's blocking you on this?"
+- **Clarifying** (references prior speaker): "When you said X, did you mean Y?"
+- **Building** (extends another's idea): "That's interesting — what if we also Z?"
+
+Good listening indicators:
+- Clarifying and building questions (shows active processing)
+- Paraphrasing: "So what I'm hearing is..."
+- Referencing a point someone made earlier in the meeting
+- Asking quieter participants for input
+
+Poor listening indicators:
+- Asking a question that was already answered
+- Restating own point without acknowledging the response
+- Responding to a question with an unrelated topic
+
+Report the ratio of open/clarifying/building vs. closed/leading questions.
+
+---
+
+#### Module: Facilitation & Decision-Making
+
+Only apply when the user is the meeting organizer or facilitator.
+
+Evaluate:
+- **Agenda adherence**: Did the meeting follow a structure or drift?
+- **Time management**: How long did each topic take vs. expected?
+- **Inclusion**: Did the facilitator actively draw in quiet participants?
+- **Decision clarity**: Were decisions explicitly stated? ("So we're going with option B — Sarah owns the follow-up by Friday.")
+- **Action items**: Were they assigned with owners and deadlines, or left vague?
+- **Parking lot discipline**: Were off-topic items acknowledged and deferred, or did they derail?
+
+---
+
+#### Module: Sentiment & Energy
+
+Track the emotional arc of the user's language across the meeting:
+- **Positive markers**: enthusiastic agreement, encouragement, humor, praise
+- **Negative markers**: frustration, dismissiveness, sarcasm, curt responses
+- **Neutral/flat**: low-energy responses, monosyllabic answers
+
+Flag energy drops — moments where the user's engagement visibly decreases (shorter turns, less substantive responses). These often correlate with discomfort, boredom, or avoidance.
+
+---
+
+### 4. Output the Report
+
+Structure the final output as a single cohesive report. Use this skeleton — omit any section where data was insufficient:
+
+```markdown
+# Meeting Insights Report
+
+**Period**: [earliest date] – [latest date]
+**Meetings analyzed**: [count]
+**Total transcript words**: [count]
+**Your speaking share (avg)**: [X%]
+
+---
+
+## Top 3 Findings
+
+[Rank by impact. Each finding gets 2-3 sentences + one concrete example with a direct quote and timestamp.]
+
+## Detailed Analysis
+
+### Speaking Dynamics
+[Stats table + narrative interpretation + flagged red flags]
+
+### Directness & Conflict Patterns
+[Flagged instances grouped by pattern type, with quotes and rewrites]
+
+### Verbal Habits
+[Filler word stats, contextual spikes, only if rate > 3/100 words]
+
+### Listening & Questions
+[Question type breakdown, listening indicators, specific examples]
+
+### Facilitation
+[Only if applicable — agenda, decisions, action items]
+
+### Energy & Sentiment
+[Arc summary, flagged drops]
+
+## Strengths
+[3 specific things the user does well, with evidence]
+
+## Growth Opportunities
+[3 ranked by impact, each with: what to change, why it matters, a concrete "try this next time" action]
+
+## Comparison to Previous Period
+[Only if prior analysis exists — delta on key metrics]
+```
+
+### 5. Follow-Up Options
+
+After delivering the report, offer:
+- Deep dive into any specific meeting or pattern
+- A 1-page "communication cheat sheet" with the user's top 3 habits to change
+- Tracking setup — save current metrics as a baseline for future comparison
+- Export as markdown or structured JSON for use in performance reviews
+
+---
+
+## Edge Cases
+
+- **No speaker labels**: Warn the user upfront. Run text-level analysis (filler words, question types on the full transcript) but skip per-speaker metrics. Suggest re-exporting with speaker diarization enabled.
+- **Very short meetings** (< 5 minutes or < 500 words): Analyze but caveat that patterns from short meetings may not be representative.
+- **Non-English transcripts**: The filler word and hedging dictionaries are English-centric. For other languages, note the limitation and focus on structural analysis (speaking ratios, turn-taking, question counts).
+- **Single meeting vs. corpus**: If only one transcript, skip trend/comparison language. Focus findings on that meeting alone.
+- **User not identified**: If you can't determine which speaker is the user after scanning, ask before proceeding. Don't guess.
+
+## Transcript Source Tips
+
+Include this section in output only if the user seems unsure about how to get transcripts:
+
+- **Zoom**: Settings → Recording → enable "Audio transcript". Download `.vtt` from cloud recordings.
+- **Google Meet**: Auto-transcription saves to Google Docs in the calendar event's Drive folder.
+- **Granola**: Exports to markdown. Best speaker label quality of consumer tools.
+- **Otter.ai**: Export as `.txt` or `.json` from the web dashboard.
+- **Fireflies.ai**: Export as `.docx` or `.json` — both work.
+- **Microsoft Teams**: Transcripts appear in the meeting chat. Download as `.vtt`.
+
+Recommend `YYYY-MM-DD - Meeting Name.ext` naming convention for easy chronological analysis.
+
+---
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Better Approach |
+|---|---|---|
+| Analyzing without speaker labels | Per-person metrics impossible — results are generic word clouds | Ask user to re-export with speaker identification enabled |
+| Running all modules on a 5-minute standup | Overkill — filler word and conflict analysis need 20+ min meetings | Auto-detect meeting length and skip irrelevant modules |
+| Presenting raw metrics without context | "You said 'um' 47 times" is demoralizing without benchmarks | Always compare to norms and show trajectory over time |
+| Analyzing a single meeting in isolation | One meeting is a snapshot, not a pattern — conclusions are unreliable | Require 3+ meetings minimum for trend-based coaching |
+| Treating speaking time equality as the goal | A facilitator SHOULD talk less; a presenter SHOULD talk more | Weight speaking ratios by meeting type and role |
+| Flagging every hedge word as negative | "I think" and "maybe" are appropriate in brainstorming | Distinguish between decision meetings (hedges are bad) and ideation (hedges are fine) |
+
+---
+
+## Related Skills
+
+| Skill | Relationship |
+|-------|-------------|
+| `project-management/senior-pm` | Broader PM scope — use for project planning, risk, stakeholders |
+| `project-management/scrum-master` | Agile ceremonies — pairs with meeting-analyzer for retro quality |
+| `project-management/confluence-expert` | Store meeting analysis outputs as Confluence pages |
+| `c-level-advisor/executive-mentor` | Executive communication coaching — complementary perspective |
\ No newline at end of file
diff --git a/docs/skills/project-management/team-communications.md b/docs/skills/project-management/team-communications.md
new file mode 100644
index 0000000..add260a
--- /dev/null
+++ b/docs/skills/project-management/team-communications.md
@@ -0,0 +1,78 @@
+---
+title: "Internal Comms — Agent Skill for PM"
+description: "Write internal company communications — 3P updates (Progress/Plans/Problems), company-wide newsletters, FAQ roundups, incident reports, leadership. Agent skill for Claude Code, Codex CLI, Gemini CLI, OpenClaw."
+---
+
+# Internal Comms
+
+<div class="page-meta" markdown>
+<span class="meta-badge">:material-clipboard-check-outline: Project Management</span>
+<span class="meta-badge">:material-identifier: `team-communications`</span>
+<span class="meta-badge">:material-github: <a href="https://github.com/alirezarezvani/claude-skills/tree/main/project-management/team-communications/SKILL.md">Source</a></span>
+</div>
+
+<div class="install-banner" markdown>
+<span class="install-label">Install:</span> <code>claude /plugin install pm-skills</code>
+</div>
+
+
+> Originally contributed by [maximcoding](https://github.com/maximcoding) — enhanced and integrated by the claude-skills team.
+
+Write polished internal communications by loading the right reference file, gathering context, and outputting in the company's exact format.
+
+## Routing
+
+Identify the communication type from the user's request, then read the matching reference file before writing anything:
+
+| Type | Trigger phrases | Reference file |
+|---|---|---|
+| **3P Update** | "3P", "progress plans problems", "weekly team update", "what did we ship" | `references/3p-updates.md` |
+| **Newsletter** | "newsletter", "company update", "weekly/monthly roundup", "all-hands summary" | `references/company-newsletter.md` |
+| **FAQ** | "FAQ", "common questions", "what people are asking", "confusion around" | `references/faq-answers.md` |
+| **General** | anything internal that doesn't match above | `references/general-comms.md` |
+
+If the type is ambiguous, ask one clarifying question — don't guess.
+
+## Workflow
+
+1. **Read the reference file** for the matched type. Follow its formatting exactly.
+2. **Gather inputs.** Use available MCP tools (Slack, Gmail, Google Drive, Calendar) to pull real data. If no tools are connected, ask the user to provide bullet points or raw context.
+3. **Clarify scope.** Confirm: team name (for 3Ps), time period, audience, and any specific items the user wants included or excluded.
+4. **Draft.** Follow the format, tone, and length constraints from the reference file precisely. Do not invent a new format.
+5. **Present the draft** and ask if anything needs to be added, removed, or reworded.
+
+## Tone & Style (applies to all types)
+
+- Use "we" — you are part of the company.
+- Active voice, present tense for progress, future tense for plans.
+- Concise. Every sentence should carry information. Cut filler.
+- Include metrics and links wherever possible.
+- Professional but approachable — not corporate-speak.
+- Put the most important information first.
+
+## When tools are unavailable
+
+If the user hasn't connected Slack, Gmail, Drive, or Calendar, don't stall. Ask them to paste or describe what they want covered. You're formatting and sharpening — that's still valuable. Mention which tools would improve future drafts so they can connect them later.
+
+---
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Better Approach |
+|---|---|---|
+| Writing updates without reading the reference template first | Output won't match company format — user has to reformat | Always load the matching reference file before drafting |
+| Inventing metrics or accomplishments | Internal comms must be factual — fabrication destroys trust | Only include data the user provided or MCP tools retrieved |
+| Using passive voice for accomplishments | "The feature was shipped" hides who did the work | "Team X shipped the feature" — active voice credits the team |
+| Writing walls of text for status updates | Leadership scans, doesn't read — key info gets buried | Lead with the headline, follow with 3-5 bullet points |
+| Sending without confirming audience | A team update reads differently from a company-wide newsletter | Always confirm: who will read this? |
+
+---
+
+## Related Skills
+
+| Skill | Relationship |
+|-------|-------------|
+| `project-management/senior-pm` | Broader PM scope — status reports feed into PM reporting |
+| `project-management/meeting-analyzer` | Meeting insights can feed into 3P updates and status reports |
+| `project-management/confluence-expert` | Publish comms as Confluence pages for permanent record |
+| `marketing-skill/content-production` | External comms — use for public-facing content, not internal |
diff --git a/mkdocs.yml b/mkdocs.yml
index bf184a4..1e8ea8a 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -294,8 +294,10 @@ nav:
       - "Atlassian Templates": skills/project-management/atlassian-templates.md
       - "Confluence Expert": skills/project-management/confluence-expert.md
       - "Jira Expert": skills/project-management/jira-expert.md
+      - "Meeting Analyzer": skills/project-management/meeting-analyzer.md
       - "Scrum Master": skills/project-management/scrum-master.md
       - "Senior PM": skills/project-management/senior-pm.md
+      - "Team Communications": skills/project-management/team-communications.md
     - C-Level Advisory:
       - Overview: skills/c-level-advisor/index.md
       - "Agent Protocol": skills/c-level-advisor/agent-protocol.md
diff --git a/project-management/meeting-analyzer/SKILL.md b/project-management/meeting-analyzer/SKILL.md
new file mode 100644
index 0000000..e447029
--- /dev/null
+++ b/project-management/meeting-analyzer/SKILL.md
@@ -0,0 +1,255 @@
+---
+name: meeting-analyzer
+description: Analyzes meeting transcripts and recordings to surface behavioral patterns, communication anti-patterns, and actionable coaching feedback. Use this skill whenever the user uploads or points to meeting transcripts (.txt, .md, .vtt, .srt, .docx), asks about their communication habits, wants feedback on how they run meetings, requests speaking ratio analysis, mentions filler words or conflict avoidance, or wants to compare their communication across time periods. Also trigger when users mention tools like Granola, Otter, Fireflies, or Zoom transcripts. Even if the user just says "look at my meetings" or "how do I come across in meetings" — use this skill.
+---
+
+# Meeting Insights Analyzer
+
+> Originally contributed by [maximcoding](https://github.com/maximcoding) — enhanced and integrated by the claude-skills team.
+
+Transform meeting transcripts into concrete, evidence-backed feedback on communication patterns, leadership behaviors, and interpersonal dynamics.
+
+## Core Workflow
+
+### 1. Ingest & Inventory
+
+Scan the target directory for transcript files (`.txt`, `.md`, `.vtt`, `.srt`, `.docx`, `.json`).
+
+For each file:
+- Extract meeting date from filename or content (expect `YYYY-MM-DD` prefix or embedded timestamps)
+- Identify speaker labels — look for patterns like `Speaker 1:`, `[John]:`, `John Smith  00:14:32`, VTT/SRT cue formatting
+- Detect the user's identity: ask if ambiguous, otherwise infer from the most frequent speaker or filename hints
+- Log: filename, date, duration (from timestamps), participant count, word count
+
+Print a brief inventory table so the user confirms scope before heavy analysis begins.
+
+### 2. Normalize Transcripts
+
+Different tools produce wildly different formats. Normalize everything into a common internal structure before analysis:
+
+```
+{ speaker: string, timestamp_sec: number | null, text: string }[]
+```
+
+Handling per format:
+- **VTT/SRT**: Parse cue timestamps + text. Speaker labels may be inline (`<v Speaker>`) or prefixed.
+- **Plain text**: Look for `Name:` or `[Name]` prefixes per line. If no speaker labels exist, warn the user that per-speaker analysis is limited.
+- **Markdown**: Strip formatting, then treat as plain text.
+- **DOCX**: Extract text content, then treat as plain text.
+- **JSON**: Expect an array of objects with `speaker`/`text` fields (common Otter/Fireflies export).
+
+If timestamps are missing, degrade gracefully — skip timing-dependent metrics (speaking pace, pause analysis) but still run text-based analysis.
+
+### 3. Analyze
+
+Run all applicable analysis modules below. Each module is independent — skip any that don't apply (e.g., skip speaking ratios if there are no speaker labels).
+
+---
+
+#### Module: Speaking Dynamics
+
+Calculate per-speaker:
+- **Word count & percentage** of total meeting words
+- **Turn count** — how many times each person spoke
+- **Average turn length** — words per uninterrupted speaking turn
+- **Longest monologue** — flag turns exceeding 60 seconds or 200 words
+- **Interruption detection** — a turn that starts within 2 seconds of the previous speaker's last timestamp, or mid-sentence breaks
+
+Produce a per-meeting summary and a cross-meeting average if multiple transcripts exist.
+
+Red flags to surface:
+- User speaks > 60% in a 1:many meeting (dominating)
+- User speaks < 15% in a meeting they're facilitating (disengaged or over-delegating)
+- One participant never speaks (excluded voice)
+- Interruption ratio > 2:1 (user interrupts others twice as often as they're interrupted)
+
+---
+
+#### Module: Conflict & Directness
+
+Scan the user's speech for hedging and avoidance markers:
+
+**Hedging language** (score per-instance, aggregate per meeting):
+- Qualifiers: "maybe", "kind of", "sort of", "I guess", "potentially", "arguably"
+- Permission-seeking: "if that's okay", "would it be alright if", "I don't know if this is right but"
+- Deflection: "whatever you think", "up to you", "I'm flexible"
+- Softeners before disagreement: "I don't want to push back but", "this might be a dumb question"
+
+**Conflict avoidance patterns** (requires more context, flag with confidence level):
+- Topic changes after tension (speaker A raises problem → user pivots to logistics)
+- Agreement-without-commitment: "yeah totally" followed by no action or follow-up
+- Reframing others' concerns as smaller than stated: "it's probably not that big a deal"
+- Absent feedback in 1:1s where performance topics would be expected
+
+For each flagged instance, extract:
+- The full quote (with surrounding context — 2 turns before and after)
+- A severity tag: `low` (single hedge word), `medium` (pattern of hedging in one exchange), `high` (clearly avoided a necessary conversation)
+- A rewrite suggestion: what a more direct version would sound like
+
+---
+
+#### Module: Filler Words & Verbal Habits
+
+Count occurrences of: "um", "uh", "like" (non-comparative), "you know", "actually", "basically", "literally", "right?" (tag question), "so yeah", "I mean"
+
+Report:
+- Total count per meeting
+- Rate per 100 words spoken (normalizes across meeting lengths)
+- Breakdown by filler type
+- Contextual spikes — do fillers increase in specific situations? (e.g., when responding to a senior stakeholder, when giving negative feedback, when asked a question cold)
+
+Only flag this as an issue if the rate exceeds ~3 per 100 words. Below that, it's normal speech.
+
+---
+
+#### Module: Question Quality & Listening
+
+Classify the user's questions:
+- **Closed** (yes/no): "Did you finish the report?"
+- **Leading** (answer embedded): "Don't you think we should ship sooner?"
+- **Open genuine**: "What's blocking you on this?"
+- **Clarifying** (references prior speaker): "When you said X, did you mean Y?"
+- **Building** (extends another's idea): "That's interesting — what if we also Z?"
+
+Good listening indicators:
+- Clarifying and building questions (shows active processing)
+- Paraphrasing: "So what I'm hearing is..."
+- Referencing a point someone made earlier in the meeting
+- Asking quieter participants for input
+
+Poor listening indicators:
+- Asking a question that was already answered
+- Restating own point without acknowledging the response
+- Responding to a question with an unrelated topic
+
+Report the ratio of open/clarifying/building vs. closed/leading questions.
+
+---
+
+#### Module: Facilitation & Decision-Making
+
+Only apply when the user is the meeting organizer or facilitator.
+
+Evaluate:
+- **Agenda adherence**: Did the meeting follow a structure or drift?
+- **Time management**: How long did each topic take vs. expected?
+- **Inclusion**: Did the facilitator actively draw in quiet participants?
+- **Decision clarity**: Were decisions explicitly stated? ("So we're going with option B — Sarah owns the follow-up by Friday.")
+- **Action items**: Were they assigned with owners and deadlines, or left vague?
+- **Parking lot discipline**: Were off-topic items acknowledged and deferred, or did they derail?
+
+---
+
+#### Module: Sentiment & Energy
+
+Track the emotional arc of the user's language across the meeting:
+- **Positive markers**: enthusiastic agreement, encouragement, humor, praise
+- **Negative markers**: frustration, dismissiveness, sarcasm, curt responses
+- **Neutral/flat**: low-energy responses, monosyllabic answers
+
+Flag energy drops — moments where the user's engagement visibly decreases (shorter turns, less substantive responses). These often correlate with discomfort, boredom, or avoidance.
+
+---
+
+### 4. Output the Report
+
+Structure the final output as a single cohesive report. Use this skeleton — omit any section where data was insufficient:
+
+```markdown
+# Meeting Insights Report
+
+**Period**: [earliest date] – [latest date]
+**Meetings analyzed**: [count]
+**Total transcript words**: [count]
+**Your speaking share (avg)**: [X%]
+
+---
+
+## Top 3 Findings
+
+[Rank by impact. Each finding gets 2-3 sentences + one concrete example with a direct quote and timestamp.]
+
+## Detailed Analysis
+
+### Speaking Dynamics
+[Stats table + narrative interpretation + flagged red flags]
+
+### Directness & Conflict Patterns
+[Flagged instances grouped by pattern type, with quotes and rewrites]
+
+### Verbal Habits
+[Filler word stats, contextual spikes, only if rate > 3/100 words]
+
+### Listening & Questions
+[Question type breakdown, listening indicators, specific examples]
+
+### Facilitation
+[Only if applicable — agenda, decisions, action items]
+
+### Energy & Sentiment
+[Arc summary, flagged drops]
+
+## Strengths
+[3 specific things the user does well, with evidence]
+
+## Growth Opportunities
+[3 ranked by impact, each with: what to change, why it matters, a concrete "try this next time" action]
+
+## Comparison to Previous Period
+[Only if prior analysis exists — delta on key metrics]
+```
+
+### 5. Follow-Up Options
+
+After delivering the report, offer:
+- Deep dive into any specific meeting or pattern
+- A 1-page "communication cheat sheet" with the user's top 3 habits to change
+- Tracking setup — save current metrics as a baseline for future comparison
+- Export as markdown or structured JSON for use in performance reviews
+
+---
+
+## Edge Cases
+
+- **No speaker labels**: Warn the user upfront. Run text-level analysis (filler words, question types on the full transcript) but skip per-speaker metrics. Suggest re-exporting with speaker diarization enabled.
+- **Very short meetings** (< 5 minutes or < 500 words): Analyze but caveat that patterns from short meetings may not be representative.
+- **Non-English transcripts**: The filler word and hedging dictionaries are English-centric. For other languages, note the limitation and focus on structural analysis (speaking ratios, turn-taking, question counts).
+- **Single meeting vs. corpus**: If only one transcript, skip trend/comparison language. Focus findings on that meeting alone.
+- **User not identified**: If you can't determine which speaker is the user after scanning, ask before proceeding. Don't guess.
+
+## Transcript Source Tips
+
+Include this section in output only if the user seems unsure about how to get transcripts:
+
+- **Zoom**: Settings → Recording → enable "Audio transcript". Download `.vtt` from cloud recordings.
+- **Google Meet**: Auto-transcription saves to Google Docs in the calendar event's Drive folder.
+- **Granola**: Exports to markdown. Best speaker label quality of consumer tools.
+- **Otter.ai**: Export as `.txt` or `.json` from the web dashboard.
+- **Fireflies.ai**: Export as `.docx` or `.json` — both work.
+- **Microsoft Teams**: Transcripts appear in the meeting chat. Download as `.vtt`.
+
+Recommend `YYYY-MM-DD - Meeting Name.ext` naming convention for easy chronological analysis.
+
+---
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Better Approach |
+|---|---|---|
+| Analyzing without speaker labels | Per-person metrics impossible — results are generic word clouds | Ask user to re-export with speaker identification enabled |
+| Running all modules on a 5-minute standup | Overkill — filler word and conflict analysis need 20+ min meetings | Auto-detect meeting length and skip irrelevant modules |
+| Presenting raw metrics without context | "You said 'um' 47 times" is demoralizing without benchmarks | Always compare to norms and show trajectory over time |
+| Analyzing a single meeting in isolation | One meeting is a snapshot, not a pattern — conclusions are unreliable | Require 3+ meetings minimum for trend-based coaching |
+| Treating speaking time equality as the goal | A facilitator SHOULD talk less; a presenter SHOULD talk more | Weight speaking ratios by meeting type and role |
+| Flagging every hedge word as negative | "I think" and "maybe" are appropriate in brainstorming | Distinguish between decision meetings (hedges are bad) and ideation (hedges are fine) |
+
+---
+
+## Related Skills
+
+| Skill | Relationship |
+|-------|-------------|
+| `project-management/senior-pm` | Broader PM scope — use for project planning, risk, stakeholders |
+| `project-management/scrum-master` | Agile ceremonies — pairs with meeting-analyzer for retro quality |
+| `project-management/confluence-expert` | Store meeting analysis outputs as Confluence pages |
+| `c-level-advisor/executive-mentor` | Executive communication coaching — complementary perspective |
\ No newline at end of file
diff --git a/project-management/team-communications/SKILL.md b/project-management/team-communications/SKILL.md
new file mode 100644
index 0000000..4789148
--- /dev/null
+++ b/project-management/team-communications/SKILL.md
@@ -0,0 +1,67 @@
+---
+name: team-communications
+description: Write internal company communications — 3P updates (Progress/Plans/Problems), company-wide newsletters, FAQ roundups, incident reports, leadership updates, status reports, project updates, and general internal comms. Use this skill any time the user asks to draft, edit, or format something meant for internal audiences. Trigger on keywords like "3P", "weekly update", "newsletter", "FAQ", "internal comms", "status report", "company update", "team update", "incident report", or any request to summarize work for leadership, teammates, or the broader company. Even casual requests like "write my update" or "summarize what my team did this week" should trigger this skill.
+---
+
+# Internal Comms
+
+> Originally contributed by [maximcoding](https://github.com/maximcoding) — enhanced and integrated by the claude-skills team.
+
+Write polished internal communications by loading the right reference file, gathering context, and outputting in the company's exact format.
+
+## Routing
+
+Identify the communication type from the user's request, then read the matching reference file before writing anything:
+
+| Type | Trigger phrases | Reference file |
+|---|---|---|
+| **3P Update** | "3P", "progress plans problems", "weekly team update", "what did we ship" | `references/3p-updates.md` |
+| **Newsletter** | "newsletter", "company update", "weekly/monthly roundup", "all-hands summary" | `references/company-newsletter.md` |
+| **FAQ** | "FAQ", "common questions", "what people are asking", "confusion around" | `references/faq-answers.md` |
+| **General** | anything internal that doesn't match above | `references/general-comms.md` |
+
+If the type is ambiguous, ask one clarifying question — don't guess.
+
+## Workflow
+
+1. **Read the reference file** for the matched type. Follow its formatting exactly.
+2. **Gather inputs.** Use available MCP tools (Slack, Gmail, Google Drive, Calendar) to pull real data. If no tools are connected, ask the user to provide bullet points or raw context.
+3. **Clarify scope.** Confirm: team name (for 3Ps), time period, audience, and any specific items the user wants included or excluded.
+4. **Draft.** Follow the format, tone, and length constraints from the reference file precisely. Do not invent a new format.
+5. **Present the draft** and ask if anything needs to be added, removed, or reworded.
+
+## Tone & Style (applies to all types)
+
+- Use "we" — you are part of the company.
+- Active voice, present tense for progress, future tense for plans.
+- Concise. Every sentence should carry information. Cut filler.
+- Include metrics and links wherever possible.
+- Professional but approachable — not corporate-speak.
+- Put the most important information first.
+
+## When tools are unavailable
+
+If the user hasn't connected Slack, Gmail, Drive, or Calendar, don't stall. Ask them to paste or describe what they want covered. You're formatting and sharpening — that's still valuable. Mention which tools would improve future drafts so they can connect them later.
+
+---
+
+## Anti-Patterns
+
+| Anti-Pattern | Why It Fails | Better Approach |
+|---|---|---|
+| Writing updates without reading the reference template first | Output won't match company format — user has to reformat | Always load the matching reference file before drafting |
+| Inventing metrics or accomplishments | Internal comms must be factual — fabrication destroys trust | Only include data the user provided or MCP tools retrieved |
+| Using passive voice for accomplishments | "The feature was shipped" hides who did the work | "Team X shipped the feature" — active voice credits the team |
+| Writing walls of text for status updates | Leadership scans, doesn't read — key info gets buried | Lead with the headline, follow with 3-5 bullet points |
+| Sending without confirming audience | A team update reads differently from a company-wide newsletter | Always confirm: who will read this? |
+
+---
+
+## Related Skills
+
+| Skill | Relationship |
+|-------|-------------|
+| `project-management/senior-pm` | Broader PM scope — status reports feed into PM reporting |
+| `project-management/meeting-analyzer` | Meeting insights can feed into 3P updates and status reports |
+| `project-management/confluence-expert` | Publish comms as Confluence pages for permanent record |
+| `marketing-skill/content-production` | External comms — use for public-facing content, not internal |
diff --git a/project-management/team-communications/references/3p-updates.md b/project-management/team-communications/references/3p-updates.md
new file mode 100644
index 0000000..5329bfb
--- /dev/null
+++ b/project-management/team-communications/references/3p-updates.md
@@ -0,0 +1,47 @@
+## Instructions
+You are being asked to write a 3P update. 3P updates stand for "Progress, Plans, Problems." The main audience is for executives, leadership, other teammates, etc. They're meant to be very succinct and to-the-point: think something you can read in 30-60sec or less. They're also for people with some, but not a lot of context on what the team does.
+
+3Ps can cover a team of any size, ranging all the way up to the entire company. The bigger the team, the less granular the tasks should be. For example, "mobile team" might have "shipped feature" or "fixed bugs," whereas the company might have really meaty 3Ps, like "hired 20 new people" or "closed 10 new deals." 
+
+They represent the work of the team across a time period, almost always one week. They include three sections:
+1) Progress: what the team has accomplished over the next time period. Focus mainly on things shipped, milestones achieved, tasks created, etc.
+2) Plans: what the team plans to do over the next time period. Focus on what things are top-of-mind, really high priority, etc. for the team.
+3) Problems: anything that is slowing the team down. This could be things like too few people, bugs or blockers that are preventing the team from moving forward, some deal that fell through, etc.
+
+Before writing them, make sure that you know the team name. If it's not specified, you can ask explicitly what the team name you're writing for is.
+
+
+## Tools Available
+Whenever possible, try to pull from available sources to get the information you need:
+- Slack: posts from team members with their updates - ideally look for posts in large channels with lots of reactions
+- Google Drive: docs written from critical team members with lots of views
+- Email: emails with lots of responses of lots of content that seems relevant
+- Calendar: non-recurring meetings that have a lot of importance, like product reviews, etc.
+
+
+Try to gather as much context as you can, focusing on the things that covered the time period you're writing for:
+- Progress: anything between a week ago and today
+- Plans: anything from today to the next week
+- Problems: anything between a week ago and today
+
+
+If you don't have access, you can ask the user for things they want to cover. They might also include these things to you directly, in which case you're mostly just formatting for this particular format.
+
+## Workflow
+
+1. **Clarify scope**: Confirm the team name and time period (usually past week for Progress/Problems, next
+week for Plans)
+2. **Gather information**: Use available tools or ask the user directly
+3. **Draft the update**: Follow the strict formatting guidelines
+4. **Review**: Ensure it's concise (30-60 seconds to read) and data-driven
+
+## Formatting
+
+The format is always the same, very strict formatting. Never use any formatting other than this. Pick an emoji that is fun and captures the vibe of the team and update.
+
+[pick an emoji] [Team Name] (Dates Covered, usually a week)
+Progress: [1-3 sentences of content]
+Plans: [1-3 sentences of content]
+Problems: [1-3 sentences of content]
+
+Each section should be no more than 1-3 sentences: clear, to the point. It should be data-driven, and generally include metrics where possible. The tone should be very matter-of-fact, not super prose-heavy.
\ No newline at end of file
diff --git a/project-management/team-communications/references/company-newsletter.md b/project-management/team-communications/references/company-newsletter.md
new file mode 100644
index 0000000..4997a07
--- /dev/null
+++ b/project-management/team-communications/references/company-newsletter.md
@@ -0,0 +1,65 @@
+## Instructions
+You are being asked to write a company-wide newsletter update. You are meant to summarize the past week/month of a company in the form of a newsletter that the entire company will read. It should be maybe ~20-25 bullet points long. It will be sent via Slack and email, so make it consumable for that.
+
+Ideally it includes the following attributes:
+- Lots of links: pulling documents from Google Drive that are very relevant, linking to prominent Slack messages in announce channels and from executives, perhgaps referencing emails that went company-wide, highlighting significant things that have happened in the company.
+- Short and to-the-point: each bullet should probably be no longer than ~1-2 sentences
+- Use the "we" tense, as you are part of the company. Many of the bullets should say "we did this" or "we did that"
+
+## Tools to use
+If you have access to the following tools, please try to use them. If not, you can also let the user know directly that their responses would be better if they gave them access.
+
+- Slack: look for messages in channels with lots of people, with lots of reactions or lots of responses within the thread
+- Email: look for things from executives that discuss company-wide announcements
+- Calendar: if there were meetings with large attendee lists, particularly things like All-Hands meetings, big company announcements, etc. If there were documents attached to those meetings, those are great links to include.
+- Documents: if there were new docs published in the last week or two that got a lot of attention, you can link them. These should be things like company-wide vision docs, plans for the upcoming quarter or half, things authored by critical executives, etc.
+- External press: if you see references to articles or press we've received over the past week, that could be really cool too.
+
+If you don't have access to any of these things, you can ask the user for things they want to cover. In this case, you'll mostly just be polishing up and fitting to this format more directly.
+
+## Sections
+The company is pretty big: 1000+ people. There are a variety of different teams and initiatives going on across the company. To make sure the update works well, try breaking it into sections of similar things. You might break into clusters like {product development, go to market, finance} or {recruiting, execution, vision}, or {external news, internal news} etc. Try to make sure the different areas of the company are highlighted well.
+
+## Prioritization
+Focus on:
+- Company-wide impact (not team-specific details)
+- Announcements from leadership
+- Major milestones and achievements
+- Information that affects most employees
+- External recognition or press
+
+Avoid:
+- Overly granular team updates (save those for 3Ps)
+- Information only relevant to small groups
+- Duplicate information already communicated
+
+## Example Formats
+
+:megaphone: Company Announcements
+- Announcement 1
+- Announcement 2
+- Announcement 3
+
+:dart: Progress on Priorities
+- Area 1
+    - Sub-area 1
+    - Sub-area 2
+    - Sub-area 3
+- Area 2
+    - Sub-area 1
+    - Sub-area 2
+    - Sub-area 3
+- Area 3
+    - Sub-area 1
+    - Sub-area 2
+    - Sub-area 3
+
+:pillar: Leadership Updates
+- Post 1
+- Post 2
+- Post 3
+
+:thread: Social Updates
+- Update 1
+- Update 2
+- Update 3
diff --git a/project-management/team-communications/references/faq-answers.md b/project-management/team-communications/references/faq-answers.md
new file mode 100644
index 0000000..395262a
--- /dev/null
+++ b/project-management/team-communications/references/faq-answers.md
@@ -0,0 +1,30 @@
+## Instructions
+You are an assistant for answering questions that are being asked across the company. Every week, there are lots of questions that get asked across the company, and your goal is to try to summarize what those questions are. We want our company to be well-informed and on the same page, so your job is to produce a set of frequently asked questions that our employees are asking and attempt to answer them. Your singular job is to do two things:
+
+- Find questions that are big sources of confusion for lots of employees at the company, generally about things that affect a large portion of the employee base
+- Attempt to give a nice summarized answer to that question in order to minimize confusion.
+
+Some examples of areas that may be interesting to folks: recent corporate events (fundraising, new executives, etc.), upcoming launches, hiring progress, changes to vision or focus, etc.
+
+
+## Tools Available
+You should use the company's available tools, where communication and work happens. For most companies, it looks something like this:
+- Slack: questions being asked across the company - it could be questions in response to posts with lots of responses, questions being asked with lots of reactions or thumbs up to show support, or anything else to show that a large number of employees want to ask the same things
+- Email: emails with FAQs written directly in them can be a good source as well
+- Documents: docs in places like Google Drive, linked on calendar events, etc. can also be a good source of FAQs, either directly added or inferred based on the contents of the doc
+
+## Formatting
+The formatting should be pretty basic:
+
+- *Question*: [insert question - 1 sentence]
+- *Answer*: [insert answer - 1-2 sentence]
+
+## Guidance
+Make sure you're being holistic in your questions. Don't focus too much on just the user in question or the team they are a part of, but try to capture the entire company. Try to be as holistic as you can in reading all the tools available, producing responses that are relevant to all at the company.
+
+## Answer Guidelines
+- Base answers on official company communications when possible
+- If information is uncertain, indicate that clearly
+- Link to authoritative sources (docs, announcements, emails)
+- Keep tone professional but approachable
+- Flag if a question requires executive input or official response
\ No newline at end of file
diff --git a/project-management/team-communications/references/general-comms.md b/project-management/team-communications/references/general-comms.md
new file mode 100644
index 0000000..0ea9770
--- /dev/null
+++ b/project-management/team-communications/references/general-comms.md
@@ -0,0 +1,16 @@
+  ## Instructions
+  You are being asked to write internal company communication that doesn't fit into the standard formats (3P
+  updates, newsletters, or FAQs).
+
+  Before proceeding:
+  1. Ask the user about their target audience
+  2. Understand the communication's purpose
+  3. Clarify the desired tone (formal, casual, urgent, informational)
+  4. Confirm any specific formatting requirements
+
+  Use these general principles:
+  - Be clear and concise
+  - Use active voice
+  - Put the most important information first
+  - Include relevant links and references
+  - Match the company's communication style
\ No newline at end of file