[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PVEFF0JWX2SKEP509D6ZH7":3,"skill-same:01M6PVEFF0JWX2SKEP509D6ZH7":62},{"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":42,"commitSha":43,"skillDirectory":44,"forksCount":41,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M6PVEFF0JWX2SKEP509D6ZH7","library-editing",null,"Put a component where this project reads it, and wire it to a role. Use before adding or removing a trait, rule or skill, and when a component you wrote is not reaching the agent.","muratovv\u002Fai-hats","muratovv","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F7502801?v=4","01M6JGCBN4KEJX012GPJVSH04T","Fedor Muratov","01M6JGCBSNMN7CW3RGTPPE0MN2",3,"MIT","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Flibrary-editing\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33],"library","editing","library editing","component","use","project","rule","it","you","role","2026-11-10 10:12:30",false,"---\nname: library-editing\ndescription: >-\n  Put a component where this project reads it, and wire it to a role. Use\n  before adding or removing a trait, rule or skill, and when a component\n  you wrote is not reaching the agent.\nlicense: MIT\nai_hats:\n  schema_version: 1\n  type: skill\n---\n\n# Library Editing\n\nPut a component where this project reads it, and wire it to the role that needs it.\n\n## When to Use\n\nTwo neighbours own the steps on either side of this one. **Writing** the\ncomponent — its structure, its description, its validation scenario — is\n`skill-template`, and deciding that prose is the right mechanism at all is\n`prompt-authoring`. **Proving** the wiring worked is `composition-verification`;\nthis skill stops at \"the edit is made\", it does not certify it arrived.\n\n## Procedure\n\n### 1. Put the component in a root this project reads\n\nYour own roots are **flat** — no layer directory under them:\n\n```\n\u003Cproject>\u002Flibraries\u002F{roles,traits,rules,skills}\u002F\u003Cname>\u002F     # project-local\n~\u002F.ai-hats\u002F{roles,traits,rules,skills}\u002F\u003Cname>\u002F              # user-wide\n```\n\nAny further root listed in `~\u002F.ai-hats\u002Flibrary_paths.yaml` or under\n`library_paths:` in the project's `ai-hats.yaml` has the same shape.\n`~\u002F.ai-hats\u002Fcore\u002Frules\u002Ffoo\u002F` resolves to nothing — the `core\u002F` \u002F `usage\u002F` split\nexists only inside the shipped library. Roots layer last-wins, so a component\nwhose name matches a shipped one overrides it.\n\n**Start a new component from a shipped one, not from memory.** A rule is a bare\n`rule.md`; a skill is a `SKILL.md` (`skill-template` owns its shape); a trait is\na `config.yaml` with `name`, `composition` (`traits` \u002F `rules` \u002F `skills` \u002F\n`apps`) and `injection`; a role is that same `config.yaml` plus `priorities`,\nand is the usual unit of work in a project of your own. `ai-hats list roles`\n(and `list traits` \u002F `list rules` \u002F `list skills`) names the shipped ones — copy\nthe closest and edit it, so the keys are right before the content is.\n`ai-hats config status` then tags each component of the active role with the\nlayer it resolved from (`built-in` \u002F `global` \u002F `project`), which is how you\nconfirm yours won.\n\n### 2. Wire it — persistently, or for one session\n\nPersistent, written into `ai-hats.yaml` (project) or\n`~\u002F.ai-hats\u002Fcustomizations.yaml` (global):\n\n```bash\nai-hats config customize \u003Crole> --add-trait \u003Cname> --project\nai-hats config customize \u003Crole> --add-skill \u003Cname> --remove-skill \u003Cname> --global\nai-hats config customize \u003Crole> --injection-append \"\u003Ctext>\"\n```\n\nEphemeral, for this launch only — a **role spec**, and nothing is written:\n\n```bash\nai-hats -r \"dev-python + skill-engineer\"           # quotes when spaces are used\nai-hats -r dev-python+skill-engineer               # compact form, same thing\nai-hats -r \"dev-python - dev::shell + skill-engineer\"\n```\n\nReach for the role spec when you are testing whether a component changes\nbehaviour at all. Persist it once the answer is yes — a spec nobody wrote down\nis a result nobody can reproduce.\n\n### 3. The `+` \u002F `-` grammar, and the two traps in it\n\nThe base role comes first, then operations. Both operators take exactly one\ncomponent name.\n\n- **`-` is an operator only when surrounded by spaces.** `trait-base` is one\n  identifier; `- trait-base` removes it. A hyphenated name never splits.\n- **A removal resolves against the COMPOSED set**, not against the role's own\n  declaration: you can drop a rule a trait brought in, without editing the trait.\n- A repeated operand, or a trailing `+` with nothing after it, is refused with a\n  parse error rather than silently ignored.\n\nThe spec becomes a third overlay layer — `[global, project, runtime]` — so it\nwins over both persistent layers for that session.\n\n### 4. Know when the edit takes effect\n\nThere is no sync command. Roles are composed fresh at every launch, so an edit\nto a component body, to `ai-hats.yaml`, or to a customization is live for the\n**next** session — including a component you just wrote by hand. `ai-hats self\ninit` validates the config and refreshes the project scaffold; it is not how a\ncomposition change lands.\n\nOne exception. A skill's git gates are resolved at commit time from the composed\nrole, but the `.githooks\u002F\u003Cevent>` dispatcher that runs them is a stub written\nonly by `ai-hats init` \u002F `self init` \u002F `self update` \u002F the first interactive\nlaunch — `config customize` never writes one. A gate under an event whose stub\nexists is live at the next commit; a gate on an event with no stub yet is inert\nuntil you run `ai-hats self init` once.\n\nNever hand-copy component files into a provider's own directory. Those trees are\nmaterialized per session from the resolved library; a hand-made copy drifts from\nthe source and never composes.\n\n### 5. Then prove it arrived\n\nAn edit that the composer never resolved leaves the file looking perfect. Go to\n**composition-verification** before reporting the change landed.\n\n## Completion\n\n- The component sits in a root this project actually reads.\n- It is wired either persistently (and the command is recorded) or by an explicit\n  role spec for a deliberately ephemeral test.\n- The next launch is understood to be when it takes effect.\n- Arrival is confirmed through `composition-verification`, not assumed.\n\n**Validation scenario (RED).** An agent asked to give a working role the\nauthoring craft writes a trait into `~\u002F.ai-hats\u002Fcore\u002Ftraits\u002F`, mirroring the\nshipped library's layer layout. The path resolves to nothing, the composer\nreports no error, and the role is unchanged — while the file on disk looks\nexactly right. Step 1 prevents it; step 5 catches it if step 1 was skipped.\n\n## Anti-Patterns\n\n- Mirroring the shipped `core\u002F` \u002F `usage\u002F` layers inside your own root.\n- Testing a component by editing the shipped library instead of overriding it by\n  name from your own root.\n- Leaving a promising role spec ephemeral, so the result cannot be reproduced.\n- Writing `- trait-base` as `-trait-base` and wondering why the parse failed.\n- Copying skill files into the provider's directory by hand.\n","# Library Editing\n\nPut a component where this project reads it, and wire it to the role that needs it.\n\n## When to Use\n\nTwo neighbours own the steps on either side of this one. **Writing** the\ncomponent — its structure, its description, its validation scenario — is\n`skill-template`, and deciding that prose is the right mechanism at all is\n`prompt-authoring`. **Proving** the wiring worked is `composition-verification`;\nthis skill stops at \"the edit is made\", it does not certify it arrived.\n\n## Procedure\n\n### 1. Put the component in a root this project reads\n\nYour own roots are **flat** — no layer directory under them:\n\n```\n\u003Cproject>\u002Flibraries\u002F{roles,traits,rules,skills}\u002F\u003Cname>\u002F     # project-local\n~\u002F.ai-hats\u002F{roles,traits,rules,skills}\u002F\u003Cname>\u002F              # user-wide\n```\n\nAny further root listed in `~\u002F.ai-hats\u002Flibrary_paths.yaml` or under\n`library_paths:` in the project's `ai-hats.yaml` has the same shape.\n`~\u002F.ai-hats\u002Fcore\u002Frules\u002Ffoo\u002F` resolves to nothing — the `core\u002F` \u002F `usage\u002F` split\nexists only inside the shipped library. Roots layer last-wins, so a component\nwhose name matches a shipped one overrides it.\n\n**Start a new component from a shipped one, not from memory.** A rule is a bare\n`rule.md`; a skill is a `SKILL.md` (`skill-template` owns its shape); a trait is\na `config.yaml` with `name`, `composition` (`traits` \u002F `rules` \u002F `skills` \u002F\n`apps`) and `injection`; a role is that same `config.yaml` plus `priorities`,\nand is the usual unit of work in a project of your own. `ai-hats list roles`\n(and `list traits` \u002F `list rules` \u002F `list skills`) names the shipped ones — copy\nthe closest and edit it, so the keys are right before the content is.\n`ai-hats config status` then tags each component of the active role with the\nlayer it resolved from (`built-in` \u002F `global` \u002F `project`), which is how you\nconfirm yours won.\n\n### 2. Wire it — persistently, or for one session\n\nPersistent, written into `ai-hats.yaml` (project) or\n`~\u002F.ai-hats\u002Fcustomizations.yaml` (global):\n\n```bash\nai-hats config customize \u003Crole> --add-trait \u003Cname> --project\nai-hats config customize \u003Crole> --add-skill \u003Cname> --remove-skill \u003Cname> --global\nai-hats config customize \u003Crole> --injection-append \"\u003Ctext>\"\n```\n\nEphemeral, for this launch only — a **role spec**, and nothing is written:\n\n```bash\nai-hats -r \"dev-python + skill-engineer\"           # quotes when spaces are used\nai-hats -r dev-python+skill-engineer               # compact form, same thing\nai-hats -r \"dev-python - dev::shell + skill-engineer\"\n```\n\nReach for the role spec when you are testing whether a component changes\nbehaviour at all. Persist it once the answer is yes — a spec nobody wrote down\nis a result nobody can reproduce.\n\n### 3. The `+` \u002F `-` grammar, and the two traps in it\n\nThe base role comes first, then operations. Both operators take exactly one\ncomponent name.\n\n- **`-` is an operator only when surrounded by spaces.** `trait-base` is one\n  identifier; `- trait-base` removes it. A hyphenated name never splits.\n- **A removal resolves against the COMPOSED set**, not against the role's own\n  declaration: you can drop a rule a trait brought in, without editing the trait.\n- A repeated operand, or a trailing `+` with nothing after it, is refused with a\n  parse error rather than silently ignored.\n\nThe spec becomes a third overlay layer — `[global, project, runtime]` — so it\nwins over both persistent layers for that session.\n\n### 4. Know when the edit takes effect\n\nThere is no sync command. Roles are composed fresh at every launch, so an edit\nto a component body, to `ai-hats.yaml`, or to a customization is live for the\n**next** session — including a component you just wrote by hand. `ai-hats self\ninit` validates the config and refreshes the project scaffold; it is not how a\ncomposition change lands.\n\nOne exception. A skill's git gates are resolved at commit time from the composed\nrole, but the `.githooks\u002F\u003Cevent>` dispatcher that runs them is a stub written\nonly by `ai-hats init` \u002F `self init` \u002F `self update` \u002F the first interactive\nlaunch — `config customize` never writes one. A gate under an event whose stub\nexists is live at the next commit; a gate on an event with no stub yet is inert\nuntil you run `ai-hats self init` once.\n\nNever hand-copy component files into a provider's own directory. Those trees are\nmaterialized per session from the resolved library; a hand-made copy drifts from\nthe source and never composes.\n\n### 5. Then prove it arrived\n\nAn edit that the composer never resolved leaves the file looking perfect. Go to\n**composition-verification** before reporting the change landed.\n\n## Completion\n\n- The component sits in a root this project actually reads.\n- It is wired either persistently (and the command is recorded) or by an explicit\n  role spec for a deliberately ephemeral test.\n- The next launch is understood to be when it takes effect.\n- Arrival is confirmed through `composition-verification`, not assumed.\n\n**Validation scenario (RED).** An agent asked to give a working role the\nauthoring craft writes a trait into `~\u002F.ai-hats\u002Fcore\u002Ftraits\u002F`, mirroring the\nshipped library's layer layout. The path resolves to nothing, the composer\nreports no error, and the role is unchanged — while the file on disk looks\nexactly right. Step 1 prevents it; step 5 catches it if step 1 was skipped.\n\n## Anti-Patterns\n\n- Mirroring the shipped `core\u002F` \u002F `usage\u002F` layers inside your own root.\n- Testing a component by editing the shipped library instead of overriding it by\n  name from your own root.\n- Leaving a promising role spec ephemeral, so the result cannot be reproduced.\n- Writing `- trait-base` as `-trait-base` and wondering why the parse failed.\n- Copying skill files into the provider's directory by hand.\n",{"name":5,"ai_hats":39,"license":15,"description":7},{"type":40,"schema_version":41},"skill",1,"master","f922a7f627276366873d546942d9ad899a86f71a","packages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Flibrary-editing","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats","https:\u002F\u002Fgithub.com\u002Fmuratovv","2026-11-05 20:59:10",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add muratovv\u002Fai-hats --skill library-editing",{"tool":54,"command":55},"bunx","bunx skills add muratovv\u002Fai-hats --skill library-editing",{"tool":57,"command":58},"pnpm","pnpm dlx skills add muratovv\u002Fai-hats --skill library-editing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Flibrary-editing\u002FSKILL.md",true,[],[63,88,113,132,153,167],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":34},"01M6PVFB1SM738R2SRSRSF7CY6","tool-evaluation-protocol","Time-bounded protocol for evaluating new tools, libraries, or methodologies before adoption. Use when evaluating a candidate dependency for the project, researching a methodology (e.g. ML\u002FLLM frameworks, testing approaches), or following up on a hype-driven recommendation.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Ftool-evaluation-protocol\u002FSKILL.md",[],[70,71,72,73,74,75,76,77,78,79,28,80,81,82,83,29,84,85,86,87],"protocol","Evaluation","tool","tool evaluation protocol","testing","ml","libraries","adoption","methodology","Tools","dependency","up","frameworks","time","recommendation","for","bounded","candidate",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":34},"01M6PVF7HATBEX1G7N50E2QT57","systematic-debugging","4-phase bug-fix protocol (evidence, pattern, hypothesis, verify). Use when investigating any error, failure, or unexpected behavior, handling bug reports from users or monitoring, or diagnosing test failures with non-obvious causes.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fsystematic-debugging\u002FSKILL.md",[],[95,96,97,98,70,99,100,101,102,103,28,104,105,106,107,108,109,110,111,112],"systematic debugging","debugging","systematic","test","monitoring","hypothesis","verify","behavior","fix","evidence","bug","reports","pattern","users","error","with","bug-fix","phase",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":34},"01M6PVF3MTQN3RPF73AN34856J","skill-template","Canonical template and validation guide for ai-hats skills. Use when creating a new skill, reviewing an existing one for structural compliance, or deciding which pattern fits a new behavior.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fskill-template\u002FSKILL.md",[119],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[121,122,123,124,125,102,126,28,127,107,128,129,130,85,131],"template","skill template","validation","compliance","hats","guide","new skill","structural","canonical","which","Existing",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":139,"publishedAt":34},"01M6PVF06SCV28QARM5MQPANC9","skill-optimization","Audit and refactor library components to eliminate redundancy and staleness. Use during periodic library maintenance, after adding multiple new skills or rules, when a role's token budget is too high, or after retrospectives identify component issues.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fskill-optimization\u002FSKILL.md",[138],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[140,141,142,27,143,24,144,145,146,147,28,148,149,150,151,33,152],"Optimization","skill optimization","components","issues","audit","refactor","Budget","Rules","periodic","maintenance","token","token budget","high",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":34},"01M6PVEXM9717016T9MW82HDCT","silent-fallback-gate","PreToolUse hook — refuses an Edit or Write that adds an inert broad except. Use when a Python edit was blocked for a silent fallback.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fsilent-fallback-gate\u002FSKILL.md",[],[160,161,162,163,164,165,28,166,85],"gate","fallback","silent fallback gate","python","write","edit","hook",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":174,"publishedAt":34},"01M6PVESM49C5NT7SB7N3F76VS","retro-to-framework","Convert an observation about agent behavior — from a retrospective or from a single incident — into a framework-level change (hook, rule, skill, skill update). Use after a retrospective identifies problems that are not project-specific, after an incident where an agent misapplied a component it had read, when CLAUDE.md band-aids accumulate (more than 3 per-project rules that could be generic), or when the same problem recurs across multiple projects.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fretro-to-framework\u002FSKILL.md",[173],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[175,176,177,178,27,179,180,181,147,102,28,182,183,29,184,185,186,187,188,189],"framework","retro","retro to framework","change","retrospective","projects","convert","incident","across","problem","about","more","skill update","single","generic"]