💡 Background and Solution

💡 Background and Solution

The Select dropdown could jump when the option list changed during search. This PR keeps the scroll position stable after options are updated. No public API changes are introduced.

对应中文示例：

```markdown
### 💡 需求背景和解决方案

Select 在搜索过程中更新选项后，下拉列表会出现滚动位置跳动。这个 PR 在选项变更后保持滚动位置稳定。不涉及公开 API 变更。

两个示例的共同结构是：“现象 + 处理方式 + 对外影响声明”三段式，先写要解决的问题，再写采用的方案，最后点明外部可感知差异（有或没有）。正文不是逐文件流水账，而应归纳“为什么改”和“改完后对开发者/用户有什么影响”。

五、Change Log 的写法：实质条目与占位条目

模板中的 Change Log 是一张双语表格。参考文档将其区分为两类场景。

1. 需要写实质 changelog 的场景

当改动会影响以下任一对象时，必须写明对用户的影响：

• 组件使用方式；
• 公开 API；
• 交互行为；
• UI / 视觉表现；
• 用户实际可感知结果。

示例写法：

### 📝 Change Log

| Language   | Changelog                                        |
| ---------- | ------------------------------------------------ |
| 🇺🇸 English | Fix Select dropdown scroll jumping during search |
| 🇨🇳 Chinese | 修复 Select 搜索时下拉列表滚动位置跳动问题       |

写作视角是“对开发者的影响”，而非实现细节。最终这些条目会进入仓库根目录的 CHANGELOG.en-US.md 与 CHANGELOG.zh-CN.md，可以对照仓库现有 changelog 的条目风格（每条附 PR 编号与组件名）来校准自己的措辞粒度。

2. 无需 changelog 的场景

常见包括：

• site
• docs
• demo
• ci
• 纯测试
• 内部维护或重构，且无外部可感知变化

这类场景不要硬写影响描述，可直接使用占位表格：

### 📝 Change Log

| Language   | Changelog             |
| ---------- | --------------------- |
| 🇺🇸 English | No changelog required |
| 🇨🇳 Chinese | 无需更新日志          |

也可以更短，直接写 N/A、No changelog required、无需更新日志 之一。前提是 保留模板 section，不要直接删掉整个 changelog 区块——模板结构中该 section 必须存在。这一占位策略与 CI 行为完全对齐：pr-open-check.yml 中 skip-title-start: 'docs, chore, test, ci' 的配置意味着这些类型的 PR 会跳过 changelog 填写检查，因此占位即可通过校验。

六、基线分支（base branch）的推断建议

参考文档的核心目标：尽量推断“当前分支实际从哪里切出来”，而不是拍脑袋默认 master。建议的判断顺序为：

1. 用户明确指定了 base branch -> 直接使用；
2. 查看当前分支是否能从 reflog 看出 checkout 来源；
3. 查看 git branch -vv 的 tracking / upstream 作为辅助线索；
4. 必要时结合 merge-base 比较候选分支；
5. 若仍无法确定，再退回远端默认分支或仓库默认分支。

配套命令：

git branch --show-current
git branch -vv
git reflog show --date=local $(git branch --show-current)
git remote show origin
git merge-base HEAD <candidate-branch>

同时给出三条注意事项：

• upstream 不是绝对父分支，只是候选线索；
• reflog 最接近真实答案，但不一定一直存在（可能被清理）；
• 不确定时要明确告诉用户“这是推断值”。

在 SKILL.md 中该流程还有两个配套约定：不要默认就用 master；若改动性质判断为 feat 且当前基线不是明显的功能分支（如 feature/*），应额外提醒用户确认是否应提交到对应 feature 分支——这与 中文模板 头部注释“新特性请提交至 feature 分支，其余可提交至 master 分支”的要求相呼应。此外，创建 PR 前还应基于 base...HEAD 的完整 diff 归纳改动（git log --oneline <base>..HEAD、git diff --stat <base>...HEAD），而不是只根据最近一个 commit 或工作区未提交内容写 PR。

七、创建 PR 前的确认草稿

参考文档要求：在真正执行 gh pr create 之前，先给用户一个确认版草稿，例如：

我先整理了一版待提交的 PR 草稿，请你确认：

- Base branch: `feature-x`
- PR title: `site: adjust token panel interaction on theme preview page`
- PR type: `📝 Site / documentation improvement`
- Change Log: `No changelog required`

如果没问题，我再继续创建 PR；如果你想改 title、type、base 或正文，我先帮你改。