[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PVEK8Q9ZK13HMMHV7VD6HT":3,"skill-same:01M6PVEK8Q9ZK13HMMHV7VD6HT":63},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":42,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M6PVEK8Q9ZK13HMMHV7VD6HT","prompt-authoring",null,"Choose the mechanism before the wording, then write prose that holds. Use before wording or rewording any rule, injection or skill body, and when a written instruction has failed to change behaviour.","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\u002Fprompt-authoring\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],"prompt","authoring","prompt authoring","change","injection","choose","write","use","prose","rule","body","2026-11-10 10:12:30",false,"---\nname: prompt-authoring\ndescription: >-\n  Choose the mechanism before the wording, then write prose that holds.\n  Use before wording or rewording any rule, injection or skill body, and\n  when a written instruction has failed to change behaviour.\nlicense: MIT\nai_hats:\n  schema_version: 1\n  type: skill\n---\n\n# Prompt Authoring\n\nProse is the mechanism you reach for last. Earn it first, then write it to hold.\n\n## When to Use\n\nThe ranking of mechanisms by cost is the ladder in trait `skill-engineer`; this\nskill answers the question the ladder leaves open — whether THIS defect is one\nprose can fix — and then how to write the words. Structure, description and\nvalidation scenario of the file you end up writing are `skill-template`.\n\n## Procedure\n\n### 1. Are you FORBIDDING something, or guiding it?\n\nThis is the fork, and it decides the mechanism before any wording question.\n\n**To forbid — work the automation first.** If the goal is that an action must\nnot happen, a machine that refuses it is the answer, and prose is the fallback\nyou take only when there is no automatable invariant or when building it costs\nmore than the defect does. Say which, and name the cost; \"seems hard\" is not a\nreason. Prose forbids nothing on its own: it asks, every turn, and one turn will\nanswer no.\n\n**To guide — prose is the right instrument, not a concession.** Naming a\ncomponent so it is not invented, saying which of two paths applies, teaching\nwhat a good answer looks like, holding a judgement no rule can express: no gate\ndoes any of this, and reaching for one here builds a machine that refuses the\nwrong thing.\n\nGetting the fork wrong is expensive in both directions. Wording a prohibition\nbuys a rule that is argued around; gating a judgement buys false refusals, and\nthose cost more than they look — see `agent-cli-guidelines` § \"Fire only when\nyou should\".\n\n### 2. What a prompt that already failed tells you\n\nIf the instruction was in the prompt and the behaviour happened anyway, that is\na measurement. What it measures depends on step 1.\n\n**For a prohibition, it is evidence for automating.** Saying it again, louder,\nis the move the evidence has already refuted. Climb, and record that prose was\ntried so the next author does not spend the same session.\n\n**For guidance, it is evidence about the SHAPE of the text, not about prose as\na mechanism.** Three rewrites have a record of working on text that had already\nfailed once, and they are the only three: moving it to where the decision is\nmade; replacing a citation with the content itself; and rewriting an enumeration\ninto the invariant behind it. What has never worked is adding another bullet or\nadding emphasis. If your revision is not one of the three, it is the fourth\nthing, and it has no record.\n\nThen narrow it further. Three states look identical in the symptom and demand\nopposite fixes.\n\n| What the evidence shows                                                                                                            | What it means           | The move                                                                  |\n| ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------- |\n| The instruction was **not in the prompt**                                                                                          | the agent never knew    | prose — write it                                                          |\n| It was in the prompt but **never reached** (unloaded skill body, a doc the project does not have, a section for a different stage) | a DELIVERY defect       | move it to the point of use, do not reword                                |\n| It was present, reached, and **selectively applied**                                                                               | this text does not bind | a prohibition goes to automation; guidance gets one of the three rewrites |\n\nPresence is settled by reading the render (**composition-verification**), never\nby remembering what the file says. Reaching is settled by the transcript: did\nthe agent quote it, act on part of it, or work in that section at all?\n\n**The default when the transcript is silent.** Rows two and three look identical\nfor always-on text — a rule or an injection leaves no load event to point at, so\n\"never reached\" can never be shown. Resolve it by construction: always-on prose\nIS reached every turn, so a violated rule with no positive evidence of partial\napplication is row three, not row two. Row two is available only for content that\nhad to be fetched — a skill body, a doc, a section belonging to another stage —\nwhere the transcript can show the fetch never happened. Without this default the\ncheaper fix wins by silence, and rewording ships again.\n\nThe third row is the one that costs sessions, and it has a shape worth\nrecognizing: an agent applies one half of a document it plainly read and skips\nthe other — the words were on the path and did not bind. That observation is a\nsingle uncontrolled session, so treat it as a pattern to look for, not as a\nsettled frequency; what is settled is the move it rules out, which is saying the\nsame thing more firmly.\n\n### 3. If prose is earned, write the invariant — not the enumeration\n\nA list of forbidden spellings is refuted by the first spelling not on it, and\nthe agent that finds one has been given permission. Name the property that makes\nany of them wrong, then let the list serve as illustration:\n\n> ❌ \"Do not use `cat`, `head`, `tail`, `sed -n`.\"\n> ✅ \"Reach for the narrowest tool the session offers; drop to the shell only\n> when none of them expresses the operation — `cat`, `head` and `sed -n` are\n> the common spellings, not the boundary.\"\n\n### 4. Put it where the decision is made\n\nAn instruction read at the wrong moment is not read. Prose that guides a choice\nbelongs at the point of that choice — in the always-on layer if the agent must\nnot be able to reach the decision without it, in a skill body if it can be\nfetched once the decision is recognized. Which layer, and what it costs per\nturn, is the ladder's question.\n\n### 5. Show the foil, and the cost of being wrong\n\nA rule with no counter-example gets rationalized into compliance with whatever\nthe agent already intended. Pair the shape to write with the shape to cut, and\nstate what breaks when it is ignored — a consequence is harder to argue with\nthan an imperative.\n\nTwo shapes fail this on their own, and `skill-template`'s validation checklist\nalready refuses both — \"target behaviour stated positively\" and \"every omission\nis a decision\". Audit against it rather than against a copy here; what belongs\nin this skill is why they bite: an agent told only what NOT to do picks its own\nsecond choice, and every silence is delegated to model priors, which is exactly\nwhere the old behaviour lives. The step-2 default for always-on text is that\nsecond rule applied to this skill's own hardest branch.\n\n### 6. Re-read it as an agent looking for a way out\n\nLast pass, adversarial: can this be read as advisory? Does it leave a\n\"when in doubt\" that resolves to the old behaviour? Does an unlisted case fall\noutside it? Close those before committing — that is what step 3 buys you, and\nwhat a rewrite that only adds emphasis never does.\n\n## Completion\n\n- Step 1's fork is answered out loud: forbidding, or guiding. For a prohibition,\n  automation was ruled out by no automatable invariant or by a named cost that\n  loses — \"clearer wording\" is not a reason and does not appear here.\n- Which of the three states in step 2 applies is stated, with its evidence; and\n  a revision to text that already failed is one of the three rewrites with a\n  record, not a fourth thing.\n- The text names an invariant, sits at the point of use, and carries a foil.\n- One adversarial re-read was done and its loopholes closed.\n- The prediction is handed to **library-change-hypothesis-protocol**: this skill\n  argues prose is the right mechanism BEFOREHAND; only the check recorded there\n  can show afterwards that it worked. Prose whose effect nobody will measure is\n  the state-three defect being created rather than fixed.\n\n**Validation scenario (RED).** A recurring defect keeps appearing. The agent\nopens the rule that already forbids it and strengthens the wording — \"never,\nunder any circumstances\" — then reports the fix. The transcript shows the agent\nhad read that very rule in the failing session and acted against it, so the\nreworded rule fails identically next time, having cost a release cycle to learn\nwhat steps 1 and 2 would have said in one reading: a prompt that already failed\nis an argument for automating, not for saying it louder.\n\n## Anti-Patterns\n\n- Rewording an instruction the evidence shows was read and ignored.\n- Answering a delivery defect with better wording instead of better placement.\n- Enumerating the forms of a violation instead of naming what makes them wrong.\n- Adding emphasis — caps, \"MUST\", \"never ever\" — as the substance of a revision.\n- Writing the rule without the foil, then wondering why it was argued around.\n","# Prompt Authoring\n\nProse is the mechanism you reach for last. Earn it first, then write it to hold.\n\n## When to Use\n\nThe ranking of mechanisms by cost is the ladder in trait `skill-engineer`; this\nskill answers the question the ladder leaves open — whether THIS defect is one\nprose can fix — and then how to write the words. Structure, description and\nvalidation scenario of the file you end up writing are `skill-template`.\n\n## Procedure\n\n### 1. Are you FORBIDDING something, or guiding it?\n\nThis is the fork, and it decides the mechanism before any wording question.\n\n**To forbid — work the automation first.** If the goal is that an action must\nnot happen, a machine that refuses it is the answer, and prose is the fallback\nyou take only when there is no automatable invariant or when building it costs\nmore than the defect does. Say which, and name the cost; \"seems hard\" is not a\nreason. Prose forbids nothing on its own: it asks, every turn, and one turn will\nanswer no.\n\n**To guide — prose is the right instrument, not a concession.** Naming a\ncomponent so it is not invented, saying which of two paths applies, teaching\nwhat a good answer looks like, holding a judgement no rule can express: no gate\ndoes any of this, and reaching for one here builds a machine that refuses the\nwrong thing.\n\nGetting the fork wrong is expensive in both directions. Wording a prohibition\nbuys a rule that is argued around; gating a judgement buys false refusals, and\nthose cost more than they look — see `agent-cli-guidelines` § \"Fire only when\nyou should\".\n\n### 2. What a prompt that already failed tells you\n\nIf the instruction was in the prompt and the behaviour happened anyway, that is\na measurement. What it measures depends on step 1.\n\n**For a prohibition, it is evidence for automating.** Saying it again, louder,\nis the move the evidence has already refuted. Climb, and record that prose was\ntried so the next author does not spend the same session.\n\n**For guidance, it is evidence about the SHAPE of the text, not about prose as\na mechanism.** Three rewrites have a record of working on text that had already\nfailed once, and they are the only three: moving it to where the decision is\nmade; replacing a citation with the content itself; and rewriting an enumeration\ninto the invariant behind it. What has never worked is adding another bullet or\nadding emphasis. If your revision is not one of the three, it is the fourth\nthing, and it has no record.\n\nThen narrow it further. Three states look identical in the symptom and demand\nopposite fixes.\n\n| What the evidence shows                                                                                                            | What it means           | The move                                                                  |\n| ---------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------- |\n| The instruction was **not in the prompt**                                                                                          | the agent never knew    | prose — write it                                                          |\n| It was in the prompt but **never reached** (unloaded skill body, a doc the project does not have, a section for a different stage) | a DELIVERY defect       | move it to the point of use, do not reword                                |\n| It was present, reached, and **selectively applied**                                                                               | this text does not bind | a prohibition goes to automation; guidance gets one of the three rewrites |\n\nPresence is settled by reading the render (**composition-verification**), never\nby remembering what the file says. Reaching is settled by the transcript: did\nthe agent quote it, act on part of it, or work in that section at all?\n\n**The default when the transcript is silent.** Rows two and three look identical\nfor always-on text — a rule or an injection leaves no load event to point at, so\n\"never reached\" can never be shown. Resolve it by construction: always-on prose\nIS reached every turn, so a violated rule with no positive evidence of partial\napplication is row three, not row two. Row two is available only for content that\nhad to be fetched — a skill body, a doc, a section belonging to another stage —\nwhere the transcript can show the fetch never happened. Without this default the\ncheaper fix wins by silence, and rewording ships again.\n\nThe third row is the one that costs sessions, and it has a shape worth\nrecognizing: an agent applies one half of a document it plainly read and skips\nthe other — the words were on the path and did not bind. That observation is a\nsingle uncontrolled session, so treat it as a pattern to look for, not as a\nsettled frequency; what is settled is the move it rules out, which is saying the\nsame thing more firmly.\n\n### 3. If prose is earned, write the invariant — not the enumeration\n\nA list of forbidden spellings is refuted by the first spelling not on it, and\nthe agent that finds one has been given permission. Name the property that makes\nany of them wrong, then let the list serve as illustration:\n\n> ❌ \"Do not use `cat`, `head`, `tail`, `sed -n`.\"\n> ✅ \"Reach for the narrowest tool the session offers; drop to the shell only\n> when none of them expresses the operation — `cat`, `head` and `sed -n` are\n> the common spellings, not the boundary.\"\n\n### 4. Put it where the decision is made\n\nAn instruction read at the wrong moment is not read. Prose that guides a choice\nbelongs at the point of that choice — in the always-on layer if the agent must\nnot be able to reach the decision without it, in a skill body if it can be\nfetched once the decision is recognized. Which layer, and what it costs per\nturn, is the ladder's question.\n\n### 5. Show the foil, and the cost of being wrong\n\nA rule with no counter-example gets rationalized into compliance with whatever\nthe agent already intended. Pair the shape to write with the shape to cut, and\nstate what breaks when it is ignored — a consequence is harder to argue with\nthan an imperative.\n\nTwo shapes fail this on their own, and `skill-template`'s validation checklist\nalready refuses both — \"target behaviour stated positively\" and \"every omission\nis a decision\". Audit against it rather than against a copy here; what belongs\nin this skill is why they bite: an agent told only what NOT to do picks its own\nsecond choice, and every silence is delegated to model priors, which is exactly\nwhere the old behaviour lives. The step-2 default for always-on text is that\nsecond rule applied to this skill's own hardest branch.\n\n### 6. Re-read it as an agent looking for a way out\n\nLast pass, adversarial: can this be read as advisory? Does it leave a\n\"when in doubt\" that resolves to the old behaviour? Does an unlisted case fall\noutside it? Close those before committing — that is what step 3 buys you, and\nwhat a rewrite that only adds emphasis never does.\n\n## Completion\n\n- Step 1's fork is answered out loud: forbidding, or guiding. For a prohibition,\n  automation was ruled out by no automatable invariant or by a named cost that\n  loses — \"clearer wording\" is not a reason and does not appear here.\n- Which of the three states in step 2 applies is stated, with its evidence; and\n  a revision to text that already failed is one of the three rewrites with a\n  record, not a fourth thing.\n- The text names an invariant, sits at the point of use, and carries a foil.\n- One adversarial re-read was done and its loopholes closed.\n- The prediction is handed to **library-change-hypothesis-protocol**: this skill\n  argues prose is the right mechanism BEFOREHAND; only the check recorded there\n  can show afterwards that it worked. Prose whose effect nobody will measure is\n  the state-three defect being created rather than fixed.\n\n**Validation scenario (RED).** A recurring defect keeps appearing. The agent\nopens the rule that already forbids it and strengthens the wording — \"never,\nunder any circumstances\" — then reports the fix. The transcript shows the agent\nhad read that very rule in the failing session and acted against it, so the\nreworded rule fails identically next time, having cost a release cycle to learn\nwhat steps 1 and 2 would have said in one reading: a prompt that already failed\nis an argument for automating, not for saying it louder.\n\n## Anti-Patterns\n\n- Rewording an instruction the evidence shows was read and ignored.\n- Answering a delivery defect with better wording instead of better placement.\n- Enumerating the forms of a violation instead of naming what makes them wrong.\n- Adding emphasis — caps, \"MUST\", \"never ever\" — as the substance of a revision.\n- Writing the rule without the foil, then wondering why it was argued around.\n",{"name":5,"ai_hats":40,"license":15,"description":7},{"type":41,"schema_version":42},"skill",1,"master","f922a7f627276366873d546942d9ad899a86f71a","packages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fprompt-authoring","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats","https:\u002F\u002Fgithub.com\u002Fmuratovv","2026-11-05 20:59:10",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add muratovv\u002Fai-hats --skill prompt-authoring",{"tool":55,"command":56},"bunx","bunx skills add muratovv\u002Fai-hats --skill prompt-authoring",{"tool":58,"command":59},"pnpm","pnpm dlx skills add muratovv\u002Fai-hats --skill prompt-authoring","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fprompt-authoring\u002FSKILL.md",true,[],[64,90,115,134,158,171],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":35},"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",[],[71,72,73,74,75,76,77,78,79,80,31,81,82,83,84,85,86,87,88,89],"protocol","Evaluation","tool","tool evaluation protocol","testing","ml","libraries","adoption","methodology","Tools","dependency","up","frameworks","time","project","recommendation","for","bounded","candidate",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":35},"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",[],[97,98,99,100,71,101,102,103,104,105,31,106,107,108,109,110,111,112,113,114],"systematic debugging","debugging","systematic","test","monitoring","hypothesis","verify","behavior","fix","evidence","bug","reports","pattern","users","error","with","bug-fix","phase",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":122,"publishedAt":35},"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",[121],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[123,124,125,126,127,104,128,31,129,109,130,131,132,87,133],"template","skill template","validation","compliance","hats","guide","new skill","structural","canonical","which","Existing",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":35},"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",[140],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[142,143,144,145,146,147,148,149,150,151,31,152,153,154,155,156,157],"Optimization","skill optimization","components","component","issues","library","audit","refactor","Budget","Rules","periodic","maintenance","token","token budget","role","high",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":35},"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",[],[165,166,167,168,30,169,31,170,87],"gate","fallback","silent fallback gate","python","edit","hook",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":178,"publishedAt":35},"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",[177],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[179,180,181,27,145,182,183,184,151,104,31,185,186,85,187,188,189,190,191,192],"framework","retro","retro to framework","retrospective","projects","convert","incident","across","problem","about","more","skill update","single","generic"]