I’ve never submitted a pull request to an open source project before.

It’s one of those things that always felt like it was for other people — people who know the codebase, who understand the contributing guidelines, who won’t embarrass themselves with a bad PR. I’ve wanted to contribute for years. I just never did.

Yesterday I forked a repo, added three tools, and opened a PR in about 30 minutes. Most of that time was setting up Claude to interact with GitHub so we can do this more easily next time.

The Gap

I’ve been using the mcp-discord MCP server to give my AI agents access to Discord — reading messages, creating forum posts, managing channels. It works well for what it does.

We use Discord forum channels for task tracking. One post per task, tags for status like “In-Progress”, “Done”, etc. The existing tools let you create posts and reply, but there was no way to:

  • See what tags are available in a forum
  • Update a post’s tags, title, or archive status after creation
  • Edit a message the bot already sent

I’d been working around these limitations for days. Then I realized I could just… fix it.

What AI Changes About Contributing

The intimidating parts of open source contribution used to be:

  • Understanding the codebase — How is it structured? What patterns does it follow? Where do I put new code?
  • Getting the implementation right — Will my code match the project’s style? Am I handling edge cases?
  • The PR itself — Is my description good enough? Did I miss something obvious?

Claude handled all of this. I pointed it at the repo, described what I needed, and it:

  1. Analyzed the codebase structure and existing patterns
  2. Identified exactly which files needed changes (schemas, handlers, tool definitions, routing)
  3. Wrote the implementation following the project’s conventions
  4. Helped write the PR description with a testing matrix

The actual coding took maybe 10 minutes. The rest was GitHub setup — forking, creating a feature branch, configuring gh CLI authentication. Infrastructure work that only needs to happen once.

The Contribution

Three new tools, about 250 lines:

discord_get_forum_tags — Returns all available tags for a forum channel. Without this, you’re guessing at tag names.

discord_update_forum_post — Modifies an existing forum post: rename it, change tags, archive/unarchive, lock/unlock. Tags can be specified by name or ID.

discord_edit_message — Edits a message the bot previously sent. Includes an ownership check so you can’t edit other users’ messages.

PR #24 is up and waiting on maintainer review.

The Bug I Caught Before the Maintainer Did

After the first commit, I manually tested all the happy paths — creating tags, updating posts, editing messages. Everything worked. That would have been a reasonable stopping point.

But I asked Claude to think about edge cases — things a reviewer might call out, things we might have missed on the first pass. Claude ran through a bunch of scenarios: invalid tag names, empty arrays, editing non-bot messages, tag lookup by ID vs name. That’s when it found the silent failure bug.

The initial implementation silently dropped invalid tag names. Pass ["Done", "Typo"] and it would apply “Done” and quietly ignore “Typo” without telling you. Not a crash, not an error — just silent wrong behavior. The kind of thing that would absolutely get flagged in a code review.

The fix went into a second commit: validate all tags upfront, return an error listing the invalid ones and all available alternatives. That testing matrix ended up in the PR description too, which shows the maintainer exactly what was covered.

This is a good pattern for working with AI: after the first pass works, explicitly prompt it to think about what it might have missed, what a reviewer would flag, what edge cases could bite you. The happy path is easy. The edge cases are where PRs get sent back.

What Changed

Contributing to open source always felt like a skill barrier. Turns out it was more of an anxiety barrier. The actual work — understanding a codebase, following its patterns, writing clean code — is exactly what AI is good at.

I’m not saying AI wrote the PR and I just clicked buttons. I identified the need, made the design decisions (tag lookup by name or ID, ownership validation on edits, explicit error messages for invalid inputs), and reviewed everything before submitting. But the parts that used to paralyze me — “am I doing this right? does this match the project’s style?” — those are answered in seconds now.

I’ll be doing this more often.

If you’ve been putting off contributing to an open source project because it feels intimidating, try bringing AI along. The barrier is lower than you think.