with one click
meeting
// Process meeting transcripts into journal entries, tasks, and memory updates
// Process meeting transcripts into journal entries, tasks, and memory updates
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | meeting |
| description | Process meeting transcripts into journal entries, tasks, and memory updates |
| triggers | ["process this meeting","meeting transcript","meeting notes"] |
| user-invocable | true |
| help | {"purpose":"Process a meeting transcript through the 14-step TARS pipeline — calendar\nmatch, participant resolution, knowledge inventory, secret scan, summary,\nnuance capture, journal + transcript write, task extraction, memory\nproposals — all gated on review-before-persist.","use_cases":["Process this meeting transcript","I just had a meeting with [person], here's what we said...","Turn this transcript into a journal entry"],"scope":"meeting,transcript,journal,followthrough"} |
The highest-value workflow in TARS. Transforms raw meeting transcripts into structured journal entries, actionable tasks, and durable memory updates through a 14-step pipeline (plus a 7b nuance-capture sub-step) with mandatory user review gates.
All workspace writes go through mcp__tars_vault__* tools (see skills/core/SKILL.md → "Write interface"). All integration calls resolve via mcp__tars_vault__resolve_capability — never hard-code mcp__apple_* or mcp__microsoft_365_*. All names use canonical forms from the alias registry. All persistence requires user confirmation. Wikilinks must be formed via mcp__tars_vault__format_wikilink — see core → "Wikilink discipline". Hand-formed [[...]] containing smart quotes or illegal characters is rejected at the MCP and hook layers.
When a resolve_capability call returns status: "unavailable", follow the degradation messaging convention in skills/core/SKILL.md section "Degradation messaging convention".
Hooks now enforce tars- prefix, content chunking, alias-registry load, changelog writes, and telemetry. The pipeline body below describes intent; the MCP server handles validation and logging.
Steps 1-6: Preparation (load context, detect format, resolve calendar/participants, check knowledge, scan secrets)
Step 7: Processing (LLM analysis of transcript)
Step 7b: Nuance capture (second Haiku pass over raw transcript — safety net)
Steps 8-9: Persistence (journal entry + transcript archive)
Steps 10-11: Extraction with review (tasks + memory, user confirms each)
Steps 12-14: Cleanup (unresolved names, daily note, self-evaluation)
The tars-vault MCP server holds the alias registry in-process (invalidated on file-mtime change). Name-resolution calls (mcp__tars_vault__resolve_alias) use the cache. If the SessionStart hook has run this session, the canonical-names head is already in additionalContext. No explicit load is required — call mcp__tars_vault__resolve_alias(name="…") whenever a speaker label, attendee, or entity reference needs canonicalization.
Inspect the raw transcript and classify its format and available metadata.
| Format | Identifying signals |
|---|---|
otter | "Otter.ai" header, Speaker N labels, MM:SS timestamps |
fireflies | "Fireflies.ai" header, structured JSON with SPEAKER/LINE_TEXT fields |
zoom | "WEBVTT" header or Zoom chat export format |
teams | Microsoft Teams transcript format, <v> tags or Teams metadata |
raw_text | Speaker labels present but no platform markers |
unknown | No recognizable structure |
Produce a checklist of what the transcript provides:
Format: [detected format]
Has date: yes/no
Has duration: yes/no
Has attendees header: yes/no
Has speaker labels: yes/no
Has timestamps: yes/no
Fill in whatever the transcript provides. Missing fields will be resolved in subsequent steps. Do not guess missing values.
ALWAYS query the calendar, even when the transcript provides a date. Calendar data is authoritative for meeting title, full attendee list (including silent participants), organizer, and precise time.
cap = mcp__tars_vault__resolve_capability(capability="calendar")
# use cap.tools[*].name dynamically — never hard-code mcp__apple_calendar__* or mcp__microsoft_365_*
If cap.status == "unavailable" and calendar.required: true in _system/integrations.md, halt with a clear message. Otherwise degrade to transcript-provided date + user confirmation.
If resolve_capability(capability="meeting-recording") returns a connected provider and the user did not paste a transcript, propose:
Import transcript from "<recording title>" (<recording URL>)?
Uses whichever tool the resolver returns (Minutes.app, Otter, Fireflies, etc.).
a. Transcript has a date: Use the transcript date to define a narrow calendar query window (that day, +/- 1 day).
b. Transcript lacks a date: Query the past 3 business days from today.
c. Match criteria: Score each calendar event against the transcript using:
d. Single strong match: Present for confirmation with a binary question.
This appears to be the "Q1 Planning Sync" from Mon 2026-03-16 at 10:00am. Correct? [Y/N]
e. Multiple matches (Issue 3): Present as a multiple-choice list.
Which meeting is this transcript from?
1. Mon 2026-03-16, 10:00am -- "Q1 Planning" with Jane Smith, Bob Chen
2. Tue 2026-03-17, 2:00pm -- "Platform Review" with Sarah Lopez
3. None of these -- I'll specify
f. No match and calendar unavailable: Ask the user directly.
When did this meeting happen? (e.g., "yesterday at 2pm" or "2026-03-19")
g. NEVER proceed without a resolved date and time. The pipeline halts here until date/time is confirmed.
Once matched, extract and carry forward:
tars-meeting-datetime frontmatter)Merge two participant sources into one canonical list:
Pass 1: Alias registry Check the alias registry loaded in Step 1 for an exact match or known variation. If found, map to canonical form.
Pass 2: Vault search
mcp__tars_vault__search_by_tag(tag="tars/person", query="<name>", limit=5)
If the name matches exactly one person note, use it.
Pass 3: Contextual disambiguation If ambiguous (multiple candidates), use context clues:
Pass 4: Ask the user If any names remain unresolved after passes 1-3, batch ALL unresolved names into a single interaction.
For ambiguous names, present multiple-choice:
Who is "Dan" in this meeting?
1. Dan Rivera (Engineering)
2. Dan Chen (Infrastructure)
3. Someone new -- I'll provide details
For unknown names, ask directly:
Who is "Mick"? Please provide their full name.
Present the final resolved participant list for confirmation before proceeding:
Participants resolved:
- Jane Smith (from calendar + transcript)
- Bob Chen (from calendar + transcript)
- Sarah Lopez (from calendar only, silent in transcript)
- You
Correct? [Y / Edit]
NEVER use generic speaker labels ("Speaker 1", "Unknown") in any output.
Before extracting anything, check what the workspace already knows about the entities and topics in this transcript.
For each person, initiative, decision, or topic identified in the transcript:
mcp__tars_vault__search_by_tag(tag="tars/person", query="<entity>", limit=5)
mcp__tars_vault__search_by_tag(tag="tars/initiative", query="<entity>", limit=5)
mcp__tars_vault__search_by_tag(tag="tars/decision", query="<entity>", limit=5)
Use mcp__tars_vault__fts_search and mcp__tars_vault__semantic_search for paraphrase/prose matching over journal + transcripts + contexts.
Classify each piece of information from the transcript against existing vault knowledge:
Apply the canonical NEW/UPDATE/REDUNDANT/CONTRADICTS classification rules (see skills/core/SKILL.md §Check before writing).
Knowledge check:
- Jane Smith: 12 entries in memory. Last updated 2026-03-15.
- Platform Rewrite: active initiative, 8 related entries.
- "REST vs GraphQL": decision already recorded (2026-02-28).
Will focus on what's new or changed.
If processing a batch of transcripts chronologically, note the position:
This is transcript 2 of 5. Later transcripts will supersede earlier ones on overlapping topics.
Run the secrets scanner against transcript content BEFORE any workspace writes.
mcp__tars_vault__scan_secrets(content="<transcript_content>")
Returns JSON: {block: [...], warn: [...], negative_sentiment: [...]}. The MCP server also runs scan_secrets internally before every write via PreToolUse hook; the pre-write call here is belt-and-braces so redaction happens before the transcript is echoed back to the user.
If blocked: Redact the sensitive content and notify the user. Do not proceed with the redacted content without confirmation.
If warned: Flag the content for user review. Present the flagged items and ask whether to include, redact, or rephrase before proceeding.
Analyze the transcript and produce structured output for ALL of the following sections. Do not skip any section. If a section has no content, state "None identified."
Classify into:
Format: "Owner" -- Task description (deadline if stated)
Directly addresses the top-declared retrieval pain: summaries miss nuance, contrarian views, specific phrases, and quantitative claims. Runs AFTER Step 7 and BEFORE Step 8 so the nuance section lands in the same journal entry as the main summary.
meeting_nuance_skipped, reason) only if the
transcript was unavailable (e.g., meeting-recording import produced summary
only) or was <500 words total. The nuance pass is cheap enough (~1 extra
Haiku call) that it should run by default.Spawn a sub-agent with subagent_type="general-purpose", model Haiku,
max_turns=1, temperature 0.2. Feed it the verbatim prompt from
skills/meeting/reference/nuance-pass-prompt.md, substituting
{{TRANSCRIPT_TEXT}} with the full raw transcript (before any archival
chunking). The prompt requires a single JSON object back.
Six arrays, any of which may be empty:
| Key | Content |
|---|---|
notable_phrases | Verbatim phrases the summary dropped. Speaker + quote + nearby text for grep. |
contrarian_views | Statements contradicting the dominant summary sentiment. |
specific_quotes | Quotes worth preserving verbatim with rationale. |
unusual_technical_terms | Jargon worth indexing with speaker + context sentence. |
emotional_strong_statements | Strong emotional statements with emotion type. |
numbers_and_dates_missed | Quantitative claims absent from the summary. |
Never apply durability / accountability filtering here — those gates run on persistence, not capture. Over-capture is the design intent.
The nuance JSON is rendered beneath the main summary as a ## Notable phrases & perspectives section. Suggested layout (omit empty sub-headings):
## Notable phrases & perspectives
### Notable phrases
- **Jane Smith** (~12:14): "we've been papering over this for six months"
- **Bob Chen** (~23:02): "that's technically a rewrite, not a refactor"
### Contrarian views
- **Sarah Lopez**: pushed back on the REST-over-GraphQL decision — "we'll regret this when the mobile team gets here"
> Quote: "we'll regret this when the mobile team gets here"
### Specific quotes worth preserving
- **Jane Smith**: "the whole reason we did the Q1 rewrite was to avoid exactly this conversation" — captures the frustration behind the roadmap reset
### Unusual technical terms
- **idempotency fences** (Bob Chen): raised in the context of the retry-queue redesign
### Strong emotional statements
- **Sarah Lopez** (frustration): "I've been asking for this for eight months"
### Numbers & dates missed
- 2026-06-30 — vendor contract renewal (mentioned once by Jane, absent from summary)
- $340k — projected savings from consolidation (Bob's estimate)
Nothing in this section is persisted to memory automatically. It lives in the journal as a searchable reading of the room. Memory extraction (Step 11) still runs its own durability gate on any item the user later promotes.
Failure here must not block the pipeline:
meeting_nuance_failed with the error
string. Proceed to Step 8 as if 7b never ran.meeting_nuance_captured with counts (all zero).On success emit meeting_nuance_captured with counts per category:
{
"event": "meeting_nuance_captured",
"counts": {
"notable_phrases": 4,
"contrarian_views": 1,
"specific_quotes": 2,
"unusual_technical_terms": 3,
"emotional_strong_statements": 1,
"numbers_and_dates_missed": 2
}
}
/lint can later surface meetings where the nuance pass returned all-zero
counts — often a symptom of a malformed transcript rather than a thin meeting.
mcp__tars_vault__create_note(
name="YYYY-MM-DD Meeting Title",
path="journal/YYYY-MM/YYYY-MM-DD-meeting-slug.md",
template="meeting-journal",
frontmatter={...},
body="..."
)
If template= is not available for the meeting-journal template in the user's vault, the server falls back to mcp__tars_vault__write_note_from_content automatically. Auto-chunking applies when body >40KB.
The create_note call takes the full frontmatter inline. Values:
---
tags: [tars/journal, tars/meeting]
tars-date: YYYY-MM-DD
tars-meeting-datetime: YYYY-MM-DDTHH:MM:SS
tars-participants: ["[[Jane Smith]]", "[[Bob Chen]]"]
tars-organizer: "[[Jane Smith]]"
tars-topics: [topic-slug-1, topic-slug-2]
tars-initiatives: ["[[Platform Rewrite]]"]
tars-source: calendar | transcript
tars-calendar-title: "Original Calendar Title"
tars-transcript: "[[YYYY-MM-DD-meeting-slug-transcript]]"
tars-transcript-format: otter | fireflies | zoom | teams | raw_text
tars-created: YYYY-MM-DD
---
Append the structured report from Step 7 to the journal entry body:
# Meeting Title
**Date:** YYYY-MM-DD | **Time:** HH:MM | **Participants:** [[Jane Smith]], [[Bob Chen]]
**Initiatives:** [[Platform Rewrite]]
## Topics
[From Step 7]
## Updates
[From Step 7]
## Concerns
[From Step 7]
## Decisions
[From Step 7]
## Action items
[From Step 7]
## Unresolved items
[From Step 7]
## Key quotes
[From Step 7]
## Notable phrases & perspectives
[From Step 7b — omit if the nuance pass was skipped; keep heading if pass ran with zero findings]
## Associated captures
[Screenshots and images related to this meeting, if any]
Title priority:
Slug rules:
mcp-planningWhen the calendar title differs from the transcript header, keep tars-calendar-title in frontmatter for reference.
The tars-vault MCP server automatically adds a space-form alias (e.g. "2026-04-06 Gba Ai Panel Prep") to the aliases list whenever a note is created under journal/ with a YYYY-MM-DD-slug filename. This means wikilinks of the form [[2026-04-06 GBA AI Panel Prep]] resolve in Obsidian without any manual alias step.
You do NOT need to add aliases manually in Step 8 — the server handles it. The returned aliases_added field confirms what was injected. If you supply your own aliases list in frontmatter, the server extends it rather than overwriting it.
Move the original transcript to the archive with a standardized filename and bidirectional links.
mcp__tars_vault__create_note(
name="YYYY-MM-DD-meeting-slug-transcript",
path="archive/transcripts/YYYY-MM/YYYY-MM-DD-meeting-slug-transcript.md",
template="transcript",
frontmatter={
"tags": ["tars/transcript"],
"tars-journal-entry": "[[YYYY-MM-DD Meeting Title]]",
"tars-date": "YYYY-MM-DD",
"tars-meeting-datetime": "YYYY-MM-DDTHH:MM:SS",
"tars-participants": ["[[Jane Smith]]", "[[Bob Chen]]"],
"tars-format": "otter",
"tars-created": "YYYY-MM-DD"
}
)
mcp__tars_vault__append_note(
file="YYYY-MM-DD-meeting-slug-transcript",
content="<full raw transcript text>"
)
The server auto-chunks at 40KB boundaries so arbitrarily large transcripts persist cleanly.
tars-transcript property points to the archived transcripttars-journal-entry property points back to the journal entryNEVER delete the original transcript. Archive it, link it, preserve it.
Every task candidate goes through the accountability test. The user always sees and selects which tasks to create.
For each potential action item from Step 7, test ALL three criteria:
| Criterion | Question | Pass example | Fail example |
|---|---|---|---|
| Concrete | Is it a specific deliverable? | "Review hiring plan" | "Think about Q4" |
| Owned | Does it have a clear single owner? | "Bob will send the report" | "The team needs to align" |
| Verifiable | Will we know when it's done? | "Share migration report by Friday" | "Stay on top of things" |
All three must pass. If any criterion fails, the item is filtered out.
Always present ALL candidates, showing both kept and filtered items:
15 potential tasks found. 8 pass the accountability test:
1. [KEEP] Review hiring plan (you, due 2026-03-25, high)
2. [KEEP] Share migration report (Bob Chen, due 2026-03-24, medium)
3. [KEEP] Update API documentation (you, due 2026-03-28, medium)
4. [KEEP] Schedule vendor demo (Sarah Lopez, due 2026-03-26, low)
5. [KEEP] Draft budget proposal (you, due 2026-03-31, high)
6. [KEEP] Send test results to QA (Bob Chen, due 2026-03-25, medium)
7. [KEEP] Review platform architecture doc (you, due 2026-03-28, low)
8. [KEEP] Follow up with Sarah on API timeline (you, due 2026-03-28, low)
-- Filtered out --
9. "We should think about Q4" -- no owner, not concrete
10. "The team needs to align on priorities" -- no specific owner
11. "Keep an eye on the timeline" -- not verifiable
12. "Stay on top of vendor responses" -- not concrete
13. "Someone should look into that" -- no owner
14. "We need to be more proactive" -- not concrete, not verifiable
15. "Let's circle back on that" -- not concrete
Which to create?
- "all" to create 1-8
- "1, 3, 7" to keep specific ones
- "all except 4" to exclude specific ones
- "move 10 to keep" to override a filter decision
- "none" to skip all
After the user responds, create ONLY the selected tasks using the tasks skill protocol:
mcp__tars_vault__create_note(
name="Task Title",
path="tasks/YYYY-MM-DD-task-slug.md",
template="task",
frontmatter={
"tags": ["tars/task"],
"tars-status": "open",
"tars-owner": "[[Owner Name]]",
"tars-due": "YYYY-MM-DD",
"tars-priority": "high",
"tars-source": "[[YYYY-MM-DD Meeting Title]]",
"tars-created": "YYYY-MM-DD"
}
)
| Condition | Category |
|---|---|
| Has due date, owner is user | Active |
| Has due date, owner is someone else | Delegated |
| No due date | Backlog |
| User says | Resolution |
|---|---|
| "today" | Current date YYYY-MM-DD |
| "tomorrow" | Current date + 1 day |
| "this week" | Thursday of current week |
| "next week" | Monday of next week |
| "Friday" / "next Friday" | First occurrence of that day after today |
| "end of month" | Last day of current month |
| "later" / no date | Backlog (no due date) |
NEVER use relative dates in output. Always resolve to YYYY-MM-DD.
Memory persistence requires passing the durability test, checking against existing knowledge, handling negative sentiment, and getting user confirmation.
All 4 criteria must pass:
| Criterion | Question |
|---|---|
| Lookup value | Will this be useful for lookup next week or next month? |
| Signal | Is this high-signal and broadly applicable? |
| Durability | Is this durable, not transient or tactical? |
| Behavior change | Does this change how TARS should interact in the future? |
Pass examples: "Jane now leads both platform and mobile teams." / "Vendor contract renews June 2026." / "Decision: REST over GraphQL for public API."
Fail examples: "Meeting rescheduled to Thursday." / "Bob will send the report by Friday." / "We discussed the timeline."
For each item passing the durability test, compare against the vault inventory from Step 5:
Apply the canonical NEW/UPDATE/REDUNDANT/CONTRADICTS classification rules (see skills/core/SKILL.md §Check before writing).
Scan proposed memory updates for negative patterns:
When negative sentiment is detected, present with options:
This about Steve has negative sentiment: "Steve has been slow to deliver on infrastructure commitments."
Save with flag for periodic review? [Y / Rephrase / Skip]
If saved with flag:
<!-- tars-flag:negative YYYY-MM-DD -->content<!-- end-tars-flag -->tars-has-flagged-content: true on the person's note via mcp__tars_vault__update_frontmatter(file="memory/people/<name>", updates={"tars-has-flagged-content": true})_views/flagged-content.base for periodic cleanupIf rephrase: Ask user for alternative wording and save the rephrased version without a flag.
If skip: Do not persist.
Proposed memory updates:
1. [[Jane Smith]]: Now leads both platform and mobile teams (UPDATE -- was platform only)
2. [[Bob Chen]]: Concerned about Q3 timeline, may need additional hires (NEW)
3. [[Platform Rewrite]]: Decision to use REST over GraphQL for public API (NEW decision)
4. [[Steve Park]]: Slow to deliver on infrastructure [FLAGGED -- negative sentiment]
-- Skipped --
5. "We discussed the roadmap" -- failed durability test (no specific insight)
6. "Jane mentioned the Q1 results" -- redundant (already in memory from 2026-03-15)
Save? [all / 1, 3 / none / edit #2]
For each confirmed memory update:
New person/entity notes:
mcp__tars_vault__create_note(
name="Entity Name",
path="memory/<type>/entity-name.md",
template="<type>",
frontmatter={"tags": ["tars/<type>"], "tars-created": "YYYY-MM-DD"}
)
Updates to existing notes:
mcp__tars_vault__append_note(
file="Entity Name",
content="## Update YYYY-MM-DD\n[New information from meeting]\nSource: [[YYYY-MM-DD Meeting Title]]"
)
mcp__tars_vault__update_frontmatter(file="Entity Name", property="tars-modified", value="YYYY-MM-DD")
New decisions:
mcp__tars_vault__create_note(
name="Decision Title",
path="memory/decisions/decision-slug.md",
template="decision",
frontmatter={"tags": ["tars/decision"], "tars-date": "YYYY-MM-DD", "tars-created": "YYYY-MM-DD"}
)
| Type | Folder |
|---|---|
| Person | memory/people/ |
| Vendor | memory/vendors/ |
| Competitor | memory/competitors/ |
| Product | memory/products/ |
| Initiative | memory/initiatives/ |
| Decision | memory/decisions/ |
| Org context | memory/org-context/ |
After all writes are complete, scan every wikilink in the journal entry and any newly created/updated notes.
For any wikilink that does not resolve to an existing note:
mcp__tars_vault__append_note(
file="alias-registry",
content="| <Unresolved Name> | ?? (needs full name) |"
)
The mcp__tars_vault__create_note / append_note tools also run the auto-wikilink pass (§3.3) — ambiguous name candidates are returned for batched user review, never auto-linked silently.
Report all unresolved names in the output summary.
The PostToolUse hook emits a vault_write telemetry event for each MCP write. It does not write to the daily note or changelog.
Append a meeting-processing summary to today's daily note explicitly:
mcp__tars_vault__append_note(
file="journal/YYYY-MM-DD",
content="## Meeting processed: [[YYYY-MM-DD Meeting Title]]\n- Tasks: N created (of M extracted)\n- Memory: N updates\n- Transcript: archived to [[archive/transcripts/...]]\n"
)
Write a changelog entry to _system/changelog/YYYY-MM-DD.md with batch_id for rollback.
Emit at minimum: meeting_processed, tasks_proposed, memory_proposed.
If any errors occurred during the pipeline (failed calendar lookup, MCP write error, script failure, unresolved ambiguity):
mcp__tars_vault__search_by_tag(tag="tars/issue", query="<error-signature-keywords>", limit=5)
mcp__tars_vault__update_frontmatter(file="<issue-note>", property="tars-occurrence-count", value="<n+1>")
mcp__tars_vault__update_frontmatter(file="<issue-note>", property="tars-last-seen", value="YYYY-MM-DD")
mcp__tars_vault__append_note(file="<issue-note>",
content="## Occurrence YYYY-MM-DD\n<Error context from this run>")
Note: the PostToolUse hook emits telemetry only. Backlog deduplication is the skill's responsibility. This step covers pipeline-level errors (missed calendar match, unresolved attendee, secret-scan block).
mcp__tars_vault__create_note(
name="Issue: <Brief Description>",
path="_system/backlog/issues/issue-slug.md",
template="backlog-item",
frontmatter={
"tags": ["tars/backlog", "tars/issue"],
"tars-backlog-type": "issue",
"tars-issue-type": "cli-error",
"tars-severity": "warning",
"tars-occurrence-count": 1,
"tars-first-seen": "YYYY-MM-DD",
"tars-last-seen": "YYYY-MM-DD",
"tars-status": "open",
"tars-context": "Meeting processing, <step where error occurred>",
"tars-created": "YYYY-MM-DD"
}
)
End every meeting processing run with this summary, regardless of whether all steps succeeded:
---
## Meeting processed
**Journal:** `journal/YYYY-MM/YYYY-MM-DD-meeting-slug.md`
**Transcript:** `archive/transcripts/YYYY-MM/YYYY-MM-DD-meeting-slug-transcript.md`
## Task extraction
| # | Task | Owner | Due | Category | Status |
|---|------|-------|-----|----------|--------|
| 1 | Review hiring plan | You | 2026-03-25 | Active | Created |
| 2 | Share migration report | Bob Chen | 2026-03-24 | Delegated | Created |
## Memory updates
| Action | Entity | Summary |
|--------|--------|---------|
| Updated | [[Jane Smith]] | Now leads platform and mobile |
| Created | REST vs GraphQL | New decision record |
## Summary
- Journal entry created
- Transcript archived with bidirectional links
- Tasks: N created (M candidates, K filtered, J skipped by user)
- Memory: N updates (X new, Y updated, Z skipped)
- Unresolved names: N (added to alias registry)
- Errors: [any errors, or "None"]
| Resource | Budget |
|---|---|
| Alias registry | Full read (Step 1) |
| Calendar | 1 query for event matching (Step 3) |
| Vault search | Up to 5 queries per entity/topic (Step 5) |
| Scripts | 1 scan-secrets.py invocation (Step 6) |
| Memory reads | Up to 10 targeted file reads for knowledge inventory |
| Backlog search | 1 query for existing issues (Step 14) |
meeting_nuance_failed, and continue to Step 8