Followup Todos

Follow-up Todos

Usage

• /followup-todos <path> — Extract and propose follow-ups from a specific meeting note.
• /followup-todos (no args) — Run /note-status pending --step=todos to show meetings missing follow-up extraction. The user picks one (or more) to process.

Output format (mandatory)

• Never insert Obsidian Tasks / checkbox lines: no - [ ], - [x], - [-], or any - [?] pattern.
• Never append Tasks-plugin inline metadata on inserted lines: no 📅, 🛫, ⏳, or other parsed task tokens. (Optional priority emoji at the very end as plain text — e.g. 🔼 — is fine if it reads naturally in prose.)
• Always insert plain list items: - Description… Wikilinks ([[@Name]], [[+Team]]) and bold are allowed.

Prerequisites

The meeting file should ideally have cached AI transcripts (from /cache-notes). If not cached, suggest running /cache-notes <path> first. However, the skill also works on notes with only manual content.

Optional context

For classification (owner, urgency, dates in the proposal step), you may still use people-resolver and obsidian-tasks as reference — but do not copy Tasks checkbox or date-token syntax into the note.

Workflow

Step 1: Read the meeting note and gather context

See vault-context for vault discovery conventions.

Read the entire file. Also read Tracker.md to cross-reference Jira tickets and current task status — this helps:

• Set priority: A ticket already marked 🔺 in the Tracker should keep that priority (as trailing emoji in the bullet text if you include one).
• Avoid duplicates: If a follow-up already exists in the Tracker for the same Jira ticket, flag it in the proposal table (Step 3) rather than creating a duplicate line in the note.
• Add context: If the meeting references a Jira ticket ID (e.g. PROJ-1234), pull its current status and assignee from the Tracker.

Extract action items from all content sources, skipping lines that are already captured as follow-ups (compare meaning, not only exact text):

1. Manual notes (between frontmatter --- and ## 🤖 AI Notes): Free-text action items (e.g. "- Talk to Alex about X"). Skip lines that are checkbox tasks (- [*] — any single character between brackets) when deduplicating, but note the vault may still contain legacy - [ ] lines from older runs.
2. [!gemini_todos] callout: Gemini's "Suggested Next Steps" — explicit action items.
3. [!gemini_notes] callout: Summary & Details — scan for implicit commitments ("will do X", "agreed to Y", "plans to Z").
4. Other provider callouts ([!otter_todos], etc.): Same treatment as Gemini.

Also extract:

• Existing plain bullets and checkbox lines in the follow-up section to avoid duplicates
• Participants: from frontmatter (to resolve assignees)
• Meeting date (from filename or created: frontmatter)

Step 2: Classify each action item

For each candidate action item (from manual notes, transcript todos, or implicit commitments in details), determine:

1. Owner: Who is responsible? See people-resolver for name matching and assignee rules.

2. Relevance: Score as high, medium, or skip:

   • High: Action is for the user, has a clear deliverable, or is time-sensitive.
   • Medium: Action is for someone else but the user should track it, or it's vague but potentially important.
   • Skip: Purely informational, already completed (based on date vs today), or not actionable.

3. Priority (for the proposal table only): Based on urgency and impact (see priorities in obsidian-tasks). When inserting bullets, you may end the line with a single priority emoji (🔺 ⏫ 🔼 🔽) as plain text — never as Tasks metadata.

4. Dates: Note due/start in the proposal table when helpful; do not put 📅 / 🛫 / ⏳ on inserted lines. If a date matters, write it in words in the bullet (e.g. "by 2026-03-26").