用途：把现有的 GitHub 自动化想法（脚本、机器人、手动工作流）落地为真正的 GitHub App。
技术栈（2026 标准）：Node.js + TypeScript；框架 Probot；认证与 App 原语 @octokit/app；API 客户端 @octokit/rest（通过 context.octokit）。选择理由：Probot 提供 webhook 优先的结构，@octokit/app 处理 JWT 与安装令牌，需要控制时可下沉到原始 Octokit。
脚手架命令： npx create-probot-app my-github-app cd my-github-app npm run dev 初始化时选择 TypeScript 与最小模板，尽量保持范围狭窄，一个 App 只做一条自动化回路。
工作流：识别自动化机会 → 映射到 webhook 事件与仓库操作 → 用 Probot 脚手架 → 实现 webhook 处理器 → 锁定最小可用权限 → 部署 → 在 staging 仓库/组织验证。发现清单包括：触发事件、所需仓库/issue/PR 状态、将执行的 GitHub 写入、所需权限、失败模式（重试、评论、打标签、无操作）。
项目结构：默认 Probot 布局含 src/index.ts、test/、app.yml、package.json、tsconfig.json。逻辑增长后建议拆为 index.ts（仅接线事件）、handlers/（pull-request、issues、push）、domain/（可测试的核心决策逻辑）、github/client.ts（octokit 辅助）。原则：webhook 胶水层保持薄，决策放入深层模块。
常见用例：PR 自动化（按路径自动打标签、强制检查清单评论、自动请求评审）；issue 管理（按模板分诊标签、自动关闭陈旧 issue、路由到团队）；代码评审机器人（对风险 diff 评论、在 PR 打开/同步时强制约定、用状态检查阻止合并）；CI 集成（在 PR/push 时触发外部系统、回写提交状态、通过 checks 管理部署）。
权限模型：把权限当作接口，从事件与写入出发，只加必需的读写范围，非必要优先只读。典型映射：打标签需 Issues 与 Pull requests 读写；评论需 Issues 或 Pull requests 读写；状态检查需 Commit statuses 或 Checks 读写；读取仓库配置需 Metadata 只读（始终）。建议在仓库中维护“操作—API 调用—所需权限”表。
部署：选择最契合 webhook 模型的主机。默认可选 Vercel、云函数（AWS Lambda、GCP Cloud Functions、Azure Functions）、自托管长驻 worker/队列/自定义基础设施。Probot 可经轻量胶水以 serverless 运行；较重自动化使用队列与幂等键；保持 webhook 低延迟，重活延后。
验证：不可跳过。本地运行 npm run dev；创建开发用 GitHub App 并安装到 staging 仓库；把 webhook URL 指向开发隧道；触发事件（开 PR、编辑 issue、push）；确认日志出现预期处理器路径；确认 GitHub 侧副作用（标签、评论、检查）发生；为决策逻辑与处理器编写测试。最小验证清单：事件已接收、护栏生效（仓库/组织/分支过滤）、API 调用成功、无重复副作用、权限足够但不过度。
限制：资料未提供具体价格、平台支持范围、性能指标或完整代码示例；参考文件为 skills/github-app-scaffold/references/probot-patterns.md。