🧠 Spike - Generalize Tiger to handle multiple meeting types (auto-detect + route to right skill)

[Lewkans]

Goal

Generalize SSW.Tiger so it can handle multiple meeting types (sprint reviews, initial client meetings, retros, generic team meetings) instead of being hard-coded for sprint reviews. The system should auto-detect the meeting type from contextual clues in the transcript and pick the right skill/template to process it.

Context

Current SSW.Tiger pipeline assumes every transcript is a sprint review. Calum demonstrated using Tiger for an initial client meeting (analysing speakers, time-on-topic, applying SSW rules) — output was useful but the dashboard format was the wrong shape for the meeting type.

Approach (spike)

Investigate:

1. How to classify meeting type from a transcript — title, speakers, content patterns, explicit metadata
2. How to route a transcript to the right skill/template once classified — sprint-review, initial-meeting-analysis, retro-only, generic-meeting-summary
3. Whether classification should live in Tiger itself or as a separate pre-processing skill that emits metadata

Acceptance criteria

1. A short design write-up identifying:
   • The set of meeting types we want to support initially (≥3)
   • The classification strategy (heuristic vs LLM-based vs explicit metadata)
   • How a new meeting-type template plugs into the current Tiger pipeline
2. A working proof-of-concept on at least 2 meeting types (e.g. sprint review + initial client meeting) routing to different output templates
3. Estimate for the productionised version (separate PBI to follow)

Background — discussion

As per Calum in Sprint 10 Retro — "we need to come up with a way of sort of … generalizing Tiger".

Eddie volunteered to take the spike (line 4600). Michael as fallback if Eddie's day allocation is too tight (Eddie has 1 day in Sprint 11).

Out of scope

• Productionised meeting-type routing (separate PBI after spike)
• Per-client custom templates (later)

[edkranz]

Generalize Tiger from "meeting analyzer" to "skill execution pipeline"

Why

Today Tiger is hardcoded around sprint-review meetings: VTT input, sprint-shaped tabs, "meeting" terminology baked into Cosmos schema, env vars, and the Claude prompt. We want it to be the deployment pipeline for AI-generated HTML artifacts, with meeting analysis being one of many possible skills (sprint-review, 1-on-1, initial-meeting, survey analysis, etc.).

Concept

Tiger becomes: trigger → dispatch → skill executes → deploy → index.

A "skill" is a self-contained bundle declaring how to handle one kind of input and produce one kind of artifact. Adding a skill = dropping a folder. No core changes.

Vocabulary changes

Today	Tomorrow
meeting	artifact (output) + input (source)
meetingId	artifactId
transcript.vtt	input.{ext} (skill decides)
attendees.json	participants.json (skill-optional)
Cosmos meetings container	new artifacts container with skill discriminator
hardcoded "sprint" subject filter	per-skill inputMatchers

Old /{project}/{meetingId}/ URLs keep working — URL shape unchanged.

Skill manifest schema

{
  "name": "sprint-review",
  "version": "1",
  "description": "Sprint review/retro/planning analysis",
  "inputMatchers": [
    { "type": "subjectRegex", "pattern": "(?i)sprint" },
    { "type": "fileExtension", "value": ".vtt" }
  ],
  "idStrategy": "timestamp",       // | "slug" | "uuid"
  "parser": "./parser.js",
  "agents": [
    { "name": "timeline-analyzer", "output": "timeline.json", "parallel": true },
    { "name": "people-analyzer", "output": "people.json", "parallel": true },
    { "name": "insights-generator", "output": "insights.json", "parallel": true },
    { "name": "analytics-generator", "output": "analytics.json", "parallel": true },
    { "name": "longitudinal-analyzer", "output": "longitudinal.json", "parallel": true },
    { "name": "consolidator", "output": "consolidated.json", "parallel": false }
  ],
  "playbook": "./playbook.md",
  "template": "./template.html",
  "indexFields": ["participantCount", "totalDurationMinutes", "topicsCount", "actionItemsCount"]
}

Target layout

tiger-skills/
├── _shared/
│   ├── agents/                     # the 6 generic agents (incl. consolidator)
│   ├── lib/                        # vtt-parser, participant-resolver, ssw-people-photo
│   ├── template-base.html          # SSW branding fragments
│   └── CORE.md                     # generic pipeline rules (was top of CLAUDE.md)
├── sprint-review/
│   ├── manifest.json
│   ├── parser.js
│   ├── playbook.md                 # sprint-flavoured rules from CLAUDE.md
│   └── template.html
├── 1on1/
├── initial-meeting/
└── survey/                         # CSV/JSON input, different agents

projects/{project}/{artifactId}/
├── input.{ext}
├── manifest.json                   # which skill ran + dispatcher trace
├── analysis/
└── dashboard/index.html

Dispatcher

One webhook to rule them all — the existing Graph webhook + manual triggers all funnel into a single ingestion path. Dispatcher then chooses a skill via:

1. Explicit override — TIGER_SKILL=... env var or --skill CLI flag
2. Manifest matchers — first skill whose inputMatchers all pass (subject regex, file extension, content regex, attendee count, etc.)
3. Classifier agent fallback — small Claude call when no manifest matches; reads opening + metadata, returns best skill name

Dispatcher decision + reasoning written to {artifactDir}/manifest.json for traceability.

Pipeline change

processor/index.js becomes skill-agnostic:

1. validateCredentials()
2. ingestInput()                          // get raw input + metadata
3. const skill = await dispatch(input)    // ← NEW
4. const artifactId = skill.makeArtifactId(input)
5. await skill.parser.parse(input, artifactDir)
6. await invokeClaude({ skill, artifactDir, ... })   // prompt built from skill.playbook
7. await deploy(artifactDir)              // generic
8. await index(artifactDir, skill.indexFields)       // generic

