chore: prettier ignore readme

[DanielRivers]

Explain your changes

Add readme to prettier ignore for clearer docs

Checklist

• I have read the “Pull requests” section in the contributing guidelines.
• I agree to the terms within the code of conduct.

🛟 If you need help, consider asking for advice over in the Kinde community.

[coderabbitai]

Walkthrough

Updated .prettierignore to add README.md to the ignore list; existing entries (generated, pnpm-lock.yaml, CHANGELOG.md) remain.

Changes

Cohort / File(s)	Summary
Prettier ignore configuration ./.prettierignore	Added README.md to Prettier ignore list; retained existing ignored entries (generated, pnpm-lock.yaml, CHANGELOG.md).

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title "chore: prettier ignore readme" directly and succinctly reflects the primary change in the changeset—adding README.md to .prettierignore as shown in the raw_summary—and uses a conventional "chore" prefix to indicate a non-functional update, so it communicates the intent to reviewers clearly. It is concise and specific enough for a teammate scanning history to understand the main change. Therefore the title is appropriate for this changeset.
Description Check	✅ Passed	The PR description plainly states the intent ("Add readme to prettier ignore for clearer docs"), matches the .prettierignore modification described in the raw_summary, and includes the contributor checklist and links, so it is directly related to the changeset and provides adequate context for this low-risk chore. The level of detail is sufficient for reviewers to understand why the change was made. Therefore it passes the lenient description check.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/ignore-readme-prettier

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 451c31e and b4226cb.

📒 Files selected for processing (1)

• .prettierignore (1 hunks)

🔇 Additional comments (2)

.prettierignore (2)

3-3: LGTM: keeping CHANGELOG.md out of Prettier is sensible.

This avoids unintended reflows in auto-generated or tooling-managed changelogs.

---

4-4: Consider broadening the pattern or using a targeted Prettier override.

• If this repo has package-level READMEs (monorepo), ignore them all:

-README.md
+**/README*.md

• Alternatively, keep formatting but stop Markdown reflow via Prettier overrides (preserves consistency while protecting prose):
  Add to .prettierrc:

{
  "overrides": [
    { "files": ["**/README*.md"], "options": { "proseWrap": "preserve" } }
  ]
}

[ suggest_optional_refactor ][ request_verification ]
Run to see if broader ignore is warranted:

#!/bin/bash
# List all READMEs that might still be formatted by Prettier
fd --glob 'README*.md' -t f -H

Tip

👮 Agentic pre-merge checks are now available in preview!

Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.

• Built-in checks – Quickly apply ready-made checks to enforce title conventions, require pull request descriptions that follow templates, validate linked issues for compliance, and more.
• Custom agentic checks – Define your own rules using CodeRabbit’s advanced agentic capabilities to enforce organization-specific policies and workflows. For example, you can instruct CodeRabbit’s agent to verify that API documentation is updated whenever API schema files are modified in a PR. Note: Upto 5 custom checks are currently allowed during the preview period. Pricing for this feature will be announced in a few weeks.

Please see the documentation for more information.

Example:

reviews:
  pre_merge_checks:
    custom_checks:
      - name: "Undocumented Breaking Changes"
        mode: "warning"
        instructions: |
          Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).

Please share your feedback with us on this Discord post.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}