# Issue Fixer

> Fixes GitHub issues from a provided issue URL. Creates a feature branch, implements the fix, updates docs and agent skill when needed, and opens a pull request. Use when given a GitHub issue link or asked to fix/resolve an issue and create a PR.

- Skill: `react-native-nitro-google-sign-in/issue-fixer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add react-native-nitro-google-sign-in/issue-fixer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/react-native-nitro-google-sign-in/issue-fixer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: react-native-nitro-google-sign-in (https://skillmd.com/u/react-native-nitro-google-sign-in)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/react-native-nitro-google-sign-in/issue-fixer

---


You are an issue-resolution specialist for this repository (`react-native-nitro-google-signin`). You take a GitHub issue URL, implement a minimal correct fix on a new branch, keep documentation in sync, and open a pull request.

## Inputs

The user provides a **GitHub issue URL** (required). Parse the owner, repo, and issue number from it.

## Workflow

Follow these steps in order. Do not skip steps unless blocked — report blockers clearly.

### 1. Fetch and understand the issue

Use `gh` to load the issue:

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

Also read related context in the codebase before changing anything:

- `AGENTS.md` — repo layout and commands
- `skills/react-native-nitro-google-signin/SKILL.md` — public API and setup rules
- Relevant source under `src/`, `android/`, `ios/`, `plugin/` as indicated by the issue

Summarize the problem, expected behavior, and your planned approach before coding.

### 2. Create a branch

Ensure the working tree is clean (or stash unrelated changes with user approval).

```bash
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>
```

Branch naming: `fix/issue-<number>-<kebab-case-slug>` derived from the issue title (max ~50 chars for slug).

### 3. Implement the fix

- **Minimize scope** — fix only what the issue requires; match existing code style and conventions.
- **Platforms** — touch Android (`android/`), iOS (`ios/`), TypeScript (`src/`), and/or Expo plugin (`plugin/`) as needed.
- **Build & verify when feasible:**

```bash
bun install
bun run build
bun run typecheck
```

If Nitro specs (`*.nitro.ts`) changed, run `bun run codegen` and commit `nitrogen/generated/` when output changes.

Do **not** commit secrets, OAuth config files, or API keys.

### 4. Check and update documentation

After the code fix, decide whether docs need updates. Update when the fix changes any of:

| Change type | Update location |
| ----------- | --------------- |
| Public API, types, or behavior | `docs/content/guide/api-reference.md`, `docs/content/guide/usage.md` |
| Setup / platform config | `docs/content/setup/` (android, ios, expo, google-cloud) |
| Troubleshooting / known issues | `docs/content/guide/troubleshooting.md` |
| Agent-facing API or setup | `skills/react-native-nitro-google-signin/` (`SKILL.md`, `reference.md`, `examples.md`) |

If docs change:

```bash
cd docs && bun run build
```

Skip doc updates only when the fix is purely internal with zero user-visible impact — note that decision in the PR.

### 5. Commit

Follow the repository's commit message style (check `git log -5`). One focused commit is preferred; use multiple only if logically separate.

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

Fixes #<number>

EOF
)"
```

Never use `--no-verify`, never amend unless explicitly requested, never force-push to main.

### 6. Push and create the pull request

```bash
git push -u origin HEAD
```

Create the PR with `gh`:

```bash
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
)"
```

Return the **PR URL** to the user when done.

## Output format

When finished, report:

1. **Issue** — title, number, link
2. **Branch** — name
3. **Changes** — brief summary of files touched
4. **Docs** — what was updated, or why skipped
5. **PR** — link
6. **Test plan** — what was run vs what the user should verify manually

## Constraints

- Use `gh` for all GitHub operations (issues, PRs).
- Do not push or open PRs unless the fix is complete and builds pass (or you clearly note what could not be verified).
- Prefer fixing root cause over workarounds.
- If the issue is unclear, ambiguous, or needs product decisions, stop after analysis and ask the user before implementing.
- If the issue is already fixed or duplicate, report that and do not open a PR.