菜单
This skill should be used when the user asks to 'watch PRs', 'monitor PR status', 'PRを監視', 'PRの状態を見て', 'babysit this PR', 'PRが通るまで見て', or when the agent needs to monitor PR health after push, PR creation, or CI failure detection.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
This skill should be used when the user asks to "lint AI assistant config", "check AGENTS.md", "validate SKILL.md", "agnix lint", or wants to detect and fix best-practice violations in Claude Code / agent configuration files.
This skill is the mandatory reference for all Claude Code hook creation. Use cc-hooks-ts for every hook. This skill should be used when the user asks to "create a hook", "add a hook", "write a hook", "implement a hook", "rewrite hooks in TypeScript", "use cc-hooks-ts", or needs to build any Claude Code hook — cc-hooks-ts is always required regardless of whether explicitly mentioned.
Auto-activate CCS CLI delegation for deterministic tasks. Parses user input, auto-selects optimal profile (glm/kimi/custom) from ~/.ccs/config.json, enhances prompts with context, executes via `ccs {profile} -p "task"` or `ccs {profile}:continue`, and reports results. Triggers on "use ccs [task]" patterns, typo/test/refactor keywords. Excludes complex architecture, security-critical code, performance optimization, breaking changes.
This skill should be used when the user asks to "handoff from CCS", "Claude Codeの作業を引き継ぐ", "rate limit handoff", "context overflow", or wants to resume interrupted work from another CCS profile session.
This skill should be used when the user asks for "code review", "レビューして", "review this diff", "実装をレビュー", or wants rigorous review of recently created artifacts.
Direct utility reference for code-review PR scripts. Documents unresolved-thread, comment, CI-status, and CI-log helpers used by higher-level PR workflows.
| name | github-workflow:watch-pr |
| description | This skill should be used when the user asks to 'watch PRs', 'monitor PR status', 'PRを監視', 'PRの状態を見て', 'babysit this PR', 'PRが通るまで見て', or when the agent needs to monitor PR health after push, PR creation, or CI failure detection. |
| tools | ["Read"] |
Reference guide for monitoring GitHub PRs. Read this BEFORE starting any PR monitoring to avoid silent failures.
Read references/pitfalls.md for the full list of edge cases that silently break PR monitoring.
When monitoring a PR, evaluate conditions in this order. The first match determines the action — do NOT skip ahead.
mergeStateStatus: dirty) — Resolve conflicts FIRST. GHA pull_request workflows are not dispatched while conflicts exist (see "Key Rule" below).mergeStateStatus: behind) — If "require branches to be up to date" is enabled, run git fetch origin && git merge origin/<base> && git push to update the PR branch.code-review:check-pr CI checker.ci-watcher agent in background.code-review:check-pr review checker.blocked) — Waiting on reviewers. Report pending.Per GitHub's official documentation: "Workflows will not run on pull_request activity if the pull request has a merge conflict. The merge conflict must be resolved first." This is confirmed by real-world observation across multiple projects — GHA workflows are not dispatched and do not appear in gh pr checks.
Exceptions:
pull_request_target trigger — Runs even with conflicts (it targets the base branch, not the merge ref).push-triggered workflows — Run on the head commit regardless, but do not test the merged state.Always check conflict status first. If conflicts exist, resolve them before evaluating CI — GHA checks will not arrive until the PR is conflict-free.
Always run gh pr view --json mergeable,mergeStateStatus BEFORE gh pr checks.
The base branch may be updated by other merges while CI is running. After CI completes, re-check the PR merge state — conflicts may have appeared during the CI run, invalidating the results.
mergeStateStatus ValuesPossible values for the REST API mergeable_state field (lowercase) and the GraphQL MergeStateStatus enum (uppercase). Not all values are documented — some are observed in practice.
clean — Mergeable and passing commit status. Review status is NOT encoded here — check reviewDecision (GraphQL only) separately.dirty — Merge conflicts exist. GHA pull_request workflows will not run.blocked — Branch protection rules not met (required reviews, required checks pending or failed, or merge queue).unstable — Mergeable with non-passing commit status. The failing checks are non-required — if required checks fail, the state is blocked instead.behind — Head branch is behind the base branch. May need to update before merging if "require branches to be up to date" is enabled.unknown — GitHub has not yet computed the merge state.has_hooks / HAS_HOOKS — Observed (not officially documented): mergeable with passing commit status and pre-receive hooks present. Primarily seen on GitHub Enterprise Server. Treat as a positive state similar to clean.mergeable Can Be nullGitHub computes mergeability asynchronously. The first API call after a push often returns mergeable: null. Retry 2-3 times with 2-second delays. Do NOT proceed with monitoring until mergeable has a definitive value.
ci-watcher agent — Background CI watching after confirming no conflicts. Auto-detects current branch PR.code-review:check-pr — CI failure log analysis and review comment fix workflows.code-review:github-pr — Lower-level utility scripts. Use via check-pr, not directly.references/pitfalls.md — GitHub PR monitoring pitfalls — edge cases that silently break monitoring workflows