ceos/fastmcp
1
0
Fork 0
mirror of https://github.com/PrefectHQ/fastmcp.git synced 2026-08-09 15:19:10 +02:00
Code Issues Projects Releases Packages Wiki Activity

Drop stale label-noting instructions from CLAUDE.md and review-pr skill (#4654)

Browse source 
Labels are bot-assigned from title/body/code; noting a "suggested" label
in the PR body was a leftover from an unrelated PR (#4392) and doesn't
match how this repo actually labels things.
This commit is contained in:
Jeremiah Lowin 2026-07-27 10:31:58 -04:00 • committed by GitHub
commit 9ea5a40728
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 3 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

7
.claude/skills/review-pr/SKILL.md
View file

@ -96,12 +96,9 @@ Codex sometimes re-posts old comments that reference code you've already fixed (
## Labels — never apply or invent them ## Labels — never apply or invent them
**Do not apply labels to PRs or issues programmatically, and never create new ones.** Labeling is the maintainer's call (and is often automated). Two hard rules: **Do not apply labels to PRs or issues programmatically, and never create new ones.** Issues and PRs in this repo are auto-labeled by a bot based on title, body, and code changes — there's no fixed canonical list to match against, and GitHub's "add labels" API auto-creates any label name that doesn't already exist, so a typo or guessed name silently pollutes the repo's label list with a stray, uncolored duplicate. There is no MCP tool to delete a label, so a mistaken creation can only be cleaned up by hand in repo settings.
- **Never invent a label.** GitHub's "add labels" API *auto-creates* any label name that doesn't already exist — so a typo or a guessed name silently pollutes the repo's label list with a stray, uncolored duplicate. Adding `breaking` (which does not exist) creates it alongside the real `breaking change` label. Don't call out a "suggested" or "appropriate" label in the PR body either — the bot doesn't read it, and it just adds noise.
- **Use only labels that already exist.** If you genuinely need to confirm a label, look it up first (`get_label` / the repo's label list) and match the exact name. The canonical names here are specific — e.g. the breaking-change label is **`breaking change`**, not `breaking`; enhancements is **`enhancements`**, features is **`features`**, bugs is **`bugs`**.
When a change warrants a label (e.g. it's breaking), **say so in the PR body and let the maintainer apply the label** rather than applying it yourself. There is no MCP tool to delete a label, so a mistaken creation can only be cleaned up by hand in repo settings — the cost of guessing is high and one-directional.
## When a PR is ready ## When a PR is ready

2
CLAUDE.md
View file

@ -60,7 +60,7 @@ When modifying MCP functionality, changes typically need to be applied across al
- Prek hooks are required (run automatically on commits) - Prek hooks are required (run automatically on commits)
- Never amend commits to fix prek failures - Never amend commits to fix prek failures
- Never apply labels manually or invent new ones — the GitHub API auto-creates any unknown label name, polluting the repo's label list. Note the appropriate label in the PR body and let the maintainer/automation apply it. Canonical names: `bugs`, `breaking change`, `enhancements`, `features` (it's `breaking change`, not `breaking`). See the review-pr skill. - Never apply labels manually or invent new ones — issues and PRs are auto-labeled by a bot based on title/body/code changes. Don't note a "suggested" or "appropriate" label anywhere in the PR body either. See the review-pr skill.
- Improvements = enhancements (not features) unless specified - Improvements = enhancements (not features) unless specified
- **NEVER** force-push on collaborative repos - **NEVER** force-push on collaborative repos
- **ALWAYS** run prek before PRs - **ALWAYS** run prek before PRs