agentleFS
Sign inStart free
adhyayanrathi01adhyayanrathi01/product-manager-os/skills/communication/analyze-team-communications/SKILL.md

analyze-team-communications

Skill2 starsChanged 2 months agoMITView on GitHub

Analyze team communication from chat, email, threads, announcements, or collaboration exports to identify decisions, commitments, blockers, product signals, unresolved questions, and stakeholder concerns. Use when a PM asks about recent communication or communication related to a module, feature, team, project, topic, or date range.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify read authorization and a bounded source read.

    line 12
  2. Very specific:

    Use references/communication-style.md when creating a summary or draft.

    line 39
  3. Very specific:

    Every field above must appear as a labeled section in the produced output.

    line 62

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Analyze Team Communications

<!-- CORE:BEGIN -->

Contract

  • Require the decision, source ID, allowed scope, participant or channel boundary, absolute period, topic, and privacy or retention rules.
  • Verify read authorization and a bounded source read. If coverage is partial, analyze only retrieved content and identify missing channels, threads, or dates.
  • Block requests outside the permitted scope. Emit the shared evidence handoff for reusable findings.
<!-- CORE:END -->

Process

  1. Clarify the decision being supported and the requested scope:
    • date range;
    • channel, mailbox, thread, team, or participant group;
    • module, feature, project, topic, or decision. Resolve relative periods to absolute dates and a timezone.
  2. Discover the available communication access through an MCP, CLI, API, export, or local file.
  3. Confirm that the requested scope respects the user’s access and private-channel boundaries.
  4. Record source coverage and exclude bots, automated alerts, repeated notifications, signatures, quoted-email duplication, and irrelevant conversation where possible.
  5. Reconstruct threads and chronology before summarizing isolated messages.
  6. Extract:
    • confirmed facts and evidence;
    • decisions and their owners;
    • commitments and deadlines;
    • blockers and dependencies;
    • stakeholder concerns and objections;
    • unresolved questions;
    • changes in direction;
    • repeated product signals.
  7. Separate explicit statements from inferred interpretation. Do not infer emotion, intent, or consensus from weak signals.
  8. Label a decision as confirmed only when the source records explicit approval from an authorized owner. Otherwise label it proposed or unclear.
  9. Identify contradictions, stale decisions, unclosed loops, and missing participants.
  10. Use references/communication-style.md when creating a summary or draft. Prefer company-specific guidance from context.md when present.
  11. Present findings for PM review. Do not send, reply, react, or email without explicit approval.
  12. Save meaningful findings using skills/evidence/evidence-handoff.md, then update the relevant project and root work files as needed.
<!-- CORE:BEGIN -->

Output

Provide:

  • Scope and source coverage
  • Timeline or thread map when useful
  • Confirmed decisions
  • Commitments, owners, and dates
  • Blockers and unresolved questions
  • Stakeholder concerns and product signals
  • Contradictions or stale assumptions
  • Implications and suggested follow-ups for the PM
  • Optional draft communication, clearly marked as unsent

Preserve attribution only when it materially supports follow-up or accountability.

Required fields: Scope and source coverage|Confirmed decisions|Commitments|Blockers|Stakeholder concerns|Contradictions|Implications for the PM

Every field above must appear as a labeled section in the produced output. Verify with evals/check-output.sh analyze-team-communications <artifact>.

<!-- CORE:END -->

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free