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 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.