How to file a GitHub issue by texting a crash log

To file a GitHub issue by texting a crash log, send the relevant, redacted log to an assistant with an authorized GitHub connection, name the repository and ask it to prepare and submit a bug report. The report should include reproduction steps, expected and actual behavior, environment details and the original error. Set whether you want a draft first. The assistant should return the created issue URL only after GitHub confirms creation.

Original generated illustration. The crash, reproducer and issue draft below are downloadable.

What does the finished issue look like?

We created a tiny fictional application example called TrailNotes, ran it and captured a real JavaScript exception. Calling formatTitle({ title: null }) produced:

fixture=TrailNotes-demo-1; input={"title":null}
runtime=v26.3.1; platform=darwin
TypeError: Cannot read properties of null (reading 'trim')
    at formatTitle (reproduce-crash.mjs:4:21)

The application name and input are illustrative. The exception and runtime output are from the actual local execution. No production app, personal message or user's device log was accessed.

The resulting issue title is “Handle null note titles without a TypeError.” Its body separates the observed failure from a product decision: should a missing title become “Untitled,” or should the input be rejected? A crash log cannot decide that requirement for the team.

Open the finished issue body, JSON issue payload and actual crash log. The reproducer and run instructions let you trigger the same failure. This article stops at a reviewable draft; it did not create a GitHub issue.

What should you text your assistant?

A useful request gives the assistant both the evidence and the destination:

Draft a bug report for OWNER/REPO from this crash log. I was opening a note with a missing title. Include the error, relevant stack frames, reproduction steps, expected versus actual behavior and known environment details. Mark anything missing. Check for an existing issue with the same failure. Show me the draft before posting, and do not include credentials, personal data or the full raw log.

Replace OWNER/REPO and describe what you actually did. For a mobile crash, include the app version, operating-system version and device model if known. For a web failure, browser version and the affected action may be more useful. A Node.js runtime from our fixture would not establish any of those mobile details.

If you already have a standing policy allowing the assistant to file bugs in a particular repository, state that scope. A new repository, a public issue or an attachment containing private information can require a different decision.

How does the log become an issue?

The assistant should extract the exception and useful stack frames, then connect them to a reproducible action. It should preserve the difference between what was observed and what it infers.

Evidence	What it establishes
Exception message	The operation that failed
Relevant stack frame	Where the exception surfaced
Input and reproduction steps	How to try the same failure
Runtime or build identifier	The environment actually recorded
Proposed fix	A hypothesis until tested

In our fixture, the source directly calls .trim() on a null title, so the local failure is straightforward to reproduce. In a real app, the earlier question could be why a null title reached that function. Avoid jumping from one stack frame to “the database is broken.”

Search the repository for the exception and affected component before opening a duplicate. If a matching report exists, return its link and explain the overlap. Adding a comment is another write action and should follow the user's authorization.

How do you review and submit it to GitHub?

GitHub repositories may use issue templates or forms, so fit the evidence to the destination's fields. GitHub's issue-creation guide explains the repository workflow and available entry points. Creating an issue.

For an assistant with an authenticated GitHub CLI environment, this command opens a prefilled browser review:

gh issue create --repo OWNER/REPO \
  --title "Handle null note titles without a TypeError" \
  --body-file issue.md --web

This is an example command, not a submission made for this article. --body-file reads the prepared body, while --web opens the issue-creation flow in the browser. GitHub CLI reference.

After an authorized submission, capture the returned issue number and URL. If a request times out, check whether the issue exists before retrying. A lost response does not necessarily mean the first write failed.

How would Instinct × Vaaya handle this?

With Instinct on WhatsApp or iMessage, a text and attached log can be the starting point. Where the setup has an authorized GitHub integration, the assistant can prepare the report and carry out the permitted submission. Vaaya can supply external compute or document processing when the task needs it; connecting Vaaya alone does not authorize a write to a GitHub repository.

Our example needed only local Node.js execution and an authored issue draft. It did not require a paid service or a live chat integration. For a larger workflow, the valuable return message is still concrete: the draft to review, or the verified GitHub issue link, plus any missing evidence the team should collect.

If another assistant reviews the draft, keep that review bounded. Our two-assistant demonstration shows why an additional model's verdict is useful evidence, but does not replace a reproducible check.

Questions

Can I create a GitHub issue by texting an AI assistant?

Yes, if the assistant can receive the log and has an authorized GitHub integration or CLI environment. It should identify the destination repository, prepare the issue, check for duplicates and submit only within the permissions you gave it.

What should a crash-log issue include?

Include a specific title, what the user was doing, reproduction steps, expected and actual behavior, the relevant error and stack frames, and known environment details. Mark missing information and distinguish a suspected cause from a verified cause.

Should I send the entire crash log?

Share the smallest relevant excerpt after checking for credentials, session tokens, personal data and private URLs. Keep useful error messages and source locations. An assistant cannot guarantee that every secret was removed automatically.

Did this article create a real GitHub issue?

No. It reproduces a real TypeError in a fictional local fixture and provides a finished issue draft and JSON payload. No issue was posted to a repository.

Does a stack trace prove the root cause?

It identifies where an error surfaced. A small reproducer can verify a local failure, but the cause in a production application may involve earlier input handling or other code. Keep hypotheses separate from established evidence.