From Interviews to Linear and GitHub Issues
UserTold.ai turns interviews into evidence review packets that can become Linear or GitHub work after a project-aware review, without losing the user context that justified the work.
The goal is not to auto-file generic tickets. UserTold groups related evidence for review; a human or agent with project context verifies the packet and decides whether it is delivery work. When a packet is promoted, the title says the problem, the body carries the evidence, and the links point back to the source interviews.
The handoff path
- Run interviews against a specific study.
- Extract evidence from transcripts and observed behavior.
- Review or filter evidence by type, confidence, interview, or target work item.
- Group one or more evidence cards into an evidence review packet.
- Verify the packet against source context and current project knowledge.
- Promote it to delivery work only when the reviewed packet is action-ready.
- Push the work item to Linear or GitHub when it is ready for delivery.
Each step keeps the evidence attached. A review packet is not just a summary; it is connected to the quotes and moments that created it. A delivery issue should only exist after that packet has been verified.
What the review packet should contain
A useful packet should answer these questions before delivery handoff:
| Question | Evidence source |
|---|---|
| What user problem happened? | Evidence card title and type |
| Who experienced it and where? | Interview metadata and page context |
| What did the user say or do? | Quote, timestamp, and timeline events |
| Why do these cards belong together? | Grouping rationale and uncertainty notes |
| Has project context confirmed this should be work? | Human or agent verification decision |
| What happens after delivery? | Linear completion sync, resolved evidence, and recurrence watch |
That makes the promoted issue usable by a human engineer, a product lead, or a coding agent.
Example work item body
## Problem
New users do not understand which provider key is required during setup.
## Review packet
Status: Verified for delivery
Decision: Promote to Linear because setup-key confusion blocks activation for the current onboarding project.
## Evidence
- Interview `ses_123`: "I do not know which key this wants."
- Page: `/settings/integrations`
- Behavior: opened docs twice, returned to the same field, changed the key scope, then abandoned setup.
## Delivery direction
Add provider-specific key requirements and a connection test before saving.
## Verification
When the Linear issue is completed, resolve the linked setup-key evidence and watch future interviews for similar struggling moments that may resurface.
This is the kind of issue that can be routed to Linear or GitHub without burying the original research.
Linear and GitHub usage
UserTold supports tracker handoff from the app and automation surfaces. Teams can review packets first, then push the promoted work item when it has enough verified evidence.
Use Linear when the team already plans and prioritizes product work there. Use GitHub Issues when engineering work lives closer to the repo. For Linear handoff, keep the UserTold work item linked so source evidence stays attached, completion can resolve the current evidence, and future similar evidence can be reviewed as recurrence.
Agent-friendly workflow
For agentic delivery, the important property is inspectability. A coding agent should be able to see:
- the problem statement
- linked evidence quotes
- interview or playback references
- the intended product area
- the human or agent verification decision that promoted the packet
- the verification criterion
That reduces the chance that an agent ships a plausible but ungrounded fix.
Qualified next step
Use this flow when you already have interview evidence and need to decide what work should enter the delivery queue. For the underlying research model, read agentic user research. For automation details, use the MCP integration or CLI reference.