Add self-approve-pr skill

[geekygecko]

Description

Adds a self-approve-pr skill that decides whether a Pocket Casts Android PR can be self-approved by its author instead of requiring a human reviewer. The skill runs five gates (ownership/primary-platform, CI status, outstanding feedback, critical-area avoidance, and low-risk judgment). When every gate passes it applies the [Review] Self Approved label. It deliberately does not merge: branch protection blocks a CLI merge without an approving review, so the author completes the merge from the GitHub UI ("Merge without waiting for requirements to be met (bypass rules)" then "Squash and merge").

This keeps trust cheap to extend for small, safe changes while making sure risky diffs (playback, database, sync, payments, auth, downloads) always get a second pair of eyes.

Fixes #

Testing Instructions

1. Check out this branch so the skill is available.
2. Run /self-approve-pr check <pr-number> on an open PR you authored and confirm the five-gate table renders with PASS/FAIL reasons and no label is applied in check mode.
3. Run /self-approve-pr <pr-number> on a small, low-risk PR of your own that has green CI and no outstanding feedback; confirm it asks for confirmation, then applies the [Review] Self Approved label and stops without merging.
4. Confirm it directs you to merge via the GitHub UI bypass flow.
5. Run it against a PR that touches a critical area (e.g. a Room migration) and confirm gate 4 fails and it refuses to label.

Screenshots or Screencast

Not applicable (no UI change).

Checklist

• If this is a user-facing change, I have added an entry in CHANGELOG.md
• Ensure the linter passes (./gradlew spotlessApply to automatically apply formatting/linting)
• I have considered whether it makes sense to add tests for my changes
• All strings that need to be localized are in modules/services/localization/src/main/res/values/strings.xml
• Any jetpack compose components I added or changed are covered by compose previews
• I have updated (or requested that someone edit) the Event Horizon schema to reflect any new or changed analytics.

[claude]

Claude finished @geekygecko's task in 55s —— View job

---

PR Review: Add self-approve-pr skill

I reviewed .agents/skills/self-approve-pr/SKILL.md. This is a well-written, thoughtfully-scoped skill — the gate rationale is clear and the risk model (never self-merge critical areas; keep the human in the UI merge loop) is sound. I found two concrete correctness issues in the allowed-tools list and a few smaller notes.

• Read the changed file
• Analyze allowed-tools vs. commands actually used
• Review gate logic, security, and edge cases

---

🔴 allowed-tools is missing the two most important commands

The frontmatter allowed-tools (line 4) does not cover two commands the skill relies on, so both will hit a permission prompt / be blocked when the skill runs unattended:

1. gh pr edit — the core labelling action. Line 86 runs:

   gh pr edit <num> --add-label "[Review] Self Approved"

   But allowed-tools only permits gh pr view *, gh pr checks *, and gh pr diff *. There is no Bash(gh pr edit *). This is the whole point of the skill in non-check mode, so it should be allowed explicitly.

2. gh api graphql — gate 3's unresolved-thread check. Lines 43-48 call gh api graphql -F number=<num> -f query=.... The allowed gh api patterns are gh api user *, gh api orgs/Automattic/teams/pocket-casts-android/*, and gh api repos/Automattic/pocket-casts-android/*. None of these match gh api graphql, so gate 3 will fail to run cleanly.

Suggested addition to line 4:

Bash(gh pr edit * --add-label *), Bash(gh api graphql *)

(Scoping gh pr edit to --add-label keeps the skill from being able to make other PR edits.)

Fix this →

---

🟡 Smaller notes

• --repo guidance vs. examples (line 15). The skill says to pass --repo Automattic/pocket-casts-android explicitly "to be safe", but none of the example commands (lines 16, 27, 33, 86, etc.) include it. Either add it to the examples or soften the instruction, so the model isn't given conflicting guidance.
• reviewThreads(first: 100) pagination (line 46). On a PR with more than 100 review threads the query silently misses the tail, which could let an unresolved thread slip past gate 3. Rare in practice, but worth a one-line note that the count is capped (or paginate).
• Bypass-merge assumption (line 87). The final instruction assumes the author has permission to "Merge without waiting for requirements... (bypass rules)". If branch protection doesn't grant the author bypass, the documented flow dead-ends. A sentence noting this requires repo bypass permission would set expectations.

None of these are blocking except the allowed-tools gaps, which I'd recommend fixing before merge since they break the skill's happy path. Nice work overall — the gate design is careful and the writing is clear.

[dangermattic]

	1 Message
📖	This PR is still a Draft: some checks will be skipped.

Generated by 🚫 Danger