# pr-maneiro: a Chrome extension that comments on pull requests as a Brazilian celebrity

> pr-maneiro is a small browser extension that posts a pull request comment in the voice of one of around fifty Brazilian public figures, picked from a JavaScript data file. It is a joke project with a real extension structure, and its usefulness ended when GitHub moved its pull request pages into a React app.

**IgorHalfeld/pr-maneiro** — Faça alguém feliz com um comentário no PR!

- Repository: https://github.com/IgorHalfeld/pr-maneiro
- Stars: 539 · Forks: 55
- Language: JavaScript
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/igorhalfeld-pr-maneiro

## A personality file drives the whole extension

The interesting engineering in pr-maneiro is not the comment posting. It is that the entire personality catalogue is a plain JavaScript object, and adding to it requires no build step and no tooling beyond a text editor.

The readme explains the format with a worked example, and each entry carries four fields.

```js
ney: {
  name: 'Neymar Jr',                               // nome (pode ter espaços)
  username: 'neymarjr',                            // username
  msg: 'Saudade do que a gente não viveu ainda!!', // mensagem do tweet
  image: 'https://i.imgur.com/k2Uah9s.jpg'         // url da image (precisa usar o imgur.com)
}
```

The inline comments are in Portuguese and they are the documentation. The name can contain spaces, the username is the account the comment appears to come from, the msg is the text of the comment, and the image URL needs to point at imgur.com, which is a constraint on where you can host the avatar. The example is the Neymar Jr entry, and the catalogue in the readme runs from Arnaldo Cezar Coelho through Chill Guy, covering footballers, politicians, television presenters, singers and a few others.

The readme also asks contributors to add the new persona to the list in the readme itself, so the data file and the documentation are meant to move together. That is a small but telling detail: there is no registry, no discovery mechanism and no schema validation, so the list of available personas is whatever is in the file.

## Extension structure without a framework

The repository layout describes the architecture more precisely than the readme does.

At the top level there is a manifest.json, which is where a Chrome extension declares its permissions and its background and content scripts. Alongside it sit index.html and index.template.html, which is the usual pattern for a project that keeps a source template and generates the shipped page, and a style.css for the extension's own styling. The scripts/ directory holds the JavaScript, and the readme points at scripts/persons.js as the file to edit when adding a persona. There is a components/ directory, a libs/ directory for third party code, and an assets/ folder containing the demo gifs and the icon image. The icon exists in both icon.png and icon.svg form, and the README header references an icon.png directly.

The absence of a framework is the point. There is no bundler in the scripts, no build step in the package manifest, and no transpiler. The package.json has exactly two scripts, test and lint, and the lint command targets the scripts directory with eslint using the --ext.js flag.

The development dependencies confirm the era and the setup. There is jest at version 24 with the matching type definitions, eslint 6 with the standard config and its import, jest, node, promise and standard plugins, and husky 3. The husky configuration registers a pre-commit hook that runs npm run lint and npm test, so a commit is checked before it is made. The repository also has a.eslintrc.js, a.prettierrc, an.editorconfig and a.travis.yml file for continuous integration.

## Installation is a clone and a load

The installation section is short, and it is short because there is nothing to compile. The readme tells you to clone the repository and install it in the Chrome extensions, with a demo gif showing the steps. There is no npm install step for end users, no package to publish and no server to start.

That is a genuine advantage for a project like this. There is no dependency tree to resolve, no build to wait for and no toolchain version to match. You clone, open the extensions page, load the unpacked directory, and the extension is there. The development dependencies exist for the maintainer and for contributors, not for the person who wants the joke to work.

The cost is that it is Chrome only, or at least Chromium only, since the readme describes the Chrome extension flow and the manifest is a Chrome manifest. There is no Firefox packaging mentioned and no Safari equivalent.

There is also a version story to be aware of. The repository lists a single release, 0.1.0 with the note Primeira versão, published on 2019-12-22, and a note near the top of the readme that version 2 is being developed in a specific pull request. So the master branch carries the first version while the rework happens in a separate branch, and the readme does not say when or whether that branch was merged. If you are evaluating the project, that pull request is where the current work is, and the readme points you at it explicitly.

## Tests, linting and a pre-commit hook

The tooling is small but it is real, and for a project with a data file at its centre that is the right amount.

The test command is jest, and the repository has a jest.config.js at the top level. The dev dependencies include the jest type definitions and the eslint jest plugin, which is the combination you would expect if the tests assert on the shape of the data rather than driving the browser. Given that the persona catalogue is an object literal, the most valuable thing a test can check is that every entry has the four fields and that the image URLs point where the readme says they must point. The repository does not document what the tests assert, so that is an inference from the structure rather than a claim about the suite.

The linting story is a little more detailed. The eslint configuration is a.eslintrc.js file, the style is handled by a.prettierrc, and the eslint plugins in the dependency list map to the standard style rules: eslint-config-standard with its import, node, promise and standard plugins. There are just the two scripts, lint for the check and test for jest, with no auto-fix shortcut.

