[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PVE69W69WHGH7BBEJ8PM80":3,"skill-same:01M6PVE69W69WHGH7BBEJ8PM80":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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":46,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6PVE69W69WHGH7BBEJ8PM80","composition-verification",null,"Prove a role\u002Ftrait\u002Frule\u002Fskill edit reached the composed prompt. Use after editing any library component, before reporting a composition change landed, and when a rule or skill looks absent from a role that should carry it.","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\u002Fcomposition-verification\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"verification","Composition","composition verification","change","component","library","reporting","editing","prompt","edit","use","rule","it","role","prove","2026-11-10 10:12:30",false,"---\nname: composition-verification\ndescription: >-\n  Prove a role\u002Ftrait\u002Frule\u002Fskill edit reached the composed prompt. Use\n  after editing any library component, before reporting a composition\n  change landed, and when a rule or skill looks absent from a role that\n  should carry it.\nlicense: MIT\nai_hats:\n  schema_version: 1\n  type: skill\n---\n\n# Composition Verification\n\nProve the edit arrived — by reading the render, not the file you just edited.\n\n## When to Use\n\nNot for judging whether the change is *good*: auditing a composed role for\ncontradictions is `role-coherence-protocol`, run by `ai-hats reflect role \u003Cname>`.\nThis skill answers the narrower question that must come first — did the change\nreach the prompt at all?\n\nIt is the last of three steps, and owns only its own. Deciding that prose is the\nright mechanism and writing it is `prompt-authoring`; placing the component in a\nroot this project reads and wiring it to a role is `library-editing`. Arrive\nhere once the edit is made.\n\nThe general discipline of proving your verification path is not itself broken\nis **positive-control**; this skill is that discipline applied to composition,\nand step 3 is where the two meet.\n\n## Procedure\n\n### 1. Read the render, not the source\n\n```bash\nai-hats config show-prompt --role \u003Crole>    # the prompt the agent would see\nai-hats config show-prompt --stats          # the same, as structured JSON\nai-hats config status                       # role, dependency tree, health\nai-hats --dry-run                           # what a launch would deliver\n```\n\n`--role` is an option, not a positional: `show-prompt \u003Crole>` fails with\n`Got unexpected extra argument`. With no `--role` it renders the project's\nactive role, which is the wrong answer given quietly.\n\nA file on disk can look perfect while the composer never resolved it: a typo in\na component name, a component placed in a layer the role does not search, or an\nunknown key under `composition:` (stripped with one stderr WARN each). None of\nthose change the file you are re-reading.\n\n### 2. Know what does and does not enter the prompt\n\n| Component          | In the prompt?                                                     |\n| ------------------ | ------------------------------------------------------------------ |\n| trait injections   | yes — merged into one body, deduplicated by **text**               |\n| role injection     | yes                                                                |\n| rule bodies        | yes — appended as a separate `RULES` section, not inside the merge |\n| skill bodies       | **no** — loaded on trigger                                         |\n| skill descriptions | **no** — the harness indexes them for selection                    |\n\nSo grepping the render for a skill name proves nothing about whether the skill\nis attached. For skills, read the resolved component list (`config status`)\ninstead. Two traits carrying identical injection prose contribute it **once**,\nsilently — a \"missing\" section may be a text-level duplicate, not a drop.\n\n### 3. Every zero needs a positive control\n\nA grep that finds nothing has two explanations: the thing is absent, or the\nsearch is broken. Before reporting absence, run a pattern over the **same\nrender and the same scope** that must hit — a section heading you know is\nthere. No control, no verdict.\n\nFor a removal, invert it: the thing you moved must still be found where it\nnow lives.\n\n### 4. Compare before and after with one interpreter\n\nMaterialize the pre-edit tree (`git archive \u003Cref>`), compose both, and diff the\ncomponent sets — gained, lost, and `errors == []` on each side. A before-figure\nrecalled from an earlier session is not a measurement.\n\n### 5. Price it, do not predict it\n\n```bash\nai-hats list tokens \u003Crole>\n```\n\nIt prices the same composed plan `show-prompt` renders — overlays from\n`~\u002F.ai-hats\u002Fcustomizations.yaml` and the project's `ai-hats.yaml` included.\nThe `Tokens` total sums skill bodies too, and those are **not** resident: the\nfigure to quote is the `Always-on` footer (injections, rule bodies, and each\nskill's name + description). Quote the number this run produced.\n\nConfirm you priced the tree you meant: the table should list a component that\nexists only there. Pricing the wrong library returns a plausible number with no\nerror, which is the one failure this step cannot detect on its own.\n\n### 6. When you need the object graph, compose in-process\n\nOnly when the CLI's output is not enough — you want `errors`, the resolved\ncomponents, or to compose a library root other than the one cwd implies. A\nready script sits next to this skill: `examples\u002Fcompose-in-process.md`. Copy it,\nset the role, run it with the interpreter of the checkout you mean.\n\nThe one thing to carry without reading it: **always pass overlays**. Omitting\nthem silently skips user-global customizations and the project's own overlays —\nthe usual cause of a false \"the rule is not there\".\n\nTo force a specific library root instead:\n\n```bash\nexport AI_HATS_LIBRARY_ROOT=\u003Cpath to a library root>\n```\n\n### 7. From a worktree, read-only and writing commands disagree\n\nRun the read-only command from inside the worktree you edited: `config\nshow-prompt`, `--dry-run`, `config status`'s role tree, or a `list` subcommand\nthat reads the library (`list providers` reads none). It composes from that\nworktree when the root you edited is one of:\n\n- the built-in layers — the worktree is an ai-hats source checkout;\n- the project's `libraries\u002F`;\n- a user-global or configured root (`~\u002F.ai-hats`, an entry of\n  `~\u002F.ai-hats\u002Flibrary_paths.yaml` or of `ai-hats.yaml: library_paths`) whose\n  MAIN checkout the worktree belongs to.\n\nAny other root is read where it is listed.\n\nTwo things in that output still answer about the PROJECT, and are not bugs:\n`config status`'s **Health** block (version, venv, materialized prompt) reports\nwhat is installed here, and its `Library:` line comes from `importlib` rather\nthan the resolver — so it can disagree with the tree the same command just\ncomposed from.\n\nA command that **writes** — `self init`, anything materializing into the agent\ndirectory — targets the project, which for a linked worktree is the MAIN\ncheckout, so tracker operations reach the one live backlog. What it composes\nfollows the list above for `libraries\u002F` and same-repo roots; only the built-in\nlayers differ — a writer takes them from the project's own source checkout\n(cwd only when the project names none). So `self init` run inside a worktree\nships the branch's `libraries\u002F` and same-repo roots into MAIN's shared\nartifacts: run it from MAIN unless that is what you want.\n\nTo force either side: `AI_HATS_LIBRARY_ROOT` pins the built-in root, and a path\npassed in-process (step 6, `Assembler(project, library_paths=[\u003Croot>])`) outranks\nevery listed root; neither ever consulted cwd.\n\n### 8. Know when the edit takes effect\n\nComposition happens at launch and there is no sync command — `library-editing`\n§4 has it. What matters here: that is why verification is a read-only command\nand never \"restart and see\".\n\n## Completion\n\n- The claim \"the change reached the prompt\" is backed by the render, not the file.\n- Every reported absence carries its positive control.\n- Any cost figure comes from this run's output.\n\n**Validation scenario (RED).** An agent adds a skill to a trait, re-reads the\ntrait's `config.yaml`, sees its own line, and reports the role now carries it —\nwhile the composer never resolved the name and the role's prompt is unchanged.\nThe same agent then greps the render for the skill's body text, finds nothing,\nand concludes the composition is broken — when skill bodies never enter the\nprompt at all. Both halves of that session are wrong for opposite reasons, and\nboth are prevented by steps 1–2.\n\n## Anti-Patterns\n\n- Verifying by re-reading the file you just edited.\n- Grepping the merged injection for a skill and reading the zero as a defect.\n- Reporting an absence with no positive control on the search.\n- Quoting a token figure from memory instead of this run's output.\n- Composing in-process without overlays, then diagnosing a \"missing\" rule.\n","# Composition Verification\n\nProve the edit arrived — by reading the render, not the file you just edited.\n\n## When to Use\n\nNot for judging whether the change is *good*: auditing a composed role for\ncontradictions is `role-coherence-protocol`, run by `ai-hats reflect role \u003Cname>`.\nThis skill answers the narrower question that must come first — did the change\nreach the prompt at all?\n\nIt is the last of three steps, and owns only its own. Deciding that prose is the\nright mechanism and writing it is `prompt-authoring`; placing the component in a\nroot this project reads and wiring it to a role is `library-editing`. Arrive\nhere once the edit is made.\n\nThe general discipline of proving your verification path is not itself broken\nis **positive-control**; this skill is that discipline applied to composition,\nand step 3 is where the two meet.\n\n## Procedure\n\n### 1. Read the render, not the source\n\n```bash\nai-hats config show-prompt --role \u003Crole>    # the prompt the agent would see\nai-hats config show-prompt --stats          # the same, as structured JSON\nai-hats config status                       # role, dependency tree, health\nai-hats --dry-run                           # what a launch would deliver\n```\n\n`--role` is an option, not a positional: `show-prompt \u003Crole>` fails with\n`Got unexpected extra argument`. With no `--role` it renders the project's\nactive role, which is the wrong answer given quietly.\n\nA file on disk can look perfect while the composer never resolved it: a typo in\na component name, a component placed in a layer the role does not search, or an\nunknown key under `composition:` (stripped with one stderr WARN each). None of\nthose change the file you are re-reading.\n\n### 2. Know what does and does not enter the prompt\n\n| Component          | In the prompt?                                                     |\n| ------------------ | ------------------------------------------------------------------ |\n| trait injections   | yes — merged into one body, deduplicated by **text**               |\n| role injection     | yes                                                                |\n| rule bodies        | yes — appended as a separate `RULES` section, not inside the merge |\n| skill bodies       | **no** — loaded on trigger                                         |\n| skill descriptions | **no** — the harness indexes them for selection                    |\n\nSo grepping the render for a skill name proves nothing about whether the skill\nis attached. For skills, read the resolved component list (`config status`)\ninstead. Two traits carrying identical injection prose contribute it **once**,\nsilently — a \"missing\" section may be a text-level duplicate, not a drop.\n\n### 3. Every zero needs a positive control\n\nA grep that finds nothing has two explanations: the thing is absent, or the\nsearch is broken. Before reporting absence, run a pattern over the **same\nrender and the same scope** that must hit — a section heading you know is\nthere. No control, no verdict.\n\nFor a removal, invert it: the thing you moved must still be found where it\nnow lives.\n\n### 4. Compare before and after with one interpreter\n\nMaterialize the pre-edit tree (`git archive \u003Cref>`), compose both, and diff the\ncomponent sets — gained, lost, and `errors == []` on each side. A before-figure\nrecalled from an earlier session is not a measurement.\n\n### 5. Price it, do not predict it\n\n```bash\nai-hats list tokens \u003Crole>\n```\n\nIt prices the same composed plan `show-prompt` renders — overlays from\n`~\u002F.ai-hats\u002Fcustomizations.yaml` and the project's `ai-hats.yaml` included.\nThe `Tokens` total sums skill bodies too, and those are **not** resident: the\nfigure to quote is the `Always-on` footer (injections, rule bodies, and each\nskill's name + description). Quote the number this run produced.\n\nConfirm you priced the tree you meant: the table should list a component that\nexists only there. Pricing the wrong library returns a plausible number with no\nerror, which is the one failure this step cannot detect on its own.\n\n### 6. When you need the object graph, compose in-process\n\nOnly when the CLI's output is not enough — you want `errors`, the resolved\ncomponents, or to compose a library root other than the one cwd implies. A\nready script sits next to this skill: `examples\u002Fcompose-in-process.md`. Copy it,\nset the role, run it with the interpreter of the checkout you mean.\n\nThe one thing to carry without reading it: **always pass overlays**. Omitting\nthem silently skips user-global customizations and the project's own overlays —\nthe usual cause of a false \"the rule is not there\".\n\nTo force a specific library root instead:\n\n```bash\nexport AI_HATS_LIBRARY_ROOT=\u003Cpath to a library root>\n```\n\n### 7. From a worktree, read-only and writing commands disagree\n\nRun the read-only command from inside the worktree you edited: `config\nshow-prompt`, `--dry-run`, `config status`'s role tree, or a `list` subcommand\nthat reads the library (`list providers` reads none). It composes from that\nworktree when the root you edited is one of:\n\n- the built-in layers — the worktree is an ai-hats source checkout;\n- the project's `libraries\u002F`;\n- a user-global or configured root (`~\u002F.ai-hats`, an entry of\n  `~\u002F.ai-hats\u002Flibrary_paths.yaml` or of `ai-hats.yaml: library_paths`) whose\n  MAIN checkout the worktree belongs to.\n\nAny other root is read where it is listed.\n\nTwo things in that output still answer about the PROJECT, and are not bugs:\n`config status`'s **Health** block (version, venv, materialized prompt) reports\nwhat is installed here, and its `Library:` line comes from `importlib` rather\nthan the resolver — so it can disagree with the tree the same command just\ncomposed from.\n\nA command that **writes** — `self init`, anything materializing into the agent\ndirectory — targets the project, which for a linked worktree is the MAIN\ncheckout, so tracker operations reach the one live backlog. What it composes\nfollows the list above for `libraries\u002F` and same-repo roots; only the built-in\nlayers differ — a writer takes them from the project's own source checkout\n(cwd only when the project names none). So `self init` run inside a worktree\nships the branch's `libraries\u002F` and same-repo roots into MAIN's shared\nartifacts: run it from MAIN unless that is what you want.\n\nTo force either side: `AI_HATS_LIBRARY_ROOT` pins the built-in root, and a path\npassed in-process (step 6, `Assembler(project, library_paths=[\u003Croot>])`) outranks\nevery listed root; neither ever consulted cwd.\n\n### 8. Know when the edit takes effect\n\nComposition happens at launch and there is no sync command — `library-editing`\n§4 has it. What matters here: that is why verification is a read-only command\nand never \"restart and see\".\n\n## Completion\n\n- The claim \"the change reached the prompt\" is backed by the render, not the file.\n- Every reported absence carries its positive control.\n- Any cost figure comes from this run's output.\n\n**Validation scenario (RED).** An agent adds a skill to a trait, re-reads the\ntrait's `config.yaml`, sees its own line, and reports the role now carries it —\nwhile the composer never resolved the name and the role's prompt is unchanged.\nThe same agent then greps the render for the skill's body text, finds nothing,\nand concludes the composition is broken — when skill bodies never enter the\nprompt at all. Both halves of that session are wrong for opposite reasons, and\nboth are prevented by steps 1–2.\n\n## Anti-Patterns\n\n- Verifying by re-reading the file you just edited.\n- Grepping the merged injection for a skill and reading the zero as a defect.\n- Reporting an absence with no positive control on the search.\n- Quoting a token figure from memory instead of this run's output.\n- Composing in-process without overlays, then diagnosing a \"missing\" rule.\n",{"name":5,"ai_hats":44,"license":15,"description":7},{"type":45,"schema_version":46},"skill",1,"master","f922a7f627276366873d546942d9ad899a86f71a","packages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fcomposition-verification","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats","https:\u002F\u002Fgithub.com\u002Fmuratovv","2026-11-05 20:59:10",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add muratovv\u002Fai-hats --skill composition-verification",{"tool":59,"command":60},"bunx","bunx skills add muratovv\u002Fai-hats --skill composition-verification",{"tool":62,"command":63},"pnpm","pnpm dlx skills add muratovv\u002Fai-hats --skill composition-verification","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fcomposition-verification\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"examples\u002Fcompose-in-process.md","REFERENCE","参考文档",1518,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fcomposition-verification\u002Fexamples\u002Fcompose-in-process.md",[74,100,125,144,165,178],{"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":39},"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",[],[81,82,83,84,85,86,87,88,89,90,34,91,92,93,94,95,96,97,98,99],"protocol","Evaluation","tool","tool evaluation protocol","testing","ml","libraries","adoption","methodology","Tools","dependency","up","frameworks","time","project","recommendation","for","bounded","candidate",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":39},"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",[],[107,108,109,110,81,111,112,113,114,115,34,116,117,118,119,120,121,122,123,124],"systematic debugging","debugging","systematic","test","monitoring","hypothesis","verify","behavior","fix","evidence","bug","reports","pattern","users","error","with","bug-fix","phase",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":132,"publishedAt":39},"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",[131],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[133,134,135,136,137,114,138,34,139,119,140,141,142,97,143],"template","skill template","validation","compliance","hats","guide","new skill","structural","canonical","which","Existing",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":151,"publishedAt":39},"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",[150],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[152,153,154,28,155,29,156,157,158,159,34,160,161,162,163,37,164],"Optimization","skill optimization","components","issues","audit","refactor","Budget","Rules","periodic","maintenance","token","token budget","high",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":39},"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",[],[172,173,174,175,176,33,34,177,97],"gate","fallback","silent fallback gate","python","write","hook",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":185,"publishedAt":39},"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",[184],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[186,187,188,27,28,189,190,191,159,114,34,192,193,95,194,195,196,197,198,199],"framework","retro","retro to framework","retrospective","projects","convert","incident","across","problem","about","more","skill update","single","generic"]