[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PVBQ495AD2WHM6JR19DK44":3,"skill-same:01M6PVBQ495AD2WHM6JR19DK44":69},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":37,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":43,"install":44,"resources":57},"01M6PVBQ495AD2WHM6JR19DK44","devils-advocate",null,"The Approach & counter stage of the plan-gate — a skeptic value-counter that steelmans the value, then challenges whether the work is worth doing (needed? missed anything? another way?) before scoping. Reached through plan-gate, not as an independent trigger.","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\u002Fcore\u002Fskills\u002Fdevils-advocate\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29],"devils advocate","plan","work","scoping","skeptic","gate","missed","stage","as","trigger","value","2026-11-10 10:12:30",false,"---\nname: devils-advocate\ndescription: >-\n  The Approach & counter stage of the plan-gate — a skeptic value-counter\n  that steelmans the value, then challenges whether the work is worth\n  doing (needed? missed anything? another way?) before scoping. Reached\n  through plan-gate, not as an independent trigger.\nlicense: MIT\nai_hats:\n  schema_version: 1\n  type: skill\n---\n\n# Devil's Advocate\n\nThe **Approach & counter stage of `plan-gate`**: a structured skeptic pass that\nfills the `Approach & counter` section of `plan.md`. It takes the **value** the\nplan claims (the `Requirements` section, Q1 \"Goal & user value\") and puts it\nunder attack **before** the plan is scoped — *is this value real? did we miss\nsomething? is there a cheaper way to the same outcome?*\n\n**The counter is verification-shaped, not attack-shaped:** steelman the value\nfirst (state its strongest version), only then surface the strongest\ncounterargument. The point is to catch \"right scope, wrong direction\" — work\nthat is well-sized and well-built but **not worth doing as framed** — while\nredirection is still cheap. It operationalises `trait-agent`'s **anti-anchoring**\nprinciple with a concrete procedure.\n\n## When to Use\n\nReach this stage through `plan-gate`, not as a standalone brainstorm→plan\ntrigger — `plan-gate` is the single entry point and routes here to fill the\n`Approach & counter` section of `plan.md`.\n\n- Run it **after** `requirements-interview` states the value and **before**\n  `design-minimalism` scopes the means. Loop with the interview until the value\n  settles, then hand off to scope.\n- The section is **conditional** (`required=False`): the engine never blocks\n  `execute` on it. A trivial task writes `N\u002FA — \u003Creason>`; a non-trivial one\n  should carry a real counter.\n- Sibling stages: `requirements-interview` owns WHAT + the value (it *states*\n  it); `design-minimalism` owns HOW MUCH (it minimises means and takes the task\n  as given); **this** stage is the only one that challenges *whether the value\n  itself holds*.\n\n## Checklist\n\nRun the 4-step method on the plan's core value claim:\n\n1. **Steelman the value.** State the strongest version of *why this is worth\n   doing* and *what the user gets* — pulled from `Requirements`. No strawman: if\n   the value can't be stated well, fix the Requirements first.\n2. **Name the unstated assumption.** What must be true for that value to be\n   real? (e.g. \"users actually hit this case\", \"the cost of not doing it is\n   high\", \"no existing path already covers it\").\n3. **Counter it — three probes:**\n   - **Needed?** Do users really hit this? What concretely breaks if we **don't**\n     do it? Is the pain hypothetical?\n   - **Missed?** Is there a blind spot — an ignored case, stakeholder, or cost;\n     a simpler problem underneath this one?\n   - **Another way?** Is there a cheaper \u002F smaller \u002F already-built path to the\n     same value? (Reuse over new code, config over feature, doc over tool.)\n     **Make this probe empirical, not rhetorical:** a claimed consumer or\n     capability is a *hypothesis* — before assuming new code is needed, run the\n     cheapest disconfirming PoC: `grep` the engine \u002F codebase for machinery that\n     already covers it. (\"Is the wt-close gate already enforced?\" → one grep for\n     `_check_clean` answered yes — but only at S6, after the build, not at S0.)\n4. **Assess impact.** If a counter holds, what changes? Resolve explicitly —\n   **proceed** (counter doesn't hold, say why), **descope**, **redirect**, or\n   **drop**. Record the resolution so a reviewer sees the decision, not just the\n   doubt.\n\nOptional, when the value is contested: fallacy tags on the original rationale;\nscope-testing (claimed vs assumed vs unsupported); second-order effects of\nshipping it.\n\n## Worked Example\n\n**The epic this stage belongs to.** The original plan proposed a\nphased split of the unified plan-gate. A counter-pass steelmanned it\n(\"phases isolate risk\"), named the assumption (\"each phase delivers value\nalone\"), countered it (\"the section is useless without its method — M3 ships\nboth or neither\"), and assessed impact (**redirect**: ship section + method\ntogether). The split was refuted *before* execute — exactly the\n\"right scope, wrong direction\" save this stage exists for.\n\n## Rationalization red-flags\n\nThe skeptic pass is the easiest stage to talk yourself out of. These are the\nrationalizations that precede a skipped or hollow counter:\n\n| Rationalization (what you tell yourself)                                                                    | Why it's wrong                                                                                                                                                                                                        |\n| ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| \"This is obviously worth doing — write N\u002FA\"                                                                 | Reflex `N\u002FA` on a non-trivial plan is the exact failure this stage prevents; a steelman + one real counter costs little                                                                                               |\n| \"I already know the answer is proceed\"                                                                      | Then *record* the counter you considered and why it fails — a resolution, not a skipped step                                                                                                                          |\n| \"Questioning it now will just slow us down\"                                                                 | Redirecting before execute is cheap; rebuilding after shipping the wrong thing is not                                                                                                                                 |\n| \"This counter already ran at authoring — no need to re-run\" (on a resumed \u002F bounced \u002F premise-changed plan) | The premise that changed is exactly what the prior counter never tested; a resumed plan gets a fresh counter scoped to what moved (see `rule_backlog_discipline §5` — a retracted premise bounces the task back here) |\n\n**Red-flag words in your own reasoning:** \"obviously\", \"clearly worth it\", \"no\npoint questioning\", \"we already decided\", \"already decided at authoring\", \"still\nready to implement\". Any of these → write a real steelman → assumption → counter →\nimpact, even when the impact is *proceed*.\n(Rationalization-table discipline adapted from obra\u002Fsuperpowers, MIT.)\n\n## Anti-Patterns\n\n- **Reflex `N\u002FA` on a non-trivial plan.** The section is optional so the engine\n  won't stop you — but skipping the skeptic pass on real work is the failure\n  mode this stage exists to prevent.\n- **Strawmanning your own approach.** Skipping step 1 makes the counter cheap\n  and the conclusion foregone. Steelman first.\n- **Challenging scope here.** \"This abstraction is speculative\" is\n  `design-minimalism`'s job (HOW MUCH). This stage asks whether the *value* is\n  real (WHY), not whether the means are minimal.\n- **Reviewing output.** Judge skills critique work already done; this\n  challenges the **decision before** work starts.\n- **Doubt without resolution.** A counter with no recorded impact\u002Fdecision is\n  noise. Every counter ends in proceed \u002F descope \u002F redirect \u002F drop, with a why.\n\n## Completion\n\n- `Approach & counter` carries a real counter (steelman → assumption → counter →\n  impact) **or** an explicit `N\u002FA — \u003Creason>`.\n- Each surviving counter has a recorded resolution (proceed \u002F descope \u002F redirect\n  \u002F drop) with rationale.\n- The value handed to `design-minimalism` for scoping is one that survived the\n  pass — not the unexamined original.\n\n## See also\n\n- `requirements-interview` — the prior stage; *states* the value this challenges.\n- `design-minimalism` — the next stage; minimises the means once the value settles.\n- `trait-agent` \"Anti-Anchoring\" — the base principle this stage operationalises.\n- `domain-reviewer` — reviews code *after* work; this challenges the decision *before*.\n","# Devil's Advocate\n\nThe **Approach & counter stage of `plan-gate`**: a structured skeptic pass that\nfills the `Approach & counter` section of `plan.md`. It takes the **value** the\nplan claims (the `Requirements` section, Q1 \"Goal & user value\") and puts it\nunder attack **before** the plan is scoped — *is this value real? did we miss\nsomething? is there a cheaper way to the same outcome?*\n\n**The counter is verification-shaped, not attack-shaped:** steelman the value\nfirst (state its strongest version), only then surface the strongest\ncounterargument. The point is to catch \"right scope, wrong direction\" — work\nthat is well-sized and well-built but **not worth doing as framed** — while\nredirection is still cheap. It operationalises `trait-agent`'s **anti-anchoring**\nprinciple with a concrete procedure.\n\n## When to Use\n\nReach this stage through `plan-gate`, not as a standalone brainstorm→plan\ntrigger — `plan-gate` is the single entry point and routes here to fill the\n`Approach & counter` section of `plan.md`.\n\n- Run it **after** `requirements-interview` states the value and **before**\n  `design-minimalism` scopes the means. Loop with the interview until the value\n  settles, then hand off to scope.\n- The section is **conditional** (`required=False`): the engine never blocks\n  `execute` on it. A trivial task writes `N\u002FA — \u003Creason>`; a non-trivial one\n  should carry a real counter.\n- Sibling stages: `requirements-interview` owns WHAT + the value (it *states*\n  it); `design-minimalism` owns HOW MUCH (it minimises means and takes the task\n  as given); **this** stage is the only one that challenges *whether the value\n  itself holds*.\n\n## Checklist\n\nRun the 4-step method on the plan's core value claim:\n\n1. **Steelman the value.** State the strongest version of *why this is worth\n   doing* and *what the user gets* — pulled from `Requirements`. No strawman: if\n   the value can't be stated well, fix the Requirements first.\n2. **Name the unstated assumption.** What must be true for that value to be\n   real? (e.g. \"users actually hit this case\", \"the cost of not doing it is\n   high\", \"no existing path already covers it\").\n3. **Counter it — three probes:**\n   - **Needed?** Do users really hit this? What concretely breaks if we **don't**\n     do it? Is the pain hypothetical?\n   - **Missed?** Is there a blind spot — an ignored case, stakeholder, or cost;\n     a simpler problem underneath this one?\n   - **Another way?** Is there a cheaper \u002F smaller \u002F already-built path to the\n     same value? (Reuse over new code, config over feature, doc over tool.)\n     **Make this probe empirical, not rhetorical:** a claimed consumer or\n     capability is a *hypothesis* — before assuming new code is needed, run the\n     cheapest disconfirming PoC: `grep` the engine \u002F codebase for machinery that\n     already covers it. (\"Is the wt-close gate already enforced?\" → one grep for\n     `_check_clean` answered yes — but only at S6, after the build, not at S0.)\n4. **Assess impact.** If a counter holds, what changes? Resolve explicitly —\n   **proceed** (counter doesn't hold, say why), **descope**, **redirect**, or\n   **drop**. Record the resolution so a reviewer sees the decision, not just the\n   doubt.\n\nOptional, when the value is contested: fallacy tags on the original rationale;\nscope-testing (claimed vs assumed vs unsupported); second-order effects of\nshipping it.\n\n## Worked Example\n\n**The epic this stage belongs to.** The original plan proposed a\nphased split of the unified plan-gate. A counter-pass steelmanned it\n(\"phases isolate risk\"), named the assumption (\"each phase delivers value\nalone\"), countered it (\"the section is useless without its method — M3 ships\nboth or neither\"), and assessed impact (**redirect**: ship section + method\ntogether). The split was refuted *before* execute — exactly the\n\"right scope, wrong direction\" save this stage exists for.\n\n## Rationalization red-flags\n\nThe skeptic pass is the easiest stage to talk yourself out of. These are the\nrationalizations that precede a skipped or hollow counter:\n\n| Rationalization (what you tell yourself)                                                                    | Why it's wrong                                                                                                                                                                                                        |\n| ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| \"This is obviously worth doing — write N\u002FA\"                                                                 | Reflex `N\u002FA` on a non-trivial plan is the exact failure this stage prevents; a steelman + one real counter costs little                                                                                               |\n| \"I already know the answer is proceed\"                                                                      | Then *record* the counter you considered and why it fails — a resolution, not a skipped step                                                                                                                          |\n| \"Questioning it now will just slow us down\"                                                                 | Redirecting before execute is cheap; rebuilding after shipping the wrong thing is not                                                                                                                                 |\n| \"This counter already ran at authoring — no need to re-run\" (on a resumed \u002F bounced \u002F premise-changed plan) | The premise that changed is exactly what the prior counter never tested; a resumed plan gets a fresh counter scoped to what moved (see `rule_backlog_discipline §5` — a retracted premise bounces the task back here) |\n\n**Red-flag words in your own reasoning:** \"obviously\", \"clearly worth it\", \"no\npoint questioning\", \"we already decided\", \"already decided at authoring\", \"still\nready to implement\". Any of these → write a real steelman → assumption → counter →\nimpact, even when the impact is *proceed*.\n(Rationalization-table discipline adapted from obra\u002Fsuperpowers, MIT.)\n\n## Anti-Patterns\n\n- **Reflex `N\u002FA` on a non-trivial plan.** The section is optional so the engine\n  won't stop you — but skipping the skeptic pass on real work is the failure\n  mode this stage exists to prevent.\n- **Strawmanning your own approach.** Skipping step 1 makes the counter cheap\n  and the conclusion foregone. Steelman first.\n- **Challenging scope here.** \"This abstraction is speculative\" is\n  `design-minimalism`'s job (HOW MUCH). This stage asks whether the *value* is\n  real (WHY), not whether the means are minimal.\n- **Reviewing output.** Judge skills critique work already done; this\n  challenges the **decision before** work starts.\n- **Doubt without resolution.** A counter with no recorded impact\u002Fdecision is\n  noise. Every counter ends in proceed \u002F descope \u002F redirect \u002F drop, with a why.\n\n## Completion\n\n- `Approach & counter` carries a real counter (steelman → assumption → counter →\n  impact) **or** an explicit `N\u002FA — \u003Creason>`.\n- Each surviving counter has a recorded resolution (proceed \u002F descope \u002F redirect\n  \u002F drop) with rationale.\n- The value handed to `design-minimalism` for scoping is one that survived the\n  pass — not the unexamined original.\n\n## See also\n\n- `requirements-interview` — the prior stage; *states* the value this challenges.\n- `design-minimalism` — the next stage; minimises the means once the value settles.\n- `trait-agent` \"Anti-Anchoring\" — the base principle this stage operationalises.\n- `domain-reviewer` — reviews code *after* work; this challenges the decision *before*.\n",{"name":5,"ai_hats":35,"license":15,"description":7},{"type":36,"schema_version":37},"skill",1,"master","f922a7f627276366873d546942d9ad899a86f71a","packages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fdevils-advocate","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats","https:\u002F\u002Fgithub.com\u002Fmuratovv","2026-11-05 20:59:10",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add muratovv\u002Fai-hats --skill devils-advocate",{"tool":50,"command":51},"bunx","bunx skills add muratovv\u002Fai-hats --skill devils-advocate",{"tool":53,"command":54},"pnpm","pnpm dlx skills add muratovv\u002Fai-hats --skill devils-advocate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fdevils-advocate\u002FSKILL.md",true,[58,63],{"path":59,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"LICENSE","许可证",1070,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fdevils-advocate\u002FLICENSE",{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"metadata.yaml","REFERENCE","参考文档",847,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fdevils-advocate\u002Fmetadata.yaml",[70,97,122,145,169,182],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":30},"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",[],[77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96],"protocol","Evaluation","tool","tool evaluation protocol","testing","ml","libraries","adoption","methodology","Tools","use","dependency","up","frameworks","time","project","recommendation","for","bounded","candidate",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":30},"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",[],[104,105,106,107,77,108,109,110,111,112,87,113,114,115,116,117,118,119,120,121],"systematic debugging","debugging","systematic","test","monitoring","hypothesis","verify","behavior","fix","evidence","bug","reports","pattern","users","error","with","bug-fix","phase",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":133,"publishedAt":30},"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",[128],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[134,135,136,137,138,111,139,87,140,116,141,142,143,94,144],"template","skill template","validation","compliance","hats","guide","new skill","structural","canonical","which","Existing",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":30},"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",[151],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},[153,154,155,156,157,158,159,160,161,162,87,163,164,165,166,167,168],"Optimization","skill optimization","components","component","issues","library","audit","refactor","Budget","Rules","periodic","maintenance","token","token budget","role","high",{"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":30},"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",[],[24,176,177,178,179,180,87,181,94],"fallback","silent fallback gate","python","write","edit","hook",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":30},"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",[188],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},[190,191,192,193,156,194,195,196,162,111,87,197,198,92,199,200,201,202,203,204],"framework","retro","retro to framework","change","retrospective","projects","convert","incident","across","problem","about","more","skill update","single","generic"]