pick
Fetch open todo issues from a repo, analyze them, and pick the best one to work on next. Prefers PRs with review feedback over new issues.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Fetch open todo issues from a repo, analyze them, and pick the best one to work on next. Prefers PRs with review feedback over new issues.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Analyze workflow runs and produce a daily reflection.
Execute a work plan. Make changes, run validation, commit.
Review open issues and close obsolete, resolved, or duplicate ones. Label underspecified issues. Split oversized issues.
Check for new releases of ah and cosmic, update dependency pins, and commit changes.
Research a codebase and write a plan for a work item.
Review work execution against the plan. Validate changes, check for issues, render verdict.
| name | pick |
| description | Fetch open todo issues from a repo, analyze them, and pick the best one to work on next. Prefers PRs with review feedback over new issues. |
You are selecting the next work item from a GitHub repository. PRs with review feedback take priority over new issues.
WORK_REPO environment variable. All tools read it automatically.ensure_labels (no arguments needed — reads repo from environment).get_prs_with_feedback (no arguments needed).updatedAt (longest waiting for attention).
b. Write your output with type set to "pr" and the PR details. Include the reason field from the tool result.
c. Skip the remaining steps.count_open_prs (no arguments needed). If more than 4, write o/pick/issue.json with {"error": "pr_limit"} and stop.list_issues (no arguments needed) to get open issues (returns issues labeled todo plus issues filed by repo collaborators).todo — collaborator-filed issues without todo are lower priority candidates. For each, assess:
set_issue_labels with issue_number set to the issue number, add set to ["doing"], remove set to ["todo"].Write o/pick/issue.json:
For a PR with feedback:
{
"type": "pr",
"number": 123,
"title": "...",
"body": "...",
"url": "https://github.com/owner/repo/pull/123",
"branch": "<headRefName from PR>",
"reason": "<changes_requested|checks_failing|merge_conflict|changes_requested,checks_failing|...>",
"reviews": [
{
"author": "username",
"body": "review body text",
"state": "CHANGES_REQUESTED",
"submittedAt": "2026-01-01T00:00:00Z",
"comments": [
{
"path": "file.tl",
"line": 42,
"body": "inline comment text",
"createdAt": "2026-01-01T00:00:00Z"
}
]
}
],
"comments": [...]
}
Copy the reviews array exactly as returned by get_prs_with_feedback, including each review's nested comments array (inline review comments). These inline comments contain file-specific feedback that downstream phases need to address.
For an issue:
{
"type": "issue",
"number": 123,
"title": "...",
"body": "...",
"url": "https://github.com/owner/repo/issues/123",
"branch": "work/<number>-<8 random hex chars>"
}
The branch name for issues must be work/<number>-<8 random hex chars>.
Write o/pick/reasoning.md: brief explanation of why this work item was picked over others.
If there are no PRs with feedback and no open todo issues, write o/pick/issue.json containing {"error": "no_issues"} and explain in reasoning.md.
When any tool call fails, classify the error and write o/pick/issue.json with exactly {"error": "<code>"} (no other fields). Use one of these codes:
| code | when to use |
|---|---|
no_issues | no PRs with feedback and no open todo issues found |
pr_limit | more than 4 open PRs |
auth_failure | tool returns 401, 403, "not accessible", "bad credentials", or other authentication/permission errors |
api_failure | tool returns gh CLI or GraphQL errors that are not auth-related (network errors, 5xx, malformed responses) |
label_failure | ensure_labels fails (prevents safe pick) |
Classification rules:
auth_failure.ensure_labels fails → label_failure.api_failure.