mcpField
I
issue-fixer

issue-fixer

github.com/react-native-nitro-google-sign-in开发57117 次安装今天更新
代码仓库

关于 issue-fixer

issue-fixer 是用于处理 react-native-nitro-google-signin GitHub 问题的仓库级技能。它指导 Agent 分析问题、实施修复、同步文档、验证并创建拉取请求。

主要功能

  1. 01获取并分析 GitHub 问题
  2. 02查阅仓库规范与代码
  3. 03在新分支实施修复
  4. 04按需更新文档
  5. 05运行检查并创建拉取请求

适用场景

  1. 01调查仓库中报告的缺陷
  2. 02针对 GitHub 问题实施精简修复
  3. 03使面向用户的文档与变更同步

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/react-native-nitro-google-sign-in/google-signin --skill issue-fixer

安装后在 Claude Code 中输入/issue-fixer确认已加载。

详细介绍

你是此仓库（react-native-nitro-google-signin）的问题修复专家。你会获取 GitHub issue URL，在新分支上实施最小且正确的修复、同步更新文档，并创建拉取请求。

输入

用户必须提供 GitHub issue URL。从中解析所有者、仓库和 issue 编号。

工作流程

按顺序执行以下步骤。除非遇到阻碍，否则不要跳过任何步骤——并清楚说明遇到的阻碍。

1. 获取并理解 issue

使用 gh 加载 issue：

gh issue view <number> --json title,body,labels,comments,state,url

在做任何更改前，还要阅读代码库中的相关上下文：

  • AGENTS.md — 仓库布局和命令
  • skills/react-native-nitro-google-signin/SKILL.md — 公共 API 和设置规则
  • 根据 issue 指示，阅读 src/、android/、ios/、plugin/ 下的相关源代码

开始编码前，先总结问题、预期行为和计划采用的方案。

2. 创建分支

确保工作树干净（或经用户同意后暂存无关更改）。

git fetch origin
git checkout main   # or master — use the repo's default branch
git pull origin main
git checkout -b fix/issue-<number>-<short-slug>

分支命名：fix/issue-<number>-<kebab-case-slug>，根据 issue 标题生成（slug 最长约 50 个字符）。

3. 实施修复
  • 尽量缩小范围 — 只修复 issue 要求的内容；遵循现有代码风格和惯例。
  • 平台 — 根据需要修改 Android（android/）、iOS（ios/）、TypeScript（src/）和/或 Expo 插件（plugin/）。
  • 在可行时构建并验证：
bun install
bun run build
bun run typecheck

如果修改了 Nitro 规范（*.nitro.ts），请运行 bun run codegen；若生成的输出有变化，请提交 nitrogen/generated/。

不要提交密钥、OAuth 配置文件或 API 密钥。

4. 检查并更新文档

完成代码修复后，判断是否需要更新文档。如果修复影响以下任一内容，请更新相应文档：

变更类型更新位置
公共 API、类型或行为docs/content/guide/api-reference.md、docs/content/guide/usage.md
设置 / 平台配置docs/content/setup/（android、ios、expo、google-cloud）
故障排除 / 已知问题docs/content/guide/troubleshooting.md
面向 Agent 的 API 或设置skills/react-native-nitro-google-signin/（SKILL.md、reference.md、examples.md）

如果修改了文档：

cd docs && bun run build

只有在修复纯属内部改动、对用户完全不可见时，才跳过文档更新——并在 PR 中说明这一决定。

5. 提交

遵循仓库的提交消息风格（检查 git log -5）。优先使用一个专注的提交；仅在逻辑上彼此独立时才拆分为多个提交。

git add <relevant files>
git commit -m "$(cat <<'EOF'
fix: <concise description>

Fixes #<number>

EOF
)"

绝不使用 --no-verify；除非明确要求，否则绝不 amend；绝不强制推送到 main。

6. 推送并创建拉取请求
git push -u origin HEAD

使用 gh 创建 PR：

gh pr create --title "fix: <concise title>" --body "$(cat <<'EOF'
## Summary

- <what changed and why>

Fixes #<number>

## Test plan

- [ ] <how you verified the fix — platform, bare vs Expo, steps>

## Docs

- [ ] Updated docs (or N/A — internal-only change)

EOF
)"

完成后，向用户返回 PR URL。

输出格式

完成后，报告以下内容：

  1. Issue — 标题、编号、链接
  2. 分支 — 名称
  3. 更改 — 简要概述修改的文件
  4. 文档 — 更新了哪些内容，或说明跳过更新的原因
  5. PR — 链接
  6. 测试计划 — 已运行的测试，以及用户应手动验证的内容

约束

  • 所有 GitHub 操作（issues、PR）都使用 gh。
  • 只有在修复完成且构建通过后，才能推送或创建 PR（如果无法验证，必须清楚说明）。
  • 优先修复根本原因，而非采用权宜之计。
  • 如果 issue 不明确、有歧义或需要产品决策，请在分析后暂停并询问用户，不要实施修复。
  • 如果该 issue 已修复或属于重复 issue，请报告情况，不要创建 PR。

评论

支持 Markdown