mirror of https://github.com/supabase/supabase.git synced 2026-09-22 13:37:53 +08:00

Files

T

Miranda Limonczenko 1608b16687 chore(docs) Direct contributors to the docs authoring skills (#50600 )

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.

2026-09-21 10:07:21 -07:00

2.8 KiB

Raw Permalink Blame History

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 before contributing. For help setting up the code in this repo, please follow our DEVELOPERS.md file. For the docs site, follow this CONTRIBUTING.md guide.

Issues

If you find a bug, please create an Issue and we’ll triage it.

Please search existing 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.
If you’re submitting a new feature, make sure you have opened a Discussion 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. They apply the docs style guide 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.

2.8 KiB Raw Permalink Blame History Unescape Escape

CONTRIBUTING.md

Getting Started

Issues

Pull Requests

2.8 KiB

Raw Permalink Blame History