Mohit Aggarwal Contributor Guide Skill
Most would-be contributors give up at setup friction or unclear expectations. A good CONTRIBUTING.md removes
the guesswork: how to get the project running, how to propose a change, what a mergeable PR looks like, and
where to ask. This skill writes that guide — welcoming, specific, and aimed at getting someone to a successful
first PR.
Required Inputs
Ask for these only if they aren't already provided:
- Project & stack — what it is, language/framework, repo layout basics.
- Dev setup — how to clone, install, run locally, and run tests.
- Workflow — branch model, commit/PR conventions, where issues live, who reviews.
- Standards — linting/formatting, test requirements, the Code of Conduct (link).
- Norms (optional) — how decisions are made, response times, good-first-issue process.
Output Format
A CONTRIBUTING.md:
Contributing to [Project]
A warm one-liner: contributions are welcome, here's how to make it smooth.
Ways to contribute — issues, docs, code, triage — not everyone writes code.
Development setup
# clone, install, run, test — the exact commands
…so a contributor can get the project running and tests passing locally.
Finding something to work on — point to good first issue / help wanted; ask people to comment before starting larger work.
Making a change (the workflow)
- Branch from … with naming convention …
- Make the change; follow the standards below.
- Add/update tests; run the linter/tests locally.
- Open a PR — what the PR description should include; link the issue.
Standards — formatting/linting, test expectations, commit/PR conventions, the Code of Conduct link.
What happens next — who reviews, rough turnaround, how feedback works.
Getting help — where to ask (Discussions, chat, issue) — make it explicitly OK to ask.
Quality Checks
- Setup commands actually get the project running and tests passing
- The contribution workflow is numbered and unambiguous (branch → change → test → PR)
- Standards (lint, tests, commit/PR conventions, CoC) are stated and linked
- It points to good-first-issues and welcomes non-code contributions
- It's encouraging in tone and tells people exactly where to get help
Anti-Patterns
- Do not assume the contributor knows the setup — spell out the exact commands
- Do not leave PR expectations implicit — say what a mergeable PR includes
- Do not be gatekeep-y or cold — friction and tone both lose contributors
- Do not omit how to get help or who reviews — uncertainty stalls first PRs
- Do not forget the Code of Conduct link — it sets the community standard
Based On
Open-source contribution best practices (clear setup, defined workflow, good-first-issues, welcoming tone, CoC).