[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXYE4T7H65DZXVPVY73ZBB":3,"skill-same:01M6DXYE4T7H65DZXVPVY73ZBB":70},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":63},"01M6DXYE4T7H65DZXVPVY73ZBB","pr-review-output-format",null,"Output format specification for PR review agents. Defines the JSON schema, field reference, severity emoji prefixes, and comment body format for PR reviews.","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\u002Freview\u002Foutput-formats\u002Fpr-review-output-format\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"pr review","pr","review","format","output","pr review output format","body","for","true","reviews","false","emoji","specification","reference","schema","json","severity","json schema","2026-11-10 10:12:30",false,"---\nname: pr-review-output-format\ndescription: Output format specification for PR review agents. Defines the JSON\n  schema, field reference, severity emoji prefixes, and comment body format for\n  PR reviews.\nuser-invocable: false\ndisable-model-invocation: true\n---\n\n# PR Review Output Format\n\n## JSON Schema\n\nReturn your analysis as a JSON code block. Do not include any text before or\nafter the JSON block — the orchestrator will parse this output directly.\n\n```json\n{\n  \"lens\": \"\u003Clens-identifier>\",\n  \"summary\": \"2-3 sentence assessment from this lens perspective.\",\n  \"strengths\": [\n    \"Positive observation about what the PR gets right from this lens perspective\"\n  ],\n  \"comments\": [\n    {\n      \"path\": \"src\u002Fexample.ts\",\n      \"line\": 42,\n      \"end_line\": null,\n      \"side\": \"RIGHT\",\n      \"severity\": \"critical\",\n      \"confidence\": \"high\",\n      \"lens\": \"\u003Clens-identifier>\",\n      \"title\": \"Brief finding title\",\n      \"body\": \"? **\u003CLens Name>**\\n\\n[Issue description — 1-2 sentences with enough context to understand standalone].\\n\\n**Impact**: [Why this matters — 1 sentence].\\n\\n**Suggestion**: [Concrete fix — 1-2 sentences, optionally with a code snippet].\"\n    }\n  ],\n  \"general_findings\": [\n    {\n      \"severity\": \"minor\",\n      \"lens\": \"\u003Clens-identifier>\",\n      \"title\": \"Cross-cutting finding title\",\n      \"body\": \"Description of the finding that cannot be anchored to a specific diff line.\"\n    }\n  ]\n}\n```\n\n## Field Reference\n\n- **lens**: Agent lens identifier (e.g., `\"architecture\"`, `\"security\"`,\n  `\"test-coverage\"`, `\"code-quality\"`, `\"standards\"`, `\"usability\"`,\n  `\"performance\"`, `\"documentation\"`, `\"database\"`, `\"correctness\"`,\n  `\"compatibility\"`, `\"portability\"`, `\"safety\"`)\n- **summary**: 2-3 sentence assessment from this lens perspective\n- **strengths**: Positive observations (fed into the review summary — never\n  posted as inline comments)\n- **comments**: Line-anchored findings for inline PR comments\n  - **path**: File path relative to repository root (as shown in the diff\n    header, e.g., `src\u002Fauth\u002Fhandler.ts`)\n  - **line**: Line number in the file where the comment should appear. For\n    `\"RIGHT\"` side, this is the line number in the new version of the file. For\n    `\"LEFT\"` side, this is the line number in the old version. The line MUST be\n    visible in the diff (within a hunk).\n  - **end_line**: Last line number for multi-line comments, or `null` for\n    single-line. Must be in the same diff hunk as `line`.\n  - **side**: `\"RIGHT\"` for commenting on added, modified, or context lines in\n    the new file (the vast majority of comments). `\"LEFT\"` only for commenting\n    on deleted lines.\n  - **severity**: One of `\"critical\"`, `\"major\"`, `\"minor\"`, `\"suggestion\"`\n  - **confidence**: One of `\"high\"`, `\"medium\"`, `\"low\"`\n  - **lens**: The lens identifier (same value as the top-level `lens` field).\n    Included on each comment so the orchestrator can attribute findings after\n    merging outputs from multiple agents.\n  - **title**: Brief title for the finding (used in the summary index)\n  - **body**: Self-contained comment body formatted for a GitHub PR inline\n    comment. See \"Comment Body Format\" below.\n- **general_findings**: Findings that cannot be anchored to specific diff lines\n  (cross-cutting concerns, missing functionality, architectural observations)\n  - **severity**, **lens**, **title**, **body**: Same semantics as in `comments`\n\n## Multi-Line Comment API Mapping\n\nThe agent schema uses `line` (start of range) and `end_line` (end of range).\nThe GitHub API inverts this: `start_line` is the beginning and `line` is the\nend. The orchestrator handles this mapping when constructing the API payload.\n\nExample — agent output:\n```json\n{ \"line\": 10, \"end_line\": 15, \"side\": \"RIGHT\" }\n```\nBecomes API payload:\n```json\n{ \"start_line\": 10, \"start_side\": \"RIGHT\", \"line\": 15, \"side\": \"RIGHT\" }\n```\n\nFor single-line comments (`end_line` is `null`), the API payload uses only\n`line` and `side` — `start_line` and `start_side` are omitted entirely (not\nset to `null`).\n\n## Severity Emoji Prefixes\n\nUse these **actual Unicode emoji characters** at the start of each comment `body`:\n- `?` for `\"critical\"` severity\n- `?` for `\"major\"` severity\n- `?` for `\"minor\"` and `\"suggestion\"` severity\n\n**IMPORTANT**: Use the actual Unicode emoji characters shown above (? ? ?), NOT\ntext shortcodes like `:red_circle:`, `:yellow_circle:`, or `:blue_circle:`. The\noutput is rendered as markdown, not Slack\u002FDiscord, so shortcodes will appear as\nliteral text.\n\n## Comment Body Format\n\nEach comment `body` should follow this structure:\n\n```\n[emoji] **[Lens Name]**\n\n[Issue description — 1-2 sentences, standalone context].\n\n**Impact**: [Why this matters].\n\n**Suggestion**: [Concrete fix, optionally with a short code snippet].\n```\n\nExample:\n\n```\n? **Architecture**\n\nThis module directly imports from the data layer, bypassing the service\nboundary. This couples the API handler to the database schema.\n\n**Impact**: Changes to the database schema will ripple into the API layer.\n\n**Suggestion**: Introduce a service interface to mediate between the API and\ndata layers.\n```\n\n## Diff Anchoring Guidelines\n\n- Every finding in `comments` must reference a line number that is visible in\n  the diff (within a hunk). Lines outside diff hunks will cause API errors.\n- For findings about added or modified code, use the line number in the new\n  file version and set side to `\"RIGHT\"`.\n- For findings about deleted code, use the line number in the old file version\n  and set side to `\"LEFT\"`.\n- For findings spanning multiple lines, identify both the start line (`line`)\n  and end line (`end_line`) within the same diff hunk.\n- For findings that cannot be anchored to a specific diff line, classify them\n  as general findings.\n- When in doubt, use `general_findings` rather than risking an invalid line\n  reference.\n\n**Output only the JSON block** — do not include additional prose, narrative\nanalysis, or markdown outside the JSON code fence. The orchestrator parses\nyour output as JSON.\n","# PR Review Output Format\n\n## JSON Schema\n\nReturn your analysis as a JSON code block. Do not include any text before or\nafter the JSON block — the orchestrator will parse this output directly.\n\n```json\n{\n  \"lens\": \"\u003Clens-identifier>\",\n  \"summary\": \"2-3 sentence assessment from this lens perspective.\",\n  \"strengths\": [\n    \"Positive observation about what the PR gets right from this lens perspective\"\n  ],\n  \"comments\": [\n    {\n      \"path\": \"src\u002Fexample.ts\",\n      \"line\": 42,\n      \"end_line\": null,\n      \"side\": \"RIGHT\",\n      \"severity\": \"critical\",\n      \"confidence\": \"high\",\n      \"lens\": \"\u003Clens-identifier>\",\n      \"title\": \"Brief finding title\",\n      \"body\": \"? **\u003CLens Name>**\\n\\n[Issue description — 1-2 sentences with enough context to understand standalone].\\n\\n**Impact**: [Why this matters — 1 sentence].\\n\\n**Suggestion**: [Concrete fix — 1-2 sentences, optionally with a code snippet].\"\n    }\n  ],\n  \"general_findings\": [\n    {\n      \"severity\": \"minor\",\n      \"lens\": \"\u003Clens-identifier>\",\n      \"title\": \"Cross-cutting finding title\",\n      \"body\": \"Description of the finding that cannot be anchored to a specific diff line.\"\n    }\n  ]\n}\n```\n\n## Field Reference\n\n- **lens**: Agent lens identifier (e.g., `\"architecture\"`, `\"security\"`,\n  `\"test-coverage\"`, `\"code-quality\"`, `\"standards\"`, `\"usability\"`,\n  `\"performance\"`, `\"documentation\"`, `\"database\"`, `\"correctness\"`,\n  `\"compatibility\"`, `\"portability\"`, `\"safety\"`)\n- **summary**: 2-3 sentence assessment from this lens perspective\n- **strengths**: Positive observations (fed into the review summary — never\n  posted as inline comments)\n- **comments**: Line-anchored findings for inline PR comments\n  - **path**: File path relative to repository root (as shown in the diff\n    header, e.g., `src\u002Fauth\u002Fhandler.ts`)\n  - **line**: Line number in the file where the comment should appear. For\n    `\"RIGHT\"` side, this is the line number in the new version of the file. For\n    `\"LEFT\"` side, this is the line number in the old version. The line MUST be\n    visible in the diff (within a hunk).\n  - **end_line**: Last line number for multi-line comments, or `null` for\n    single-line. Must be in the same diff hunk as `line`.\n  - **side**: `\"RIGHT\"` for commenting on added, modified, or context lines in\n    the new file (the vast majority of comments). `\"LEFT\"` only for commenting\n    on deleted lines.\n  - **severity**: One of `\"critical\"`, `\"major\"`, `\"minor\"`, `\"suggestion\"`\n  - **confidence**: One of `\"high\"`, `\"medium\"`, `\"low\"`\n  - **lens**: The lens identifier (same value as the top-level `lens` field).\n    Included on each comment so the orchestrator can attribute findings after\n    merging outputs from multiple agents.\n  - **title**: Brief title for the finding (used in the summary index)\n  - **body**: Self-contained comment body formatted for a GitHub PR inline\n    comment. See \"Comment Body Format\" below.\n- **general_findings**: Findings that cannot be anchored to specific diff lines\n  (cross-cutting concerns, missing functionality, architectural observations)\n  - **severity**, **lens**, **title**, **body**: Same semantics as in `comments`\n\n## Multi-Line Comment API Mapping\n\nThe agent schema uses `line` (start of range) and `end_line` (end of range).\nThe GitHub API inverts this: `start_line` is the beginning and `line` is the\nend. The orchestrator handles this mapping when constructing the API payload.\n\nExample — agent output:\n```json\n{ \"line\": 10, \"end_line\": 15, \"side\": \"RIGHT\" }\n```\nBecomes API payload:\n```json\n{ \"start_line\": 10, \"start_side\": \"RIGHT\", \"line\": 15, \"side\": \"RIGHT\" }\n```\n\nFor single-line comments (`end_line` is `null`), the API payload uses only\n`line` and `side` — `start_line` and `start_side` are omitted entirely (not\nset to `null`).\n\n## Severity Emoji Prefixes\n\nUse these **actual Unicode emoji characters** at the start of each comment `body`:\n- `?` for `\"critical\"` severity\n- `?` for `\"major\"` severity\n- `?` for `\"minor\"` and `\"suggestion\"` severity\n\n**IMPORTANT**: Use the actual Unicode emoji characters shown above (? ? ?), NOT\ntext shortcodes like `:red_circle:`, `:yellow_circle:`, or `:blue_circle:`. The\noutput is rendered as markdown, not Slack\u002FDiscord, so shortcodes will appear as\nliteral text.\n\n## Comment Body Format\n\nEach comment `body` should follow this structure:\n\n```\n[emoji] **[Lens Name]**\n\n[Issue description — 1-2 sentences, standalone context].\n\n**Impact**: [Why this matters].\n\n**Suggestion**: [Concrete fix, optionally with a short code snippet].\n```\n\nExample:\n\n```\n? **Architecture**\n\nThis module directly imports from the data layer, bypassing the service\nboundary. This couples the API handler to the database schema.\n\n**Impact**: Changes to the database schema will ripple into the API layer.\n\n**Suggestion**: Introduce a service interface to mediate between the API and\ndata layers.\n```\n\n## Diff Anchoring Guidelines\n\n- Every finding in `comments` must reference a line number that is visible in\n  the diff (within a hunk). Lines outside diff hunks will cause API errors.\n- For findings about added or modified code, use the line number in the new\n  file version and set side to `\"RIGHT\"`.\n- For findings about deleted code, use the line number in the old file version\n  and set side to `\"LEFT\"`.\n- For findings spanning multiple lines, identify both the start line (`line`)\n  and end line (`end_line`) within the same diff hunk.\n- For findings that cannot be anchored to a specific diff line, classify them\n  as general findings.\n- When in doubt, use `general_findings` rather than risking an invalid line\n  reference.\n\n**Output only the JSON block** — do not include additional prose, narrative\nanalysis, or markdown outside the JSON code fence. The orchestrator parses\nyour output as JSON.\n",{"name":5,"description":7,"user-invocable":38,"disable-model-invocation":42},true,"main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Freview\u002Foutput-formats\u002Fpr-review-output-format",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-13 08:45:04",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":42},[53,56,59],{"tool":54,"command":55},"npx","npx skills add atomicinnovation\u002Faccelerator --skill pr-review-output-format",{"tool":57,"command":58},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill pr-review-output-format",{"tool":60,"command":61},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill pr-review-output-format","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Foutput-formats\u002Fpr-review-output-format\u002FSKILL.md",[64],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"scripts\u002Fherdr_environment.py","SCRIPT","脚本",45153,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fcoding-agents\u002Fskills\u002Foperate-herdr\u002Fscripts\u002Fherdr_environment.py",[71,106,131,153,168,193],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":87,"publishedAt":37},"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",[77,82],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[88,89,20,90,91,92,93,94,95,96,97,98,99,100,101,102,103,21,104,105],"explore pr","explore","diagrams","exploration","re","review findings","walkthrough","design","map","when","number","URL","Bash","code","architecture","reviewer","notes","change",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":37},"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",[],[113,114,115,116,117,118,119,100,105,120,121,122,123,124,125,126,127,128,129,130],"work","update","update work item","work item","enforcement","manage","use","config","edit","validate","status","transition","frontmatter","Existing","tags","changes","fields","op",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":37},"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",[],[113,138,139,140,141,142,143,100,144,105,145,146,147,148,149,150,151,120,152,125,97],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":37},"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",[],[160,113,161,138,139,162,26,163,164,165,27,29,166,167],"sync work items recovery","recovery","work-items","terminal","read","person","orders","pending",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":177,"publishedAt":37},"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",[174],{"categoryNo":175,"categoryName":176,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000008","测试与质量",[178,179,113,180,116,181,182,183,184,185,186,100,187,188,120,122,189,190,191,98,192,125],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","user","gaps",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":37},"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",[],[21,113,200,116,201,202,119,100,203,204,120,122,189,191,205,97,206,207,125,208],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path"]