$npx -y skills add umairalipathan1980/Claude-Skill-for-Multimodal-Report-Generation --skill documenting-meetingsConverts scattered meeting data (recordings, handwritten notes, diagrams, digital notes, supplementary documents) into a structured MS Word deliverable with summary, decisions, action items, open questions, and follow-up message. Use when the user mentions meeting notes, meeting
| 1 | # Meeting Documentation |
| 2 | |
| 3 | Converts scattered meeting materials—audio/video recordings, handwritten notes, diagrams, digital notes, and supplementary documents—into a single, well-formatted MS Word document containing a concise summary, decisions, action items with owners and due dates, open questions, and a ready-to-send follow-up message. |
| 4 | |
| 5 | It is designed to run in **Claude Desktop** with: |
| 6 | - An MCP **filesystem** server (for listing/reading files and folders) |
| 7 | - An MCP **gaik-transcriber** server (for transcribing audio/video recordings) |
| 8 | |
| 9 | ## When to Use |
| 10 | |
| 11 | Use this skill when: |
| 12 | - User mentions "meeting notes", "meeting summary", "meeting minutes", "meeting documentation" |
| 13 | - User needs to consolidate multiple meeting materials into one document |
| 14 | - User asks to extract action items, decisions, or follow-ups from a meeting |
| 15 | - User has meeting recordings, handwritten notes, or other meeting artifacts to process |
| 16 | - User wants a structured deliverable from meeting data |
| 17 | |
| 18 | ## Inputs |
| 19 | |
| 20 | **Required (at least one):** |
| 21 | - Meeting recordings (audio/video files) – transcribed using `gaik-transcriber:transcribe_audio` |
| 22 | - Handwritten notes (scanned images) – interpreted visually |
| 23 | - Digital notes (text files, markdown, etc.) |
| 24 | - Diagrams/sketches/figures (images) |
| 25 | - Comments or notes from multiple people |
| 26 | |
| 27 | **Optional:** |
| 28 | - Supplementary documents (PowerPoint slides, PDF guidelines, policy documents, Excel files) |
| 29 | - Output template (blank .docx with predefined headers, sections, logos, etc.) |
| 30 | - Sample output document (.docx or .pdf) defining style, format, tone, and length to follow |
| 31 | |
| 32 | **Required parameter:** |
| 33 | - `input_folder`: Path to the main input folder containing the required subfolder structure. If not provided, ask the user to specify it. |
| 34 | |
| 35 | **Required folder structure:** |
| 36 | ``` |
| 37 | <input_folder>/ |
| 38 | ├── input_documents/ # Required: recordings, photos, notes, presentations, PDFs, etc. |
| 39 | ├── templates/ # Optional: blank template with predefined headers, sections, logos |
| 40 | └── sample_documents/ # Optional: sample document defining style, format, tone, length |
| 41 | ``` |
| 42 | |
| 43 | ## Tooling Rules (Windows vs Linux Path Safety) |
| 44 | |
| 45 | ### Why this matters |
| 46 | On Windows, Claude Desktop + toolchains sometimes behave like they are in a POSIX shell, producing paths like `/mnt/c/...`. |
| 47 | Meanwhile, your MCP servers may run **native Windows Python**, expecting `C:\...`. |
| 48 | This mismatch can cause “file not found” or failing shell commands. |
| 49 | |
| 50 | ### Strict rules |
| 51 | 1) **Prefer MCP filesystem tools for file/folder operations** |
| 52 | Use the filesystem server for listing and reading files instead of shell commands. |
| 53 | |
| 54 | 2) **Avoid bash commands on Windows** |
| 55 | If you must run a command on Windows, prefer **PowerShell**. |
| 56 | |
| 57 | 3) **When calling gaik-transcriber, prefer Windows drive-letter paths on Windows** |
| 58 | Pass file paths like `C:\Users\...\recording.m4a`. |
| 59 | If you only have a POSIX/WSL path (e.g., `/mnt/c/...`), convert it to a Windows path before calling the transcriber, or rely on the transcriber server’s internal normalization (recommended). |
| 60 | |
| 61 | 4) **Never assume the environment is Linux** |
| 62 | Treat the runtime as OS-ambiguous and enforce the above rules to stay stable. |
| 63 | |
| 64 | 5) **Never do the following:** |
| 65 | NEVER run pip install, python -c, pdfplumber, or any ad-hoc parsing code for .pdf/.pptx/.xlsx. |
| 66 | |
| 67 | NEVER use /mnt/user-data/uploads/... paths; only use paths returned by the MCP filesystem listing or the user-provided Windows folder. |
| 68 | |
| 69 | If you are about to do any of the above, STOP and switch to the built-in PDF/PPTX/XLSX skills. |
| 70 | |
| 71 | ## Workflow |
| 72 | |
| 73 | ### Step 0 — Collect context |
| 74 | Ask (only if not provided): |
| 75 | - Meeting title or purpose (optional) |
| 76 | - Desired output format (Markdown is default) |
| 77 | - Any special focus: “only action items”, “only decisions”, “customer-facing summary”, etc. |
| 78 | |
| 79 | ## Step 1 — Validate input folder structure and capabilities |
| 80 | |
| 81 | If the user has not specified an input folder path, ask for it and confirm it contains `input_documents/` (required). |
| 82 | |
| 83 | ### 1) Validate folder structure (MCP filesystem only) |
| 84 | Use the filesystem MCP tool to list: |
| 85 | - `<input_folder>` |
| 86 | - `<input_folder>\input_documents` (required) |
| 87 | - `<input_folder>\templates` (optional) |
| 88 | - `<input_folder>\sample_documents` (optional) |
| 89 | |
| 90 | If `input_documents/` is missing or empty, stop and ask the user to add the meeting artifacts there. |
| 91 | |
| 92 | ### 2) Capability check (prevents Windows/Linux path loops for binaries) |
| 93 | Purpose: decide upfront whether this environment can process **binary** files from a Windows folder without requiring the user to upload them. |
| 94 | |
| 95 | Inventory binary files found in: |
| 96 | - `<input_folder>\input_documents` |
| 97 | - `<input_fo |