github-ops

name	github-ops
description	GitHub issue, PR, and release operations via gh CLI. Not for code review or release builds.
version	2.1.0
allowed-tools	["Bash","Read"]

GitHub Operations Skill

Use this skill when working with GitHub issues, PRs, and releases for Pake. It carries the project facts and boundaries; standard gh usage is assumed.

Golden Rule

Always use gh CLI and query live state before acting. Never assume state from memory or a previous turn.

Project Facts

• Repo: tw93/Pake. Workflows: release.yml (V* tag, builds app assets), npm-publish.yml (npm Trusted Publishing; also workflow_dispatch from main for npm-only hotfixes), quality-and-test.yml (push CI), pake-cli.yaml / single-app.yaml (public build surfaces external users trigger from forks).
• Poll CI with gh run view <run-id> --json status,conclusion. Never pipe gh run watch or build output through tail/head; pipes swallow the real exit code and misreport failures as green.
• Verify npm state with npm view pake-cli@<version> version gitHead dist.tarball --json; gitHead ties the published package to the intended commit. Check the latest pointer separately with npm view pake-cli version; it can point at a different commit than the fix under review.
• Inline PR review comments live at gh api repos/tw93/Pake/pulls/<n>/comments; gh pr view does not show them.
• App-release truth is gh release view <tag> --json assets (asset count/state), not workflow names or source state.

Safety Rules

1. ALWAYS draft the reply first and show it to the user for approval before calling any write operation (gh issue comment, gh pr comment, gh pr merge, gh issue close, gh release create, etc.). Approval of one draft does not extend to future comments.
2. NEVER merge, close, or modify without explicit user request.
3. ALWAYS query current state before taking action — never assume.
4. Before replying to an issue or PR, read the body to confirm the author's language; match their language in the reply. This applies to the author, not to arbitrary thread commenters.
5. Before replying that a CLI fix is released, verify the exact artifact with npm view pake-cli@<version> version gitHead dist.tarball --json and confirm gitHead contains the fix. Check npm view pake-cli version separately for the latest pointer. For app releases, use gh release view <tag> --json assets.
6. Before closing an issue after release, confirm the target with gh issue view <id> --json number,title,state,author,url and include the concrete version or upgrade command in the comment.