mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
Miranda Limonczenko
1608b16687
Prerequisite for [DOCS-1289](https://linear.app/supabase/issue/DOCS-1289/get-the-linter-to-fix-what-it-flags-or-retirereplace-the-linter). ## Problem The `write-the-docs` and `edit-the-docs` skills carry the docs style guide, so a contributor who uses them writes to the guide without having read it. Right now nothing points a contributor at them. `apps/docs/CONTRIBUTING.md` describes the skills as an option for agent users, halfway down a 559-line page, and no other contributor-facing file mentions them at all. ## Solution - **CodeRabbit reminder.** One path instruction for `apps/docs/content/**/*.mdx`. When a page collects two or more style, terminology, or structure issues, CodeRabbit adds a single comment pointing the author at `/write-the-docs` or `/edit-the-docs`. A single nit gets no pointer, so the comment reads as a signal rather than boilerplate. - **Docs CONTRIBUTING.** The intro lists the skills by task, draft through self-review, before the style rules, and links the existing skills section for framing and architecture. The section opener now reads as an expectation rather than a conditional, with the agent mechanics moved to a second paragraph. - **Root CONTRIBUTING.** A pre-flight check under Pull Requests, with the same task list nested under it. Matches the docs checklist item in #50591. - **Word list.** Names the skills that apply the list. - **Docs README and DEVELOPERS.** One sentence in each Contributing section. **Not in this PR:** CodeRabbit reminds, it doesn't enforce. Feeding the two `SKILL.md` files to `knowledge_base.code_guidelines` would make it review docs content against the style guide. That's a decision for DOCS-1289 itself. **Verification caveat:** this PR changes no MDX under `apps/docs/content/`, so the new path instruction doesn't fire on its own review. ## Manual testing 1. See all new content references in the diff. 2. Review for clarity and value. 3. Consider suggesting other ways to promote the usage of this skill to all docs contributors.
36 lines
2.8 KiB
Markdown
36 lines
2.8 KiB
Markdown
# CONTRIBUTING.md
|
||
|
||
Thank you for contributing to Supabase! We’re a big, exciting open source project and we’d love to have you contribute! Here’s some resources and guidance to help you get started:
|
||
|
||
## Getting Started
|
||
|
||
To ensure a positive and inclusive environment, please read our [code of conduct](https://github.com/supabase/.github/blob/main/CODE_OF_CONDUCT.md) before contributing. For help setting up the code in this repo, please follow our [DEVELOPERS.md](https://github.com/supabase/supabase/blob/master/DEVELOPERS.md) file. For the [docs](https://supabase.com/docs) site, follow this [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide.
|
||
|
||
## Issues
|
||
|
||
If you find a bug, please create an Issue and we’ll triage it.
|
||
|
||
- Please search [existing Issues](https://github.com/supabase/supabase/issues) before creating a new one.
|
||
- Please include a clear description of the problem along with steps to reproduce it. Exact steps with screenshots and urls really help here.
|
||
|
||
## Pull Requests
|
||
|
||
We actively welcome your Pull Requests! A couple of things to keep in mind before you submit:
|
||
|
||
- If you’re fixing an Issue, make sure someone else hasn’t already created a PR fixing the same issue. Likewise, make sure to link your PR to the related Issue(s).
|
||
- We will always try to accept the first viable PR that resolves the Issue.
|
||
- If you're new, we encourage you to take a look at issues tagged with [good first issue](https://github.com/supabase/supabase/labels/good%20first%20issue).
|
||
- If you’re submitting a new feature, make sure you have opened a [Discussion](https://github.com/orgs/supabase/discussions/new/choose) to discuss the new feature before opening a PR. We’d love to accept your hard work, but unfortunately if a feature hasn’t gone through a proper design process, your PR will be closed.
|
||
- Please use the PR message template and provide detailed context for quicker review. PRs without clear problem statements will be closed.
|
||
|
||
Prior to submitting your PR, please conduct the following pre-flight checks:
|
||
|
||
- Run `npm run build` locally to ensure that your code builds successfully without having to wait on us to approve Vercel Preview deploys.
|
||
- Ensure that the Prettier tests run successfully on your PR.
|
||
- If your PR changes docs content, use the docs authoring [agent skills](https://github.com/supabase/supabase/tree/master/.agents/skills). They apply the [docs style guide](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) for you.
|
||
- `/write-the-docs` to draft a new page, or `/edit-the-docs` to revise an existing page.
|
||
- `/test-the-docs` to run any snippets you added.
|
||
- `/review-the-docs` to self-review before you open the PR.
|
||
|
||
Running these before you create the PR will help reduce back and forth with the team.
|