Zurück zu Fähigkeiten

foundation-meeting-brief

product-on-purpose
Aktualisiert 2 days ago
5 Ansichten
238
33
238
Auf GitHub ansehen
Designword

Über

Diese Fähigkeit erstellt ein privates, strategisches Vorbereitungsdokument für hochbedeutsame Besprechungen, bei denen Positionierung entscheidend ist. Sie unterstützt Nutzer dabei, privat Schlüsselelemente wie Positionen der Beteiligten, gewünschte Ergebnisse, Kernbotschaften und vorbereitete Antworten zu skizzieren. Entwickler sollten sie nutzen, um einen persönlichen taktischen Plan zu erstellen, der sich von einer gemeinsamen Tagesordnung unterscheidet, für Besprechungen, die eine fortgeschrittene Vorbereitung erfordern.

Schnellinstallation

Claude Code

Empfohlen
Primär
npx skills add product-on-purpose/pm-skills -a claude-code
Plugin-BefehlAlternativ
/plugin add https://github.com/product-on-purpose/pm-skills
Git CloneAlternativ
git clone https://github.com/product-on-purpose/pm-skills.git ~/.claude/skills/foundation-meeting-brief

Kopieren Sie diesen Befehl und fügen Sie ihn in Claude Code ein, um diese Fähigkeit zu installieren

Dokumentation

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Meeting Brief

A meeting brief is the user's private strategic preparation document for a meeting where context, stakes, or positioning matter. It captures what the user needs to know, what they want to accomplish, who they are engaging with, and how to navigate the conversation. This is strategic prep, not meeting structure, which keeps it distinct from a meeting agenda.

This skill belongs to the Meeting Skills Family. It conforms to the Meeting Skills Family Contract.

When to Use

  • Walking into a stakeholder review, exec briefing, or negotiation-adjacent conversation
  • First meeting with a new stakeholder where relationship calibration matters
  • A meeting where the user needs something from others (capacity commitment, decision, approval)
  • Any conversation where specific positioning, messaging, or risk navigation is required

When NOT to Use

  • Preparing the agenda attendees will see. Use /meeting-agenda instead.
  • Post-meeting summarization. Use /meeting-recap.
  • The meeting is low-stakes and well-trodden (recurring team sync, standup). A brief is overhead for these; the agenda alone is sufficient.

Zero-friction execution

