Process meeting transcripts to extract reports, tasks, and memory. Handles "Process this meeting", action item extraction, meeting summaries. Calendar integration for scheduling context.
Processes meeting transcripts to extract structured reports, create tasks, and update memory with parallel execution.
npx claudepluginhub ajayjohn/tars-work-assistantThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Process meeting transcripts to extract structured reports, persist to journal, create tasks, and extract memory using a unified orchestrated pipeline.
This skill combines transcript analysis, structured report generation, task extraction, memory persistence, and journal creation into a single coordinated workflow. Progress is tracked with real-time TodoWrite updates.
Parallelization: After the journal entry is saved (Step 3), task extraction (Step 4) and memory extraction (Step 5) run as parallel sub-agents using the Task tool. This yields a 30-40% wall-clock improvement on typical meetings. Both sub-agents read from the saved journal file, ensuring isolated context and no cross-contamination.
Read reference/replacements.md BEFORE processing any content. Apply canonical names to ALL text: frontmatter, prose, action items, task assignments.
The transcript may be:
SPEAKER, LINE_TEXT, LINE_ID fieldsRead reference/integrations.md Calendar section for provider details and status. If calendar integration is configured, query for this meeting if date/time can be inferred. Resolve the meeting date to YYYY-MM-DD format before querying. Execute the list_events operation with the meeting date and offset=1.
Why: Calendar provides full attendee list (including silent participants), official meeting title, organizer, and meeting notes/agenda. The attendee list is also critical for name resolution in Step 1.4.
Extract:
participants frontmatter and name resolution)If meeting not found or calendar integration is unreachable, proceed with transcript-only processing and note the gap.
Apply the name resolution protocol (core skill, Memory protocol section):
reference/replacements.md for an exact matchBuild a name resolution table mapping each raw speaker label to its canonical form. Apply this table to all downstream steps (report, tasks, memory).
Produce ALL of the following sections from the transcript analysis:
Classify into:
Format: "Owner" -- Task description (deadline if stated)
Create file in journal/YYYY-MM/:
Filename: YYYY-MM-DD-meeting-slug.md
Template:
---
date: YYYY-MM-DD
title: Meeting Title
calendar_title: Original Calendar Title # Only if different from title
type: meeting
participants: [Name1, Name2, Name3]
organizer: Name # From calendar if available
topics: [topic1, topic2]
initiatives: [Initiative1, Initiative2]
source: calendar | transcript # Indicate primary data source
---
# Meeting Title
**Date:** YYYY-MM-DD | **Participants:** [[Name1]], [[Name2]], [[Name3]]
**Initiatives:** [[Initiative1]], [[Initiative2]]
## Topics
[From report]
## Updates
[From report]
## Concerns
[From report]
## Decisions
[From report]
## Action items
[From report]
Title priority hierarchy:
Slug rules:
mcp-planningWhen calendar title is used, if it differs significantly from transcript context, keep calendar_title in frontmatter for reference.
After saving the journal entry in Step 3, spawn two parallel sub-agents using the Task tool. Both sub-agents run concurrently, reading from the saved journal file path rather than from the raw transcript in context.
Launch both sub-agents in a single message using multiple Task tool calls. Do NOT wait for one to complete before starting the other.
Spawn a Task sub-agent with the following prompt structure:
You are extracting tasks from a meeting journal entry.
Read the journal file at: {journal_file_path}
Read the task integration config at: reference/integrations.md (Tasks section)
For each action item in the journal:
1. Apply accountability test (NEVER create tasks for "Team" or "We" without a specific lead)
2. Check for duplicates: execute the task integration `list` operation for all configured lists
3. Resolve metadata:
- Map relative dates to YYYY-MM-DD using date resolution
- Default to `backlog` if no due date
- Source: {journal_file_path}
4. Execute the `add` operation via the task integration with metadata in notes field
5. Check each tool response. Only add to tasks_created if the response confirms success.
If the response indicates failure, add to errors[].
6. Place in appropriate list based on owner and due date:
- Has due date + owner is user -> `Active` list
- Has due date + owner is other -> `Delegated` list
- No due date -> `Backlog` list
After all creation attempts, execute `list_reminders` for each list that received
new tasks. Verify each task appears by matching title. Add any tasks that were
reported as created but are missing from the list to the "creation_unverified" array.
NEVER populate tasks_created based on intent. Only include tasks confirmed present
in the verification query.
Return a JSON summary of tasks created:
{
"tasks_created": [
{"title": "...", "owner": "...", "list": "...", "due": "..."}
],
"creation_unverified": [],
"duplicates_skipped": [...],
"errors": [...]
}
Standard task creation fields:
title: "Task description"
list: Active
due: YYYY-MM-DD
notes: |
source: journal/YYYY-MM/YYYY-MM-DD-slug.md
created: YYYY-MM-DD
initiative: [[Initiative Name]]
owner: Name
Spawn a Task sub-agent with the following prompt structure:
You are extracting durable memory from a meeting journal entry.
Read the journal file at: {journal_file_path}
Read memory indexes: memory/people/_index.md, memory/initiatives/_index.md, memory/decisions/_index.md
Read reference/replacements.md and apply canonical names.
If the main agent provided a name resolution table, use those resolved names.
Apply durability test to insights from the meeting:
- Stakeholder updates -> memory/people/{name}.md
- Initiative updates -> memory/initiatives/{name}.md
- Decisions -> memory/decisions/{slug}.md
- Update relevant _index.md files
Do NOT persist: scheduling logistics, temporary blockers, action items.
BEFORE writing any [[wikilink]] in a memory file, verify the referenced entity exists
in one of the memory indexes read above. If the entity does NOT exist in any index,
do NOT fabricate the wikilink. Instead, write the name as plain text and note it in
the "skipped" array with reason "unverified entity reference".
Return a JSON summary of memory updates:
{
"created": [{"path": "...", "summary": "..."}],
"updated": [{"path": "...", "summary": "..."}],
"skipped": [{"insight": "...", "reason": "failed durability test"}]
}
After both sub-agents complete, collect their results and merge into the output summary. If either sub-agent fails:
| Sub-agent | Input | Output | Failure mode |
|---|---|---|---|
| Task extraction | Journal file path, integrations.md Tasks section, replacements.md | JSON: tasks created, creation unverified, duplicates skipped, errors | Report errors in summary, do not block memory extraction |
| Memory extraction | Journal file path, memory indexes, replacements.md | JSON: files created, files updated, insights skipped | Report errors in summary, do not block task extraction |
Shared constraints for both sub-agents:
reference/replacements.md and apply canonical names.lock files when writing shared memory files (see core skill cowork protocol)Scan ENTIRE output for any terms from reference/replacements.md that were not replaced. Correct before saving.
When processing transcripts, if new names are found that:
reference/replacements.mdAdd them to reference/replacements.md with a placeholder for the user to complete:
| Mick | ?? (needs full name) |
| JT | ?? (needs full name) |
This allows the user to update canonical names as needed without losing track of unknown references. Report these additions in the output summary.
End your response with:
---
## Meeting context
Created: `journal/YYYY-MM/YYYY-MM-DD-meeting-slug.md`
## Task updates
| Operation | Task | Details |
|-----------|------|---------|
| Created | Task description | Owner, due date, destination |
## Memory updates
| Action | File | Summary |
|--------|------|---------|
| Created/Updated | `memory/path/file.md` | What changed |
## Summary
- Journal entry created (file path)
- Tasks created (count by list)
- Memory entries created or updated (count by category)
- Any warnings or gaps (e.g., names not in replacements.md, calendar lookup failed)
Use the TodoWrite tool to give the user real-time visibility into pipeline progress. Create the todo list at the start and update as steps complete:
1. Process transcript and generate structured report [in_progress → completed]
2. Save journal entry [pending → completed]
3. Extract tasks (parallel sub-agent) [pending → completed]
4. Extract memory (parallel sub-agent) [pending → completed]
5. Replacement verification [pending → completed]
6. Compile and return summary [pending → completed]
Parallelization note: Steps 3 and 4 run concurrently. Mark BOTH as in_progress when spawning the sub-agents. Mark each completed as its sub-agent returns. If one sub-agent completes before the other, update its status immediately without waiting for the other.
Mark each step in_progress before starting it and completed immediately after. If a step fails, keep it as in_progress and add a new todo describing the issue.
For long transcripts (>30 minutes or >5,000 words), offload intermediate results to files rather than keeping everything in context:
This architecture means transcript length has minimal impact on Steps 4-5 performance, since sub-agents load only the structured journal output.
_index.md + up to 5 targeted fileslist operation for all configured lists (duplicate check)list_events operation for meeting metadatareference/replacements.md (mandatory)Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Use this skill whenever the user wants to do anything with PDF files. This includes reading or extracting text/tables from PDFs, combining or merging multiple PDFs into one, splitting PDFs apart, rotating pages, adding watermarks, creating new PDFs, filling PDF forms, encrypting/decrypting PDFs, extracting images, and OCR on scanned PDFs to make them searchable. If the user mentions a .pdf file or asks to produce one, use this skill.
Use this skill any time a .pptx file is involved in any way — as input, output, or both. This includes: creating slide decks, pitch decks, or presentations; reading, parsing, or extracting text from any .pptx file (even if the extracted content will be used elsewhere, like in an email or summary); editing, modifying, or updating existing presentations; combining or splitting slide files; working with templates, layouts, speaker notes, or comments. Trigger whenever the user mentions "deck," "slides," "presentation," or references a .pptx filename, regardless of what they plan to do with the content afterward. If a .pptx file needs to be opened, created, or touched, use this skill.