[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CATGC9N83F0TF8PW7Y7N6C":3,"skill-same:01M6CATGC9N83F0TF8PW7Y7N6C":73},{"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":23,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6CATGC9N83F0TF8PW7Y7N6C","merge-reconciler",null,"Neutral third-party resolution of agent merge conflicts.","adnichols\u002Fai-configs","adnichols","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F493746?v=4","01M6C33VRY9WF6XWYPT1AFA7JJ","Aaron Nichols","01M6C33VWTNKGRM92E9G643V4W",5,"MIT","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fautonomous-ai-agents\u002Fmerge-reconciler\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33],"merge","merge reconciler","macos","linux","windows","git","multi-agent","hermes","hermes agent","merge conflicts","2026-11-10 10:12:30",false,"---\nname: merge-reconciler\ndescription: \"Neutral third-party resolution of agent merge conflicts.\"\nversion: 1.0.0\nauthor: Hermes Agent\nlicense: MIT\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [Multi-Agent, Git, Merge-Conflict, Kanban, Arbitration]\n    related_skills: [hermes-agent]\n---\n\n# Merge Reconciler\n\nResolve a git merge conflict between two AGENTS' branches as an impartial third\nparty. Agents resolving conflicts against a peer's work reliably either\noverwrite the peer or abandon their own change — they lack the peer's context\nand are biased toward their own side. This skill is the fix: a neutral\nreconciler that receives both diffs plus both sides' stated intents and\nproduces a merged result, like a merge-queue arbiter.\n\n## When to Use\n\n- Two agent branches\u002Fworktrees collide during a parallel campaign (kanban\n  engineering pipeline, parallel-PR wave, multi-worktree refactor).\n- `git merge` or `git rebase` halts on conflicts between two agents' work and\n  neither original agent should self-adjudicate.\n- Do NOT use for conflicts within a single agent's own work, or for trivial\n  lockfile\u002Fgenerated-file conflicts (regenerate those instead).\n\n## Prerequisites\n\n- A repo checkout containing the halted merge, or the two branch names plus\n  permission to run the merge yourself.\n- Both sides' intent sources: kanban completion summaries (`terminal` running\n  `hermes kanban show \u003Ctask-id>`), PR bodies, or at minimum each branch's\n  commit messages.\n- The project's build\u002Ftest command, if one exists.\n\n## How to Run\n\n**Standalone** — a human (or agent) invokes this skill inside the conflicted\nrepo: load the skill, then follow the Procedure top to bottom.\n\n**Spawned neutral agent** — the preferred shape in multi-agent campaigns:\n\n- `delegate_task`: spawn a subagent whose task message contains the repo path,\n  both branch names, and both sides' intent summaries verbatim, plus an\n  instruction to follow this skill.\n- Kanban-native: create a reconciliation card assigned to a **third profile**\n  (not either worker's profile) with BOTH conflicted cards linked as parents —\n  `kanban_create(title=\"reconcile branch-a x branch-b\", assignee=\"reconciler\",\n  parents=[\"t_a\", \"t_b\"])`. The parent links carry both sides' completion\n  summaries into the reconciler's context automatically; the card body should\n  name the repo path and the two branches.\n\n## Quick Reference\n\n| Hunk class | Definition | Resolution |\n|---|---|---|\n| disjoint-intent | The two changes serve different goals and can coexist | Combine both |\n| same-question-different-answer | Both sides answered one design question differently | Pick ONE per stated intents; surface the decision |\n| superseded | One side's premise no longer holds after the other's change | Keep the surviving side; note why |\n\nImpartiality contract: never favor the side that spawned you; touch ONLY\nconflicted regions (no drive-by edits); every design-question pick must appear\nexplicitly in the hand-back summary.\n\n## Procedure\n\n### 1. Gather both sides\n\n- Run via `terminal`: `git status` (confirm the conflicted state and list\n  conflicted files), `git merge-base \u003CA> \u003CB>`, then for each side\n  `git log --oneline \u003Cbase>..\u003Cside>` and `git diff \u003Cbase>..\u003Cside> -- \u003Cfile>`\n  for every conflicted file. In a halted merge, `HEAD` is one side and\n  `MERGE_HEAD` is the other.\n- Collect each side's intent: `hermes kanban show \u003Ctask-id>` for completion\n  summaries\u002Fmetadata, or the PR body, or the commit messages from the log\n  above. Write down one sentence of intent per side before touching any file.\n- Done when: you can state both intents in your own words and have both diffs\n  for every conflicted file.\n\n### 2. Classify every conflicted hunk\n\n- Open each conflicted file with `read_file` and locate each\n  `\u003C\u003C\u003C\u003C\u003C\u003C\u003C`\u002F`=======`\u002F`>>>>>>>` block.\n- Assign each hunk exactly one class from the Quick Reference table, judging\n  by the stated intents — not by which change looks nicer.\n- If a single hunk contains multiple independent decisions (e.g., new logic\n  that combines cleanly PLUS a styling\u002Frounding choice both sides answered\n  differently), decompose it into sub-decisions and classify each one.\n- A single file often mixes classes: one hunk may be a design collision while\n  a neighboring hunk is disjoint. Classify per hunk, not per file.\n- Done when: every hunk has a written class and a one-line rationale.\n\n### 3. Resolve under the impartiality contract\n\n- Edit each hunk with `patch` (or `write_file` for whole-file rewrites):\n  - disjoint-intent → merge both changes so each intent is fully served.\n  - same-question-different-answer → pick the answer that best serves the\n    STATED intents (e.g., an intent of \"strict validation\" beats \"quick\n    default\" if the task required correctness). Never split the difference\n    into a hybrid neither side asked for.\n  - superseded → keep the surviving side; delete the dead premise.\n- Never favor the side that spawned you. If intents genuinely tie, escalate\n  (block the kanban card \u002F report back) rather than guess.\n- Change nothing outside conflict markers — no formatting, renames, or\n  opportunistic fixes.\n- `git add` each resolved file via `terminal`.\n- Done when: `search_files` finds no `\u003C\u003C\u003C\u003C\u003C\u003C\u003C` markers in the repo and every\n  resolved file is staged.\n\n### 4. Verify\n\n- Run the project's build\u002Ftests via `terminal`; at minimum import\u002Fexecute the\n  touched modules. Both intents must be observable in the merged behavior\n  (e.g., side A's new semantics AND side B's disjoint addition both present).\n- Complete the merge: `git commit` (the default merge message plus a body\n  listing hunk decisions is fine).\n- Done when: verification passes and the merge commit exists.\n\n### 5. Hand back\n\n- Produce a completion summary naming EVERY hunk decision:\n  `file:lines — class — which side(s) kept — rationale`. For every\n  same-question-different-answer hunk, state the design question and the\n  answer you picked so a human can veto it — never bury a design call.\n- Kanban: `kanban_complete(summary=...)`. Standalone: print the summary.\n- Done when: the summary is delivered and lists all hunks.\n\n## Pitfalls\n\n- **Self-favoring**: if you were spawned by one of the conflicting agents,\n  you are structurally biased — state this and weigh the other side's intent\n  deliberately. Prefer the third-profile shape so this never arises.\n- **Splitting the difference** on a design collision produces a hybrid nobody\n  designed; pick one answer and surface it.\n- **Per-file classification**: files usually mix hunk classes; classifying a\n  whole file as one class silently drops a disjoint change.\n- **Drive-by edits** make the merge unreviewable and steal decisions from the\n  original agents.\n- **Missing intents**: commit messages alone can be thin; prefer kanban\n  completion summaries or PR bodies. If neither side's intent is recoverable,\n  escalate instead of guessing.\n- **Repeat offenders**: repeated conflicts on the SAME file across rounds are\n  a hotspot signal, not routine reconciliation work — flag it (e.g. a\n  `hotspot: \u003Cpath> — \u003Creason>` kanban comment) so the orchestrator decomposes\n  that file, rather than serially reconciling every new collision on it.\n\n## Verification\n\n- `git status` shows a clean tree on the target branch with a merge commit.\n- No conflict markers remain (`search_files` pattern `\u003C\u003C\u003C\u003C\u003C\u003C\u003C`).\n- Build\u002Ftests pass; both sides' intents are demonstrably present or the\n  dropped one is explicitly named in the summary.\n- The hand-back summary enumerates every hunk with class and rationale.\n","# Merge Reconciler\n\nResolve a git merge conflict between two AGENTS' branches as an impartial third\nparty. Agents resolving conflicts against a peer's work reliably either\noverwrite the peer or abandon their own change — they lack the peer's context\nand are biased toward their own side. This skill is the fix: a neutral\nreconciler that receives both diffs plus both sides' stated intents and\nproduces a merged result, like a merge-queue arbiter.\n\n## When to Use\n\n- Two agent branches\u002Fworktrees collide during a parallel campaign (kanban\n  engineering pipeline, parallel-PR wave, multi-worktree refactor).\n- `git merge` or `git rebase` halts on conflicts between two agents' work and\n  neither original agent should self-adjudicate.\n- Do NOT use for conflicts within a single agent's own work, or for trivial\n  lockfile\u002Fgenerated-file conflicts (regenerate those instead).\n\n## Prerequisites\n\n- A repo checkout containing the halted merge, or the two branch names plus\n  permission to run the merge yourself.\n- Both sides' intent sources: kanban completion summaries (`terminal` running\n  `hermes kanban show \u003Ctask-id>`), PR bodies, or at minimum each branch's\n  commit messages.\n- The project's build\u002Ftest command, if one exists.\n\n## How to Run\n\n**Standalone** — a human (or agent) invokes this skill inside the conflicted\nrepo: load the skill, then follow the Procedure top to bottom.\n\n**Spawned neutral agent** — the preferred shape in multi-agent campaigns:\n\n- `delegate_task`: spawn a subagent whose task message contains the repo path,\n  both branch names, and both sides' intent summaries verbatim, plus an\n  instruction to follow this skill.\n- Kanban-native: create a reconciliation card assigned to a **third profile**\n  (not either worker's profile) with BOTH conflicted cards linked as parents —\n  `kanban_create(title=\"reconcile branch-a x branch-b\", assignee=\"reconciler\",\n  parents=[\"t_a\", \"t_b\"])`. The parent links carry both sides' completion\n  summaries into the reconciler's context automatically; the card body should\n  name the repo path and the two branches.\n\n## Quick Reference\n\n| Hunk class | Definition | Resolution |\n|---|---|---|\n| disjoint-intent | The two changes serve different goals and can coexist | Combine both |\n| same-question-different-answer | Both sides answered one design question differently | Pick ONE per stated intents; surface the decision |\n| superseded | One side's premise no longer holds after the other's change | Keep the surviving side; note why |\n\nImpartiality contract: never favor the side that spawned you; touch ONLY\nconflicted regions (no drive-by edits); every design-question pick must appear\nexplicitly in the hand-back summary.\n\n## Procedure\n\n### 1. Gather both sides\n\n- Run via `terminal`: `git status` (confirm the conflicted state and list\n  conflicted files), `git merge-base \u003CA> \u003CB>`, then for each side\n  `git log --oneline \u003Cbase>..\u003Cside>` and `git diff \u003Cbase>..\u003Cside> -- \u003Cfile>`\n  for every conflicted file. In a halted merge, `HEAD` is one side and\n  `MERGE_HEAD` is the other.\n- Collect each side's intent: `hermes kanban show \u003Ctask-id>` for completion\n  summaries\u002Fmetadata, or the PR body, or the commit messages from the log\n  above. Write down one sentence of intent per side before touching any file.\n- Done when: you can state both intents in your own words and have both diffs\n  for every conflicted file.\n\n### 2. Classify every conflicted hunk\n\n- Open each conflicted file with `read_file` and locate each\n  `\u003C\u003C\u003C\u003C\u003C\u003C\u003C`\u002F`=======`\u002F`>>>>>>>` block.\n- Assign each hunk exactly one class from the Quick Reference table, judging\n  by the stated intents — not by which change looks nicer.\n- If a single hunk contains multiple independent decisions (e.g., new logic\n  that combines cleanly PLUS a styling\u002Frounding choice both sides answered\n  differently), decompose it into sub-decisions and classify each one.\n- A single file often mixes classes: one hunk may be a design collision while\n  a neighboring hunk is disjoint. Classify per hunk, not per file.\n- Done when: every hunk has a written class and a one-line rationale.\n\n### 3. Resolve under the impartiality contract\n\n- Edit each hunk with `patch` (or `write_file` for whole-file rewrites):\n  - disjoint-intent → merge both changes so each intent is fully served.\n  - same-question-different-answer → pick the answer that best serves the\n    STATED intents (e.g., an intent of \"strict validation\" beats \"quick\n    default\" if the task required correctness). Never split the difference\n    into a hybrid neither side asked for.\n  - superseded → keep the surviving side; delete the dead premise.\n- Never favor the side that spawned you. If intents genuinely tie, escalate\n  (block the kanban card \u002F report back) rather than guess.\n- Change nothing outside conflict markers — no formatting, renames, or\n  opportunistic fixes.\n- `git add` each resolved file via `terminal`.\n- Done when: `search_files` finds no `\u003C\u003C\u003C\u003C\u003C\u003C\u003C` markers in the repo and every\n  resolved file is staged.\n\n### 4. Verify\n\n- Run the project's build\u002Ftests via `terminal`; at minimum import\u002Fexecute the\n  touched modules. Both intents must be observable in the merged behavior\n  (e.g., side A's new semantics AND side B's disjoint addition both present).\n- Complete the merge: `git commit` (the default merge message plus a body\n  listing hunk decisions is fine).\n- Done when: verification passes and the merge commit exists.\n\n### 5. Hand back\n\n- Produce a completion summary naming EVERY hunk decision:\n  `file:lines — class — which side(s) kept — rationale`. For every\n  same-question-different-answer hunk, state the design question and the\n  answer you picked so a human can veto it — never bury a design call.\n- Kanban: `kanban_complete(summary=...)`. Standalone: print the summary.\n- Done when: the summary is delivered and lists all hunks.\n\n## Pitfalls\n\n- **Self-favoring**: if you were spawned by one of the conflicting agents,\n  you are structurally biased — state this and weigh the other side's intent\n  deliberately. Prefer the third-profile shape so this never arises.\n- **Splitting the difference** on a design collision produces a hybrid nobody\n  designed; pick one answer and surface it.\n- **Per-file classification**: files usually mix hunk classes; classifying a\n  whole file as one class silently drops a disjoint change.\n- **Drive-by edits** make the merge unreviewable and steal decisions from the\n  original agents.\n- **Missing intents**: commit messages alone can be thin; prefer kanban\n  completion summaries or PR bodies. If neither side's intent is recoverable,\n  escalate instead of guessing.\n- **Repeat offenders**: repeated conflicts on the SAME file across rounds are\n  a hotspot signal, not routine reconciliation work — flag it (e.g. a\n  `hotspot: \u003Cpath> — \u003Creason>` kanban comment) so the orchestrator decomposes\n  that file, rather than serially reconciling every new collision on it.\n\n## Verification\n\n- `git status` shows a clean tree on the target branch with a merge commit.\n- No conflict markers remain (`search_files` pattern `\u003C\u003C\u003C\u003C\u003C\u003C\u003C`).\n- Build\u002Ftests pass; both sides' intents are demonstrably present or the\n  dropped one is explicitly named in the summary.\n- The hand-back summary enumerates every hunk with class and rationale.\n",{"name":5,"author":39,"license":15,"version":40,"metadata":41,"platforms":51,"description":7},"Hermes Agent","1.0.0",{"hermes":42},{"tags":43,"related_skills":49},[44,45,46,47,48],"Multi-Agent","Git","Merge-Conflict","Kanban","Arbitration",[50],"hermes-agent",[27,26,28],"main","64e2fc9afa7bb3da1138eb73399144d0e7e73e9d","_hermes\u002Fdefault\u002Fskills\u002Fautonomous-ai-agents\u002Fmerge-reconciler",4,"https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs","https:\u002F\u002Fgithub.com\u002Fadnichols","2026-11-06 00:28:38",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add adnichols\u002Fai-configs --skill merge-reconciler",{"tool":65,"command":66},"bunx","bunx skills add adnichols\u002Fai-configs --skill merge-reconciler",{"tool":68,"command":69},"pnpm","pnpm dlx skills add adnichols\u002Fai-configs --skill merge-reconciler","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fautonomous-ai-agents\u002Fmerge-reconciler\u002FSKILL.md",true,[],[74,91,121,146,157,173],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":34},"01M6CB7RN791P5RRRCJWWC7DAR","blocked-page-recovery","Use when a fetch fails: 403\u002F429, paywall, WAF, bot wall.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fweb\u002Fblocked-page-recovery\u002FSKILL.md",[],[81,82,83,84,85,86,87,32,31,88,89,28,90,27,26],"recovery","page","blocked page recovery","bot","fallback","use","fetch","Citations","waf","research",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":106,"publishedAt":34},"01M6CB7NQY2VVYCQJ1QBXACQF4","writing-plans","Use when creating or updating executable software plans. Keep plans as local files unless the user explicitly asks to register them in Doct.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fwriting-plans\u002FSKILL.md",[97,100,101],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[107,108,109,110,111,112,113,114,115,116,117,118,86,119,32,31,120],"writing","writing plans","documentation","test","workflow","design","user","development","planning","files","implementation","html","ops","plan",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":136,"publishedAt":34},"01M6CB7JME246KZQHP73Z2STDF","test-driven-development","TDD: enforce RED-GREEN-REFACTOR, tests before code.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Ftest-driven-development\u002FSKILL.md",[127,130,133],{"categoryNo":128,"categoryName":129,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":131,"categoryName":132,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":134,"categoryName":135,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000037","律师与法务",[110,114,137,138,139,32,31,140,120,141,142,143,26,144,27,145,28],"test driven development","red-green-refactor","superpowers","quality","refactor","code","debugging","tdd","testing",{"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":153,"publishedAt":34},"01M6CB7FQ407KQTD4Z9VAWKY54","systematic-debugging","4-phase root cause debugging: understand bugs before fixing.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fsystematic-debugging\u002FSKILL.md",[152],{"categoryNo":131,"categoryName":132,"taxonomyType":21,"taxonomyTypeDesc":22},[143,154,114,139,32,31,155,120,156,28,110,27,26],"systematic debugging","troubleshooting","investigation",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":166,"publishedAt":34},"01M6CB7D57MK88HE5YPZHKH68Q","spike","Throwaway experiments to validate an idea before build.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fspike\u002FSKILL.md",[163],{"categoryNo":164,"categoryName":165,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[159,28,167,168,90,169,27,26,170,171,172,32,31,120,115],"validate","experiments","prototype","feasibility","sketch","experiment",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":183,"publishedAt":34},"01M6CB7APAQ37YE5YE1MAAFT42","simplify-code","Parallel 3-agent cleanup of recent code changes.","https:\u002F\u002Fgithub.com\u002Fadnichols\u002Fai-configs\u002Fblob\u002Fmain\u002F_hermes\u002Fdefault\u002Fskills\u002Fsoftware-development\u002Fsimplify-code\u002FSKILL.md",[179,180],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":181,"categoryName":182,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000030","开发工程师",[184,185,142,186,32,31,187,120,141,188,189,190,114,28,110,27,191,26],"simplify code","simplify","subagent","parallel","code-review","delegation","cleanup","review"]