[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXQY6MRRZ78VG77Y2NBAFC":3,"skill-same:01M6DXQY6MRRZ78VG77Y2NBAFC":93},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M6DXQY6MRRZ78VG77Y2NBAFC","respond-to-pr",null,"Respond to pull request review feedback interactively, working through each item with verification and code changes. Use when the user wants to address PR review comments.","atomicinnovation\u002Faccelerator","atomicinnovation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F65866524?v=4","01M6DXP513JV585FN2QPNR6079","Atomic","01M6DXP55MPK99YVZ2HGMEN991",34,"MIT","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fgithub\u002Frespond-to-pr\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"pr","respond","respond to pr","feedback","when","review feedback","request","number","URL","base","use","user","repo","address pr review","review","Bash","pull request review","pull","verification","code","pull request","collaboration","pr review","config","pr review comments","2026-11-10 10:12:30",false,"---\nname: respond-to-pr\ndescription: Respond to pull request review feedback interactively, working\n  through each item with verification and code changes. Use when the user wants\n  to address PR review comments.\nargument-hint: \"[PR number or URL]\"\nallowed-tools:\n   - Bash(accelerator config *)\n   - Bash(accelerator collaboration pr base-repo *)\n---\n\n# Respond to PR\n\n!`accelerator config context --skill respond-to-pr --fail-safe`\n\n**PR reviews directory**: !`accelerator config path review_prs --fail-safe`\n\nYou are tasked with working through outstanding pull request review feedback\nin a systematic, interactive fashion. For each piece of feedback, you verify\nit against the codebase, confirm the approach with the user, make changes,\nand respond on GitHub.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **Check if a PR number or URL was provided**:\n\n- If a PR number or URL was provided as an argument, identify the PR\n  immediately\n- Begin the process\n\n2. **If no argument provided**, respond with:\n\n```\nI'll help you respond to pull request review feedback. Please provide:\n1. The PR number or URL (or I'll check the current branch)\n\nTip: You can invoke this command with an argument:\n  `\u002Frespond-to-pr 123`\n```\n\nThen check if the current branch has a PR:\n`gh pr view --json number,url,title,state 2>\u002Fdev\u002Fnull`\n\nIf a PR is found on the current branch, offer to use it. If not, wait for\nthe user's input.\n\n## Process Steps\n\n### Step 1: Fetch PR Context and Outstanding Feedback\n\n1. **Get PR metadata**:\n   ```bash\n   gh pr view {number} --json number,url,title,state,baseRefName,headRefName\n   ```\n\n2. **Validate PR state**: Check that `state` is `OPEN`. If the PR is closed\n   or merged, inform the user and use the `AskUserQuestion` tool with two\n   options:\n   1. **Yes, proceed anyway** — continue responding to a closed\u002Fmerged PR\n   2. **No, abort** — exit the workflow\n   If the user chooses No, exit the workflow.\n\n3. **Get repo info and current user**:\n   ```bash\n   accelerator collaboration pr base-repo {number}\n   gh api user --jq '.login'\n   ```\n\n4. **Ensure on the correct branch**: Check the current branch or bookmark\n   using the appropriate VCS command for this repository (refer to the\n   session's VCS context). Compare with the PR's `headRefName`. If different,\n   inform the user and use the `AskUserQuestion` tool with two options:\n   1. **Yes, switch to PR branch** — check out [headRefName] before continuing\n   2. **No, stay on current branch** — continue without switching\n\n5. **Check for a structured review artifact**:\n\n   Look for `{pr reviews directory}\u002F{number}-review-*.md` (e.g.,\n   `123-review-1.md`, `123-review-2.md`). If one or more files match:\n\n- Load the highest-numbered file (the most recent review cycle)\n- Read the review document\n- Extract the verdict, lenses used, and per-lens findings\n- Note the severity and confidence of each finding\n- This will inform the triage in Step 2\n\nIf no matching files are found, proceed without review context — the\nskill works the same as before, just without the additional context.\n\n6. **Fetch review threads via GraphQL** (primary source for inline feedback):\n\n   Use the GraphQL API as the single source of truth for review thread data.\n   This avoids the need to correlate REST and GraphQL IDs — each thread node\n   includes the thread ID (for resolution), resolution status, and all comment\n   data in one query.\n\n   ```bash\n   gh api graphql -f query='\n     query($owner: String!, $repo: String!, $number: Int!, $cursor: String) {\n       repository(owner: $owner, name: $repo) {\n         pullRequest(number: $number) {\n           reviewThreads(first: 100, after: $cursor) {\n             pageInfo { hasNextPage endCursor }\n             nodes {\n               id\n               isResolved\n               isOutdated\n               path\n               line\n               comments(first: 100) {\n                 nodes {\n                   id\n                   databaseId\n                   body\n                   author { login }\n                   createdAt\n                 }\n               }\n             }\n           }\n         }\n       }\n     }\n   ' -f owner=\"{owner}\" -f repo=\"{repo}\" -F number={number}\n   ```\n\n   **Pagination**: Check `pageInfo.hasNextPage`. If true, re-run the query\n   with `-f cursor=\"{endCursor}\"` to fetch the next page. Repeat until all\n   threads are fetched. If the total exceeds 100 threads, inform the user of\n   the count so they know the full scope.\n\n7. **Fetch top-level reviews and issue comments via REST**:\n\n   These are not part of the review thread model and require REST:\n\n   ```bash\n   # Reviews (top-level review bodies and verdicts)\n   gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Freviews --paginate\n\n   # Issue comments (conversation-level discussion)\n   gh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002F{number}\u002Fcomments --paginate\n   ```\n\n   **Note**: Issue comments and top-level review bodies cannot be \"resolved\"\n   via the `resolveReviewThread` mutation — they are not part of the review\n   thread model. These items follow a \"respond only\" path in Step 4 (skip\n   the resolve step).\n\n8. **Error handling** (standard pattern):\n   - `gh` not installed or not authenticated: suggest `gh auth login`\n   - No default remote: suggest `gh repo set-default`\n   - PR not found: inform user, list open PRs with `gh pr list --limit 10`\n   - Rate limiting (HTTP 403 with rate limit headers): inform the user,\n     suggest waiting and retrying\n   - GraphQL errors: check for an `errors` key in the response before\n     processing `data`; report specific error messages to the user\n   - Network\u002Fconnectivity failures: suggest checking `gh auth status`\n\n   **Mid-workflow error recovery** (for Steps 4e and 4f):\n   - Thread reply fails (404 — thread deleted or outdated after force-push):\n     offer to post as a top-level PR comment instead\n   - Thread resolution fails (permission or stale thread ID): inform user\n     the thread was not resolved; suggest resolving manually on GitHub\n   - Partial failure (code changed but response not posted): clearly state\n     what succeeded and what failed so the user knows the current state\n\n### Step 2: Filter and Triage Feedback\n\n1. **Filter out noise**:\n   - Exclude resolved review threads (using GraphQL `isResolved` data)\n   - Exclude reviews with verdict `APPROVED` that have no body text\n   - Exclude bot comments (e.g., CI bots) unless they contain actionable\n     feedback\n\n2. **Categorise each piece of feedback**:\n\n   | Category | Description | Examples |\n   |----------|-------------|---------|\n   | **Blocking** | Must fix before merge | Changes requested, security issues, bugs |\n   | **Simple** | Quick fixes, low risk | Typos, naming, import ordering, small refactors |\n   | **Complex** | Requires thought\u002Fdiscussion | Architecture changes, design decisions, large refactors |\n   | **Question** | Needs a response, not code changes | Clarification requests, \"why did you...\" |\n   | **Disagreement** | Feedback appears incorrect or inappropriate | Suggestions that would break things, misunderstandings |\n\n   If a structured review artifact was loaded in Step 1, cross-reference\n   GitHub review comments against the review's findings. For each comment\n   that matches a finding from the review:\n\n   - Use the finding's `severity` to inform the category (critical severity\n     → Blocking; major affecting multiple files or requiring design decisions\n     → Complex; major affecting a single file with a clear fix → Simple)\n   - Note the `confidence` level — low-confidence findings may warrant\n     more careful verification in Step 4a\n   - Note the `lens` — this provides context about what quality dimension\n     the finding addresses\n   - If the review's cross-cutting themes are relevant, mention them when\n     presenting the item to the user in Step 3\n\n3. **Group by review thread**: Keep inline comments that belong to the same\n   review thread together — they share context and should be addressed as a\n   unit.\n\n4. **Order by priority**: Blocking > Simple > Complex > Question >\n   Disagreement. Within the same category, order by reviewer (address one\n   reviewer's feedback before moving to the next for coherence).\n\n5. **Handle empty result**: If no outstanding feedback remains after\n   filtering (all threads resolved, no actionable comments), inform the\n   user:\n   ```\n   No outstanding feedback on PR #{number}. All review threads are resolved.\n   ```\n   If there are reviewers who previously requested changes, offer to\n   re-request review from them. Then exit the workflow.\n\n### Step 3: Present Feedback Summary and Gather Preferences\n\nIf a review artifact was loaded, add a note after the header:\n\n```\n> Review context loaded from `{pr reviews directory}\u002F{number}-review-{N}.md`\n> (verdict: {verdict}, {N} lenses, {date})\n```\n\nPresent the triaged feedback to the user with a total count upfront:\n\n```\n## Outstanding Feedback for PR #{number}: {title}\n\nFound **{total} items** of outstanding feedback ({blocking_count} blocking,\n{simple_count} simple, {complex_count} complex, {question_count} questions,\n{disagreement_count} potential disagreements).\n\n### Blocking ({count})\n1. **{reviewer}** on `{file}:{line}` — {summary of comment}\n2. ...\n\n### Simple Fixes ({count})\n3. **{reviewer}** on `{file}:{line}` — {summary of comment}\n4. ...\n\n### Complex Changes ({count})\n5. **{reviewer}** — {summary of review body or comment}\n6. ...\n\n### Questions to Answer ({count})\n7. **{reviewer}** on `{file}:{line}` — {summary of question}\n8. ...\n\n### Potential Disagreements ({count})\n9. **{reviewer}** on `{file}:{line}` — {summary + why it may be wrong}\n10. ...\n```\n\nAfter the summary, gather workflow preferences:\n\n```\nBefore we start, a few preferences:\n\n1. **Working mode**:\n   a. **Guided** — confirm each item individually (recommended for complex\u002F\n      disagreement items)\n   b. **Express** — for Simple items, present change + response together and\n      apply without per-step confirmation; Guided for all other categories\n\n2. **Commit strategy**:\n   a. Commit after each item\n   b. Commit after each category\n   c. Commit at the end (or when you say so)\n\n3. **Thread resolution**:\n   a. Resolve threads after responding (default)\n   b. Leave threads for reviewers to resolve\n\n4. **Order**: Proceed in the order above, or re-prioritise \u002F skip items?\n```\n\nWait for user confirmation and preferences before proceeding.\n\n### Step 4: Work Through Each Item\n\nAt any point during this step, the user can:\n- **Skip**: \"Skip this item\" — mark as deferred, move to the next item\n- **Stop**: \"Stop here\" — present a progress summary of what was addressed\n  vs. remaining, and exit the workflow\n\nFor each feedback item, follow this cycle (adapting to guided vs express\nmode as selected in Step 3):\n\n**4a. Verify the feedback:**\n\n- Read the relevant code in the codebase (not just the diff)\n- Understand the reviewer's concern in full context\n- Check if the feedback is technically correct\n- Check if the suggested change would break anything\n\n**4b. Present analysis to the user:**\n\nFor items where the feedback is correct:\n\n```\n### Item {N}: {summary}\n**Reviewer**: {name} on `{file}:{line}`\n**Feedback**: {quote or summary}\n\n**Analysis**: {explanation of the issue and what the reviewer is asking for}\n\n**Proposed change**: {description of what you'll do}\n**Draft response**: \"Fixed. {concise description of what will be changed}\"\n\n```\n\nUse the `AskUserQuestion` tool with two options:\n1. **Yes, apply this change** — make the edit now\n2. **No, skip this item** — leave it unaddressed and move on\n\n```\n```\n\nFor items where the feedback seems incorrect (Disagreement category):\n\n```\n### Item {N}: {summary}\n**Reviewer**: {name} on `{file}:{line}`\n**Feedback**: {quote or summary}\n\n**Analysis**: I've verified this against the codebase and believe the current\nimplementation is correct because:\n- {reason 1}\n- {reason 2}\n\n**Draft response** (if pushing back): \"{technical reasoning}\"\n\nUse the `AskUserQuestion` tool with three options:\n\n1. **Push back** — post the draft reasoning as a response\n2. **Implement anyway** — make the suggested change\n3. **Propose alternative** — draft an alternative approach\n```\n\nFor questions (no code changes needed):\n\n```\n### Item {N}: {summary}\n**Reviewer**: {name} on `{file}:{line}`\n**Question**: {quote}\n\n**Draft response**: {response explaining the reasoning}\n\n```\n\nUse the `AskUserQuestion` tool with two options:\n1. **Post as-is** — submit the draft response to GitHub\n2. **Adjust first** — revise the response before posting\n\n```\n```\n\nIn all cases, show the user the exact text that will be posted to GitHub\nbefore posting it. The user can edit the draft response before it is sent.\n\n**4c. Implement the change** (upon user confirmation):\n\n- Make the code changes using Edit\u002FWrite tools\n- Read surrounding code for context before editing\n- Keep changes focused on what the feedback asked for\n\n**4d. Commit** (according to the user's preference from Step 3):\n\n- **Per-item**: Offer to commit after this item. Show files modified and a\n  suggested commit message.\n- **Per-category**: Track changes. When the current category is complete,\n  offer to commit all changes in that category.\n- **At-end**: Track changes but don't offer to commit until Step 5.\n\nWhen committing, follow the `commit` skill pattern using the appropriate\nVCS commands for this repository (refer to the session's VCS context).\nKeep commits focused and atomic.\n\n**4e. Respond on GitHub:**\n\nReply in the specific comment thread (not as a top-level comment):\n\n```bash\n# For inline review comments — reply in the thread\ngh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n  --method POST -f body=\"Fixed. {concise description of what was changed}\"\n```\n\nFor questions or disagreements:\n\n```bash\ngh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n  --method POST -f body=\"{response text}\"\n```\n\nFor top-level review body comments:\n\n```bash\ngh pr comment {number} --body \"{response text}\"\n```\n\nResponse style:\n\n- Factual and concise: \"Fixed. Renamed the variable to match the convention.\"\n- No performative agreement: NOT \"Great point! You're absolutely right!\"\n- For pushback: Technical reasoning, not defensiveness\n- For questions: Clear explanation of the reasoning\n\n**4f. Resolve the review thread** (review thread items only):\n\nFor items that belong to a review thread (inline code comments from the\nGraphQL query), resolve the thread via GraphQL if the user chose to\nauto-resolve in their preferences:\n\n```bash\ngh api graphql -f query='\n  mutation($threadId: ID!) {\n    resolveReviewThread(input: {threadId: $threadId}) {\n      thread { isResolved }\n    }\n  }\n' -f threadId=\"{thread_node_id}\"\n```\n\nThe `threadId` is the GraphQL node `id` from the review threads query in\nStep 1.\n\n**For issue comments and top-level review body comments**: Skip this step.\nThese are not part of the review thread model and cannot be resolved via the\nGitHub API. Note this in the item's completion message.\n\n**4g. Move to next item:**\n\n```\nItem {N} addressed and thread resolved. Moving to item {N+1}...\n```\n\nRepeat the cycle for each remaining item.\n\n### Step 5: Wrap Up\n\nAfter all items have been addressed (or the user says \"stop here\"):\n\n1. **Present summary**:\n   ```\n   ## Summary\n\n   {addressed_count} of {total_count} feedback items addressed:\n   - {change_count} changes implemented\n   - {question_count} questions answered\n   - {pushback_count} items pushed back on\n   - {skip_count} items skipped\u002Fdeferred\n   - {commit_count} commits created\n\n   Changes are on branch `{branch_name}`.\n   ```\n\n   If items were skipped or deferred, note:\n   ```\n   {skip_count} items were skipped. You can re-run `\u002Frespond-to-pr {number}`\n   to pick up remaining unresolved items.\n   ```\n\n2. **Offer to push** (if there are unpushed commits): use the `AskUserQuestion`\n   tool with two options:\n   1. **Yes, push now** — push committed changes to the remote\n   2. **No, skip** — leave changes unpushed\n\n3. **Offer to re-request review**: present the list of reviewers who left\n   feedback, then use the `AskUserQuestion` tool with two options:\n   1. **Yes, re-request** — re-request review from the listed reviewers\n   2. **No, skip** — leave review requests as-is\n\n   If yes:\n   ```bash\n   echo '{\"reviewers\":[\"reviewer1\",\"reviewer2\"]}' | \\\n     gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Frequested_reviewers \\\n       --method POST --input -\n   ```\n\n## Important Guidelines\n\n1. **Verify before implementing** — Always check the reviewer's suggestion\n   against the actual codebase before making changes. The reviewer may not\n   have full context.\n\n2. **One item at a time** — Work through feedback sequentially. In guided\n   mode, each item gets its own verify-implement-respond cycle. In express\n   mode, simple items can be presented and applied more efficiently.\n\n3. **Confirm before acting** — In guided mode, always present your analysis\n   and proposed approach before making code changes or posting GitHub\n   responses. In express mode, present the change and response together\n   but still show what will be done before doing it.\n\n4. **Factual responses only** — Reply with what was done (\"Fixed. Extracted\n   the helper into a shared utility.\"), not with performative agreement\n   (\"Great catch! You're absolutely right!\").\n\n5. **Technical pushback when warranted** — If feedback is incorrect, present\n   the technical reasoning to the user. Don't implement changes you believe\n   are wrong without flagging them.\n\n6. **Respect commit preference** — Follow the user's chosen commit strategy\n   (per-item, per-category, or at-end). Keep commits atomic and focused.\n   Follow the `commit` skill pattern for this repository's VCS (refer to\n   session VCS context). Keep commits focused and atomic.\n\n7. **Reply in threads** — Always reply in the specific comment thread, not\n   as a new top-level comment. This keeps the conversation organised.\n\n8. **Respect the user's judgment** — For disagreements, present your analysis\n   but let the user decide. They may have context you don't.\n\n9. **Handle errors gracefully** — Follow the error recovery guidance in\n   Step 1.7. For mid-workflow failures, clearly state what succeeded and\n   what failed, and offer specific alternatives (e.g., post as top-level\n   comment, resolve manually, retry).\n\n10. **Don't over-change** — When implementing feedback, change only what was\n    asked for. Don't refactor surrounding code, add comments to unchanged\n    lines, or \"improve\" things that weren't mentioned.\n\n11. **Re-invocation is resumption** — If the user stops mid-way and later\n    re-runs `\u002Frespond-to-pr {number}`, the resolved-thread filter in Step 2\n    naturally excludes already-addressed items. Inform the user: \"I see N\n    threads were already resolved, picking up from the remaining M items.\"\n\n## What NOT to Do\n\n- Don't make code changes without user confirmation\n- Don't post GitHub responses without showing the user first\n- Don't implement all changes at once — work through them one at a time\n- Don't skip the verification step — always check the codebase first\n- Don't use performative language in GitHub responses\n- Don't commit without following the user's chosen commit strategy\n- Don't resolve threads without having addressed the feedback\n- Don't automatically re-request review — always offer first\n- Don't add co-author information or Claude attribution to commits\n- When staging files, always add specific files by name — never bulk-add\n\n## Relationship to Other Commands\n\nThe respond-to-pr skill fills a gap in the development lifecycle:\n\n1. `\u002Fcreate-plan` — Create the implementation plan\n2. `\u002Freview-plan` — Review and iterate the plan quality\n3. `\u002Fimplement-plan` — Execute the approved plan\n4. `\u002Fvalidate-plan` — Verify implementation matches the plan\n5. `\u002Fdescribe-pr` — Generate PR description\n6. `\u002Freview-pr` — Review the PR through quality lenses\n7. **`\u002Frespond-to-pr`** — Address review feedback (this command)\n8. `\u002Fcommit` — Commit changes (used within this workflow)\n\n!`accelerator config instructions respond-to-pr --fail-safe`\n","# Respond to PR\n\n!`accelerator config context --skill respond-to-pr --fail-safe`\n\n**PR reviews directory**: !`accelerator config path review_prs --fail-safe`\n\nYou are tasked with working through outstanding pull request review feedback\nin a systematic, interactive fashion. For each piece of feedback, you verify\nit against the codebase, confirm the approach with the user, make changes,\nand respond on GitHub.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **Check if a PR number or URL was provided**:\n\n- If a PR number or URL was provided as an argument, identify the PR\n  immediately\n- Begin the process\n\n2. **If no argument provided**, respond with:\n\n```\nI'll help you respond to pull request review feedback. Please provide:\n1. The PR number or URL (or I'll check the current branch)\n\nTip: You can invoke this command with an argument:\n  `\u002Frespond-to-pr 123`\n```\n\nThen check if the current branch has a PR:\n`gh pr view --json number,url,title,state 2>\u002Fdev\u002Fnull`\n\nIf a PR is found on the current branch, offer to use it. If not, wait for\nthe user's input.\n\n## Process Steps\n\n### Step 1: Fetch PR Context and Outstanding Feedback\n\n1. **Get PR metadata**:\n   ```bash\n   gh pr view {number} --json number,url,title,state,baseRefName,headRefName\n   ```\n\n2. **Validate PR state**: Check that `state` is `OPEN`. If the PR is closed\n   or merged, inform the user and use the `AskUserQuestion` tool with two\n   options:\n   1. **Yes, proceed anyway** — continue responding to a closed\u002Fmerged PR\n   2. **No, abort** — exit the workflow\n   If the user chooses No, exit the workflow.\n\n3. **Get repo info and current user**:\n   ```bash\n   accelerator collaboration pr base-repo {number}\n   gh api user --jq '.login'\n   ```\n\n4. **Ensure on the correct branch**: Check the current branch or bookmark\n   using the appropriate VCS command for this repository (refer to the\n   session's VCS context). Compare with the PR's `headRefName`. If different,\n   inform the user and use the `AskUserQuestion` tool with two options:\n   1. **Yes, switch to PR branch** — check out [headRefName] before continuing\n   2. **No, stay on current branch** — continue without switching\n\n5. **Check for a structured review artifact**:\n\n   Look for `{pr reviews directory}\u002F{number}-review-*.md` (e.g.,\n   `123-review-1.md`, `123-review-2.md`). If one or more files match:\n\n- Load the highest-numbered file (the most recent review cycle)\n- Read the review document\n- Extract the verdict, lenses used, and per-lens findings\n- Note the severity and confidence of each finding\n- This will inform the triage in Step 2\n\nIf no matching files are found, proceed without review context — the\nskill works the same as before, just without the additional context.\n\n6. **Fetch review threads via GraphQL** (primary source for inline feedback):\n\n   Use the GraphQL API as the single source of truth for review thread data.\n   This avoids the need to correlate REST and GraphQL IDs — each thread node\n   includes the thread ID (for resolution), resolution status, and all comment\n   data in one query.\n\n   ```bash\n   gh api graphql -f query='\n     query($owner: String!, $repo: String!, $number: Int!, $cursor: String) {\n       repository(owner: $owner, name: $repo) {\n         pullRequest(number: $number) {\n           reviewThreads(first: 100, after: $cursor) {\n             pageInfo { hasNextPage endCursor }\n             nodes {\n               id\n               isResolved\n               isOutdated\n               path\n               line\n               comments(first: 100) {\n                 nodes {\n                   id\n                   databaseId\n                   body\n                   author { login }\n                   createdAt\n                 }\n               }\n             }\n           }\n         }\n       }\n     }\n   ' -f owner=\"{owner}\" -f repo=\"{repo}\" -F number={number}\n   ```\n\n   **Pagination**: Check `pageInfo.hasNextPage`. If true, re-run the query\n   with `-f cursor=\"{endCursor}\"` to fetch the next page. Repeat until all\n   threads are fetched. If the total exceeds 100 threads, inform the user of\n   the count so they know the full scope.\n\n7. **Fetch top-level reviews and issue comments via REST**:\n\n   These are not part of the review thread model and require REST:\n\n   ```bash\n   # Reviews (top-level review bodies and verdicts)\n   gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Freviews --paginate\n\n   # Issue comments (conversation-level discussion)\n   gh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002F{number}\u002Fcomments --paginate\n   ```\n\n   **Note**: Issue comments and top-level review bodies cannot be \"resolved\"\n   via the `resolveReviewThread` mutation — they are not part of the review\n   thread model. These items follow a \"respond only\" path in Step 4 (skip\n   the resolve step).\n\n8. **Error handling** (standard pattern):\n   - `gh` not installed or not authenticated: suggest `gh auth login`\n   - No default remote: suggest `gh repo set-default`\n   - PR not found: inform user, list open PRs with `gh pr list --limit 10`\n   - Rate limiting (HTTP 403 with rate limit headers): inform the user,\n     suggest waiting and retrying\n   - GraphQL errors: check for an `errors` key in the response before\n     processing `data`; report specific error messages to the user\n   - Network\u002Fconnectivity failures: suggest checking `gh auth status`\n\n   **Mid-workflow error recovery** (for Steps 4e and 4f):\n   - Thread reply fails (404 — thread deleted or outdated after force-push):\n     offer to post as a top-level PR comment instead\n   - Thread resolution fails (permission or stale thread ID): inform user\n     the thread was not resolved; suggest resolving manually on GitHub\n   - Partial failure (code changed but response not posted): clearly state\n     what succeeded and what failed so the user knows the current state\n\n### Step 2: Filter and Triage Feedback\n\n1. **Filter out noise**:\n   - Exclude resolved review threads (using GraphQL `isResolved` data)\n   - Exclude reviews with verdict `APPROVED` that have no body text\n   - Exclude bot comments (e.g., CI bots) unless they contain actionable\n     feedback\n\n2. **Categorise each piece of feedback**:\n\n   | Category | Description | Examples |\n   |----------|-------------|---------|\n   | **Blocking** | Must fix before merge | Changes requested, security issues, bugs |\n   | **Simple** | Quick fixes, low risk | Typos, naming, import ordering, small refactors |\n   | **Complex** | Requires thought\u002Fdiscussion | Architecture changes, design decisions, large refactors |\n   | **Question** | Needs a response, not code changes | Clarification requests, \"why did you...\" |\n   | **Disagreement** | Feedback appears incorrect or inappropriate | Suggestions that would break things, misunderstandings |\n\n   If a structured review artifact was loaded in Step 1, cross-reference\n   GitHub review comments against the review's findings. For each comment\n   that matches a finding from the review:\n\n   - Use the finding's `severity` to inform the category (critical severity\n     → Blocking; major affecting multiple files or requiring design decisions\n     → Complex; major affecting a single file with a clear fix → Simple)\n   - Note the `confidence` level — low-confidence findings may warrant\n     more careful verification in Step 4a\n   - Note the `lens` — this provides context about what quality dimension\n     the finding addresses\n   - If the review's cross-cutting themes are relevant, mention them when\n     presenting the item to the user in Step 3\n\n3. **Group by review thread**: Keep inline comments that belong to the same\n   review thread together — they share context and should be addressed as a\n   unit.\n\n4. **Order by priority**: Blocking > Simple > Complex > Question >\n   Disagreement. Within the same category, order by reviewer (address one\n   reviewer's feedback before moving to the next for coherence).\n\n5. **Handle empty result**: If no outstanding feedback remains after\n   filtering (all threads resolved, no actionable comments), inform the\n   user:\n   ```\n   No outstanding feedback on PR #{number}. All review threads are resolved.\n   ```\n   If there are reviewers who previously requested changes, offer to\n   re-request review from them. Then exit the workflow.\n\n### Step 3: Present Feedback Summary and Gather Preferences\n\nIf a review artifact was loaded, add a note after the header:\n\n```\n> Review context loaded from `{pr reviews directory}\u002F{number}-review-{N}.md`\n> (verdict: {verdict}, {N} lenses, {date})\n```\n\nPresent the triaged feedback to the user with a total count upfront:\n\n```\n## Outstanding Feedback for PR #{number}: {title}\n\nFound **{total} items** of outstanding feedback ({blocking_count} blocking,\n{simple_count} simple, {complex_count} complex, {question_count} questions,\n{disagreement_count} potential disagreements).\n\n### Blocking ({count})\n1. **{reviewer}** on `{file}:{line}` — {summary of comment}\n2. ...\n\n### Simple Fixes ({count})\n3. **{reviewer}** on `{file}:{line}` — {summary of comment}\n4. ...\n\n### Complex Changes ({count})\n5. **{reviewer}** — {summary of review body or comment}\n6. ...\n\n### Questions to Answer ({count})\n7. **{reviewer}** on `{file}:{line}` — {summary of question}\n8. ...\n\n### Potential Disagreements ({count})\n9. **{reviewer}** on `{file}:{line}` — {summary + why it may be wrong}\n10. ...\n```\n\nAfter the summary, gather workflow preferences:\n\n```\nBefore we start, a few preferences:\n\n1. **Working mode**:\n   a. **Guided** — confirm each item individually (recommended for complex\u002F\n      disagreement items)\n   b. **Express** — for Simple items, present change + response together and\n      apply without per-step confirmation; Guided for all other categories\n\n2. **Commit strategy**:\n   a. Commit after each item\n   b. Commit after each category\n   c. Commit at the end (or when you say so)\n\n3. **Thread resolution**:\n   a. Resolve threads after responding (default)\n   b. Leave threads for reviewers to resolve\n\n4. **Order**: Proceed in the order above, or re-prioritise \u002F skip items?\n```\n\nWait for user confirmation and preferences before proceeding.\n\n### Step 4: Work Through Each Item\n\nAt any point during this step, the user can:\n- **Skip**: \"Skip this item\" — mark as deferred, move to the next item\n- **Stop**: \"Stop here\" — present a progress summary of what was addressed\n  vs. remaining, and exit the workflow\n\nFor each feedback item, follow this cycle (adapting to guided vs express\nmode as selected in Step 3):\n\n**4a. Verify the feedback:**\n\n- Read the relevant code in the codebase (not just the diff)\n- Understand the reviewer's concern in full context\n- Check if the feedback is technically correct\n- Check if the suggested change would break anything\n\n**4b. Present analysis to the user:**\n\nFor items where the feedback is correct:\n\n```\n### Item {N}: {summary}\n**Reviewer**: {name} on `{file}:{line}`\n**Feedback**: {quote or summary}\n\n**Analysis**: {explanation of the issue and what the reviewer is asking for}\n\n**Proposed change**: {description of what you'll do}\n**Draft response**: \"Fixed. {concise description of what will be changed}\"\n\n```\n\nUse the `AskUserQuestion` tool with two options:\n1. **Yes, apply this change** — make the edit now\n2. **No, skip this item** — leave it unaddressed and move on\n\n```\n```\n\nFor items where the feedback seems incorrect (Disagreement category):\n\n```\n### Item {N}: {summary}\n**Reviewer**: {name} on `{file}:{line}`\n**Feedback**: {quote or summary}\n\n**Analysis**: I've verified this against the codebase and believe the current\nimplementation is correct because:\n- {reason 1}\n- {reason 2}\n\n**Draft response** (if pushing back): \"{technical reasoning}\"\n\nUse the `AskUserQuestion` tool with three options:\n\n1. **Push back** — post the draft reasoning as a response\n2. **Implement anyway** — make the suggested change\n3. **Propose alternative** — draft an alternative approach\n```\n\nFor questions (no code changes needed):\n\n```\n### Item {N}: {summary}\n**Reviewer**: {name} on `{file}:{line}`\n**Question**: {quote}\n\n**Draft response**: {response explaining the reasoning}\n\n```\n\nUse the `AskUserQuestion` tool with two options:\n1. **Post as-is** — submit the draft response to GitHub\n2. **Adjust first** — revise the response before posting\n\n```\n```\n\nIn all cases, show the user the exact text that will be posted to GitHub\nbefore posting it. The user can edit the draft response before it is sent.\n\n**4c. Implement the change** (upon user confirmation):\n\n- Make the code changes using Edit\u002FWrite tools\n- Read surrounding code for context before editing\n- Keep changes focused on what the feedback asked for\n\n**4d. Commit** (according to the user's preference from Step 3):\n\n- **Per-item**: Offer to commit after this item. Show files modified and a\n  suggested commit message.\n- **Per-category**: Track changes. When the current category is complete,\n  offer to commit all changes in that category.\n- **At-end**: Track changes but don't offer to commit until Step 5.\n\nWhen committing, follow the `commit` skill pattern using the appropriate\nVCS commands for this repository (refer to the session's VCS context).\nKeep commits focused and atomic.\n\n**4e. Respond on GitHub:**\n\nReply in the specific comment thread (not as a top-level comment):\n\n```bash\n# For inline review comments — reply in the thread\ngh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n  --method POST -f body=\"Fixed. {concise description of what was changed}\"\n```\n\nFor questions or disagreements:\n\n```bash\ngh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Fcomments\u002F{comment_id}\u002Freplies \\\n  --method POST -f body=\"{response text}\"\n```\n\nFor top-level review body comments:\n\n```bash\ngh pr comment {number} --body \"{response text}\"\n```\n\nResponse style:\n\n- Factual and concise: \"Fixed. Renamed the variable to match the convention.\"\n- No performative agreement: NOT \"Great point! You're absolutely right!\"\n- For pushback: Technical reasoning, not defensiveness\n- For questions: Clear explanation of the reasoning\n\n**4f. Resolve the review thread** (review thread items only):\n\nFor items that belong to a review thread (inline code comments from the\nGraphQL query), resolve the thread via GraphQL if the user chose to\nauto-resolve in their preferences:\n\n```bash\ngh api graphql -f query='\n  mutation($threadId: ID!) {\n    resolveReviewThread(input: {threadId: $threadId}) {\n      thread { isResolved }\n    }\n  }\n' -f threadId=\"{thread_node_id}\"\n```\n\nThe `threadId` is the GraphQL node `id` from the review threads query in\nStep 1.\n\n**For issue comments and top-level review body comments**: Skip this step.\nThese are not part of the review thread model and cannot be resolved via the\nGitHub API. Note this in the item's completion message.\n\n**4g. Move to next item:**\n\n```\nItem {N} addressed and thread resolved. Moving to item {N+1}...\n```\n\nRepeat the cycle for each remaining item.\n\n### Step 5: Wrap Up\n\nAfter all items have been addressed (or the user says \"stop here\"):\n\n1. **Present summary**:\n   ```\n   ## Summary\n\n   {addressed_count} of {total_count} feedback items addressed:\n   - {change_count} changes implemented\n   - {question_count} questions answered\n   - {pushback_count} items pushed back on\n   - {skip_count} items skipped\u002Fdeferred\n   - {commit_count} commits created\n\n   Changes are on branch `{branch_name}`.\n   ```\n\n   If items were skipped or deferred, note:\n   ```\n   {skip_count} items were skipped. You can re-run `\u002Frespond-to-pr {number}`\n   to pick up remaining unresolved items.\n   ```\n\n2. **Offer to push** (if there are unpushed commits): use the `AskUserQuestion`\n   tool with two options:\n   1. **Yes, push now** — push committed changes to the remote\n   2. **No, skip** — leave changes unpushed\n\n3. **Offer to re-request review**: present the list of reviewers who left\n   feedback, then use the `AskUserQuestion` tool with two options:\n   1. **Yes, re-request** — re-request review from the listed reviewers\n   2. **No, skip** — leave review requests as-is\n\n   If yes:\n   ```bash\n   echo '{\"reviewers\":[\"reviewer1\",\"reviewer2\"]}' | \\\n     gh api repos\u002F{owner}\u002F{repo}\u002Fpulls\u002F{number}\u002Frequested_reviewers \\\n       --method POST --input -\n   ```\n\n## Important Guidelines\n\n1. **Verify before implementing** — Always check the reviewer's suggestion\n   against the actual codebase before making changes. The reviewer may not\n   have full context.\n\n2. **One item at a time** — Work through feedback sequentially. In guided\n   mode, each item gets its own verify-implement-respond cycle. In express\n   mode, simple items can be presented and applied more efficiently.\n\n3. **Confirm before acting** — In guided mode, always present your analysis\n   and proposed approach before making code changes or posting GitHub\n   responses. In express mode, present the change and response together\n   but still show what will be done before doing it.\n\n4. **Factual responses only** — Reply with what was done (\"Fixed. Extracted\n   the helper into a shared utility.\"), not with performative agreement\n   (\"Great catch! You're absolutely right!\").\n\n5. **Technical pushback when warranted** — If feedback is incorrect, present\n   the technical reasoning to the user. Don't implement changes you believe\n   are wrong without flagging them.\n\n6. **Respect commit preference** — Follow the user's chosen commit strategy\n   (per-item, per-category, or at-end). Keep commits atomic and focused.\n   Follow the `commit` skill pattern for this repository's VCS (refer to\n   session VCS context). Keep commits focused and atomic.\n\n7. **Reply in threads** — Always reply in the specific comment thread, not\n   as a new top-level comment. This keeps the conversation organised.\n\n8. **Respect the user's judgment** — For disagreements, present your analysis\n   but let the user decide. They may have context you don't.\n\n9. **Handle errors gracefully** — Follow the error recovery guidance in\n   Step 1.7. For mid-workflow failures, clearly state what succeeded and\n   what failed, and offer specific alternatives (e.g., post as top-level\n   comment, resolve manually, retry).\n\n10. **Don't over-change** — When implementing feedback, change only what was\n    asked for. Don't refactor surrounding code, add comments to unchanged\n    lines, or \"improve\" things that weren't mentioned.\n\n11. **Re-invocation is resumption** — If the user stops mid-way and later\n    re-runs `\u002Frespond-to-pr {number}`, the resolved-thread filter in Step 2\n    naturally excludes already-addressed items. Inform the user: \"I see N\n    threads were already resolved, picking up from the remaining M items.\"\n\n## What NOT to Do\n\n- Don't make code changes without user confirmation\n- Don't post GitHub responses without showing the user first\n- Don't implement all changes at once — work through them one at a time\n- Don't skip the verification step — always check the codebase first\n- Don't use performative language in GitHub responses\n- Don't commit without following the user's chosen commit strategy\n- Don't resolve threads without having addressed the feedback\n- Don't automatically re-request review — always offer first\n- Don't add co-author information or Claude attribution to commits\n- When staging files, always add specific files by name — never bulk-add\n\n## Relationship to Other Commands\n\nThe respond-to-pr skill fills a gap in the development lifecycle:\n\n1. `\u002Fcreate-plan` — Create the implementation plan\n2. `\u002Freview-plan` — Review and iterate the plan quality\n3. `\u002Fimplement-plan` — Execute the approved plan\n4. `\u002Fvalidate-plan` — Verify implementation matches the plan\n5. `\u002Fdescribe-pr` — Generate PR description\n6. `\u002Freview-pr` — Review the PR through quality lenses\n7. **`\u002Frespond-to-pr`** — Address review feedback (this command)\n8. `\u002Fcommit` — Commit changes (used within this workflow)\n\n!`accelerator config instructions respond-to-pr --fail-safe`\n",{"name":5,"description":7,"allowed-tools":49,"argument-hint":52},[50,51],"Bash(accelerator config *)","Bash(accelerator collaboration pr base-repo *)","[PR number or URL]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fgithub\u002Frespond-to-pr",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-13 03:45:46",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add atomicinnovation\u002Faccelerator --skill respond-to-pr",{"tool":67,"command":68},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill respond-to-pr",{"tool":70,"command":71},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill respond-to-pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fgithub\u002Frespond-to-pr\u002FSKILL.md",true,[75,81,85,89],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fbriefs-template.md","REFERENCE","参考文档",1283,"https:\u002F\u002Fgithub.com\u002Fomriariav\u002Famq-squad\u002Fblob\u002Fmain\u002Fplugins\u002Fclaude\u002Fskills\u002Famq-squad\u002Freferences\u002Fbriefs-template.md",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fpointer-stub-template.md",2044,"https:\u002F\u002Fgithub.com\u002Fomriariav\u002Famq-squad\u002Fblob\u002Fmain\u002Fplugins\u002Fclaude\u002Fskills\u002Famq-squad\u002Freferences\u002Fpointer-stub-template.md",{"path":86,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fteam-archetypes.md",2787,"https:\u002F\u002Fgithub.com\u002Fomriariav\u002Famq-squad\u002Fblob\u002Fmain\u002Fplugins\u002Fclaude\u002Fskills\u002Famq-squad\u002Freferences\u002Fteam-archetypes.md",{"path":90,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fteam-rules-template.md",7342,"https:\u002F\u002Fgithub.com\u002Fomriariav\u002Famq-squad\u002Fblob\u002Fmain\u002Fplugins\u002Fclaude\u002Fskills\u002Famq-squad\u002Freferences\u002Fteam-rules-template.md",[94,124,147,169,187,211],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":110,"publishedAt":44},"01M70S7PFGVATJREBFEGPJB718","explore-pr","Build an interactive, design-first and picture-first exploration page for a pull request — its architecture, abstractions and design decisions drawn as diagrams, a guided tour in reading order with code as the evidence, an attention map of where the risk sits, a ledger of its riskiest operations, prior review findings re-checked against the code, and simulations specific to the PR — with the reviewer's verdicts and notes saved. Use when the user wants to explore, understand or review a large pull request or its design, asks for a review page, walkthrough or visual explanation of a PR, or is struggling to review a big change.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fexplore-pr\u002FSKILL.md",[100,105],{"categoryNo":101,"categoryName":102,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[111,112,19,113,114,115,116,117,118,119,23,26,27,34,38,120,121,33,122,123],"explore pr","explore","diagrams","exploration","re","review findings","walkthrough","design","map","architecture","reviewer","notes","change",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":44},"01M6DY04WBTMFV96JMBP5ZXVFX","update-work-item","Update fields (status, priority, tags, parent, etc.) of an existing work item. Use to transition status, change priority, manage tags, or edit any frontmatter field. No transition enforcement — arbitrary changes are allowed.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fupdate-work-item\u002FSKILL.md",[],[131,132,133,134,135,136,29,34,123,42,137,138,139,140,141,142,143,144,145,146],"work","update","update work item","work item","enforcement","manage","edit","validate","status","transition","frontmatter","Existing","tags","changes","fields","op",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":44},"01M6DY0106CF15CYEJHZM14GBZ","sync-work-items","Reconcile local work items in meta\u002Fwork\u002F with the active remote tracker named by work.integration. Use when the user wants to sync, push, or pull work items to or from Jira or Linear, preview what a sync would change, or reconcile divergent local and remote state.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items\u002FSKILL.md",[],[131,154,155,156,157,158,159,34,160,123,161,162,163,164,165,166,167,42,168,141,23],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":44},"01M6HNF86984S4XK21Q26VZA21","sync-work-items-recovery","Recovery procedures for work sync failures that need a person — terminal rows, refused pending pushes and refused orders. Read by sync-work-items — not invoked directly.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items-recovery\u002FSKILL.md",[],[176,131,177,154,155,178,179,180,181,182,183,184,185,186],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":196,"publishedAt":44},"01M6DXZWH7PR72VCEXSSD4XNK4","stress-test-work-item","Interactively stress-test a work item by grilling the user on scope, assumptions, acceptance criteria, edge cases, and dependencies to surface issues, gaps, and flawed assumptions before implementation is planned.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002FSKILL.md",[193],{"categoryNo":194,"categoryName":195,"taxonomyType":103,"taxonomyTypeDesc":104},"01JBSEEDCAT000000000000008","测试与质量",[197,198,131,199,134,200,201,202,203,204,205,34,206,207,42,138,208,209,30,26,210,141],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","gaps",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":217,"publishedAt":44},"01M6DXZRQWHTWV1G9PTTHCGGYA","review-work-item","Review a work item through multiple quality lenses and collaboratively iterate based on findings. Use when the user wants to evaluate a work item before implementation or escalation.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002FSKILL.md",[],[33,131,218,134,219,220,29,34,221,222,42,138,208,30,223,23,224,225,141,226],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path"]