Inspiration
After countless sprint planning meetings, I found myself spending 8+ minutes after each meeting manually creating Jira issues from action items buried in transcripts. My team was doing the same—wasting 6+ hours per month on this repetitive task.
I realized that while tools like Fireflies and Otter transcribe meetings beautifully, they stop short of actually creating the work. There's a gap between "here's what was discussed" and "here's the Jira issue to track it."
SprintScribe AI was born from the frustration of losing context between meetings and Jira. I wanted to close that loop - to make every action item from a meeting instantly trackable, with full traceability back to where it was discussed. The "pit crew" metaphor came naturally: meetings are like race cars, and someone needs to quickly extract what matters and turn it into actionable work.
What it does
SprintScribe AI transforms meeting transcripts into actionable Jira issues in 15 seconds (vs 8 minutes manually). Here's the workflow:
- Paste Transcript → User pastes meeting transcript from Zoom, Teams, or manual notes
- AI Analysis → "Analyze with AI" button extracts:
- Action items with owners and due dates
- Decisions and agreements
- Suggestions and insights
- Confidence levels (High/Medium/Low badges)
- Review & Edit → User can edit owners, due dates before creating issues
- One-Click Creation → Batch creates Jira issues with:
- Auto-assigned owners (when names match Jira users)
- Due dates
- Enriched descriptions (meeting summary + source link)
- Full Traceability → Every Jira issue links back to Confluence page
Key Features:
- Enhanced AI extraction handles real-world formats (timestamps like
[00:12:34], speaker names) - Time saved counter shows quantified impact: "⏱️ 12.0 minutes saved"
- Production-grade safeguards (idempotency protection prevents duplicate issues)
- Rovo Agent support for hands-free automation via chat
Result: 97% time reduction with complete traceability. Teams save 6+ hours per month.
How I built it
I built SprintScribe AI entirely on Atlassian Forge, using a clean architecture:
Frontend:
- React via
@forge/reactUI Kit for the Confluence macro - Custom UI with state management for transcript analysis and issue creation
- Real-time feedback (loading states, success messages, error handling)
Backend:
- Node.js 24.x Forge Functions
- Multiple resolvers in
src/index.js:analyzeTranscript- Basic regex-based extractionanalyzeWithAI- Enhanced extraction with timestamp/speaker parsingcreateJiraIssuesFromActionItems- Batch Jira issue creationgenerateSummary- Meeting summary generation
- Rovo Agent handler in
src/pitcrewRun.js:- Idempotency check (MD5 hashing prevents duplicates)
- Rich response object (URLs, metrics, summary statistics)
- Confluence page updates with ADF formatting
Storage:
- Forge Storage API with per-page scoping (
sprintscrbe:${contentId}:*) - Prevents cross-tenant data leakage
- Persists analysis results, meeting summaries, and created issue keys
APIs:
- Jira REST API via Forge
routetemplate literals - Confluence API v2 for page updates
- All authenticated via
api.asUser()for security
Key Technical Decisions:
- Used enhanced pattern matching for real-world transcripts (not just formatted demos)
- Implemented idempotency protection early (prevents costly mistakes)
- Built dual workflow (macro UI + Rovo Agent) sharing same backend logic
- Added time saved counter for quantified value demonstration
Challenges I ran into
1. Real-World Transcript Parsing
The biggest challenge was handling actual Zoom/Teams transcripts with timestamps and speaker names. My initial regex patterns worked great for formatted demos but failed on real transcripts like [00:12:34] Sarah: Action: Refactor auth. I had to build enhanced pattern matching that:
- Extracts timestamps in multiple formats
- Maps speaker names to action item owners
- Handles natural language (not just "Action:" prefixes)
2. Idempotency Protection I realized early that users might accidentally process the same transcript twice, creating duplicate Jira issues. I implemented MD5 hashing to detect already-processed transcripts, but had to balance preventing duplicates with allowing legitimate re-processing. The solution: store transcript hash after successful processing, but allow users to reset if needed.
3. Confluence URL Construction
Getting the correct Confluence page URL for Jira issue descriptions was tricky. Forge provides context, but sometimes it's a CDN URL with _hostname_ patterns. I had to build robust URL extraction that:
- Handles CDN URLs
- Falls back to API calls if context is missing
- Constructs valid URLs without space keys (which require API lookups)
4. Rovo Agent Integration Integrating the Rovo Agent required understanding the action payload format and ensuring the agent's JSON output was properly structured. I had to add extensive error handling for malformed JSON and validate all required fields before processing.
5. Time Saved Calculation I wanted to show quantified value, but calculating "time saved" required assumptions. I settled on 1.5 minutes per issue (vs 90 seconds manual creation), which is conservative but defensible.
Accomplishments that I'm proud of
1. Production-Grade Rovo Agent Implementation I'm most proud of the Rovo Agent implementation. It includes:
- Idempotency protection (prevents duplicate issues) - something most submissions won't have
- Rich response object with URLs, metrics, and summary statistics
- Comprehensive error handling for partial failures
- Automatic Confluence page updates with proper ADF formatting
This shows engineering maturity beyond a typical hackathon project.
2. Real-World Transcript Support Building enhanced extraction that handles actual Zoom/Teams transcripts (not just formatted demos) was a significant accomplishment. The timestamp/speaker parsing makes SprintScribe actually usable by real teams, not just for demos.
3. Full Traceability The bidirectional linking between Jira and Confluence is unique. Every Jira issue includes a clickable source link, and Confluence pages show created issues. This closes the loop between discussion and execution - something no competitor offers.
4. Code Quality I'm proud that the codebase is production-ready:
- 0 linter errors
- Comprehensive error handling
- Input validation throughout
- Security best practices (no secrets, proper authentication)
- Clean, maintainable architecture
5. Time Saved Counter The simple addition of a time saved counter makes the value proposition immediately clear. Every demo now shows quantified impact, which is more compelling than feature lists.
6. Dual Workflow Building both macro UI and Rovo Agent that share the same backend logic was challenging but rewarding. It gives users flexibility while maintaining code consistency.
What I learned
1. Forge Platform Deep Dive This project taught me the full Forge stack:
- Custom UI with React and UI Kit components
- Forge Functions and resolvers
- Storage API with proper scoping
- Rovo Agent integration (cutting-edge feature)
- Product API integration (Jira and Confluence)
2. Production-Grade Engineering I learned the importance of:
- Idempotency protection (prevents costly mistakes)
- Rich response objects (better observability)
- Comprehensive error handling (graceful degradation)
- Input validation (security and reliability)
3. Real-World vs Demo There's a huge gap between "works in demo" and "works with real data." Building enhanced pattern matching for actual transcripts taught me to test with real-world inputs early.
4. User Experience Matters The time saved counter was a simple addition but makes a huge difference in how judges/users perceive value. Quantified impact is more compelling than feature lists.
5. Rovo Agent Best Practices Working with Rovo Agents taught me:
- How to structure prompts for reliable extraction
- Action payload validation and error handling
- Rich response objects for better user experience
- Idempotency patterns for agent actions
6. Balancing Features vs Time As a solo developer, I had to prioritize. I focused on:
- Core workflow (macro UI) - 80% of value
- Rovo Agent - bonus feature, but well-implemented
- Production-grade safeguards - differentiator
This taught me to build depth in core features rather than breadth of features.
What's next for SprintScribe AI
Short-Term (Next 1-2 Months):
- Live Meeting Integration: Add webhooks for Zoom and Microsoft Teams to automatically capture transcripts
- Multi-Project Support: Allow creating issues across multiple Jira projects in one batch
- Advanced User Matching: Improve owner detection with fuzzy matching and suggestions
- Analytics Dashboard: Show metrics like "meetings processed," "issues created," "time saved" over time
Medium-Term (3-6 Months):
- Meeting Templates: Pre-configured templates for standups, retros, planning meetings
- Export Capabilities: Export analysis results to CSV, PDF, or other formats
- Integration with Macro UI: Allow triggering Rovo Agent directly from macro UI
- Bulk Edit: Select multiple action items and edit owners/due dates in bulk
Long-Term (6+ Months):
- True LLM Integration: Replace pattern matching with actual LLM calls for better extraction
- Meeting Platform Native Apps: Direct integrations with Zoom, Teams as native apps
- Team Workspaces: Shared workspaces for teams with collaboration features
- Marketplace Listing: Publish to Atlassian Marketplace for broader adoption
Open Source Considerations:
- Consider open-sourcing if there's community interest
- Build plugin architecture for custom extractors
- Community-driven transcript format support
The foundation is solid - production-ready code, clear value proposition, and real-world usability. The next steps are about scale and reach.
Log in or sign up for Devpost to join the conversation.