Per the family contract, this skill never blocks on interrogation. Default flow:

  1. Read all provided inputs (topic, attendees, prior recaps, stakeholder summaries, user's primary ask)
  2. Auto-discover related artifacts via project or topics frontmatter match
  3. Run inference on missing values (stakeholder positions from prior recaps, primary ask from topic, top-3 goals from meeting type)
  4. Present a brief inference summary and accept one-word go or corrections
  5. Produce the brief

If invoked with --go, skip the inference summary. If the user provides all values upfront, no checkpoint appears.

The skill runs on inferred stakeholder positions with low-confidence flags when no stakeholder summaries are provided; it does not block on missing inputs.

Anti-meeting check

This skill opens with the shared anti-meeting check. see /meeting-agenda for the full check.

v1.1.0: the check requires a positive synchronous-value statement (tradeoff to discuss, conflict to resolve, co-creation, relationship-building, or blocker escalation). Brief-prep scenarios most often pass because they typically involve navigating stakeholder positions or negotiation dynamics. which qualify as "conflict to resolve" or "relationship-building." But the check still runs, and if no synchronous value is named, the skill recommends the async alternative before producing a brief.

Load-bearing inference gates (v1.1.0): when stakeholder positions, primary ask, or decision-maker attribution are inferred below-high confidence, flag in the go-mode summary with . The brief's tactical guidance depends on these; silent acceptance of weak inferences creates risky advice. See family contract "Zero-friction execution" section.

Instructions

When asked to create a meeting brief, follow these steps:

  1. Run anti-meeting check Apply the trigger patterns. If matched, propose async alternative and await override.

  2. Parse and load inputs Read the topic. Load any @file references. Auto-discover related artifacts: prior recaps on same topic (same project/topics frontmatter), stakeholder summaries from /discover-stakeholder-summary outputs, related project docs.

  3. Infer missing values Apply these rules:

    ValueInferred fromConfidence
    Stakeholder positionsPrior recap language, stakeholder summary contentHigh if recap cites direct quote; medium if position in 2+ sources; low otherwise
    Stakes per attendeeRole plus topic-ownership cuesAlways flag inferences
    Top 3 goalsUser's primary ask plus meeting typeOffer as ranked strawman in go-mode
    Anticipated questionsStakeholder position analysis plus typical-by-role objectionsFlag as inferred
    Risks / tensionsConflict patterns in prior recapsHigh if prior recap flagged contradiction
  4. Present go-mode inference summary Show the inferred stakeholder positions, primary ask, top-3 goals. Accept go or corrections.

  5. Build the background section Relevant history, prior decisions, recent developments. Cross-reference prior recaps by filename when available.

  6. Do per-stakeholder analysis For each key attendee: position on topic, stakes (what they win or lose), likely concerns, relationship state (strong / neutral / strained), tactical notes (how to engage).

  7. Rank desired outcomes Must achieve / should achieve / nice to achieve. Force the tradeoff explicitly.

  8. Draft key messages In priority order, phrased for delivery. Not bullet points to read; phrased as you would say them.

  9. Anticipate questions and responses Table format: Q | prepared response. Aim for the three questions the user is most likely to get.

  10. Identify risks and tensions With explicit mitigations. Flag anything that could derail the meeting.

  11. Specify asks What the user needs from specific people by name. Not generic "get alignment" but "ask alex to commit eng capacity for Q2 by Thursday."

  12. Define success signals How the user knows in the moment that the meeting went well. Behavioral cues, not just outcome markers.

  13. Render TEMPLATE.md and validate

    • visibility: private default
    • Stakeholder list has minimum fields (name, position) when present
    • Primary ask is non-empty (use "alignment" or "information gathering" if no specific ask)

Quality checklist

  • Anti-meeting check was applied and recorded
  • visibility: private default applied
  • Background section cross-references prior recaps when available
  • Every key stakeholder has a position, stakes, concerns, relationship state entry (with confidence markers on inferred fields)
  • Desired outcomes are ranked (must / should / nice), not flat
  • Key messages are phrased for delivery, not for reading
  • Anticipated Q&A table has 3 or more entries
  • Asks are specific (named person, specific ask, by-when)
  • Shareable summary suitable for trusted-advisor review only (flagged as such)
  • Sources and References section includes Generation context with inferences flagged

See also

GitHub Repository

product-on-purpose/pm-skills
Pfad: skills/foundation-meeting-brief
0
agent-skillsai-skillsclaude-codeclaude-desktopdesign-sprintfoundation-sprint

Verwandte Skills

executing-plans

Design

Verwenden Sie die Fähigkeit "executing-plans", wenn Sie einen vollständigen Implementierungsplan zur Ausführung in kontrollierten Batches mit Überprüfungspunkten vorliegen haben. Sie lädt den Plan und überprüft ihn kritisch, führt dann Aufgaben in kleinen Batches (standardmäßig 3 Aufgaben) aus und meldet den Fortschritt zwischen jedem Batch zur Überprüfung durch den Architekten. Dies gewährleistet eine systematische Implementierung mit integrierten Qualitätskontrollpunkten.

Skill ansehen

requesting-code-review

Design

Diese Fähigkeit sendet einen Unteragenten für Code-Review, um Codeänderungen anhand der Anforderungen zu analysieren, bevor fortgefahren wird. Sie sollte nach dem Abschließen von Aufgaben, der Implementierung größerer Funktionen oder vor dem Zusammenführen in den Hauptzweig verwendet werden. Die Überprüfung hilft dabei, Probleme frühzeitig zu erkennen, indem die aktuelle Implementierung mit dem ursprünglichen Plan verglichen wird.

Skill ansehen

connect-mcp-server

Design

Diese Fähigkeit bietet Entwicklern eine umfassende Anleitung, um MCP-Server über HTTP-, stdio- oder SSE-Transports mit Claude Code zu verbinden. Sie behandelt Installation, Konfiguration, Authentifizierung und Sicherheit für die Integration externer Dienste wie GitHub, Notion und benutzerdefinierter APIs. Nutzen Sie sie beim Einrichten von MCP-Integrationen, bei der Konfiguration externer Tools oder bei der Arbeit mit Claude's Model Context Protocol.

Skill ansehen

web-cli-teleport

Design

Diese Fähigkeit unterstützt Entwickler bei der Wahl zwischen Claude Code Web- und CLI-Schnittstellen basierend auf Aufgabenanalysen und ermöglicht nahtloses Session-Teleporting zwischen diesen Umgebungen. Sie optimiert den Workflow, indem sie den Sitzungsstatus und Kontext beim Wechsel zwischen Web, CLI oder Mobilgeräten verwaltet. Nutzen Sie sie für komplexe Projekte, die in verschiedenen Phasen unterschiedliche Werkzeuge erfordern.

Skill ansehen