pr-raycast

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Raycast Extension PR

Raycast 扩展 PR

Scope

适用范围

Use when the user wants to prepare, validate, or open a PR to raycast/extensions.
For extension code, lint rules, and store checklist details, use
raycast
. For generic
gh pr create
mechanics, use
pr
.
当用户希望为raycast/extensions仓库准备、验证或提交PR时使用。
关于扩展代码、lint规则和商店检查清单的详细信息,请使用**
raycast
技能。对于通用的
gh pr create
操作,请使用
pr
**技能。

Related skills

相关技能

SkillRole
raycast
Lint order, store checklist, code patterns
lint
uv run lintro fmt/chk
(first pass)
commit
Signed semantic commits, history restructuring
rebase
Sync onto
upstream/main
greptile
Pre-push Greptile CLI (max 2 runs)
coderabbit
Pre-push CodeRabbit CLI (max 2–3 runs)
技能职责
raycast
Lint顺序、商店检查清单、代码模式
lint
uv run lintro fmt/chk
(首轮检查)
commit
已签名的语义化提交、提交历史重构
rebase
upstream/main
同步
greptile
推送前运行Greptile CLI(最多2次)
coderabbit
推送前运行CodeRabbit CLI(最多2-3次)

Checklist

检查清单

text
- [ ] Rebase: 0 behind upstream/main
- [ ] Validate: lintro + npm run lint/build/validate (all pass)
- [ ] Commits: signed, logical groups (see commit skill)
- [ ] Store checklist: raycast skill (icon, screenshots, CHANGELOG, lockfile)
- [ ] Greptile CLI: ≤2 runs; fix or document skips
- [ ] CodeRabbit CLI: ≤3 runs per change set; fix or document skips
- [ ] Manual smoke test: bun run dev
- [ ] Push fork → open PR → post breakdown + how-to-test comments
text
- [ ] 变基:与upstream/main无落后提交
- [ ] 验证:lintro + npm run lint/build/validate(全部通过)
- [ ] 提交:已签名、逻辑分组(参考commit技能)
- [ ] 商店检查清单:raycast技能(图标、截图、CHANGELOG、锁文件)
- [ ] Greptile CLI:≤2次运行;修复或记录跳过项
- [ ] CodeRabbit CLI:每个变更集≤3次运行;修复或记录跳过项
- [ ] 手动冒烟测试:bun run dev
- [ ] 推送到分支仓库 → 打开PR → 发布代码分解及测试说明评论

1. Rebase & validate

1. 变基与验证

bash
git fetch upstream && git rebase upstream/main
git rev-list --left-right --count upstream/main...HEAD   # 0 N

uv run lintro fmt && uv run lintro chk                   # repo root

cd extensions/<name>
npm run lint && npm run build && npm run validate
Abort on failure. Do not push until green.
bash
git fetch upstream && git rebase upstream/main
git rev-list --left-right --count upstream/main...HEAD   # 0 N

uv run lintro fmt && uv run lintro chk                   # 仓库根目录

cd extensions/<name>
npm run lint && npm run build && npm run validate
如果失败则终止操作。未全部通过前请勿推送。

2. Commit history

2. 提交历史

Signed (
git commit -S
), semantic, imperative. New extensions: files should be
A
, not
M
.
Suggested order for new extensions: scaffold → lib → UI → entry point → tests → docs.
Restructure after squash:
bash
git reset --soft upstream/main && git reset HEAD
需签名(
git commit -S
)、语义化、命令式风格。新扩展的文件状态应为
A
(新增),而非
M
(修改)。
新扩展建议的提交顺序:脚手架 → 库 → UI → 入口文件 → 测试 → 文档。
合并后重构提交历史:
bash
git reset --soft upstream/main && git reset HEAD

commit in groups; verify: git diff <squash-sha> HEAD --stat is empty

分组提交;验证:git diff <squash-sha> HEAD --stat 无输出

undefined
undefined

3. Pre-PR audits

3. PR前审核