The husky hook ties the two together. The pre-commit hook runs npm run lint and npm test, which means a change that breaks the lint rules or the tests does not reach the repository. For a project whose main contribution flow is editing one JavaScript data file, that guard is the difference between a catalogue that stays valid over five years and one that slowly rots.

## Where an extension like this stops working

The first limitation is the one that matters most, and it is architectural rather than fixable. This extension works against the GitHub pull request page, a document that GitHub has since rebuilt as a React application with its own routing and rendering. An extension that reaches into the page for a particular element will keep working only as long as that element keeps the same shape and location. The readme does not say how the extension finds the comment box, and the readme does not explain the coupling, so it cannot be assessed from the documentation.

The second limitation is the persona model itself. Each entry carries a username, and the comment is presented as coming from that account. That is a joke, and it is a joke that depends on a person who is recognisable to whoever reads the pull request, which in practice means the audience has to share the cultural reference. For a Brazilian developer community that is a reasonable bet. For a distributed team, it is a novelty that lands flat and, worse, one that can read as mocking a colleague whose name happens to be on the list.

The third is the licensing picture, and it is worth resolving before you copy anything. The package manifest declares GPL-3.0 in its license field, while the repository is recorded as carrying a licence that GitHub cannot classify, with the LICENSE file as the place to look. The readme does not mention licensing at all. Since the interesting part of this project is its data file and its extension structure, and both are the kind of thing people copy into other projects, read the LICENSE file rather than trusting the manifest field.

On the alternative, the interesting comparison is not another extension but a different approach to the same problem. A GitHub Actions workflow or a small bot using the platform's own comment API posts a message from a bot account, and it does so through a documented interface instead of a page's DOM. The trade is the joke. A bot account can carry a custom avatar and a fixed message, so the persona is achievable, but the mechanism is a scheduled workflow rather than a click in the browser, and it needs a token rather than a browser session.

## Maintenance state and what the history shows

The maintenance picture is thin, and it should be read as thin rather than dressed up.

The last push to the repository was on 2026-04-30, and the only tagged release is 0.1.0 from 2019-12-22. There is a single release in the repository's history as far as the listed releases show, and the readme says the second version is being developed in a pull request without saying whether it landed. The recent commit activity and the absence of a second release together suggest a project that receives occasional commits without a shipping cadence.

That matters for anyone considering depending on it. There is no version matrix, no support policy and no changelog. If the page structure GitHub serves changes again, there is no maintainer on record with a stated commitment to react.

What the project does offer is a genuinely small, readable codebase for anyone learning to write a browser extension. The manifest, the content script, a data file and a test suite is the whole shape of the thing, and there is nothing hidden behind a build pipeline. Someone who wants to understand how a Chrome extension finds an element on a page and acts on it can read this one without wading through a framework.

The topics listed for the repository are just pr and pull-request, and the primary language is JavaScript. The author in the package manifest is Igor Halfeld, and the project name is a Portuguese pun on the word for a pull request, which the readme renders as a joke about making someone happy with a comment on a pull request. There is no documentation beyond the readme, no API and no published npm package, so the audience is people who clone it, load it and then read the source.

## Conclusion

pr-maneiro suits a developer who wants to read the extension source for a quick browser automation exercise, or who wants to add one persona to the data file for their own amusement, and it does not suit a team that needs a working comment bot, because the extension is built against a pull request page layout that GitHub has since replaced. Before you use it, open a pull request on GitHub and check that the comment box it targets still exists, and note that the package manifest declares GPL-3.0 while the repository itself carries a licence GitHub cannot classify, so read the LICENSE file before redistributing anything.

## FAQ

### What is the pr-maneiro Chrome extension?

It is a browser extension that comments on a pull request in the voice of one of around fifty Brazilian public figures, chosen from a data file. The readme describes it as making someone happy with a comment on a pull request.

### How do I add a new persona to pr-maneiro?

You add an entry to scripts/persons.js following the existing pattern, with a name, a username, a message and an image URL that has to be hosted on imgur.com. You also add the new template to the list in the readme so other people know it exists.

### Does pr-maneiro need to be built or installed with npm?

No. The readme says to clone the repository and install it in the Chrome extensions. There is no build step for end users, and the npm scripts in the package manifest are for the maintainer, covering linting and tests.

### What licence is pr-maneiro released under?

The package manifest declares GPL-3.0, while the repository itself carries a licence that GitHub cannot classify. The LICENSE file in the repository root is the authority, so read it before copying the code or the data file.

### Is there a second version of pr-maneiro?

The readme points to a pull request where version 2 is being developed, and the only tagged release is 0.1.0 from 2019-12-22. The readme does not say whether that work was merged into master.

## Sources

- [IgorHalfeld/pr-maneiro on GitHub](https://github.com/IgorHalfeld/pr-maneiro)
- [Issues](https://github.com/IgorHalfeld/pr-maneiro/issues)
- [README](https://github.com/IgorHalfeld/pr-maneiro/blob/master/README.md)
- [Releases](https://github.com/IgorHalfeld/pr-maneiro/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/igorhalfeld-pr-maneiro