Review PigeonPod GitHub issues end to end. Use when the user asks what an issue means, whether it is valid, how to reply, whether to add it to the GitHub Project, or to turn it into a tracked task. Read the issue and comments, inspect relevant local docs and code, explain the real requirement or bug precisely, draft a maintainer reply, and only after explicit approval perform GitHub writes. When creating a task, first recommend `Priority`, `Size`, and `Estimate`, wait for maintainer confirmation or overrides, then write those values into the project task fields.
Analyze software bugs for the PigeonPod project with a bugfix-first workflow. Use when users report broken behavior, regressions, incorrect results, crashes, data inconsistencies, sync/download failures, or ask for root-cause analysis, fix strategy, repro analysis, severity assessment, or regression-risk evaluation. Read current repository docs and code first, then use MCP tools including Context7 only when framework, library, API, or external-service behavior must be verified.
Generate and process the daily PigeonPod issue triage report. Use when reviewing open GitHub issues incrementally with a text cursor, classifying issues as requirement, bug, or discussion, drafting maintainer-facing analysis, or executing developer-approved follow-up actions from the daily report.
Analyze product and technical requirements for the PigeonPod project with software engineering rigor. Use when users ask to evaluate a feature, enhancement, non-functional requirement, integration, or migration for value, feasibility, architecture fit, implementation impact, risk, delivery scope, or tradeoffs. Do not use for bug triage or root-cause analysis; use `bug-analysis` for bugfix-oriented work. Always inspect current repository docs and code first, then use MCP tools including Context7 to verify external library, framework, or API constraints before concluding.
Find open GitHub issues that are covered by a specific release note, draft issue replies in the issue author's language, post approved comments with `gh issue comment`, and recommend whether each issue should be closed. Use when Codex needs to turn a shipped release into structured GitHub issue follow-up, especially for PigeonPod release-note-driven maintainer workflows.
Draft, refine, and publish bilingual PigeonPod GitHub release notes from commits on the `release` branch. Use when Codex needs to compare commits since the latest published GitHub release, write a new local release note under `dev-docs/release-notes`, align English and Chinese release-note sections after user edits, or create/update a GitHub Release while keeping the markdown H1 as the GitHub release title instead of the release body.