From cfaa49ab3dc8d9e5661182d5c21a66f5b26bcdab Mon Sep 17 00:00:00 2001 From: sebastien Date: Fri, 6 Nov 2026 19:48:18 +0100 Subject: [PATCH 1/2] chore(ai): link the fixed issue with a closing keyword in PR descriptions (AI-assisted) Co-Authored-By: Claude Opus 5.5 --- .agents/skills/pull-requests/SKILL.md | 1 + 1 file changed, 1 insertion(+) diff --git a/.agents/skills/pull-requests/SKILL.md b/.agents/skills/pull-requests/SKILL.md index dd3b68265c0b..17daff706ce6 100644 --- a/.agents/skills/pull-requests/SKILL.md +++ b/.agents/skills/pull-requests/SKILL.md @@ -14,6 +14,7 @@ Write the description from the GitHub pull request template in `.github/PULL_REQ - Remove the `## Pre-flight checklist` section. It is only relevant for external contributors: we assume maintainers did their best, so it only adds noise. - Remove all the HTML comments of the template. - Remove the `## Related issues/PRs` section if there is nothing relevant to link. +- If the PR fixes an issue, write `Fixes #` in the `## Related issues/PRs` section: GitHub links the issue and closes it when the PR is merged. - If a benchmark is useful to review the change (performance, bundle size…), add a `## Benchmark` section right after `## Motivation`. - If there are breaking changes, start with a `## Breaking Changes` section explaining: - The breaking change. From dcd4e28efc76f3c00c84f3834cbfcd12fc7e0668 Mon Sep 17 00:00:00 2001 From: sebastien Date: Fri, 6 Nov 2026 19:53:16 +0100 Subject: [PATCH 2/2] chore(ai): link the PR that adds a code comment (AI-assisted) Co-Authored-By: Claude Opus 5.5 --- .agents/skills/code-style/SKILL.md | 1 + 1 file changed, 1 insertion(+) diff --git a/.agents/skills/code-style/SKILL.md b/.agents/skills/code-style/SKILL.md index 95d3af1588eb..b6ee4a1e3722 100644 --- a/.agents/skills/code-style/SKILL.md +++ b/.agents/skills/code-style/SKILL.md @@ -41,6 +41,7 @@ async function main() { - Don't comment code that is self-explanatory: when the names, the signature or the code already say it, add no comment. - Comment the code that is weird, unexpected or surprising (a workaround, a non-obvious constraint, an order that matters): that's where readers need one. - Keep comments short, one line when possible. Point to the details instead of writing them out: link the issue, PR, documentation or upstream bug that explains them. +- Prefer linking the PR that adds the comment over older references: its description can hold all the context, and link to those older issues and PRs. - When moving an existing comment, keep its wording: fix typos, don't rephrase it. - Put each comment on the code it applies to, never floating between unrelated lines. To explain why an option keeps its default value, write that option with its default value, like `trailingSlash: undefined`, and comment it.