My First Open Source Contributions: Shipping to Impeccable

For a long time open source felt like something other people did. I read the issues, I cloned the repos, I studied the code, but I never actually pressed the button. The gap between using a tool and contributing to it always felt larger than it was.

What changed was a project called Impeccable. It is a design-quality skill that AI coding agents load to stop generating slop interfaces: italic-serif heroes, eyebrow chip labels, the whole library of 2025 marketing-page tells. I had been using it through Claude Code and noticed two things. First, it was solving a real problem I cared about. Second, the codebase was small enough to actually understand in a sitting. That combination made the leap feel possible instead of theoretical.

I gave myself a rule: do not pick a tiny typo issue, do not lurk for weeks, just find a real gap and ship the fix.

Impeccable lives at github.com/pbakaus/impeccable. About 25k stars, Apache-2.0, maintained by Paul Bakaus and a small group of contributors. The architecture is clean: a transformer pipeline that maps a single skill source tree to thirteen different AI harnesses (Claude Code, Cursor, Codex, Gemini, OpenCode, and more), plus a programmatic detector that scans rendered HTML for known anti-patterns.

Two things drew me in. The provider system was modular and additive: adding support for a new AI tool meant touching a registry, a transformer, and a directory map, not rewriting the world. And the detector was a pure-function design with browser and jsdom adapters wired into the same scanning loop, so adding a new rule was a matter of writing the check function and a fixture, not learning a framework.

The first contribution was a feature request that had been sitting open as issue #76: support Qoder, a new AI coding tool that ships its skills as Agent Skills at .qoder/skills/{name}/SKILL.md with slash-command invocation. Qoder fit the existing transformer model exactly. It just was not wired in.

The change was additive. I added qoder to PROVIDER_PLACEHOLDERS in scripts/lib/utils.js, registered a provider entry in scripts/lib/transformers/providers.js with the right configDir and frontmatter fields, exported a transformQoder, and extended PROVIDER_DIRS in bin/commands/skills.mjs so that the npx impeccable skills install flow detected existing Qoder installs. Then the documentation cascade: HARNESSES.md tables, DEVELOP.md reference, README install snippet, GitHub issue and PR templates.

Filed as PR #120 on April 28, 2026. Five commits, +15,426 / −22 lines (most of that is the committed .qoder/skills/impeccable/ build artifact tree). Cursor Bot flagged two issues during review (provider regex normalization and CRLF line ending handling), both of which I addressed in follow-up commits. Paul approved the next day with: "Looks good, thank you!" Merged April 29.

The second contribution was meatier. Issue #127 called for two new anti-pattern detection rules covering structural tells common in late-2025/early-2026 AI-generated marketing pages: oversized italic-serif fonts (Fraunces, Recoleta, Newsreader, Playfair, Cormorant, Tiempos) used as the primary h1, and the eyebrow-chip pattern, a tiny uppercase letter-spaced label sitting above a hero h1, sometimes as a pill chip.

I followed the existing icon-tile-stack pattern as a template. A KNOWN_SERIF_FONTS constant. Two ANTIPATTERNS entries. Pure check functions: checkItalicSerif, checkHeroEyebrow, with a resolveSerif helper. Two browser DOM adapters and two jsdom adapters wired into both element scanning loops: one branch for the IS_BROWSER path, one for the detectHtml(...) path. Two HTML fixtures with four flag cases and six pass cases each, in the two-column layout the repo conventionally uses.

Filed as PR #129 on April 30, 2026. Four commits, +838 / −20 lines, head SHA 444e4ac. Paul's review was warm but corrective: he merged in latest main, removed the typography.md and critique.md skill-file additions because they were too verbose, and left a note that the rule would flag Impeccable's own branding, which he was OK with, because there will always be legitimate reasons to use italic. Merged May 2.

The moment the work felt real was when Paul shipped Impeccable v3.0.7 and posted the release tweet on X. The post called out the new italic-serif and eyebrow-chip detectors and tagged @PokharkarVinay directly. A small thing, mechanically. A big thing, motivationally.

Twenty-five likes, four replies, a public co-credit on a release for a tool I respect. That is the loop that closes. Not the merge button, not the green check, but seeing your work shipped to the people who use the project and being named when it ships.

Reading code matters more than writing code. Both PRs followed existing patterns more than they invented anything. The hard part was finding the seam (which file to touch, which loop to extend, which test fixture format to mirror), not typing the change. The contributors who move fast are the ones who can hold a codebase's shape in their head before they edit it.

Specificity in a PR description does the heavy lifting. The Implementation Map table I included in #129 (file, change, line range) made review almost mechanical for Paul. He could verify intent without re-reading every diff hunk. Anywhere a reviewer has to reconstruct your reasoning is a place you should have written it down.

Maintainer feedback is data, not judgment. Cursor Bot's regex and CRLF flags on #120 were correct. Paul's removal of the verbose skill-file sections on #129 was correct. The right reflex is to thank, fix, and move. Not defend.

Two more issues in Impeccable have my eye: a fixture-format normalization pass and a detector for nested glassmorphism stacks. I am also looking at smaller tooling gaps in projects I depend on day-to-day. The activation barrier is gone. Now it is just picking the next problem worth solving.

If you are the version of me from three months ago, the practical advice is short. Pick a project you actually use. Read its open issues. Find one labeled good-first-issue or one that maps to a pattern you can already see in the codebase. Then ship it. The first PR is a meaningful threshold; the second one is just Tuesday.