Skip to content

chore(skills): common mistakes in lint rules#9972

Merged
dyc3 merged 1 commit intomainfrom
dyc3/lint-skill-common-mistakes
Apr 14, 2026
Merged

chore(skills): common mistakes in lint rules#9972
dyc3 merged 1 commit intomainfrom
dyc3/lint-skill-common-mistakes

Conversation

@dyc3
Copy link
Copy Markdown
Contributor

@dyc3 dyc3 commented Apr 13, 2026

Summary

tired of fixing/giving feedback on the same things over and over

Test Plan

Docs

@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Apr 13, 2026

⚠️ No Changeset found

Latest commit: c92430e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Apr 13, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: e6fcdba7-8ef5-41ea-97b5-d7a4dfb8ee39

📥 Commits

Reviewing files that changed from the base of the PR and between d18457c and c92430e.

📒 Files selected for processing (2)
  • .claude/skills/biome-developer/SKILL.md
  • .claude/skills/lint-rule-development/SKILL.md
✅ Files skipped from review due to trivial changes (1)
  • .claude/skills/biome-developer/SKILL.md

Walkthrough

This PR adds “Common Mistakes to Avoid” documentation sections in two skill guides: .claude/skills/lint-rule-development/SKILL.md and .claude/skills/biome-developer/SKILL.md. The new guidance calls out performance anti-patterns: avoid storing String/Box<str> in rule State (prefer TokenText), defer fix construction to action() instead of run(), avoid format!() inside markup! (use interpolation), and avoid allocating text from tokens/nodes (.to_string() / .to_string_trimmed()) — borrow via token.text(). No code or public API changes.

Suggested labels

A-Linter

Suggested reviewers

  • ematipico
🚥 Pre-merge checks | ✅ 2
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly describes the main change: documenting common mistakes in lint rule development across two skill files.
Description check ✅ Passed The description addresses the motivation for the PR—preventing repeated feedback on the same issues—which directly relates to the documentation additions about common mistakes.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch dyc3/lint-skill-common-mistakes

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

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
.claude/skills/lint-rule-development/SKILL.md (1)

309-309: Soften the Box<str> guidance to avoid a false absolute.

This currently reads as “Box<str> in State is a mistake”, but there are legitimate cases where owned text is needed. Suggest phrasing this as a preference, not a blanket rule.

