[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXQ4DMY1Q7BGYGA74PCRFY":3,"skill-same:01M6DXQ4DMY1Q7BGYGA74PCRFY":75},{"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":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M6DXQ4DMY1Q7BGYGA74PCRFY","create-adr",null,"Interactively create an architecture decision record (ADR). Use when the user wants to document an architectural decision, technology choice, or significant design decision. Guides through context gathering, options analysis, and consequence documentation.","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\u002Fdecisions\u002Fcreate-adr\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],"create adr","create","adr","user","when","decision record","architecture decision","guides","consequence","technology","options","record","document","use","design","choice","decision","Bash","analysis","documentation","config","architecture","validate","2026-11-10 10:12:30",false,"---\nname: create-adr\ndescription: Interactively create an architecture decision record (ADR). Use\n  when the user wants to document an architectural decision, technology choice,\n  or significant design decision. Guides through context gathering, options\n  analysis, and consequence documentation.\nargument-hint: \"[topic or description] [--supersedes ADR-NNNN]\"\nallowed-tools:\n  - Bash(accelerator config *)\n  - Bash(accelerator corpus adr *)\n  - Bash(accelerator corpus metadata derive)\n  - Bash(accelerator corpus frontmatter validate *)\n---\n\n# Create Architecture Decision Record\n\n!`accelerator config context --skill create-adr --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:reviewer, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser,\naccelerator:web-search-researcher.\n\n**Decisions directory**: !`accelerator config path decisions --fail-safe`\n\nYou are tasked with guiding the user through creating an architecture decision\nrecord (ADR) — a concise document capturing a significant architectural\ndecision, its context, the options considered, and the consequences.\n\n## Initial Setup\n\nWhen this command is invoked:\n\n1. **Check if parameters were provided**:\n\n- If a topic\u002Fdescription was provided, proceed directly to context gathering\n- If `--supersedes ADR-NNNN` was provided, note the supersession target\n- If no parameters provided, respond with:\n\n```\nI'll help you create an architecture decision record. Please provide:\n1. The topic or decision to document (e.g., \"use PostgreSQL for user data\")\n2. Any relevant context or constraints\n\nYou can also specify if this supersedes an existing ADR:\n`\u002Faccelerator:create-adr use Redis for caching --supersedes ADR-0003`\n```\n\nThen wait for the user's input.\n\n## Process Steps\n\n### Step 1: Determine ADR Number\n\n1. Run the corpus CLI to get the next ADR number:\n\n   ```\n   accelerator corpus adr next-number\n   ```\n\n2. If `--supersedes ADR-NNNN` was specified:\n   - Find the target ADR file by matching `{decisions directory}\u002FADR-NNNN-*.md`\n   - Verify exactly one file matches the glob pattern (error if zero or\n     multiple matches)\n   - Read the target ADR's status using the corpus CLI:\n     ```\n     accelerator corpus adr read-status \u003Cresolved-path>\n     ```\n   - Verify the target ADR is in `accepted` status (only accepted ADRs can be\n     superseded). This is an early-fail check to avoid wasted effort — the\n     status will be re-verified before writing in Step 4.\n   - If not `accepted`, inform the user and ask how to proceed\n\n### Step 2: Gather Context\n\n1. **Spawn agents to gather relevant context** (in parallel):\n\n- Use **{documents locator agent}** to find related research, plans, and existing ADRs\n  in the configured document directories\n- Use **{codebase locator agent}** to find relevant code related to the decision topic\n\n2. **Read any directly mentioned files** fully\n\n3. **Present gathered context and ask clarifying questions**:\n\n```\nBased on my research, here's what I found relevant to this decision:\n\n**Related documents:**\n- [list of relevant meta documents]\n\n**Related code:**\n- [list of relevant code areas]\n\n**Existing ADRs on related topics:**\n- [list of related ADRs, if any]\n\nBefore I draft the ADR, I'd like to understand:\n1. What forces or constraints are driving this decision?\n2. What alternatives have you considered?\n3. Are there specific tradeoffs you want to highlight?\n```\n\nIf context gathering finds nothing relevant (e.g., first ADR in a new project),\nskip the context sections and present:\n\n```\nNo existing documents or ADRs found related to this topic. I'll draft the ADR\nbased on the information you provide.\n\nBefore I draft, I'd like to understand:\n1. What forces or constraints are driving this decision?\n2. What alternatives have you considered?\n3. Are there specific tradeoffs you want to highlight?\n```\n\nWait for user input before proceeding.\n\n### Step 3: Draft the ADR\n\n1. **Gather metadata** by running\n   `accelerator corpus metadata derive`.\n\n2. **Draft the ADR** using the template below and present it to the user for\n   review:\n\n```\nHere's my draft ADR:\n\n[draft content]\n```\n\nUse the `AskUserQuestion` tool with two options:\n\n1. **Yes, write to disk** — save the ADR as shown\n2. **No, revise first** — make changes before saving\n\nWait for the user's answer before writing.\n\n3. **Iterate** on the draft based on user feedback. Only proceed to writing\n   when the user approves.\n\n### Step 4: Write the ADR\n\n1. Create the configured decisions directory if it doesn't exist\n\n2. **Populate frontmatter**: before writing the artifact file,\n   substitute the unified base fields into the template's frontmatter\n   block, using the metadata captured in Step 3.\n\n   1. The `Current Date\u002FTime (UTC):` value from\n      `accelerator corpus metadata derive` is the source for `date:` and\n      `last_updated:`. Repository identity is not part of the ADR\n      provenance bundle (ADRs are not code-state-anchored).\n   2. **Substitute** every field below with the indicated value:\n      - `type:` ← `adr`\n      - `id:` ← the ADR identifier `ADR-NNNN` from Step 1, always\n        quoted as a YAML string (e.g. `id: \"ADR-0042\"`)\n      - `title:` ← the ADR title (without the `ADR-NNNN:` prefix)\n      - `date:` ← the `Current Date\u002FTime (UTC):` value\n      - `author:` ← the author resolved per the standard chain\n        (config → VCS user → prompt)\n      - `producer:` ← `create-adr`\n      - `status:` ← `proposed`\n      - `last_updated:` ← the same `Current Date\u002FTime (UTC):` value\n      - `last_updated_by:` ← the same value resolved for `author`\n      - `schema_version:` ← `1` (bare integer)\n\n      Optional linkage \u002F decision-maker keys are omit-by-default:\n      the template shows each as `\"\"`\u002F`[]`, but write a key\n      into the artifact **only** when it has a value, and omit it\n      entirely otherwise (do not carry the empty placeholder through).\n\n      - `parent:` ← the owning work item as a typed-linkage ref\n        (`\"work-item:NNNN\"`). Fill when the ADR is owned by a work item;\n        otherwise omit the key.\n      - `supersedes:` ← a YAML list of typed-linkage refs of the form\n        `\"adr:ADR-NNNN\"` to the ADR(s) this one replaces. Fill when this\n        ADR supersedes another; otherwise omit the key.\n      - `relates_to:` ← list of typed-linkage refs to loosely related\n        ADRs (`[\"adr:ADR-NNNN\", ...]`). Fill when related decisions are\n        explicit; otherwise omit the key.\n      - `decision_makers:` ← a YAML list of the people who agreed to the\n        decision. Fill when decision-makers are captured; otherwise omit\n        the key.\n\n3. Write the ADR to:\n   `{decisions directory}\u002FADR-NNNN-description.md`\n   where NNNN is the number from Step 1 and description is a kebab-case summary\n\n4. If this supersedes an existing ADR:\n   - Read the superseded ADR's current status to confirm it's `accepted`\n   - Update ONLY the superseded ADR's frontmatter:\n     - Change `status: accepted` to `status: superseded`\n     - Add `superseded_by: ADR-MMMM` (where MMMM is the new ADR number)\n   - Do NOT modify any other content in the superseded ADR\n   - Append the new ADR's typed-linkage ref to the new ADR's\n     `supersedes:` list (e.g. `[\"adr:ADR-0017\"]`)\n\n5. Present the result:\n\n```\nADR created: `{decisions directory}\u002FADR-NNNN-description.md`\nStatus: proposed\n\n[If supersession]: Updated ADR-XXXX status to \"superseded\"\n\nNext steps:\n- Review and refine while in \"proposed\" status\n- When ready, use `\u002Faccelerator:review-adr` to accept or reject\n```\n\n**Validate the frontmatter**: after writing the ADR, run\n\n```bash\naccelerator corpus frontmatter validate --file {decisions directory}\u002FADR-NNNN-description.md\n```\n\nIf it exits non-zero, the document violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n## ADR Template\n\nUse this exact template structure when generating ADRs:\n\n!`accelerator config template adr --fail-safe`\n\n## Quality Guidelines\n\nWhen drafting ADRs, follow these principles:\n\n- **Concise**: One to two pages maximum. Match length to problem complexity.\n- **Assertive**: Use active voice (\"We will...\", \"We chose...\")\n- **Balanced**: Include genuine pros AND cons. Avoid the \"Fairy Tale\" pattern\n  (only pros, no cons)\n- **Honest options**: Only include options that were genuinely considered. Avoid\n  \"Dummy Alternatives\" (non-viable options to make preferred choice look good)\n- **Focused**: Each ADR captures ONE decision. If you find multiple decisions,\n  suggest creating separate ADRs.\n- **Context-rich**: Explain WHY, not just WHAT. Future readers need to\n  understand the forces at play.\n\n## Anti-Patterns to Avoid\n\n- **Fairy Tale**: Only listing positive consequences\n- **Dummy Alternative**: Including obviously non-viable options\n- **Mega-ADR**: Multi-page documents crammed with implementation detail\n- **Blueprint in Disguise**: Reads like a cookbook, not a decision journal\n- **Missing context**: Decision without the forces that drove it\n\n## Important Notes\n\n- New ADRs ALWAYS start with status `proposed`\n- ADR numbers are NEVER reused — always increment from the highest existing\n- File naming is `ADR-NNNN-description.md` (e.g., `ADR-0001-use-jujutsu.md`)\n- Only modify existing ADRs to update status fields during supersession\n- Cross-reference related documents in the References section\n- Use {documents locator agent} and {codebase locator agent} agents for context, not deep\n  file reads in the main context\n- **Dual status fields**: The template includes status in both YAML frontmatter\n  (`status: proposed`) and the body (`**Status**: Proposed`). The frontmatter\n  is the authoritative source of truth — `accelerator corpus adr read-status`\n  reads only frontmatter. The body line is for human readability. When\n  updating status, ALWAYS update both locations.\n- Before writing a new ADR file, verify the target path does not already exist\n  to prevent accidental overwrites from concurrent invocations\n\n!`accelerator config instructions create-adr --fail-safe`\n","# Create Architecture Decision Record\n\n!`accelerator config context --skill create-adr --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:reviewer, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser,\naccelerator:web-search-researcher.\n\n**Decisions directory**: !`accelerator config path decisions --fail-safe`\n\nYou are tasked with guiding the user through creating an architecture decision\nrecord (ADR) — a concise document capturing a significant architectural\ndecision, its context, the options considered, and the consequences.\n\n## Initial Setup\n\nWhen this command is invoked:\n\n1. **Check if parameters were provided**:\n\n- If a topic\u002Fdescription was provided, proceed directly to context gathering\n- If `--supersedes ADR-NNNN` was provided, note the supersession target\n- If no parameters provided, respond with:\n\n```\nI'll help you create an architecture decision record. Please provide:\n1. The topic or decision to document (e.g., \"use PostgreSQL for user data\")\n2. Any relevant context or constraints\n\nYou can also specify if this supersedes an existing ADR:\n`\u002Faccelerator:create-adr use Redis for caching --supersedes ADR-0003`\n```\n\nThen wait for the user's input.\n\n## Process Steps\n\n### Step 1: Determine ADR Number\n\n1. Run the corpus CLI to get the next ADR number:\n\n   ```\n   accelerator corpus adr next-number\n   ```\n\n2. If `--supersedes ADR-NNNN` was specified:\n   - Find the target ADR file by matching `{decisions directory}\u002FADR-NNNN-*.md`\n   - Verify exactly one file matches the glob pattern (error if zero or\n     multiple matches)\n   - Read the target ADR's status using the corpus CLI:\n     ```\n     accelerator corpus adr read-status \u003Cresolved-path>\n     ```\n   - Verify the target ADR is in `accepted` status (only accepted ADRs can be\n     superseded). This is an early-fail check to avoid wasted effort — the\n     status will be re-verified before writing in Step 4.\n   - If not `accepted`, inform the user and ask how to proceed\n\n### Step 2: Gather Context\n\n1. **Spawn agents to gather relevant context** (in parallel):\n\n- Use **{documents locator agent}** to find related research, plans, and existing ADRs\n  in the configured document directories\n- Use **{codebase locator agent}** to find relevant code related to the decision topic\n\n2. **Read any directly mentioned files** fully\n\n3. **Present gathered context and ask clarifying questions**:\n\n```\nBased on my research, here's what I found relevant to this decision:\n\n**Related documents:**\n- [list of relevant meta documents]\n\n**Related code:**\n- [list of relevant code areas]\n\n**Existing ADRs on related topics:**\n- [list of related ADRs, if any]\n\nBefore I draft the ADR, I'd like to understand:\n1. What forces or constraints are driving this decision?\n2. What alternatives have you considered?\n3. Are there specific tradeoffs you want to highlight?\n```\n\nIf context gathering finds nothing relevant (e.g., first ADR in a new project),\nskip the context sections and present:\n\n```\nNo existing documents or ADRs found related to this topic. I'll draft the ADR\nbased on the information you provide.\n\nBefore I draft, I'd like to understand:\n1. What forces or constraints are driving this decision?\n2. What alternatives have you considered?\n3. Are there specific tradeoffs you want to highlight?\n```\n\nWait for user input before proceeding.\n\n### Step 3: Draft the ADR\n\n1. **Gather metadata** by running\n   `accelerator corpus metadata derive`.\n\n2. **Draft the ADR** using the template below and present it to the user for\n   review:\n\n```\nHere's my draft ADR:\n\n[draft content]\n```\n\nUse the `AskUserQuestion` tool with two options:\n\n1. **Yes, write to disk** — save the ADR as shown\n2. **No, revise first** — make changes before saving\n\nWait for the user's answer before writing.\n\n3. **Iterate** on the draft based on user feedback. Only proceed to writing\n   when the user approves.\n\n### Step 4: Write the ADR\n\n1. Create the configured decisions directory if it doesn't exist\n\n2. **Populate frontmatter**: before writing the artifact file,\n   substitute the unified base fields into the template's frontmatter\n   block, using the metadata captured in Step 3.\n\n   1. The `Current Date\u002FTime (UTC):` value from\n      `accelerator corpus metadata derive` is the source for `date:` and\n      `last_updated:`. Repository identity is not part of the ADR\n      provenance bundle (ADRs are not code-state-anchored).\n   2. **Substitute** every field below with the indicated value:\n      - `type:` ← `adr`\n      - `id:` ← the ADR identifier `ADR-NNNN` from Step 1, always\n        quoted as a YAML string (e.g. `id: \"ADR-0042\"`)\n      - `title:` ← the ADR title (without the `ADR-NNNN:` prefix)\n      - `date:` ← the `Current Date\u002FTime (UTC):` value\n      - `author:` ← the author resolved per the standard chain\n        (config → VCS user → prompt)\n      - `producer:` ← `create-adr`\n      - `status:` ← `proposed`\n      - `last_updated:` ← the same `Current Date\u002FTime (UTC):` value\n      - `last_updated_by:` ← the same value resolved for `author`\n      - `schema_version:` ← `1` (bare integer)\n\n      Optional linkage \u002F decision-maker keys are omit-by-default:\n      the template shows each as `\"\"`\u002F`[]`, but write a key\n      into the artifact **only** when it has a value, and omit it\n      entirely otherwise (do not carry the empty placeholder through).\n\n      - `parent:` ← the owning work item as a typed-linkage ref\n        (`\"work-item:NNNN\"`). Fill when the ADR is owned by a work item;\n        otherwise omit the key.\n      - `supersedes:` ← a YAML list of typed-linkage refs of the form\n        `\"adr:ADR-NNNN\"` to the ADR(s) this one replaces. Fill when this\n        ADR supersedes another; otherwise omit the key.\n      - `relates_to:` ← list of typed-linkage refs to loosely related\n        ADRs (`[\"adr:ADR-NNNN\", ...]`). Fill when related decisions are\n        explicit; otherwise omit the key.\n      - `decision_makers:` ← a YAML list of the people who agreed to the\n        decision. Fill when decision-makers are captured; otherwise omit\n        the key.\n\n3. Write the ADR to:\n   `{decisions directory}\u002FADR-NNNN-description.md`\n   where NNNN is the number from Step 1 and description is a kebab-case summary\n\n4. If this supersedes an existing ADR:\n   - Read the superseded ADR's current status to confirm it's `accepted`\n   - Update ONLY the superseded ADR's frontmatter:\n     - Change `status: accepted` to `status: superseded`\n     - Add `superseded_by: ADR-MMMM` (where MMMM is the new ADR number)\n   - Do NOT modify any other content in the superseded ADR\n   - Append the new ADR's typed-linkage ref to the new ADR's\n     `supersedes:` list (e.g. `[\"adr:ADR-0017\"]`)\n\n5. Present the result:\n\n```\nADR created: `{decisions directory}\u002FADR-NNNN-description.md`\nStatus: proposed\n\n[If supersession]: Updated ADR-XXXX status to \"superseded\"\n\nNext steps:\n- Review and refine while in \"proposed\" status\n- When ready, use `\u002Faccelerator:review-adr` to accept or reject\n```\n\n**Validate the frontmatter**: after writing the ADR, run\n\n```bash\naccelerator corpus frontmatter validate --file {decisions directory}\u002FADR-NNNN-description.md\n```\n\nIf it exits non-zero, the document violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n## ADR Template\n\nUse this exact template structure when generating ADRs:\n\n!`accelerator config template adr --fail-safe`\n\n## Quality Guidelines\n\nWhen drafting ADRs, follow these principles:\n\n- **Concise**: One to two pages maximum. Match length to problem complexity.\n- **Assertive**: Use active voice (\"We will...\", \"We chose...\")\n- **Balanced**: Include genuine pros AND cons. Avoid the \"Fairy Tale\" pattern\n  (only pros, no cons)\n- **Honest options**: Only include options that were genuinely considered. Avoid\n  \"Dummy Alternatives\" (non-viable options to make preferred choice look good)\n- **Focused**: Each ADR captures ONE decision. If you find multiple decisions,\n  suggest creating separate ADRs.\n- **Context-rich**: Explain WHY, not just WHAT. Future readers need to\n  understand the forces at play.\n\n## Anti-Patterns to Avoid\n\n- **Fairy Tale**: Only listing positive consequences\n- **Dummy Alternative**: Including obviously non-viable options\n- **Mega-ADR**: Multi-page documents crammed with implementation detail\n- **Blueprint in Disguise**: Reads like a cookbook, not a decision journal\n- **Missing context**: Decision without the forces that drove it\n\n## Important Notes\n\n- New ADRs ALWAYS start with status `proposed`\n- ADR numbers are NEVER reused — always increment from the highest existing\n- File naming is `ADR-NNNN-description.md` (e.g., `ADR-0001-use-jujutsu.md`)\n- Only modify existing ADRs to update status fields during supersession\n- Cross-reference related documents in the References section\n- Use {documents locator agent} and {codebase locator agent} agents for context, not deep\n  file reads in the main context\n- **Dual status fields**: The template includes status in both YAML frontmatter\n  (`status: proposed`) and the body (`**Status**: Proposed`). The frontmatter\n  is the authoritative source of truth — `accelerator corpus adr read-status`\n  reads only frontmatter. The body line is for human readability. When\n  updating status, ALWAYS update both locations.\n- Before writing a new ADR file, verify the target path does not already exist\n  to prevent accidental overwrites from concurrent invocations\n\n!`accelerator config instructions create-adr --fail-safe`\n",{"name":5,"description":7,"allowed-tools":47,"argument-hint":52},[48,49,50,51],"Bash(accelerator config *)","Bash(accelerator corpus adr *)","Bash(accelerator corpus metadata derive)","Bash(accelerator corpus frontmatter validate *)","[topic or description] [--supersedes ADR-NNNN]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fdecisions\u002Fcreate-adr",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-10 21:05:37",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add atomicinnovation\u002Faccelerator --skill create-adr",{"tool":67,"command":68},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill create-adr",{"tool":70,"command":71},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill create-adr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fdecisions\u002Fcreate-adr\u002FSKILL.md",true,[],[76,109,131,152,170,194],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":92,"publishedAt":42},"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",[82,87],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[93,94,95,96,97,98,99,100,33,101,23,102,103,36,104,40,105,106,107,108],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","map","number","URL","code","reviewer","review","notes","change",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":42},"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",[],[116,117,118,119,120,121,32,36,108,39,122,41,123,124,125,126,127,128,129,130],"work","update","update work item","work item","enforcement","manage","edit","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":42},"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",[],[116,138,139,140,141,142,143,36,144,108,145,146,147,148,149,20,150,39,151,125,23],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","adopt","reconcile",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":42},"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",[],[159,116,160,138,139,161,162,163,164,165,166,167,168,169],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":179,"publishedAt":42},"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",[176],{"categoryNo":177,"categoryName":178,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000008","测试与质量",[180,181,116,182,119,183,184,185,186,187,188,36,189,190,39,41,191,192,22,102,193,125],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","gaps",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":42},"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",[],[106,116,201,119,202,203,32,36,204,205,39,41,191,22,206,23,207,208,125,209],"review work item","review work","escalation","file","quality","metadata","iterate","evaluate","path"]