CLAUDE.md shrinks to a small generic core (privacy, branding, deployment, file discipline). Sprint-specific content moves to tiger-skills/sprint-review/playbook.md.

Plan

Design lock-in first: write tiger-skills/SCHEMA.md documenting the manifest format, draft _shared/CORE.md extracted from the generic parts of CLAUDE.md, and finalize the Cosmos migration plan (below).

Then extract sprint-review as the only skill. Move sprint-specific code, prompts, and templates into tiger-skills/sprint-review/. Hardcode the dispatcher to always pick it. Verify behaviour-identical output against an existing transcript producing the same dashboard.

Then generalize vocabulary and Cosmos. Rename meetingId → artifactId across processor/, lib/, and azure-function/. Cut over to the new artifacts container. Remove the default "sprint" filter from downloadTranscript.js:59. Generalize entrypoint.sh notifications to use the skill's display name.

Then build the real dispatcher. Implement the matcher types, override flags, and the classifier-agent fallback. Add a second skill — 1-on-1 — to validate the design: same VTT input but a different playbook/template (3 tabs), matched by subject containing "1-on-1"/"1:1" or attendee count == 2. Then add a survey skill to validate input-format abstraction: CSV/JSON parser, a different agent set (theme-extractor, sentiment-analyzer), a different template. This is the proof Tiger isn't a meeting tool anymore.

Finally, polish: tiger skills list and tiger skills new <name> CLI commands, README rewrite, and clean up any remaining "meeting" references in azure-function/ and infra/.

Cosmos container migration plan

Goal: move from meetings container (hardcoded fields meetingId/meetingDate/dashboardPath/consolidated/metadata, partition key /projectName) to a new artifacts container that supports any skill, with zero downtime and no data loss.

New container shape:

• Name: artifacts
• Partition key: /projectName (unchanged — preserves query patterns)
• Document shape:

  {
    "id": "{projectName}__{artifactId}",
    "projectName": "...",
    "artifactId": "...",            // was meetingId
    "artifactDate": "...",          // was meetingDate
    "skill": "sprint-review",       // NEW — discriminator
    "skillVersion": "1",            // NEW
    "dashboardPath": "...",         // unchanged
    "deployedUrl": "...",
    "indexFields": { },             // skill-defined; was top-level metadata
    "consolidated": { },            // unchanged
    "createdAt": "...",
    "updatedAt": "..."
  }

Migration steps:

1. Provision the artifacts container in Bicep (infra/modules/cosmosDb.bicep) alongside the existing meetings container. Both live side-by-side; no destructive change yet.

2. Backfill. One-shot script (scripts/migrate-meetings-to-artifacts.js) that reads every doc from meetings and writes to artifacts with:

   • meetingId → artifactId
   • meetingDate → artifactDate
   • skill: "sprint-review", skillVersion: "1" injected
   • existing top-level meeting metrics (participantCount, etc.) moved into indexFields
   • all other fields preserved as-is
   • idempotent: uses upsert keyed on id, safe to re-run
   • dry-run flag; prints diff summary before writing

3. Dual-write. lib/cosmosClient.js writes to both containers for one release cycle. Reads still come from meetings. Behind TIGER_DUAL_WRITE_COSMOS=true env flag so it can be flipped off instantly if writes fail.

4. Cut over reads. Flip read paths (list-projects skill, dashboard lookup, deployer.js) to read from artifacts. Keep dual-writing. Verify in production for one cycle that nothing reads stale data from meetings.

5. Stop dual-writing. Switch to artifacts-only writes. meetings becomes read-only frozen history.

6. Decommission. After a buffer period (one sprint cycle minimum) with no regressions, archive meetings (export to blob storage as JSON for cold backup), then drop the container in a follow-up infra change.

Safety properties:

• No destructive change until step 6, well after cut-over has been validated in prod
• Backfill is idempotent and dry-runnable
• Dual-write is feature-flagged for instant rollback
• meetings container partition key matches artifacts, so the migration is field-mapping only — no resharding
• URL shape unchanged → no broken links during or after migration

Rollback at any step:

• Steps 1-3: nothing has been cut over; just stop dual-writing.
• Step 4: flip read paths back to meetings. Dual-writes mean both containers are still in sync.
• Step 5+: re-enable dual-write, replay any missed artifacts writes back into meetings from the dual-write window.

Decisions

Question	Decision
Single trigger or multiple?	One webhook to rule them all. All inputs funnel to the dispatcher.
Old artifacts re-render when skill changes?	No. Skill version recorded in {artifactDir}/manifest.json for traceability only.
SSW People profile photo lookup?	Refactored to a utility in _shared/lib/, not a pipeline step. Skills opt in.
Backwards-compat URLs?	Keep current shape. No URL changes; old links stay valid.
Cosmos?	New artifacts container with skill field. Backfill old data with skill: "sprint-review". Migration plan above.
URL includes skill name?	No. Skill is metadata, not a URL component.
Artifact ID schema?	Skill decides via manifest.idStrategy (timestamp | slug | uuid).

Done when

• A new skill can be added by dropping a folder under tiger-skills/ with no code changes outside it
• Sprint-review behaviour is unchanged for end users
• A 1-on-1 transcript produces a 1-on-1 dashboard, not a sprint dashboard
• A survey CSV produces a survey dashboard via the same pipeline
• CLAUDE.md contains no sprint-specific rules
• All existing Cosmos data has been migrated to the artifacts container, the meetings container is decommissioned

[edkranz]

Hey @suiyangqiu , if you get around to this one, pls let me know what you think of this plan I posted above. Happy to chat about it this week