Suggested wording tweak
-- Placing `String` or `Box<str>` in a Rule's `State` type. It's a strong indicator that you are allocating a string unnecessarily. This can usually can be avoided by using `TokenText` instead.
+- Placing `String` (and often `Box<str>`) in a Rule's `State` type when borrowed token text would do. This is often an unnecessary allocation; prefer `TokenText` where possible, and only use owned strings when ownership/lifetime requires it.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.claude/skills/lint-rule-development/SKILL.md at line 309, Change the
absolute guidance that “Placing `String` or `Box<str>` in a Rule's `State` type”
is a mistake to a softer preference: state that using `String`/`Box<str>` in a
`Rule`'s `State` may often be unnecessary and that `TokenText` is preferred when
you can avoid allocating owned text, but acknowledge there are legitimate cases
where owned text is required; update phrasing from categorical words like “is a
strong indicator” to conditional language such as “often indicates” or “may
indicate” and add a short clause that permits owned text when needed.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.claude/skills/lint-rule-development/SKILL.md:
- Around line 310-311: Fix the typo "interpolaion" to "interpolation" in the
sentence describing markup! interpolation and tighten the performance sentence
about run() vs action() for clarity and flow; specifically update the phrase
mentioning "run()" and "action()" so it reads more concise (e.g., "the run()
method should only determine whether to emit a diagnostic, and the action()
method should build the fix, because building the action can be expensive and
should be avoided when no diagnostic is emitted") while keeping references to
markup! interpolation and the run()/action() split.

---

Nitpick comments:
In @.claude/skills/lint-rule-development/SKILL.md:
- Line 309: Change the absolute guidance that “Placing `String` or `Box<str>` in
a Rule's `State` type” is a mistake to a softer preference: state that using
`String`/`Box<str>` in a `Rule`'s `State` may often be unnecessary and that
`TokenText` is preferred when you can avoid allocating owned text, but
acknowledge there are legitimate cases where owned text is required; update
phrasing from categorical words like “is a strong indicator” to conditional
language such as “often indicates” or “may indicate” and add a short clause that
permits owned text when needed.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 0cdd19ec-c5c8-4a4b-b906-350838b8b697

📥 Commits

Reviewing files that changed from the base of the PR and between 322675e and d050d1f.

📒 Files selected for processing (1)
  • .claude/skills/lint-rule-development/SKILL.md

Comment thread .claude/skills/lint-rule-development/SKILL.md Outdated
@dyc3 dyc3 force-pushed the dyc3/lint-skill-common-mistakes branch from d050d1f to b239e4d Compare April 13, 2026 21:30
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.claude/skills/lint-rule-development/SKILL.md:
- Line 309: Fix the duplicated word in the sentence about Rule state types: in
the line containing "Placing `String` or `Box<str>` in a Rule's `State` type..."
remove the extra "can" so it reads "This can usually be avoided by using
`TokenText` instead." Ensure the sentence still references `Rule`'s `State` and
`TokenText` to keep intent clear.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 0aca63b1-f194-48f2-9b8c-30a28e1e8d01

📥 Commits

Reviewing files that changed from the base of the PR and between d050d1f and b239e4d.

📒 Files selected for processing (1)
  • .claude/skills/lint-rule-development/SKILL.md

Comment thread .claude/skills/lint-rule-development/SKILL.md Outdated
@dyc3 dyc3 force-pushed the dyc3/lint-skill-common-mistakes branch from b239e4d to d18457c Compare April 13, 2026 21:35
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
.claude/skills/lint-rule-development/SKILL.md (1)

310-310: Great addition — tiny wording polish on Line 310.

Mid-sentence, E.g. reads a bit off in this style guide; e.g., is the cleaner form in en‑GB prose.

✏️ Suggested tweak
-- - Calling `format!()` (allocates a string) when formatting strings in a `markup!` block. `markup!` supports interpolation, E.g. `markup! { "Hello, "{name}"!" }`.
+- Calling `format!()` (allocates a string) when formatting strings in a `markup!` block. `markup!` supports interpolation, e.g., `markup! { "Hello, "{name}"!" }`.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.claude/skills/lint-rule-development/SKILL.md at line 310, Update the
wording at the sentence that begins "Calling `format!()` (allocates a string)
when formatting strings in a `markup!` block. `markup!` supports interpolation,
E.g. `markup! { "Hello, "{name}"!" }`" by replacing "E.g." with the lowercase
"e.g.," so it reads "...supports interpolation, e.g., `markup! { "Hello,
"{name}"!" }`" to match en‑GB punctuation and style; locate the exact sentence
in the SKILL.md content near the `format!()`/`markup!` example and apply this
single-word, punctuation change.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.claude/skills/lint-rule-development/SKILL.md:
- Line 310: Update the wording at the sentence that begins "Calling `format!()`
(allocates a string) when formatting strings in a `markup!` block. `markup!`
supports interpolation, E.g. `markup! { "Hello, "{name}"!" }`" by replacing
"E.g." with the lowercase "e.g.," so it reads "...supports interpolation, e.g.,
`markup! { "Hello, "{name}"!" }`" to match en‑GB punctuation and style; locate
the exact sentence in the SKILL.md content near the `format!()`/`markup!`
example and apply this single-word, punctuation change.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a317e405-5b03-47de-a72e-7e4450980ccf

📥 Commits

Reviewing files that changed from the base of the PR and between b239e4d and d18457c.

📒 Files selected for processing (1)
  • .claude/skills/lint-rule-development/SKILL.md

Comment thread .claude/skills/lint-rule-development/SKILL.md Outdated
Comment thread .claude/skills/lint-rule-development/SKILL.md Outdated
Comment thread .claude/skills/lint-rule-development/SKILL.md Outdated
@dyc3 dyc3 force-pushed the dyc3/lint-skill-common-mistakes branch from d18457c to c92430e Compare April 14, 2026 11:18
@dyc3 dyc3 requested a review from ematipico April 14, 2026 11:18
@dyc3 dyc3 merged commit 7a360dd into main Apr 14, 2026
4 checks passed
@dyc3 dyc3 deleted the dyc3/lint-skill-common-mistakes branch April 14, 2026 11:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants