Instruction file imported from gargislalom/so-ai-training-101-pnw-team2 (
.github/instructions/intake/workflows/odr-session-prep.instructions.md). Copyright stays with the author.
User Requirement Session Readout Prep
After on-site user requirement sessions are completed and transcripts processed, this skill synthesizes findings into readout deliverables. It operates on the processed session artifacts already in docs/discussions/{Domain}/odr/.
Where This Fits in the Process
On-site user requirement sessions (ODR, Tech, Prototype)
↓
Transcripts recorded
↓
Transcripts processed → Raw/, Summary/, Implications/ per session
↓
>>> THIS SKILL STARTS HERE <<<
↓
Inventory all processed sessions across session types
↓
Build domain readout deck + readout meeting agenda
↓
Extract and classify opportunities (automation, integration, enhancement)
↓
Build consolidated tech readout (cross-domain)
↓
Identify follow-up gaps → plan next round
When to Use
- All (or most) sessions for a domain have been processed into
docs/discussions/{Domain}/odr/ - You need to build a readout presentation from those session artifacts
- You need a meeting agenda and invite for presenting the readout to stakeholders
- You need a consolidated tech readout pulling from multiple domains
- You need to extract and classify opportunities surfaced during sessions
- You need to identify follow-up gaps after reviewing findings
Input: What Lives in the odr/ Folder
Each domain's odr/ folder contains three types of processed sessions:
| Session Type | Naming Pattern | What It Captures |
|---|---|---|
| ODR Observations | {date}-{Domain}-Workshop-D{day}-{Topic}/ |
User workflows, pain points, manual processes, workarounds, improvement opportunities |
| Tech Sessions | {date}-{Domain}-Workshop-D{day}-Tech-Session/ |
System architecture, integrations, data models, migration topics, technical opportunities |
| Prototype Reviews | {date}-{Domain}-Workshop-D{day}-{Domain}-Prototype/ |
Prototype feedback, corrections, validation against real workflows, enhancement opportunities |
Each session folder contains:
{date}-{Domain}-Workshop-D{day}-{Topic}/
├── Raw/ → transcript
├── Summary/ → {date}_{Domain}-Workshop-{Topic}_Summary.md
└── Implications and Changes/ → {date}_{Domain}-Workshop-{Topic}_Implications.md
Additionally, each domain's odr/ folder contains a prototype demo PDF:
- Naming:
{date} {Domain} Prototype Demo.pdf(e.g.,2026-02-24 FC Prototype Demo.pdf) - This PDF is the slide deck presented during the prototype review session
- One PDF per prototype session; expect one per domain
The readout synthesizes findings from all three session types plus the prototype PDF.
Phase 1: Inventory All Sessions
-
Scan the odr/ folder: Glob for
docs/discussions/{Domain}/odr/**/Summary/*.md -
Classify each session by type (ODR, Tech, Prototype) based on folder and file naming
-
Read each summary: Extract participants, key topics, pain points, and opportunities
-
Read the prototype demo PDF: Extract the "Our Understanding" facts (prior known pain points and context), the touchpoint timeline (exact dates of prior sessions), and the user journey flows validated during the session
-
Check discussion guides: Glob for
docs/xd-playground/{Domain}/discussion-guides/*.mdfor prior prep context -
Query KB for gaps: Use the KB enrichment workflow for any missing context
-
Extract opportunities: Scan summaries and implications for explicitly called-out opportunities (look for "opportunity", "automation", "enhancement", "integration opportunity", "<TEAM_NAME> could" patterns). For each opportunity, capture:
- Source session - which session surfaced it (e.g., Day 3 - Payment Posting, Day 2 - Tech Session)
- Role(s) affected - who benefits or is involved (e.g., Cashiers, Asset Managers, IT, Attorneys)
- Type tag - classify as one of:
Automation- manual processes that can be eliminated or reduced (e.g., auto-matching claim-to-bucket, smart multi-payment detection)Integration- system connections that would replace manual handoffs (e.g., vendor portal bidirectional integration, Stripe for small investor payments)Enhancement- improvements to workflows or capabilities beyond current state (e.g., searchable codes by name and number, fee waterfall logic)
- Description - one-line summary of the opportunity and its expected impact
Output: structured inventory covering all session types with participants, topics, pain points, and opportunities indexed by both session and role.
Phase 1b: Pre-Drafting Inputs
Before writing any outward-facing copy (invites, deck), confirm these inputs with the delivery lead:
- Session schedule - which sessions happened (or will happen) on which days, with whom, and on what topic. This drives the invite's specificity and the deck's schedule grid. Without it, invite copy will be generic and require rework.
- Terminology alignment - confirm the terms used for the engagement (e.g., "user requirement sessions" vs "discovery" vs "ODR"). Loaded or inconsistent terminology in outward-facing copy creates confusion. Agree on terms once and use them across all invite copy, deck slides, and agenda documents.
- Combined vs. separate readouts - decide whether domains are presented independently or combined (e.g., REO + Title + Lien Release in a single readout). This affects invite scope, invitee lists, and deck structure.
Phase 2: Readout Meeting Agenda
The agenda for the readout presentation meeting where findings are presented to stakeholders.
File naming: {date}_{Domain}-Readout-Agenda.md (e.g., 2026-03-02_FC-Readout-Agenda.md)
Pre-existing invite copy: If the meeting invite was already written and sent independently, ask the user for the final copy and add it to the domain's agenda file (docs/discussions/{Domain}/odr/{date}_{Domain}-Readout-Agenda.md). The deck's Phase 3 continuity step depends on this file existing with the finalized invite copy.
Invite copy review cycle: Invite copy is not one-shot. Expect a draft → review → finalize loop. Common iteration areas: tense consistency (past for sessions, future for readout), domain-specific terminology, scope of what the readout covers (e.g., whether prototype demo is included), and closing tone. Get delivery lead sign-off before sending.
Required sections:
-
Meeting invite copy - blockquoted blurb for the calendar invite. This copy sets the frame that carries into the deck's Purpose, Context, and Audience slides (see Phase 3):
- One-line title referencing the domain
- 2-3 paragraphs: context/location, what we observed, what the readout covers
- Bulleted agenda highlights (5-6 items, including opportunities identified)
- Optional closing: come prepared with questions, prototype feedback opportunity
-
Suggested invitees grouped by:
- SN Operations (all session participants across ODR, Tech, and Prototype sessions)
- SN Leadership & Stakeholders
- SN IT (tech session participants)
- <TEAM_NAME> Team (Slalom) by function
-
Meeting details - date, duration (~90 min), format, presenters
-
Timed agenda table - one row per readout topic with time and presenter
-
Sessions covered - table of all sessions grouped by day, including ODR, Tech, and Prototype sessions
-
Key themes - 3-5 through-lines drawn from across all session types
-
Reference link to the readout deck
Suggested: Post-send checklist (not yet formalized - consider adding after first readout):
- Track RSVPs and follow up with key participants who haven't responded
- Collect pre-meeting questions or topics attendees want addressed
- Update the deck as final sessions complete (fill TBD sections)
- Confirm AV/room setup and screen-sharing logistics
- Do a dry run with the presenting team
Phase 3: Domain Readout Deck
Create at docs/discussions/{Domain}/odr/{Domain}-readout-deck.md.
The BK readout PDF (docs/discussions/Bankruptcy/odr/2026-02-23 BK Read Out.pdf) is a guide, not a rigid template.
Invite → Deck continuity: The meeting invite copy (Phase 2) sets the audience's expectations. The deck's opening slides must carry that same framing forward:
- Purpose slide expands the invite's "This readout will share..." sentence into what it delivers and what it does not
- Context slide expands the invite's opening paragraph (time, location, session types) into a visual timeline and journey positioning
- Audience slide makes explicit who was invited and what each group should take away
When drafting the deck's opening slides, re-read the finalized invite copy and ensure consistent language, scope, and tone. If the invite omits a topic (e.g., prototype demo), the deck should reflect that same scoping.
Recommended slide structure:
- Title
- Purpose - why this readout exists, what it delivers, what it does not do
- Context - where this fits in the <TEAM_NAME> journey, what happened, how it connects forward
- Audience - table mapping each audience segment to their specific takeaways
- Agenda (numbered topics)
- Schedule grid (days x time slots - includes ODR, Tech, and Prototype sessions)
- By the Numbers (sessions, participants, word count, hours)
- Who We Talked To (grouped by role/function)
- Our Prior Understanding (timeline of touchpoints with this domain)
- Day N Discussion summaries - findings and opportunities from ODR sessions and Prototype sessions grouped by day
- Witnessed Pain Points (manual process burden, system limitations, missing capabilities)
- Opportunities Identified - two views:
- By session: each Day N section includes opportunities surfaced in that session alongside findings
- Consolidated by role: a standalone slide grouping all opportunities by affected role (Cashiers, Asset Managers, IT, etc.) with type tags (Automation / Integration / Enhancement)
- Follow-up Conversations (grouped by team/function)
- Technical Discussions Overview - high-level from Tech sessions; full details go in the consolidated tech readout
- Prototype Demo (updated based on findings from all session types)
- Q&A
- End
Using the prototype demo PDF:
- Slide 9 (Our Prior Understanding): two sections - "What we knew going in" pulls the touchpoint timeline and "Our Understanding" callout facts from the prototype PDF; "What we learned this week" maps each prior understanding to what the sessions revealed was deeper, different, or newly surfaced. Each "learned" bullet should directly extend or challenge a "knew" bullet.
- Slide 10+ (Day N Discussions): add a Prototype Review section with the user journey flows validated, corrections surfaced, and key feedback from participants
- Working Notes: list the prototype PDF as a content source
Building the Opportunities slides:
- In Day N sections (by session): after each session's findings, add an "Opportunities" subsection listing opportunities surfaced in that session. Include the role(s) affected and type tag for each. This gives the audience session-level context for how the opportunity was identified.
- Consolidated slide (by role): build a table grouping all opportunities by affected role. Each row includes the opportunity description, type tag, and source session. This gives role-specific stakeholders a single view of what's relevant to them.
| Role | Opportunity | Type | Source Session |
|---|---|---|---|
| Cashiers | Auto-match claim-to-bucket via claim number + dropdown | Automation | Day 3 - Payment Posting |
| Cashiers | Smart multi-payment detection for delinquent loans | Enhancement | Day 3 - Payment Posting |
| IT | Stripe integration for small investor payments | Integration | Tech Session |
| Asset Managers | Bidirectional vendor portal replacing email follow-up | Integration | Day 2 - Sales & Bidding |
- When an opportunity affects multiple roles, list it under each affected role
- If a session surfaces no opportunities, note that explicitly to confirm it was reviewed
Key decisions from BK/FC experience:
- Purpose/Context/Audience slides up front set the frame
- Tech overview before prototype demo gives audience technical context
- Architecture omitted from domain readouts; belongs in the consolidated tech readout
- Populate from session summaries across all three types plus the prototype PDF; mark TBD for sessions not yet completed
- Include working notes section listing content sources and pending slides
Phase 4: Consolidated Tech Readout
Create at docs/discussions/Tech-Readout/tech-readout-deck.md. Single cross-domain deck covering technical findings from all domains' Tech sessions, plus any non-tech sessions with significant technical content.
Inventory: Scan all domain odr/ folders for -Tech-Session folders plus sessions with technical depth (e.g., FPI batch architecture).
Recommended slide structure:
- Title
- Purpose - why a separate tech readout
- Context - table of all tech sessions with dates, domains, participants
- Agenda
- Current Architecture Overview
- Cross-Domain Technical Themes
- Per-domain technical findings (one slide per domain)
- Integration Inventory (table with complexity ratings)
- Technical Opportunities (automation and integration opportunities requiring technical implementation, grouped by role and domain)
- Migration & Data Considerations
- Deferred Deep Dives (table with recommended follow-up format)
- Q&A
- End
Key principles:
- Do not repeat user workflow findings from domain readouts
- Do not propose <TEAM_NAME> architecture; capture current state and implications
- Flag integrations by complexity (Low/Medium/High/Critical)
- Deferred deep dives include recommended session format and participants
Phase 5: Follow-Up Planning
- Review all Implications documents across ODR, Tech, and Prototype sessions
- Group unresolved questions by team/person
- Review opportunity inventory for items that need further validation or scoping
- Propose next round targeting gaps and high-value opportunities
- Update the readout deck's follow-up slide and opportunities slide
Templates
Meeting Invite Copy
Follow this voice and structure, adapted from actual sent invites:
Paragraph 1 - Context: Open with time/location and who was involved. Address the audience directly ("with you", "your work"). Use past tense for the sessions ("sat with", "watched", "observed"). Name the session types (prototype review, observation, technical deep dives with SNSC IT).
Paragraph 2 - What we did: "We watched/observed how you do your work today -" followed by a list of specific domain activities. End with "This readout will share what we learned" plus how it connects forward (updated prototype, informs the build, shapes the approach). If multiple topics were combined for cross-team discussion, note that here.
Paragraph 3 - What the readout covers: Future tense. Walk through findings, highlight pain points witnessed firsthand, opportunities for automation and improvement, overview of technical topics, updated prototype demo. Close with follow-up topics and next steps.
Agenda highlights: Bulleted list - what we heard (domain-specific), pain points, opportunities identified, technical considerations, updated prototype demo, follow-up conversations and next steps.
Closing: "Please come prepared with questions or corrections" - optionally mention prototype feedback opportunity. End with "We want to confirm details have been captured accurately before we move into building <TEAM_NAME>."
> **{Domain} Readout**
>
> {Context: time in Eureka, who the <TEAM_NAME> team sat with, session types.}
> We watched/observed how you do your work today - {domain-specific activities}.
> This readout will share what we learned and {connection forward}.
>
> {The team will walk through findings from each session, highlight pain points
> witnessed firsthand, give an overview of the technical topics that surfaced,
> and provide an updated prototype demo.} We'll close with a discussion of
> follow-up topics and next steps.
>
> **Agenda highlights:**
>
> - What we heard from {domain participants}
> - Pain points witnessed in real time
> - Opportunities identified for automation and improvement
> - Technical integrations and considerations for <TEAM_NAME>
> - Updated prototype demo
> - Follow-up conversations and next steps
>
> Please come prepared with questions or corrections - there will also be an
> opportunity to provide feedback after using the updated prototype directly.
> We want to confirm details have been captured accurately before we move
> into building <TEAM_NAME>.
Suggested Invitees Block
**SN Servicing - {Domain} Operations** (session participants)
- {Name} ({Role})
**SN Servicing - Leadership & Stakeholders**
- {Name} ({Role or reason for inclusion})
**SN IT**
- {Name}
**<TEAM_NAME> Team (Slalom)**
- {Name} ({Function: Delivery, Design, Solution, Architecture})
Readout Agenda Table
| # | Topic | Time | Presenter |
|---|---|---|---|
| 1 | Purpose, Context & Audience | 5 min | {Lead} |
| 2 | {Domain} Week: Schedule & By the Numbers | 5 min | {Lead} |
| 3 | Who We Talked To & Our Prior Understanding | 5 min | {Lead} |
| 4 | Day 1 Findings: {Session Name} | X min | {Facilitator} |
| ... | ... | ... | ... |
| N | Witnessed Pain Points | 5 min | {Lead} |
| N+1 | Opportunities Identified | 5 min | {Lead} |
| N+2 | Technical Discussions Overview | 5 min | {Architect} |
| N+3 | Updated Prototype Demo | 10 min | {Designer} |
| N+4 | Follow-up Conversations & Next Steps | 5 min | {Lead} |
| N+5 | Q&A | open | All |
Checklist
Domain Readout:
- [ ] Inventory all processed sessions (ODR + Tech + Prototype)
- [ ] Classify sessions by type and read all summaries
- [ ] Extract opportunities from summaries and implications (by session, by role, with type tags)
- [ ] Confirm pre-drafting inputs: session schedule, terminology, combined vs. separate
- [ ] Draft meeting invite copy for calendar invite
- [ ] Review invite copy with delivery lead (tense, terms, scope)
- [ ] Finalize and send invite
- [ ] Build suggested invitee list (Operations, Leadership, IT, <TEAM_NAME>)
- [ ] Create readout meeting agenda with timed topics and presenters
- [ ] Create domain readout deck (Purpose/Context/Audience aligned to invite framing)
- [ ] Populate deck from ODR, Tech, and Prototype session summaries
- [ ] Add per-session opportunities to Day N slides
- [ ] Build consolidated Opportunities slide grouped by role with type tags
- [ ] Mark TBD sections for sessions not yet processed
- [ ] Post-processing: update deck as new session summaries arrive
- [ ] Identify follow-up gaps from all session types
- [ ] Flag opportunities needing further validation or scoping
Tech Readout (cross-domain):
- [ ] Scan all domain odr/ folders for Tech sessions
- [ ] Scan for non-tech sessions with significant technical content
- [ ] Read all tech session summaries
- [ ] Create tech readout deck with integration inventory
- [ ] Populate per-domain findings slides
- [ ] Build cross-domain themes from patterns across sessions
- [ ] Build Technical Opportunities slide (automation + integration, by role and domain)
- [ ] Catalog deferred deep dives with recommended follow-up
- [ ] Update after each new on-site period adds sessions