AICHE +Github Integration

The short answer: open a GitHub pull request, issue, or review comment field in your browser, press ⌃+⌥+R (Mac) or Ctrl+Alt+R (Windows/Linux), speak for 30-60 seconds, and AICHE inserts formatted text at your cursor.

GitHub is where code gets discussed. Pull request descriptions, code review comments, issue reports, Discussion threads, Wiki edits. Every one of these is a text field where the quality of what you write directly affects how well your team collaborates. A PR description with context helps reviewers understand intent. A detailed issue report prevents back-and-forth clarification. A thorough code review comment teaches instead of just criticizing.

Developers know this. They still write "fixed bug" in commit messages and "LGTM" in code reviews, because typing thoughtful prose feels slow when there are 12 more PRs to review before standup. Voice changes the math. Speaking a detailed explanation takes 30 seconds. Typing it takes 3 minutes. At 30 seconds per comment, thorough reviews become practical.

1. Open GitHub in your browser and navigate to a pull request, issue, or Discussion.
2. Click into the text field - PR description, review comment, issue body, or Discussion reply.
3. Press ⌃+⌥+R (Mac) or Ctrl+Alt+R (Windows/Linux) to start recording.
4. Speak your content: what changed and why, what the issue is, or what your feedback is.
5. Press the hotkey again. AICHE transcribes and inserts the text.
6. Add markdown formatting - headers, code blocks, bullet lists, task checklists, and links.
7. Preview the rendered markdown before submitting.

Heads-up: GitHub text fields support markdown. AICHE inserts plain text, so you add formatting manually after dictation. For PR descriptions, enable Content Organization in AICHE settings to get auto-structured paragraphs that map well to markdown sections.

Pull Request Descriptions

Writing Context-Rich PRs

A good PR description answers three questions: what changed, why it changed, and how to verify it works. Most developers only cover the first question, if that.

Click into the PR description field, press your hotkey, and speak through all three. Start with the motivation: what problem exists, who it affects, and why it matters now. Then describe the approach: what you changed, what alternatives you considered, and why you chose this path. Finish with testing: what you tested manually, what the automated tests cover, and what edge cases a reviewer should look at.

That takes 60 seconds to speak. Enable Content Organization, and AICHE structures it into clear paragraphs. Add markdown headers (## What, ## Why, ## Testing) to break it into sections, and you have a PR description that reviewers can work with efficiently.

Draft PR Descriptions

Open a draft PR early and dictate the initial description while the approach is fresh. Update it as the implementation progresses. By the time you mark the PR as ready for review, the description is already complete, because you built it incrementally through voice instead of writing it all at the end.

Code Review Comments

Inline Review Feedback

GitHub's code review interface lets you comment on specific lines. Click the plus icon next to a line of code, and the comment field appears. Press your hotkey and speak your feedback.

The difference between useful and useless code review is context. "This could be better" is useless. "This uses a linear scan which works for the current dataset of 200 items, but the product roadmap targets 50,000 items by Q3, and at that scale this will add 800ms to the response time. Consider using a hash map lookup or adding a database index on this field" is useful. The second comment takes 15 seconds to speak and over a minute to type. Most reviewers type the first version because the second feels like too much effort.

Suggesting Alternatives

When you suggest a different approach in a review, explain the reasoning. Press the hotkey and say "instead of catching the generic exception here, consider catching only the specific exceptions that the database client throws, like ConnectionTimeoutException and QueryFailedException. The generic catch hides unexpected errors like NullPointerException, which should bubble up to the error monitoring rather than being silently handled." Specific suggestions with reasoning are actionable. Vague disapproval is not.

Issue Reports

Bug Reports with Reproduction Steps

Click "New Issue" on a GitHub repository, choose the Bug Report template if available, and dictate into each section. For the reproduction steps, speak through exactly what you did: "go to the settings page, click the notifications tab, toggle the email notifications switch to off, click save, refresh the page, and the switch shows as on again even though the database correctly stores the off value."

Reproduction steps spoken as you mentally replay the scenario are more accurate than steps typed from memory minutes later. Enable Content Organization, and AICHE structures your spoken walkthrough into numbered steps.

Feature Requests

Feature requests need context beyond "add feature X." Click into the issue body, press your hotkey, and speak: what problem you face, what you currently do as a workaround, what you would like the feature to do, and what constraints or edge cases you are aware of. This level of detail helps maintainers evaluate and prioritize the request.

Discussion Answers

GitHub Discussions is where community questions get answered. Click "Comment" on a Discussion, press your hotkey, and dictate a thorough answer. Explain the concept, provide the specific steps, mention common pitfalls, and link to relevant documentation.

Thoughtful Discussion answers get upvoted and help future visitors. Most answers are terse because typing detailed explanations feels disproportionate to the effort. Speaking a comprehensive answer takes the same amount of time as typing a brief one.

GitHub-Specific Tips

• Works in browser. AICHE works with GitHub in any browser - Chrome, Firefox, Safari, Edge. It inserts text wherever your cursor is, including GitHub's text editor fields.
• Wiki editing. GitHub Wiki pages are markdown files. Open the wiki editor, press your hotkey, and dictate entire documentation pages. This is the fastest way to create project wikis from scratch.
• Commit messages in terminal. For commit messages via git in the terminal, type git commit, let your default editor open, press ⌃+⌥+R, and dictate the full message. Works with vim, nano, or any editor configured as your git editor.
• GitHub Actions annotations. When documenting GitHub Actions workflow files, dictate comments explaining what each step does and why. Workflow YAML with comments is dramatically easier to maintain than uncommented workflows.

The pro-tip: Before reviewing a PR, read the diff first. Then start your review and dictate comments while scanning through the code a second time. The first read builds understanding; the second read, with voice, captures your feedback efficiently.

Result: PR descriptions with context that reviewers can work with. Code review comments that teach and explain instead of just flagging. Issue reports with reproduction steps that maintainers can actually follow. The collaboration quality that GitHub was designed to support, actually delivered.

Do this now: Open a GitHub PR you need to review, click the "Review changes" button, press your hotkey on the first file that needs feedback, and dictate what you think about the approach.