[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MZP9HAS9W5GEEPA60M5T5F":3,"skill-same:01M6MZP9HAS9W5GEEPA60M5T5F":65},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":30,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M6MZP9HAS9W5GEEPA60M5T5F","merge",null,"Land an increment to main through the branch → commit → push → PR → review-gate → merge → cleanup flow. The review gate is a four-square decision (review depth × human gate). Picks up wherever you are in the cycle. Use when the user says \"merge this\", \"land this\", \"run a review and merge\", \"ship it\", or invokes \u002Fmerge.","aaronsb\u002Fagent-ways","aaronsb","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2738471?v=4","01M6MZKZTB1QDZ0YMSVFC2F0RE","Aaron Bockelie","01M6MZKZYG6T75YE9PCBNR72QK",26,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fmerge\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"use","when","depth","run","human","ship it","review","commit","Bash","you","cleanup","main","decision","up","review gate","cycle","pr","push","branch","2026-11-10 10:12:30",false,"---\nname: merge\ndescription: Land an increment to main through the branch → commit → push → PR → review-gate → merge → cleanup flow. The review gate is a four-square decision (review depth × human gate). Picks up wherever you are in the cycle. Use when the user says \"merge this\", \"land this\", \"run a review and merge\", \"ship it\", or invokes \u002Fmerge.\nallowed-tools: Bash, Read, Edit, Grep, Glob, Agent\n---\n\n# Merge — land an increment\n\nLand current work to main. This is the **stable tail** of the develop loop: review → fix → merge → clean up. Assess the current state and pick up from wherever the user is. Landing an increment is **not** cutting a release — versioning and publishing are `\u002Frelease`.\n\n## Arguments\n\n- `\u002Fmerge` — default flow; the review gate adapts to the four-square (below)\n- `\u002Fmerge full-sail` — skip the review pause (solo\u002Fpair repos, low blast-radius only; team repos and direction-setting changes still gate)\n\n## Assess First\n\nRun these in parallel to find your position in the flow:\n\n```bash\ngit status --short              # Uncommitted changes?\ngit branch --show-current       # On main or a feature branch?\ngit log --oneline main..HEAD    # Commits ahead of main?\ngit remote show origin 2>&1     # Remote tracking state?\n```\n\nAlso read repo flavor for the human gate:\n\n```bash\ngit log --since=\"90 days ago\" --format='%aN' | sort -u | wc -l\n```\n\n- **≤2 active**: Solo\u002Fpair — lightweight PRs\n- **3+ active**: Team — review pause mandatory, suggest reviewers\n\nIf the GitHub way already injected `**Context**: Team\u002FSolo\u002Fpair project`, use that.\n\n## Flow Steps (skip what's already done)\n\n### 1. Branch (if on main with changes)\n\n```bash\ngit checkout -b \u003Cbranch-name>\n```\n\n`feature\u002Fthing`, `fix\u002Fthing`, `refactor\u002Fthing`. Use the user's name if given.\n\n### 2. Commit (if uncommitted changes)\n\nStage and commit in conventional-commit format. Split into atomic commits if there are genuinely separate concerns. Ask for message direction if intent isn't clear.\n\n### 3. Push\n\n```bash\ngit push -u origin \u003Cbranch>\n```\n\n### 4. PR\n\n```bash\ngh pr create --title \"...\" --body \"$(cat \u003C\u003C'EOF'\n## Summary\n...\n\n## Test plan\n...\nEOF\n)\"\n```\n\nTitle under 70 chars. Summary 1–3 bullets.\n\n### 5. Review Gate — the four-square\n\nThe gate is **not one policy**. Classify the increment on two axes and pick the path (the full rationale lives in the `delivery\u002Fmerge` way):\n\n|                          | machine review: **light** | machine review: **deep \u002F swarm** |\n|--------------------------|---------------------------|----------------------------------|\n| **human gate: none**     | quick `code-reviewer` (or skip for trivial) → merge | swarm review + adversarial verify → agent-gated merge |\n| **human gate: required** | single `code-reviewer` → offer to read before merge | swarm review **and** operator approval before merge |\n\n- **X (review depth)** ← complexity and blast-radius: diff size, files touched, core-vs-leaf, test coverage, reversibility. The same change class sets the gate depth (`code\u002Ftesting\u002Fgates` way): choose review depth and gate depth together, and report each gate as executed, discovered, or absent.\n- **Y (human gate)** ← does the work set direction (an ADR, an architecture change → human gate required, however small), and has the operator already read it (wrote it or reviewed it live → gate already satisfied).\n\nWhen the classification is ambiguous, **state your read and let the operator decide** rather than silently picking a corner. Inside a `\u002Fgoal` loop, bias to the autonomous corners; outside one, ask. Team repos always gate; `\u002Fmerge full-sail` is rejected for them and for direction-setting changes — say why.\n\nInvoking `\u002Fmerge` is the request for the review this gate specifies, in whichever corner you landed — dispatch the reviewers, don't stop to ask permission for them. Say why in a clause as you go (\"review needs a reader who hasn't seen my reasoning\"). For a swarm, state the number before spawning it. Reviewers run on the model their agent definition names; a review is judgment work, so never pass a cheaper `model` to save tokens. See ADR-175.\n\n**Running a single review:**\n\n```\nAgent(subagent_type=\"code-reviewer\", prompt=\"Review PR #\u003Cnumber> in this repo.\nRun gh pr diff \u003Cnumber> to see the changes. Post findings as a gh pr comment.\")\n```\n\nFor the swarm corner, fan `code-reviewer` agents across dimensions (correctness, security, reuse) and adversarially verify each finding before trusting it.\n\n### 6. Remediate\n\nA review is only worth running if the findings get fixed. Before the merge gate, fix every finding the change owns, in the branch, wording included (ADR-613, ADR-614). The `delivery\u002Fmerge` way holds the ownership test and the table of the only ways an owned finding leaves the change:\n\n- **Owned** means the change caused it, it sits inside what the diff touches, or it sits in this repository's code the claimed behaviour runs through.\n- **Fix under the project's conventions.** Where none covers the fix and the call sits below the waterline (choices), settle it as an ADR, a project way or an instruction-file line, and say so in the PR. Above the waterline, ask the operator; the finding stays open until they answer.\n- **Filing an issue is not a fix.** Decline a finding only with evidence in the PR that it is wrong. A reviewer's \"non-blocking\" settles whether the change may merge, not whether the finding waits.\n- **A fix far larger than the change** gets its own card and a design look; a change that introduced such a defect goes back to design instead of merging.\n- **Any other deferral is the operator's call**, asked per finding with what the fix costs now. Without that answer, fix it.\n- **A finding the change does not own** is a residual (`delivery\u002Fissues`) and does not hold the merge.\n- **One fix round takes every owned finding.** A cap on review rounds limits the rounds, not the fixes. A review brief asks for findings to fix, not for a follow-up list.\n\n\"Reviewed\" is not \"landed clean.\"\n\n### 7. Merge\n\n```bash\ngh pr merge \u003Cnumber> --merge\n```\n\nRegular merge (not squash\u002Frebase) unless the user prefers otherwise — preserve the branch's narrative.\n\n### 8. Cleanup\n\n```bash\ngit checkout main && git pull && git fetch --prune\ngit branch -d \u003Cbranch>\ngit branch   # verify only main + active work branches remain\n```\n\nAlways run the full sequence — stale branches and dangling refs accumulate fast.\n\n### 9. Reconcile the ADR status\n\nIf the merged work implements an ADR, that ADR is still `Draft` or `Proposed`. Flip it now, while you know which one it was.\n\n```bash\ndocs\u002Fscripts\u002Fadr list --status Draft      # implemented by this merge?\ndocs\u002Fscripts\u002Fadr list --status Proposed\n```\n\nSet `status: Accepted` in the frontmatter of each one this merge delivered, then:\n\n```bash\ndocs\u002Fscripts\u002Fadr index -y                 # regenerate the index\ndocs\u002Fscripts\u002Fadr lint                     # 0 errors before committing\n```\n\nIf the merge supersedes an ADR, or the work proved one unnecessary, archive it instead of leaving it in the active set:\n\n```bash\ndocs\u002Fscripts\u002Fadr archive \u003Cn> --superseded-by ADR-\u003Cm> --reason \"...\" --dry-run\ndocs\u002Fscripts\u002Fadr archive \u003Cn> --status Rejected --reason \"...\"    # never built\n```\n\n`adr lint` requires the reciprocal `supersedes:` on the superseding ADR. Add it, or the link rots one-directionally.\n\nCommit as `docs(adr): accept ADR-\u003Cn> post-merge and regenerate index`.\n\n### 10. Release? (only if warranted)\n\nLanding is not releasing. If the merged change warrants a versioned release (new feature, breaking change, artifact-bearing project), **suggest `\u002Frelease`** — don't auto-publish. Publishing is a one-way door.\n\n## Key Principles\n\n- **Don't ask permission per step** — assess, propose the remaining flow, execute.\n- **Pause at decision points**: commit wording, PR description, the review gate.\n- **The four-square drives the gate**, not change size alone — a one-line ADR still gates on the operator; a big leaf refactor may not.\n- **Remediate before merge** — every finding the change owns is fixed in the branch; filing an issue does not fix it.\n- **Reconcile the ledger at land time** — a Draft ADR whose work just merged is a stale record. The correction costs one line now and a corpus audit later.\n- **If mid-flow**, pick up from current state — don't restart.\n- **Merge ≠ release** — landing an increment is the daily act; releasing is `\u002Frelease`.\n\n## Not for\n\n- Writing the code being merged — this lands finished work, it doesn't author it (see `\u002Fdevelop`).\n- Releasing\u002Ftagging\u002Fpublishing artifacts — that's `\u002Frelease` and the release way.\n- Merging on a team repo, or a direction-setting change, without the gate — mandatory there.\n\n## See Also\n\n- `code-reviewer` (subagent) — the reviewer this spawns at the gate; the built-in `\u002Fcode-review` is the manual equivalent.\n- `release` — the heavier sibling: publishing a versioned release.\n- `wrap` — Step 1 of wrap delegates here to land stranded work.\n- `develop` — the loop whose stable tail this is.\n","# Merge — land an increment\n\nLand current work to main. This is the **stable tail** of the develop loop: review → fix → merge → clean up. Assess the current state and pick up from wherever the user is. Landing an increment is **not** cutting a release — versioning and publishing are `\u002Frelease`.\n\n## Arguments\n\n- `\u002Fmerge` — default flow; the review gate adapts to the four-square (below)\n- `\u002Fmerge full-sail` — skip the review pause (solo\u002Fpair repos, low blast-radius only; team repos and direction-setting changes still gate)\n\n## Assess First\n\nRun these in parallel to find your position in the flow:\n\n```bash\ngit status --short              # Uncommitted changes?\ngit branch --show-current       # On main or a feature branch?\ngit log --oneline main..HEAD    # Commits ahead of main?\ngit remote show origin 2>&1     # Remote tracking state?\n```\n\nAlso read repo flavor for the human gate:\n\n```bash\ngit log --since=\"90 days ago\" --format='%aN' | sort -u | wc -l\n```\n\n- **≤2 active**: Solo\u002Fpair — lightweight PRs\n- **3+ active**: Team — review pause mandatory, suggest reviewers\n\nIf the GitHub way already injected `**Context**: Team\u002FSolo\u002Fpair project`, use that.\n\n## Flow Steps (skip what's already done)\n\n### 1. Branch (if on main with changes)\n\n```bash\ngit checkout -b \u003Cbranch-name>\n```\n\n`feature\u002Fthing`, `fix\u002Fthing`, `refactor\u002Fthing`. Use the user's name if given.\n\n### 2. Commit (if uncommitted changes)\n\nStage and commit in conventional-commit format. Split into atomic commits if there are genuinely separate concerns. Ask for message direction if intent isn't clear.\n\n### 3. Push\n\n```bash\ngit push -u origin \u003Cbranch>\n```\n\n### 4. PR\n\n```bash\ngh pr create --title \"...\" --body \"$(cat \u003C\u003C'EOF'\n## Summary\n...\n\n## Test plan\n...\nEOF\n)\"\n```\n\nTitle under 70 chars. Summary 1–3 bullets.\n\n### 5. Review Gate — the four-square\n\nThe gate is **not one policy**. Classify the increment on two axes and pick the path (the full rationale lives in the `delivery\u002Fmerge` way):\n\n|                          | machine review: **light** | machine review: **deep \u002F swarm** |\n|--------------------------|---------------------------|----------------------------------|\n| **human gate: none**     | quick `code-reviewer` (or skip for trivial) → merge | swarm review + adversarial verify → agent-gated merge |\n| **human gate: required** | single `code-reviewer` → offer to read before merge | swarm review **and** operator approval before merge |\n\n- **X (review depth)** ← complexity and blast-radius: diff size, files touched, core-vs-leaf, test coverage, reversibility. The same change class sets the gate depth (`code\u002Ftesting\u002Fgates` way): choose review depth and gate depth together, and report each gate as executed, discovered, or absent.\n- **Y (human gate)** ← does the work set direction (an ADR, an architecture change → human gate required, however small), and has the operator already read it (wrote it or reviewed it live → gate already satisfied).\n\nWhen the classification is ambiguous, **state your read and let the operator decide** rather than silently picking a corner. Inside a `\u002Fgoal` loop, bias to the autonomous corners; outside one, ask. Team repos always gate; `\u002Fmerge full-sail` is rejected for them and for direction-setting changes — say why.\n\nInvoking `\u002Fmerge` is the request for the review this gate specifies, in whichever corner you landed — dispatch the reviewers, don't stop to ask permission for them. Say why in a clause as you go (\"review needs a reader who hasn't seen my reasoning\"). For a swarm, state the number before spawning it. Reviewers run on the model their agent definition names; a review is judgment work, so never pass a cheaper `model` to save tokens. See ADR-175.\n\n**Running a single review:**\n\n```\nAgent(subagent_type=\"code-reviewer\", prompt=\"Review PR #\u003Cnumber> in this repo.\nRun gh pr diff \u003Cnumber> to see the changes. Post findings as a gh pr comment.\")\n```\n\nFor the swarm corner, fan `code-reviewer` agents across dimensions (correctness, security, reuse) and adversarially verify each finding before trusting it.\n\n### 6. Remediate\n\nA review is only worth running if the findings get fixed. Before the merge gate, fix every finding the change owns, in the branch, wording included (ADR-613, ADR-614). The `delivery\u002Fmerge` way holds the ownership test and the table of the only ways an owned finding leaves the change:\n\n- **Owned** means the change caused it, it sits inside what the diff touches, or it sits in this repository's code the claimed behaviour runs through.\n- **Fix under the project's conventions.** Where none covers the fix and the call sits below the waterline (choices), settle it as an ADR, a project way or an instruction-file line, and say so in the PR. Above the waterline, ask the operator; the finding stays open until they answer.\n- **Filing an issue is not a fix.** Decline a finding only with evidence in the PR that it is wrong. A reviewer's \"non-blocking\" settles whether the change may merge, not whether the finding waits.\n- **A fix far larger than the change** gets its own card and a design look; a change that introduced such a defect goes back to design instead of merging.\n- **Any other deferral is the operator's call**, asked per finding with what the fix costs now. Without that answer, fix it.\n- **A finding the change does not own** is a residual (`delivery\u002Fissues`) and does not hold the merge.\n- **One fix round takes every owned finding.** A cap on review rounds limits the rounds, not the fixes. A review brief asks for findings to fix, not for a follow-up list.\n\n\"Reviewed\" is not \"landed clean.\"\n\n### 7. Merge\n\n```bash\ngh pr merge \u003Cnumber> --merge\n```\n\nRegular merge (not squash\u002Frebase) unless the user prefers otherwise — preserve the branch's narrative.\n\n### 8. Cleanup\n\n```bash\ngit checkout main && git pull && git fetch --prune\ngit branch -d \u003Cbranch>\ngit branch   # verify only main + active work branches remain\n```\n\nAlways run the full sequence — stale branches and dangling refs accumulate fast.\n\n### 9. Reconcile the ADR status\n\nIf the merged work implements an ADR, that ADR is still `Draft` or `Proposed`. Flip it now, while you know which one it was.\n\n```bash\ndocs\u002Fscripts\u002Fadr list --status Draft      # implemented by this merge?\ndocs\u002Fscripts\u002Fadr list --status Proposed\n```\n\nSet `status: Accepted` in the frontmatter of each one this merge delivered, then:\n\n```bash\ndocs\u002Fscripts\u002Fadr index -y                 # regenerate the index\ndocs\u002Fscripts\u002Fadr lint                     # 0 errors before committing\n```\n\nIf the merge supersedes an ADR, or the work proved one unnecessary, archive it instead of leaving it in the active set:\n\n```bash\ndocs\u002Fscripts\u002Fadr archive \u003Cn> --superseded-by ADR-\u003Cm> --reason \"...\" --dry-run\ndocs\u002Fscripts\u002Fadr archive \u003Cn> --status Rejected --reason \"...\"    # never built\n```\n\n`adr lint` requires the reciprocal `supersedes:` on the superseding ADR. Add it, or the link rots one-directionally.\n\nCommit as `docs(adr): accept ADR-\u003Cn> post-merge and regenerate index`.\n\n### 10. Release? (only if warranted)\n\nLanding is not releasing. If the merged change warrants a versioned release (new feature, breaking change, artifact-bearing project), **suggest `\u002Frelease`** — don't auto-publish. Publishing is a one-way door.\n\n## Key Principles\n\n- **Don't ask permission per step** — assess, propose the remaining flow, execute.\n- **Pause at decision points**: commit wording, PR description, the review gate.\n- **The four-square drives the gate**, not change size alone — a one-line ADR still gates on the operator; a big leaf refactor may not.\n- **Remediate before merge** — every finding the change owns is fixed in the branch; filing an issue does not fix it.\n- **Reconcile the ledger at land time** — a Draft ADR whose work just merged is a stale record. The correction costs one line now and a corpus audit later.\n- **If mid-flow**, pick up from current state — don't restart.\n- **Merge ≠ release** — landing an increment is the daily act; releasing is `\u002Frelease`.\n\n## Not for\n\n- Writing the code being merged — this lands finished work, it doesn't author it (see `\u002Fdevelop`).\n- Releasing\u002Ftagging\u002Fpublishing artifacts — that's `\u002Frelease` and the release way.\n- Merging on a team repo, or a direction-setting change, without the gate — mandatory there.\n\n## See Also\n\n- `code-reviewer` (subagent) — the reviewer this spawns at the gate; the built-in `\u002Fcode-review` is the manual equivalent.\n- `release` — the heavier sibling: publishing a versioned release.\n- `wrap` — Step 1 of wrap delegates here to land stranded work.\n- `develop` — the loop whose stable tail this is.\n",{"name":5,"description":7,"allowed-tools":43},"Bash, Read, Edit, Grep, Glob, Agent","65e07e94634429bf6153c8bac01b5c7dcec3e452","skills\u002Fmerge",13,"https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways","https:\u002F\u002Fgithub.com\u002Faaronsb","I like coding with AI tools and making things.","2026-11-11 14:29:16",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add aaronsb\u002Fagent-ways --skill merge",{"tool":57,"command":58},"bunx","bunx skills add aaronsb\u002Fagent-ways --skill merge",{"tool":60,"command":61},"pnpm","pnpm dlx skills add aaronsb\u002Fagent-ways --skill merge","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fmerge\u002FSKILL.md",true,[],[66,85,98,119,146,169],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":77,"publishedAt":38},"01M6MZQPWHX5QCS3PVPVY1WAVC","my-skill","A hand-built skill the user keeps in ~\u002F.claude\u002Fskills. The fixture asserts it survives the install.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fdocker\u002Fseed\u002Fclaude\u002Fskills\u002Fmy-skill\u002FSKILL.md",[72],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[78,79,80,81,82,83,84],"my skill","my","hand","user","it","fixture","install",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":92,"publishedAt":38},"01M6MZQKYC9X5E94EDSGGGKZ78","work-skill","A skill in a second Claude Code config directory. The fixture asserts the directory is untouched.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fdocker\u002Fseed\u002Fclaude-work\u002Fskills\u002Fwork-skill\u002FSKILL.md",[91],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},[93,94,95,96,97,83],"work","work skill","config","directory","code",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":105,"publishedAt":38},"01M6MZQE8ZJARAB2WGCNHN9JB8","wrap","Wrap up a session at a natural seam — land in-flight work, square the TaskList honestly, write a copy-paste continuation prompt, then hand off to a directed \u002Fcompact. Use when the user says \"wrap up\", \"wrap this up\", \"let's wrap\", \"end of session\", \"checkpoint and compact\", \"hand off\", or invokes \u002Fwrap.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fwrap\u002FSKILL.md",[104],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},[100,106,19,32,107,108,109,110,111,20,112,113,114,115,116,117,118,93,80,27],"compact","end","session","checkpoint","continuation","wrap up","prompt","grep","square","write","read","at","paste",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":126,"publishedAt":38},"01M6MZQ8GDE7JHXY907BF0B495","ways-update","Update the agent-ways installation to the latest version — preview the update with `ways manage update --what-if` (versions, release notes, the commits, local changes, the actions, dev links), read it back to the user, then apply it with `ways manage update --commit`, which pulls the app source in $XDG_DATA, refreshes the binaries and corpus, and reprojects ~\u002F.claude. Use when the user wants to update agent-ways, pull the latest ways\u002Fhooks, or refresh their ways framework install. Not for editing or authoring individual ways (that is the ways skill) or upgrading project dependencies.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fways-update\u002FSKILL.md",[125],{"categoryNo":73,"categoryName":74,"taxonomyType":75,"taxonomyTypeDesc":76},[127,128,129,130,131,19,132,133,134,135,136,137,138,139,140,141,142,143,144,145],"ways update","update","version","editing","update agent","manage","actions","hooks","release notes","dev","local","for","commits","which","links","app","pull","back","project",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":38},"01M6MZQ3N4FRH6A5Z56P034ZQW","ways-tests","Score way matching via embedding similarity, analyze vocabulary, and validate frontmatter. Use when testing how well a way matches prompts, checking cosine similarity scores, inspecting the embedding engine status, or validating way files.","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fways-tests\u002FSKILL.md",[],[153,154,155,156,157,19,113,158,159,160,161,162,116,163,164,165,166,167,168,27],"tests","ways tests","files","testing","embedding","frontmatter","prompts","status","validate","edit","matching","how","via","similarity","engine","analyze",{"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":38},"01M6MZPXNGYKM1YG02F7Z5VRFW","ways-localize","Localize agent-ways into the operator's language — translate every way's matching metadata against the English root, tune it clean, and switch ways (and Claude Code) into that language. Use when the operator asks to run ways in their language (\"set up ways in Spanish\", \"localiza ways al español\", \"ways auf Deutsch\"). Not for authoring or editing individual ways (that is the ways skill), not for English installs (already built), and not for changing Claude Code's language alone (that is a settings.json edit).","https:\u002F\u002Fgithub.com\u002Faaronsb\u002Fagent-ways\u002Fblob\u002Fmain\u002Fskills\u002Fways-localize\u002FSKILL.md",[],[176,177,27,178,116,163,179,22,180,97,19,181,182,32,183,130,138,184,185,186],"localize","ways localize","settings","json","english","settings.json","clean","translate","switch","spanish","SET"]