[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXTSTYP6YRMBDG83V0A480":3,"skill-same:01M6DXTSTYP6YRMBDG83V0A480":81},{"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":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6DXTSTYP6YRMBDG83V0A480","validate-plan",null,"Validate that an implementation plan was correctly executed by verifying success criteria and identifying deviations. Use after implementing a plan to verify correctness.","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\u002Fplanning\u002Fvalidate-plan\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"validate","plan","validate plan","implementation plan","to plan","frontmatter","implementing","path","root","correctness","detect","implementation","use","Bash","verify","file","metadata","config","2026-11-10 10:12:30",false,"---\nname: validate-plan\ndescription: Validate that an implementation plan was correctly executed by\n  verifying success criteria and identifying deviations. Use after implementing\n  a plan to verify correctness.\nargument-hint: \"[path to plan file]\"\nallowed-tools:\n   - Bash(accelerator config *)\n   - Bash(accelerator corpus metadata derive)\n   - Bash(accelerator corpus frontmatter validate *)\n   - Bash(accelerator vcs root)\n   - Bash(accelerator vcs detect --descriptive)\n---\n\n# Validate Plan\n\n!`accelerator config context --skill validate-plan --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**Plans directory**: !`accelerator config path plans --fail-safe`\n**Validations directory**: !`accelerator config path validations --fail-safe`\n\n## Plan Validation Template\n\nThe template below defines the frontmatter and body structure that\nevery plan validation report must carry. Read it now — use it to guide\nwhat information you record in the validation process and what shape\nyou persist in Step 4.\n\n!`accelerator config template validation --fail-safe`\n\nYou are tasked with validating that an implementation plan was correctly\nexecuted, verifying all success criteria and identifying any deviations or\nissues.\n\n## Initial Setup\n\nWhen invoked:\n\n1. **Determine context** - Are you in an existing conversation or starting\n   fresh?\n\n- If existing: Review what was implemented in this session\n- If fresh: Need to discover what was done through the session's VCS and\n  codebase analysis\n\n2. **Locate the plan**:\n\n- If plan path provided, use it\n- Otherwise, search recent commits for plan references or ask user\n\n3. **Gather implementation evidence**:\n\nIf the SessionStart VCS Command Reference is not in context — validate-plan\noften runs late in a long session, after it may have been compacted out —\nre-derive it first with `accelerator vcs detect --descriptive` and read the\nidioms out of the emitted `additionalContext` string.\n\n- Recent commits: list the checkout's recent revisions using the session's\n  VCS log command (see the SessionStart VCS Command Reference).\n- Implementation diff: take the cumulative change since the trunk divergence\n  point using the session's VCS diff-range idiom (see the SessionStart VCS\n  Command Reference).\n- Run the repository's checks from its root, aborting if the root cannot be\n  resolved (out of a repository, `accelerator vcs root` exits non-zero, so the\n  assignment fails and the `&&` chain stops rather than running `make` in the\n  wrong tree):\n  ```bash\n  root=\"$(accelerator vcs root)\" && cd \"$root\" && make check test\n  ```\n\n## Validation Process\n\n### Step 1: Context Discovery\n\nIf starting fresh or need more context:\n\n1. **Read the implementation plan** completely\n2. **Identify what should have changed**:\n\n- List all files that should be modified\n- Note all success criteria (automated and manual)\n- Identify key functionality to verify\n\n3. **Spawn parallel research tasks** to discover implementation:\n   ```\n   Task 1 - Verify database changes:\n   Research if migration [N] was added and schema changes match plan.\n   Check: migration files, schema version, table structure\n   Return: What was implemented vs what plan specified\n\n   Task 2 - Verify code changes:\n   Find all modified files related to [feature].\n   Compare actual changes to plan specifications.\n   Return: File-by-file comparison of planned vs actual\n\n   Task 3 - Verify test coverage:\n   Check if tests were added\u002Fmodified as specified.\n   Run test commands and capture results.\n   Return: Test status and any missing coverage\n   ```\n\n### Step 2: Systematic Validation\n\nFor each phase in the plan:\n\n1. **Check completion status**:\n\n- Look for checkmarks in the plan (- [x])\n- Verify the actual code matches claimed completion\n\n2. **Run automated verification**:\n\n- Execute each command from \"Automated Verification\"\n- Document pass\u002Ffail status\n- If failures, investigate root cause\n\n3. **Assess manual criteria**:\n\n- List what needs manual testing\n- Provide clear steps for user verification\n\n4. **Think deeply about edge cases**:\n\n- Were error conditions handled?\n- Are there missing validations?\n- Could the implementation break existing functionality?\n\n### Step 3: Generate Validation Report\n\nCompose the validation report body following the structure defined in\nthe Plan Validation Template at the top of this skill (Implementation\nStatus, Automated Verification Results, Code Review Findings, Manual\nTesting Required, Recommendations).\n\n### Step 4: Persist the Validation Report\n\nWrite the validation report to the configured validations directory:\n\n1. Derive the filename from the plan filename: extract the filename stem\n   (without directory path or `.md` extension) regardless of how the path\n   was provided. For example, if the plan is\n   `{plans directory}\u002F2026-03-22-improve-error-handling.md`, the validation is\n   `{validations directory}\u002F2026-03-22-improve-error-handling-validation.md`.\n\n2. Create the configured validations directory if it doesn't exist.\n\n#### Populate frontmatter\n\nThe `target:` field is filled automatically from the plan reference under\nvalidation — this is what makes the report traceable back to the plan it\ncovers. Per ADR-0034, the typed-linkage form is `\"plan:\u003Cplan-id>\"`.\n\nBefore writing the validation file, capture metadata and substitute the\nunified base fields and per-type extras into the template's frontmatter\nblock:\n\n1. Invoke `accelerator corpus metadata derive`\n   to obtain `Current Date\u002FTime (UTC):`.\n2. **Substitute** every field below with the indicated value:\n   - `type:` ← `plan-validation`\n   - `id:` ← the validation filename stem (e.g.\n     `2026-05-30-0065-update-artifact-templates-to-unified-schema-validation`),\n     always quoted as a YAML string\n   - `title:` ← `Validation Report: {plan title}`\n   - `date:` ← the `Current Date\u002FTime (UTC):` value\n   - `author:` ← the author value resolved per `create-work-item\u002FSKILL.md:578-580`\n   - `producer:` ← `validate-plan`\n   - `status:` ← `complete`\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, not quoted)\n   - `parent:` ← typed-linkage ref to the parent plan (`\"plan:NNNN\"`).\n     Fill when the validation names a parent plan; otherwise omit the\n     key.\n   - `target:` ← `\"plan:\u003Cplan-id>\"` (e.g.\n     `\"plan:2026-05-30-0065-update-artifact-templates-to-unified-schema\"`);\n     the typed-linkage ref to the plan being validated, per ADR-0034.\n     Always fill — every validation has a target.\n   - `relates_to:` ← list of typed-linkage refs to related artifacts\n     (`[\"plan-validation:NNNN\", ...]`). Fill when related validations\n     are explicit; otherwise omit the key.\n   - `result:` ← `pass | partial | fail` per the Implementation\n     Status of the report (see derivation rule below)\n3. Write the file with the substituted frontmatter block followed by\n   the validation report body from Step 3.\n\nDetermine the `result` field from the report:\n\n- `pass`: all phases fully implemented, all automated checks pass\n- `partial`: some phases implemented or some checks failing\n- `fail`: major deviations or critical failures\n\n4. If the validation result is `pass`, update the plan's frontmatter\n`status` field to `done` (if the plan has YAML frontmatter with a\n`status` field). This closes the plan lifecycle.\n\n5. Inform the user where the report was saved:\n```\nValidation report saved to {validations directory}\u002F{filename}.md\n```\n\n**Validate the frontmatter**: after writing, run `corpus frontmatter\nvalidate` over the validation report you just wrote:\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cpath>\n```\n\nIf it exits non-zero, the report violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n## Working with Existing Context\n\nIf you were part of the implementation:\n\n- Review the conversation history\n- Check your todo list for what was completed\n- Focus validation on work done in this session\n- Be honest about any shortcuts or incomplete items\n\n## Important Guidelines\n\n1. **Be thorough but practical** - Focus on what matters\n2. **Run all automated checks** - Don't skip verification commands\n3. **Document everything** - Both successes and issues\n4. **Think critically** - Question if the implementation truly solves the\n   problem\n5. **Consider maintenance** - Will this be maintainable long-term?\n\n## Validation Checklist\n\nAlways verify:\n\n- [ ] All phases marked complete are actually done\n- [ ] Automated tests pass\n- [ ] Code follows existing patterns\n- [ ] No regressions introduced\n- [ ] Error handling is robust\n- [ ] Documentation updated if needed\n- [ ] Manual test steps are clear\n\n## Relationship to Other Commands\n\nRecommended workflow:\n\n1. `\u002Fimplement-plan` - Execute the implementation\n2. `\u002Fcommit` - Create atomic commits for changes\n3. `\u002Fvalidate-plan` - Verify implementation correctness (saves report to\n   the configured validations directory)\n4. `\u002Fdescribe-pr` - Generate PR description\n\nThe validation works best after commits are made, as it can analyze the VCS\nhistory to understand what was implemented.\n\nRemember: Good validation catches issues before they reach production. Be\nconstructive but thorough in identifying gaps or improvements.\n\n!`accelerator config instructions validate-plan --fail-safe`\n","# Validate Plan\n\n!`accelerator config context --skill validate-plan --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**Plans directory**: !`accelerator config path plans --fail-safe`\n**Validations directory**: !`accelerator config path validations --fail-safe`\n\n## Plan Validation Template\n\nThe template below defines the frontmatter and body structure that\nevery plan validation report must carry. Read it now — use it to guide\nwhat information you record in the validation process and what shape\nyou persist in Step 4.\n\n!`accelerator config template validation --fail-safe`\n\nYou are tasked with validating that an implementation plan was correctly\nexecuted, verifying all success criteria and identifying any deviations or\nissues.\n\n## Initial Setup\n\nWhen invoked:\n\n1. **Determine context** - Are you in an existing conversation or starting\n   fresh?\n\n- If existing: Review what was implemented in this session\n- If fresh: Need to discover what was done through the session's VCS and\n  codebase analysis\n\n2. **Locate the plan**:\n\n- If plan path provided, use it\n- Otherwise, search recent commits for plan references or ask user\n\n3. **Gather implementation evidence**:\n\nIf the SessionStart VCS Command Reference is not in context — validate-plan\noften runs late in a long session, after it may have been compacted out —\nre-derive it first with `accelerator vcs detect --descriptive` and read the\nidioms out of the emitted `additionalContext` string.\n\n- Recent commits: list the checkout's recent revisions using the session's\n  VCS log command (see the SessionStart VCS Command Reference).\n- Implementation diff: take the cumulative change since the trunk divergence\n  point using the session's VCS diff-range idiom (see the SessionStart VCS\n  Command Reference).\n- Run the repository's checks from its root, aborting if the root cannot be\n  resolved (out of a repository, `accelerator vcs root` exits non-zero, so the\n  assignment fails and the `&&` chain stops rather than running `make` in the\n  wrong tree):\n  ```bash\n  root=\"$(accelerator vcs root)\" && cd \"$root\" && make check test\n  ```\n\n## Validation Process\n\n### Step 1: Context Discovery\n\nIf starting fresh or need more context:\n\n1. **Read the implementation plan** completely\n2. **Identify what should have changed**:\n\n- List all files that should be modified\n- Note all success criteria (automated and manual)\n- Identify key functionality to verify\n\n3. **Spawn parallel research tasks** to discover implementation:\n   ```\n   Task 1 - Verify database changes:\n   Research if migration [N] was added and schema changes match plan.\n   Check: migration files, schema version, table structure\n   Return: What was implemented vs what plan specified\n\n   Task 2 - Verify code changes:\n   Find all modified files related to [feature].\n   Compare actual changes to plan specifications.\n   Return: File-by-file comparison of planned vs actual\n\n   Task 3 - Verify test coverage:\n   Check if tests were added\u002Fmodified as specified.\n   Run test commands and capture results.\n   Return: Test status and any missing coverage\n   ```\n\n### Step 2: Systematic Validation\n\nFor each phase in the plan:\n\n1. **Check completion status**:\n\n- Look for checkmarks in the plan (- [x])\n- Verify the actual code matches claimed completion\n\n2. **Run automated verification**:\n\n- Execute each command from \"Automated Verification\"\n- Document pass\u002Ffail status\n- If failures, investigate root cause\n\n3. **Assess manual criteria**:\n\n- List what needs manual testing\n- Provide clear steps for user verification\n\n4. **Think deeply about edge cases**:\n\n- Were error conditions handled?\n- Are there missing validations?\n- Could the implementation break existing functionality?\n\n### Step 3: Generate Validation Report\n\nCompose the validation report body following the structure defined in\nthe Plan Validation Template at the top of this skill (Implementation\nStatus, Automated Verification Results, Code Review Findings, Manual\nTesting Required, Recommendations).\n\n### Step 4: Persist the Validation Report\n\nWrite the validation report to the configured validations directory:\n\n1. Derive the filename from the plan filename: extract the filename stem\n   (without directory path or `.md` extension) regardless of how the path\n   was provided. For example, if the plan is\n   `{plans directory}\u002F2026-03-22-improve-error-handling.md`, the validation is\n   `{validations directory}\u002F2026-03-22-improve-error-handling-validation.md`.\n\n2. Create the configured validations directory if it doesn't exist.\n\n#### Populate frontmatter\n\nThe `target:` field is filled automatically from the plan reference under\nvalidation — this is what makes the report traceable back to the plan it\ncovers. Per ADR-0034, the typed-linkage form is `\"plan:\u003Cplan-id>\"`.\n\nBefore writing the validation file, capture metadata and substitute the\nunified base fields and per-type extras into the template's frontmatter\nblock:\n\n1. Invoke `accelerator corpus metadata derive`\n   to obtain `Current Date\u002FTime (UTC):`.\n2. **Substitute** every field below with the indicated value:\n   - `type:` ← `plan-validation`\n   - `id:` ← the validation filename stem (e.g.\n     `2026-05-30-0065-update-artifact-templates-to-unified-schema-validation`),\n     always quoted as a YAML string\n   - `title:` ← `Validation Report: {plan title}`\n   - `date:` ← the `Current Date\u002FTime (UTC):` value\n   - `author:` ← the author value resolved per `create-work-item\u002FSKILL.md:578-580`\n   - `producer:` ← `validate-plan`\n   - `status:` ← `complete`\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, not quoted)\n   - `parent:` ← typed-linkage ref to the parent plan (`\"plan:NNNN\"`).\n     Fill when the validation names a parent plan; otherwise omit the\n     key.\n   - `target:` ← `\"plan:\u003Cplan-id>\"` (e.g.\n     `\"plan:2026-05-30-0065-update-artifact-templates-to-unified-schema\"`);\n     the typed-linkage ref to the plan being validated, per ADR-0034.\n     Always fill — every validation has a target.\n   - `relates_to:` ← list of typed-linkage refs to related artifacts\n     (`[\"plan-validation:NNNN\", ...]`). Fill when related validations\n     are explicit; otherwise omit the key.\n   - `result:` ← `pass | partial | fail` per the Implementation\n     Status of the report (see derivation rule below)\n3. Write the file with the substituted frontmatter block followed by\n   the validation report body from Step 3.\n\nDetermine the `result` field from the report:\n\n- `pass`: all phases fully implemented, all automated checks pass\n- `partial`: some phases implemented or some checks failing\n- `fail`: major deviations or critical failures\n\n4. If the validation result is `pass`, update the plan's frontmatter\n`status` field to `done` (if the plan has YAML frontmatter with a\n`status` field). This closes the plan lifecycle.\n\n5. Inform the user where the report was saved:\n```\nValidation report saved to {validations directory}\u002F{filename}.md\n```\n\n**Validate the frontmatter**: after writing, run `corpus frontmatter\nvalidate` over the validation report you just wrote:\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cpath>\n```\n\nIf it exits non-zero, the report violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n## Working with Existing Context\n\nIf you were part of the implementation:\n\n- Review the conversation history\n- Check your todo list for what was completed\n- Focus validation on work done in this session\n- Be honest about any shortcuts or incomplete items\n\n## Important Guidelines\n\n1. **Be thorough but practical** - Focus on what matters\n2. **Run all automated checks** - Don't skip verification commands\n3. **Document everything** - Both successes and issues\n4. **Think critically** - Question if the implementation truly solves the\n   problem\n5. **Consider maintenance** - Will this be maintainable long-term?\n\n## Validation Checklist\n\nAlways verify:\n\n- [ ] All phases marked complete are actually done\n- [ ] Automated tests pass\n- [ ] Code follows existing patterns\n- [ ] No regressions introduced\n- [ ] Error handling is robust\n- [ ] Documentation updated if needed\n- [ ] Manual test steps are clear\n\n## Relationship to Other Commands\n\nRecommended workflow:\n\n1. `\u002Fimplement-plan` - Execute the implementation\n2. `\u002Fcommit` - Create atomic commits for changes\n3. `\u002Fvalidate-plan` - Verify implementation correctness (saves report to\n   the configured validations directory)\n4. `\u002Fdescribe-pr` - Generate PR description\n\nThe validation works best after commits are made, as it can analyze the VCS\nhistory to understand what was implemented.\n\nRemember: Good validation catches issues before they reach production. Be\nconstructive but thorough in identifying gaps or improvements.\n\n!`accelerator config instructions validate-plan --fail-safe`\n",{"name":5,"description":7,"allowed-tools":42,"argument-hint":48},[43,44,45,46,47],"Bash(accelerator config *)","Bash(accelerator corpus metadata derive)","Bash(accelerator corpus frontmatter validate *)","Bash(accelerator vcs root)","Bash(accelerator vcs detect --descriptive)","[path to plan file]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fplanning\u002Fvalidate-plan",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-12 04:07:28",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add atomicinnovation\u002Faccelerator --skill validate-plan",{"tool":63,"command":64},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill validate-plan",{"tool":66,"command":67},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill validate-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fplanning\u002Fvalidate-plan\u002FSKILL.md",true,[71,77],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fcli-examples.md","REFERENCE","参考文档",550,"https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002Fhermes-sovereign-unified-v13.6\u002Fblob\u002Fmain\u002Fhermes-agent\u002Foptional-skills\u002Fsecurity\u002F1password\u002Freferences\u002Fcli-examples.md",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fget-started.md",527,"https:\u002F\u002Fgithub.com\u002Fgjbvsjjvgm-sketch\u002Fhermes-sovereign-unified-v13.6\u002Fblob\u002Fmain\u002Fhermes-agent\u002Foptional-skills\u002Fsecurity\u002F1password\u002Freferences\u002Fget-started.md",[82,118,139,161,179,203],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":98,"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",[88,93],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":94,"categoryName":95,"taxonomyType":96,"taxonomyTypeDesc":97},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[99,100,101,102,103,104,105,106,107,108,109,110,111,32,112,113,114,115,116,117],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","when","number","URL","code","architecture","reviewer","review","notes","change",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"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",[],[125,126,127,128,129,130,31,32,117,36,131,19,132,133,24,134,135,136,137,138],"work","update","update work item","work item","enforcement","manage","edit","status","transition","Existing","tags","changes","fields","op",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"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",[],[125,146,147,148,149,150,151,32,152,117,153,154,155,156,157,158,159,36,160,24,109],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"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",[],[168,125,169,146,147,170,171,172,173,174,175,176,177,178],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":188,"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",[185],{"categoryNo":186,"categoryName":187,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000008","测试与质量",[189,190,125,191,128,192,193,194,195,196,197,32,198,199,36,19,30,200,201,110,202,24],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","grilling","user","gaps",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":209,"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",[],[115,125,210,128,211,212,31,32,34,213,36,19,30,201,35,109,214,215,24,26],"review work item","review work","escalation","quality","iterate","evaluate"]