Store checklist — full list in
raycast
skill. Spot-check:
bash
node -e "console.log(require('./package.json').keywords.length)"  # ≤12
head -3 CHANGELOG.md                                               # {PR_MERGE_DATE}
rg 'interface Preferences' src/                                    # none
git ls-files package-lock.json 'bun.lock*' yarn.lock pnpm-lock.yaml
Common Greptile findings: manual Preferences types, shell/
AppleScript
file ops,
unlink()
on user files, ungated debug logs, inaccurate CHANGELOG, icon invisible on dark UI.
Greptile CLI:
greptile review -b main --agent
(max 2 runs).
CodeRabbit CLI:
coderabbit review --agent --type committed --base main
(max 2–3 runs per change set). Run parallel with Greptile when possible.
商店检查清单 — 完整清单在
raycast
技能中。抽查项:
bash
node -e "console.log(require('./package.json').keywords.length)"  # ≤12
head -3 CHANGELOG.md                                               # {PR_MERGE_DATE}
rg 'interface Preferences' src/                                    # 无此项
git ls-files package-lock.json 'bun.lock*' yarn.lock pnpm-lock.yaml
Greptile常见问题: 手动定义Preferences类型、shell/
AppleScript
文件操作、对用户文件执行
unlink()
、未限制的调试日志、不准确的CHANGELOG、图标在深色UI中不可见。
Greptile CLI:
greptile review -b main --agent
(最多2次运行)。
CodeRabbit CLI:
coderabbit review --agent --type committed --base main
(每个变更集最多2-3次运行)。尽可能与Greptile并行运行。

4. Open PR

4. 打开PR

bash
git push -u origin HEAD

gh pr create \
  --repo raycast/extensions \
  --head <fork>:<branch> \
  --base main \
  --title "Extension Name: Brief description" \
  --body "$(cat <<'EOF'
bash
git push -u origin HEAD

gh pr create \
  --repo raycast/extensions \
  --head <fork>:<branch> \
  --base main \
  --title "Extension Name: Brief description" \
  --body "$(cat <<'EOF'

🤖 Disclosure

🤖 披露

[AI assistance disclosure + human review statement]
[AI协助披露 + 人工审核声明]

Description

描述

[One paragraph]
[一段说明]

Features

功能

[User-facing bullets]
[用户可见的功能列表]

Technical Highlights

技术亮点

[Architecture, test count]
[架构、测试数量]

Screencast

屏幕录制

Screenshots in
metadata/
.
截图位于
metadata/
目录中。

Checklist

检查清单

  • Prepare for Store
  • Publish docs
  • npm run build
    tested in Raycast
  • Assets in
    assets/
    are used; README media outside
    metadata/
  • npm run lint
    and
    npm run validate
    pass EOF )"

Do **not** use `gh pr create --fill`. Title: `Extension Name: Brief description`.
  • 为商店做准备
  • 发布文档
  • npm run build
    已在Raycast中测试
  • assets/
    目录中的资源已被使用;README中的媒体文件不在
    metadata/
    目录外
  • npm run lint
    npm run validate
    已通过 EOF )"

请勿使用`gh pr create --fill`。标题格式:`Extension Name: Brief description`。

5. Post-PR comments

5. PR后评论

Add separately after opening:
  1. File breakdown — table by category (impl, tests, images, config, docs) with counts
  2. How to test — prerequisites,
    bun run dev
    , sample data URL, smoke-test steps
Reviewers need sample data or credentials to test — always provide one.
打开PR后单独添加以下内容:
  1. 文件分解 — 按类别(实现、测试、图片、配置、文档)分类的表格,包含文件数量
  2. 测试方法 — 前置条件、
    bun run dev
    示例数据URL、冒烟测试步骤
审核人员需要示例数据或凭据来进行测试——务必提供其中一项。

Review feedback

审核反馈

  1. npm run validate
    → signed commit → push
  2. Reply on threads; re-request review if needed
Stale: 14 days idle → stale; 21 days → auto-close.
  1. 执行
    npm run validate
    → 签名提交 → 推送
  2. 在讨论线程中回复;必要时重新请求审核
闲置状态:14天未活动 → 标记为闲置;21天 → 自动关闭。