Created
June 9, 2026 12:20
-
-
Save jorgeucano/608abf28075c58922536964a73122a9c to your computer and use it in GitHub Desktop.
Meeting-Intelligence.skill
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| --- | |
| name: meeting-intelligence | |
| description: > | |
| Pipeline that converts a meeting transcript into a complete Gherkin (.feature) | |
| file, ready for Claude Code. Generates Features for Outcome, Behavior, Acceptance, | |
| OKR Alignment, Tasks, and minimum questions to ask during the meeting. ALWAYS USE | |
| when the user mentions: "process this meeting", "meeting transcript", "generate spec", | |
| "meeting → spec", "process transcript", "generate tasks from this meeting", or pastes/ | |
| links a transcript. Infers everything from the transcript — no prior team knowledge assumed. | |
| compatibility: "Google Drive MCP to read transcripts by link." | |
| --- | |
| # Meeting Intelligence Pipeline | |
| Converts a meeting transcript into a single `.feature` Gherkin file, directly | |
| consumable by Claude Code. Everything lives in that one file. | |
| --- | |
| ## Step 1: Get inputs | |
| ### Transcript | |
| - If it's a Google Drive link → extract file ID and read with Google Drive MCP | |
| - If it's pasted text → use as-is | |
| - If nothing → ask for transcript or link | |
| ### OKRs (optional but recommended) | |
| - If the user provides an OKR file or link → read it and use in Step 6 | |
| - If no OKRs → mark that Feature as `[PENDING — add OKR file]` | |
| --- | |
| ## Step 2: Context resolution | |
| Before generating the `.feature`, resolve necessary context in two levels. | |
| Goal: ask the minimum number of questions — only what genuinely can't be inferred. | |
| ### Level 1 — Generic context (applies to every meeting) | |
| Try to resolve each item in this order: | |
| 1. **Is it in the transcript?** → use what it says | |
| 2. **Is it in conversation memory?** → use that | |
| 3. **Can it be inferred with high confidence?** → infer and note the inference | |
| 4. **No way to know?** → mark as pending question | |
| Generic context items to resolve: | |
| - **Meeting type**: product / strategy / ops / technical / client / retro | |
| - **Main objective**: what this meeting was trying to accomplish | |
| - **Active OKRs**: if a file was passed or there's a memory reference → use it; otherwise → `@PENDING` | |
| ### Level 2 — Transcript-specific gaps (max 3) | |
| Read the full transcript and identify what critical information is missing. | |
| Gap priority: | |
| 1. **Acceptance criteria** — how do you know when something is done? | |
| 2. **Owner + deadline** — who does what and by when? | |
| 3. **Explicit non-goals** — what was ruled out in this meeting? | |
| ### Final decision: ask or continue? | |
| After resolving Level 1 and Level 2, make ONE single grouped question block — | |
| only for what genuinely couldn't be resolved. Maximum 3 questions total across | |
| both levels. | |
| If nothing is unresolved → go directly to Step 3 without asking anything. | |
| Question block format (only if needed): | |
| ``` | |
| Before generating the .feature, I need to confirm [N] thing(s): | |
| 1. [generic context question if missing] — or — | |
| [transcript-specific question if missing] | |
| 2. ... | |
| 3. ... | |
| Answer what you know and I'll mark the rest as @PENDING. | |
| Or say "continue" to generate with what's available. | |
| ``` | |
| Wait for a response before continuing to Step 3. | |
| If the user says "continue" → generate with `@PENDING` where missing. | |
| --- | |
| ## Step 3: Generate the `.feature` file | |
| Generate ONE single file with all Features in order. File name: | |
| `[date]-[title-kebab-case].feature` | |
| Example: `2026-06-01-online-signup-flow.feature` | |
| File structure: | |
| ```gherkin | |
| # ============================================================== | |
| # [MEETING TITLE] | |
| # Date: [date] | |
| # Participants: [names detected in transcript] | |
| # Generated by: Meeting Intelligence Pipeline | |
| # ============================================================== | |
| # ============================================================== | |
| # FEATURE 1: OUTCOME | |
| # ============================================================== | |
| Feature: [title] — expected outcome | |
| As a [main actor inferred from transcript] | |
| I want [main objective of the meeting] | |
| So that [expected business result] | |
| Background: | |
| Given [current state / problem that motivated the meeting] | |
| And [additional relevant context if exists] | |
| Scenario: [name of the main outcome] | |
| Given [precondition] | |
| When [user/system action] | |
| Then [observable and verifiable result] | |
| And [additional result if applicable] | |
| Scenario: [alternative outcome if exists] | |
| ... | |
| # ============================================================== | |
| # FEATURE 2: BEHAVIOR — main flows | |
| # ============================================================== | |
| Feature: [title] — system behavior | |
| Scenario: [happy path name] | |
| Given [precondition] | |
| When [step by step action] | |
| And [next action] | |
| Then [observable result] | |
| And [additional result] | |
| Scenario: [alternative flow / abandonment] | |
| Given [precondition] | |
| When [action] | |
| Then [result] | |
| Scenario: [edge case 1] | |
| Given [edge condition] | |
| When [what happens] | |
| Then [expected system behavior] | |
| # [PENDING] if not defined in the meeting | |
| Scenario: [edge case 2] | |
| ... | |
| # ============================================================== | |
| # FEATURE 3: OPERATOR FLOWS | |
| # (manual team actions — omit if not applicable) | |
| # ============================================================== | |
| Feature: [title] — operator flows | |
| Scenario: [operator flow name] | |
| Given [operator precondition] | |
| When [team action] | |
| Then [result for operator or client] | |
| # ============================================================== | |
| # FEATURE 4: ACCEPTANCE | |
| # ============================================================== | |
| Feature: [title] — acceptance criteria | |
| Scenario: Successful end-to-end test | |
| Given [preconditions to be able to test] | |
| When [full flow is executed] | |
| Then [all Behavior Scenarios pass] | |
| And [binary criterion 1] | |
| And [binary criterion 2] | |
| # Add one And per verifiable criterion | |
| Scenario: Rollback trigger | |
| Given [system is in production] | |
| When [observable failure condition] | |
| Then [rollback or escalation action] | |
| Scenario: Success metrics | |
| Given [flow is in production] | |
| When [measured at [date or timeframe]] | |
| Then [metric] is [number or condition] | |
| # [PENDING] if not defined in the meeting | |
| # ============================================================== | |
| # FEATURE 5: TASKS | |
| # (one Feature per owner detected in the transcript) | |
| # ============================================================== | |
| Feature: Tasks — [Owner name] | |
| Scenario: [task title] @HIGH/@MEDIUM/@LOW | |
| Given [context / why this task exists] | |
| When [owner executes action] | |
| Then [concrete and verifiable closing criterion] | |
| And [dependency if exists] | |
| # Deadline: [date if mentioned, otherwise PENDING] | |
| # Repeat one Scenario per task per owner | |
| Feature: Tasks — [Owner 2 name] | |
| ... | |
| Feature: Tasks — UNASSIGNED | |
| # Only if there are tasks without a clear owner in the transcript | |
| Scenario: [task without owner] @[priority] | |
| Given [context] | |
| When [someone] executes [action] | |
| Then [closing criterion] | |
| # ============================================================== | |
| # FEATURE 6: OKR ALIGNMENT | |
| # ============================================================== | |
| Feature: [title] — OKR alignment | |
| # If no OKRs were provided: | |
| # @PENDING | |
| # Scenario: Alignment pending | |
| # Given the team's OKRs | |
| # When crossed with this meeting's decisions | |
| # Then [PENDING — provide OKR file to complete] | |
| # If OKRs were provided, generate one Scenario per relevant OKR: | |
| Scenario: Contributes to OKR "[OKR name]" | |
| Given the decision "[meeting decision]" | |
| When implemented correctly | |
| Then it advances OKR "[name]" because [concrete reason] | |
| Scenario: In tension with OKR "[OKR name]" | |
| Given the decision "[meeting decision]" | |
| When implemented | |
| Then it creates tension with "[OKR]" because [reason] | |
| And requires [action to resolve the tension] | |
| Scenario: OKR without coverage "[OKR name]" | |
| Given OKR "[name]" is active | |
| When this meeting is reviewed | |
| Then no decision advances it | |
| And @GAP — evaluate if it should be on the agenda | |
| # ============================================================== | |
| # FEATURE 7: OPEN QUESTIONS | |
| # (unresolved gaps from the meeting) | |
| # ============================================================== | |
| Feature: [title] — open questions | |
| Scenario: [gap name] @BLOCKER/@IMPORTANT/@NICE-TO-HAVE | |
| Given [gap context] | |
| When [condition that triggers it] | |
| Then [PENDING — define before [milestone or date]] | |
| # Responsible for resolving: [person if inferable, otherwise UNASSIGNED] | |
| # ============================================================== | |
| # FEATURE 8: SECOND BRAIN | |
| # (memory entry for the team) | |
| # ============================================================== | |
| Feature: [title] — second brain entry | |
| # Date: [date] | |
| # Participants: [list] | |
| Scenario: Decisions recorded | |
| Given the meeting on [date] | |
| Then the following decisions are recorded: | |
| | decision | made by | | |
| | [decision 1] | [person] | | |
| | [decision 2] | [person] | | |
| Scenario: Commitments recorded | |
| Given the meeting commitments | |
| Then they are recorded with owner and deadline: | |
| | commitment | owner | deadline | | |
| | [commitment 1] | [person] | [date/PENDING] | | |
| Scenario: Main tension recorded | |
| Given the meeting on [date] | |
| Then the main tension was: | |
| """ | |
| [main tension or trade-off in 1-2 lines] | |
| """ | |
| ``` | |
| --- | |
| ## Step 4: Final output | |
| Present: | |
| 1. The complete `.feature` file ready to copy or save | |
| 2. A one-line summary: how many Scenarios generated, how many PENDING, how many BLOCKER | |
| Summary format: | |
| ``` | |
| ✓ [N] Scenarios generated · [N] PENDING · [N] BLOCKER | |
| File: [file-name].feature | |
| ``` | |
| Then ask: | |
| - Save the `.feature` to Drive? | |
| - Pass it directly to Claude Code? | |
| - Adjust any Feature? | |
| --- | |
| ## General rules | |
| - **All output is Gherkin** — no prose, no bullets, no markdown outside the `.feature` | |
| - **Infer from transcript** — names, roles, decisions, owners: everything comes from the text | |
| - **Never invent** — if something isn't in the transcript → `[PENDING]` or `@GAP` | |
| - **Useful tags**: `@BLOCKER` `@PENDING` `@GAP` `@HIGH` `@MEDIUM` `@LOW` | |
| - **Single file** — all output in one `.feature`, not separate files | |
| - **Valid Gherkin** — Claude Code must be able to consume it without modifications |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment