Finding and triaging bugs
Kinn can search feedback from all your connected sources for signs of a bug: crashes, error messages, broken workflows, and unexpected behavior. You decide what to investigate and when to create or update a ticket.
Start with a focused search
Give Kinn a useful time period or release:
- "What new bugs have users reported since version 2.1 shipped on Monday?"
- "Find reports of login failures from the past seven days."
- "Which crashes are mentioned on more than one platform this month?"
Kinn can bring similar reports together in its answer and show the supporting messages. Ask for source links before acting so you can review the evidence.
Save important release dates or known problems as notes. That context helps future bug searches distinguish a new regression from an issue your team already knows about.
Decide what to prioritize
A high message count is useful, but it is not the only signal. Ask Kinn to compare:
- How many distinct people reported the problem
- Whether it appears in more than one source
- How recently reports appeared
- Which versions, devices, or platforms are affected
- Whether reports include repeatable steps or error messages
Treat Kinn's summary as a starting point. It reflects only the feedback sources you connected and may not represent every user.
Check your tracker
With GitHub connected, Kinn can compare the feedback with indexed issues, pull requests, and discussions.
With Jira connected, ask Kinn to search Jira live:
- "Does this crash match an open Jira issue?"
- "Search for duplicates of this login problem before we create anything."
Create or update a Jira issue
Kinn changes Jira only when you ask. A good request names the project and asks for evidence:
Create a Bug in the GAME project for this login crash. Include a concise summary, affected platforms, and links to the supporting feedback.
If an issue already exists, ask Kinn to add the new evidence as a comment or update specific fields. Always check the issue key Kinn returns.