AICHE +Github Projects Integration

The short answer: open a GitHub issue or project item, click into the description or comment field, press ⌃+⌥+R (Mac) or Ctrl+Alt+R (Windows/Linux), speak for 40-60 seconds, and AICHE inserts the formatted text at your cursor.

GitHub Projects connects planning directly to code. Issues become the specs that developers implement. Pull request descriptions explain what changed and why. Discussion comments capture design decisions. The quality of these written artifacts determines how smoothly development runs. A well-written issue with acceptance criteria, technical context, and edge cases gets implemented correctly on the first try. A vague issue generates a PR that misses the point and requires rework. The bottleneck is writing time. Detailed issues take 10-15 minutes to type, so most issues get a title and maybe a sentence. Voice captures the full technical picture in under a minute.

1. Open GitHub in your browser and navigate to your repository's Issues or Projects tab.
2. Click "New Issue" or open an existing issue. For project items, click the item to expand it.
3. Click into the description field (for new issues) or the comment field (for updates).
4. Press your AICHE hotkey (⌃+⌥+R on Mac, Ctrl+Alt+R on Windows/Linux) to start recording.
5. Speak the full context: what the issue is, how to reproduce it (for bugs), what the expected behavior is, what technical approach you'd suggest, and what the acceptance criteria are.
6. Press the hotkey again. AICHE transcribes your speech and inserts it into the text field.
7. Add labels, assignees, milestones, and project fields using GitHub's sidebar. Apply markdown formatting if needed.

Writing Issues That Become Implementation Specs

On GitHub, an issue description is often the closest thing to a technical spec that exists. The developer assigned to the issue reads the description, looks at the linked code, and starts building. If the description says "add caching to the API," the developer has to decide which endpoints, what cache duration, what invalidation strategy, and what the performance target is. If the description covers all of that, the developer builds exactly what's needed. Voice captures this level of detail naturally. Press your hotkey and speak through the issue as if you're explaining it to the developer in person: "We need to add Redis caching to the product catalog endpoint. Current response time is 800ms and the target is under 200ms. Cache TTL should be 5 minutes with cache-aside pattern. Invalidate on product updates via the existing webhook. Only cache for authenticated users since anonymous results vary by region. The catalog endpoint handles about 50,000 requests per hour so this will significantly reduce database load." That's 25 seconds of speaking for a description that takes 8 minutes to type.

Pull Request Descriptions

PR descriptions are the second most important text artifact on GitHub. A good PR description explains what changed, why it changed, how to test it, and what to watch out for during review. Most PRs ship with auto-generated commit lists and nothing else, which forces reviewers to read every line of code without context. Voice makes writing a proper PR description take less time than it takes to open the PR page. Before you click "Create pull request," press your hotkey in the description field and speak: "This PR adds rate limiting to the authentication endpoints. We were seeing credential stuffing attacks hitting the login endpoint at 500 requests per second from single IPs. Added a sliding window rate limiter using Redis, configured at 10 attempts per IP per 15-minute window. Returns 429 with a Retry-After header. Added integration tests for the rate limiting middleware. Reviewers should check the Redis key expiration logic in auth-middleware.ts." That's a 20-second dictation. The reviewer now knows exactly what to look for.

Discussion Comments and Milestone Planning

GitHub Discussions and milestone descriptions are where project-level planning happens. Milestones need descriptions that explain the scope and goals of a release. Discussions capture architecture decisions, RFC feedback, and design proposals. These tend to be longer-form writing that nobody prioritizes. Voice makes them practical to write. Open a milestone, press your hotkey, and dictate the release goals, the key features included, and the quality bar for shipping. Open a Discussion, press your hotkey, and dictate your proposal or feedback. Content Organization in AICHE settings structures your spoken thoughts into clear sections, which is especially useful for technical proposals that cover multiple components.

Heads-up: GitHub renders markdown in all text fields. AICHE inserts plain text by default. After dictation, add markdown syntax for code blocks (triple backticks), headers, and lists. If you frequently reference code in issues, dictate the context first, then manually add code snippets or links to specific files.

Pro tip: when dictating a bug report, speak while you're looking at the error. Describe what you see on screen, what you clicked, and what the console or logs show. This captures reproduction steps naturally because you're narrating the actual behavior instead of reconstructing it from memory.

Result: issues ship with full acceptance criteria and technical context, PR descriptions give reviewers the information they need, and project documentation gets written because speaking a milestone description takes two minutes instead of twenty.

Do this now: open a GitHub issue in your project, click into the description or comment field, press your hotkey, and dictate the full technical context including reproduction steps, expected behavior, and suggested approach.