[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PVEAQY0GS0HCSTZ5CM060B":3,"skill-same:01M6PVEAQY0GS0HCSTZ5CM060B":67},{"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":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},"01M6PVEAQY0GS0HCSTZ5CM060B","library-change-hypothesis-protocol",null,"After execute-stage commits land (diff finalized) and BEFORE the task transitions to done, file a companion HYP with an explicit verification_protocol — or record an explicit \"no behavior change\" note for refactors at plan-stage. NEVER file the HYP at plan-stage (precommitment anti-pattern).","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-change-hypothesis-protocol\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"protocol","library change hypothesis protocol","hypothesis","library","change","land","file","verification","commits","plan","diff","never","task","done","pattern","stage","with","companion","at","for","2026-11-10 10:12:30",false,"---\nname: library-change-hypothesis-protocol\ndescription: >-\n  After execute-stage commits land (diff finalized) and BEFORE the task\n  transitions to done, file a companion HYP with an explicit\n  verification_protocol — or record an explicit \"no behavior change\" note\n  for refactors at plan-stage. NEVER file the HYP at plan-stage\n  (precommitment anti-pattern).\nlicense: MIT\nai_hats:\n  schema_version: 1\n  type: skill\n---\n\n# Library-Change Hypothesis Protocol\n\n> **PoC status.** This skill is intentionally lightweight.\n> The framework does NOT enforce companion-HYP filing — discipline lives\n> here. If the PoC produces signal that curators skip the step, a future\n> task may lift enforcement into the engine.\n\n## Timing — read this first\n\nTwo checkpoints, NOT one:\n\n| Stage        | What you do here                                                                                                               |\n| ------------ | ------------------------------------------------------------------------------------------------------------------------------ |\n| **plan**     | Behavior-delta check only. Decide *whether* a HYP will be needed. Record decision in `plan.md`. **Do NOT create the HYP yet.** |\n| **document** | Diff is final on `task\u002F\u003Cid>` branch. **Now** create the HYP (`rack hyp create`), cross-link, commit.                           |\n\nFiling the HYP at plan-stage is a **precommitment anti-pattern**.\nThe HYP must describe what shipped — not what was\n*planned* to ship.\n\n### Why post-ship, not plan-stage\n\n1. **Falsifiability is bound to the real diff.** At plan stage the\n   final shape of the change is not yet known: scope can drift,\n   alternatives can be rejected mid-execute, wording can be rewritten.\n   A plan-stage HYP describes *intent*, not *shipment*.\n2. **Observation window opens at merge.** Until the change is on\n   `master` (or at minimum frozen on the task branch), `validation_log`\n   has nothing to accumulate. A plan-stage HYP sits `active` with no\n   evidence — noise in the active-HYP inbox.\n3. **Precommitment bias.** A plan-stage HYP starts pulling the\n   implementation toward its own framing: «we already said\n   Vertical-slicing-directive will reduce bulk-tests» makes it harder\n   in execute to honestly say «this isn't enough — promote to a full\n   skill». Post-ship HYPs are observers, not advocates.\n4. **Orphan HYPs from cancelled tasks.** If a task dies in execute\n   (cancelled, scope shifted to another card), a plan-stage HYP\n   becomes a sibling artefact needing cleanup. Post-ship HYPs only\n   exist when there's a real change to observe.\n5. **Supervisor citation.** *«Why are we filing hypotheses now? They\n   should be filed after the task is done.»* — raised at one task's\n   closure thread and repeated at the next.\n\n## When to Use\n\nTriggered when transitioning a library-curation task from **execute**\nto **document** — after the implementing commits exist and the diff is\nfinal. Library-curation = any change to a component an agent composes:\na `roles\u002F`, `traits\u002F`, `skills\u002F` or `rules\u002F` entry under one of this\nproject's library roots (`\u003Cproject>\u002Flibraries\u002F`, `~\u002F.ai-hats\u002F`, or the\nshipped library if you are editing that).\n\nSkip when: the change is to engine or harness code rather than to a\ncomposed component, or the change was already declared \"no behavior\nchange — pure refactor\" at the plan-stage check (see Step 1).\n\nIf this project has no hypotheses backlog yet, `ai-hats reflect issue`\nseeds one from the packaged definition on first write. Do not reach for\n`rack hyp` first: until the backlog is mounted that group does not\nexist, and the answer is `No such command 'hyp'` — the subcommands are\nregistered from the backlogs found in the tracker, so a missing one\nlooks like a missing feature rather than a missing directory.\n\n## Why companion HYPs at all\n\nWithout a companion HYP, library-curation changes ship blind:\n\n- Behavior-changing library edits have shipped with no HYP filed. No\n  data tells us whether those changes worked.\n- A HYP has been filed only because the user prompted for it. The\n  discipline does not survive without a checklist.\n- Even when HYPs exist, their `success_criterion` text is interpreted\n  qualitatively — one was marked `confirmed` on a single audit cite\n  against a \"≥3 of 4 transitions\" criterion. The criterion text alone\n  did not constrain the auditor.\n\nThis skill addresses the producer side: every behavior-changing\nlibrary edit gets a companion HYP whose YAML carries a\n**`verification_protocol`** field — explicit, free-form text telling\nfuture auditors exactly what shape of `--evidence` to emit. The\nconsumer side (auditor follows the protocol) lives in\n**review-hypothesis**.\n\n## Procedure\n\n### Step 1 — Behavior delta check (plan-stage)\n\nIn your task's `plan.md`, answer two questions explicitly:\n\n1. **Prior behavior?** What did agents observably do before this edit?\n2. **Post-change behavior?** What should they observably do after?\n\nBoth \"no observable change\" → **pure refactor**. Record the decision\nexplicitly in `plan.md` or via `rack transition --log` (one line:\n\"no behavior change — pure refactor: \u003Creason>\"). Skip the rest of this\nskill — no HYP needed, now or later.\n\nOtherwise → continue to Step 2 **at document-stage**, not now.\n\n### Step 2 — Author the HYP (document-stage, AFTER final commit)\n\n**Precondition:** the final implementing commit exists on\n`task\u002F\u003Cid>` and the task has been transitioned `execute → document`.\nIf you find yourself reaching for `hyp create` while the task is still\n`plan` or `execute`, **stop** — you're committing the precommitment\nanti-pattern.\n\n**First — is it already covered by an active HYP?** Check the active\nhypotheses (the reviewer's evidence block lists them, or `rack context\nHYP-NNN` per candidate) for one that already describes this change's\nmechanism. If one does,\n**do not file a new HYP** — that duplicates the backlog (the same\numbrella-first discipline as self-retrospective 4.5.a). Instead **fold\ninto it**: append an intervention marker to that HYP's `validation_log`\nand cross-link both ways (task resolution names the HYP; the marker\nnames the task + sha):\n\n```bash\nrack hyp append-verdict HYP-NNN --session-id \u003Cid> \\\n  --verdict n\u002Fa --recommendation keep \\\n  --evidence \"INTERVENTION (not an audit): \u003Ctask> (\u003Csha>) \u003Cwhat shipped>.\"\n```\n\nUse `--recommendation extend_window` instead of `keep` when your change\nmodifies the **very procedure\u002Fbehavior the HYP is measuring** — its\nwindow now straddles a pre\u002Fpost boundary and the reviewer must\nre-baseline. The `n\u002Fa` verdict + the `INTERVENTION (not an audit)`\nprefix stop the marker being read as an observation. Then **stop** — no\nnew HYP.\n\nOtherwise (no active HYP covers the change) → author a new companion HYP:\n\n```bash\nrack hyp create \"\u003Ctitle>\" --hypothesis \"…\" --baseline \"…\" \\\n  --observation-window \"…\" --success-criterion \"…\"\n\nrack transition HYP-NNN \\\n  --set verification_protocol=\"…\" \\\n  --link source_task:\u003CTASK-ID>\n```\n\n`hypothesis` is the one field the schema requires; `rack` owns `id`,\n`state` and `created`. A HYP missing `baseline`, `observation_window` or\n`success_criterion` is unfalsifiable (see Anti-Patterns).\n\n`verification_protocol` is undeclared by the schema, so it takes `--set`\nrather than a flag of its own. Never hand-write the card: an Edit\u002FWrite\nunder the tracker backlog is denied, and `rack` is its only writer.\n\n**`verification_protocol`** is a free-form string telling auditors how to\nshape their `--evidence` for this specific HYP. `rack context HYP-NNN`\nprints it back, and the session reviewer renders it into the auditor's\nhandoff. Examples below.\n\n> **Picking the data shape.** Apply `design-minimalism`'s\n> behavioral-delivery escalation ladder. An undeclared field under an\n> `allow` extras policy (rung 1) is almost always sufficient; lift to a\n> declared schema field (rung 6) only after a sweep shows the loose\n> shape produces unreadable verdicts.\n\n#### `verification_protocol` examples\n\n**Strict format** (auditor evidence is a tight machine-readable block):\n\n```yaml\nverification_protocol: |\n  Evidence MUST be exactly three lines, no prose:\n  Line 1: \"CRITERION: \u003Cverbatim string from this HYP's success_criterion>\"\n  Line 2: \"OBSERVED: \u003Cverbatim cite from audit.md or work_log, OR 'NOT OBSERVED'>\"\n  Line 3: \"VERDICT_REASON: satisfies | fails | silent\"\n```\n\n**Loose format** (auditor evidence is short prose):\n\n```yaml\nverification_protocol: |\n  Evidence: one paragraph (1–4 sentences). Address (a) what the\n  success_criterion asks for, (b) what the session showed, (c) whether\n  (b) satisfies, fails, or is silent on (a). Verbatim quotes encouraged\n  but optional.\n```\n\n**Window-counter format** (auditor maintains a running tally):\n\n```yaml\nverification_protocol: |\n  Evidence MUST start with \"WINDOW: \u003CN>\u002F\u003CM>\" where N = current sweep\n  count incl. this one, M = observation_window target. Then one line\n  citing whether this session moved the counter.\n```\n\nPick whichever protocol matches the kind of verdict you actually want\nto be able to read back in 4 weeks. Write the protocol so an auditor\nwho has never seen the task can comply.\n\n### Step 3 — Cross-link (document-stage)\n\n- Task description (or work_log entry) references the new `HYP-NNN`.\n- HYP `source_task` points back to this task.\n- The HYP-creation commit body (or the immediately-preceding ship\n  commit body) carries both IDs: e.g. `\u003CTASK-ID> \u002F HYP-NNN`.\n\n## Anti-Patterns\n\n### ✗ Plan-stage HYP filing (precommitment)\n\nCreating `HYP-NNN` while the task is still in `plan` or early `execute`.\nThe HYP locks in framing that the diff may diverge from; rollback later\nrequires `rack transition HYP-NNN stalled` + a re-creation.\n\n### ✗ HYP with empty baseline \u002F observation_window\n\nA HYP whose `baseline` is \"agents do X\" without specifying *which\nsessions* count as the baseline, or whose `observation_window` says\n\"a few sessions\" — both produce unfalsifiable verdicts. The fields\nexist because they constrain the auditor. If you can't fill them\nconcretely, the HYP isn't ready.\n\n### ✗ HYP filed for an unobservable change\n\nIf the diff has no behavior delta visible to a future agent session\n(e.g. doc-only typo fix, comment rewording), there's nothing to\nobserve. Mark as refactor at plan-stage and skip.\n\n### ✗ Duplicate HYP when an active one already covers it\n\nFiling a fresh `HYP-NNN` whose mechanism is already the subject of an\nactive HYP. Two failure shapes: (a) a near-duplicate that the supervisor\nmust merge (the same churn self-retro 4.5.c prevents); (b) recording the\ncross-link only on the **task** side (resolution) and leaving the\nexisting HYP's `validation_log` with no intervention marker — a\none-sided link a future auditor of that HYP never sees. Fold instead:\none `append-verdict` intervention marker, cross-linked both ways\n(Step 2, \"already covered\" branch).\n\n## Examples\n\n### ✓ Good (post-ship discipline)\n\nTask: rewrite `review-session` skill to add a new output field.\n\n- **Plan-stage:** prior = \"output has N fields\", post = \"N+1 fields\".\n  Recorded in `plan.md`. **No HYP yet.**\n- **Execute:** edit skill, run composition smoke, commit on\n  `task\u002F\u003Cid>`.\n- **Document-stage:** diff final. `rack hyp create \"…\" --hypothesis \"…\"`,\n  then `rack transition HYP-NNN --set verification_protocol=\"…\" --link\n  source_task:\u003CTASK-ID>`, the protocol reading \"Evidence MUST quote the\n  field name from session retro YAML and confirm it appears under\n  hypothesis_verdicts[*]\".\n\n### ✓ Good (refactor exemption)\n\nTask: dedup identical injection text between `trait-base` and\n`trait-analyst-base`. Plan-stage: prior = post = same observable\nbehavior. Record \"no behavior change — pure refactor: shared injection\ntext deduplicated, semantics unchanged\". No HYP filed — now or later.\n\n### ✗ Bad\n\nTask: add a new rule to `trait-base`. Ship without companion HYP. No\nrecord of expected behavior shift. Two weeks later, no way to tell if\nthe rule worked.\n\n**Correct response:** at document-stage (after the rule is committed),\nfile a HYP with `verification_protocol` describing what audit.md\nshould show; mention both IDs in the next commit body.\n\n### ✗ Bad (precommitment)\n\nTask: same as above, but the agent files `HYP-XXX` at plan-stage\nbefore any edit exists. Execute reveals that the rule alone is\ninsufficient; scope shifts to a new skill. The pre-filed HYP now\ndescribes a change that never shipped — must be moved to `stalled`\n(`rack transition HYP-NNN stalled`) and re-created post-ship. Wastes a\nHYP slot and produces a confusing audit trail.\n\n## Scope\n\nThis skill describes a **discipline**, not a gate. Nothing in the\nframework rejects a merge that lacks a companion HYP, nor rejects a\nHYP filed too early. If post-ship discipline slips repeatedly, a\nfollow-up task may add CI enforcement (reject `hyp create` when source\ntask is not yet in `document`\u002F`review`\u002F`done`).\n","# Library-Change Hypothesis Protocol\n\n> **PoC status.** This skill is intentionally lightweight.\n> The framework does NOT enforce companion-HYP filing — discipline lives\n> here. If the PoC produces signal that curators skip the step, a future\n> task may lift enforcement into the engine.\n\n## Timing — read this first\n\nTwo checkpoints, NOT one:\n\n| Stage        | What you do here                                                                                                               |\n| ------------ | ------------------------------------------------------------------------------------------------------------------------------ |\n| **plan**     | Behavior-delta check only. Decide *whether* a HYP will be needed. Record decision in `plan.md`. **Do NOT create the HYP yet.** |\n| **document** | Diff is final on `task\u002F\u003Cid>` branch. **Now** create the HYP (`rack hyp create`), cross-link, commit.                           |\n\nFiling the HYP at plan-stage is a **precommitment anti-pattern**.\nThe HYP must describe what shipped — not what was\n*planned* to ship.\n\n### Why post-ship, not plan-stage\n\n1. **Falsifiability is bound to the real diff.** At plan stage the\n   final shape of the change is not yet known: scope can drift,\n   alternatives can be rejected mid-execute, wording can be rewritten.\n   A plan-stage HYP describes *intent*, not *shipment*.\n2. **Observation window opens at merge.** Until the change is on\n   `master` (or at minimum frozen on the task branch), `validation_log`\n   has nothing to accumulate. A plan-stage HYP sits `active` with no\n   evidence — noise in the active-HYP inbox.\n3. **Precommitment bias.** A plan-stage HYP starts pulling the\n   implementation toward its own framing: «we already said\n   Vertical-slicing-directive will reduce bulk-tests» makes it harder\n   in execute to honestly say «this isn't enough — promote to a full\n   skill». Post-ship HYPs are observers, not advocates.\n4. **Orphan HYPs from cancelled tasks.** If a task dies in execute\n   (cancelled, scope shifted to another card), a plan-stage HYP\n   becomes a sibling artefact needing cleanup. Post-ship HYPs only\n   exist when there's a real change to observe.\n5. **Supervisor citation.** *«Why are we filing hypotheses now? They\n   should be filed after the task is done.»* — raised at one task's\n   closure thread and repeated at the next.\n\n## When to Use\n\nTriggered when transitioning a library-curation task from **execute**\nto **document** — after the implementing commits exist and the diff is\nfinal. Library-curation = any change to a component an agent composes:\na `roles\u002F`, `traits\u002F`, `skills\u002F` or `rules\u002F` entry under one of this\nproject's library roots (`\u003Cproject>\u002Flibraries\u002F`, `~\u002F.ai-hats\u002F`, or the\nshipped library if you are editing that).\n\nSkip when: the change is to engine or harness code rather than to a\ncomposed component, or the change was already declared \"no behavior\nchange — pure refactor\" at the plan-stage check (see Step 1).\n\nIf this project has no hypotheses backlog yet, `ai-hats reflect issue`\nseeds one from the packaged definition on first write. Do not reach for\n`rack hyp` first: until the backlog is mounted that group does not\nexist, and the answer is `No such command 'hyp'` — the subcommands are\nregistered from the backlogs found in the tracker, so a missing one\nlooks like a missing feature rather than a missing directory.\n\n## Why companion HYPs at all\n\nWithout a companion HYP, library-curation changes ship blind:\n\n- Behavior-changing library edits have shipped with no HYP filed. No\n  data tells us whether those changes worked.\n- A HYP has been filed only because the user prompted for it. The\n  discipline does not survive without a checklist.\n- Even when HYPs exist, their `success_criterion` text is interpreted\n  qualitatively — one was marked `confirmed` on a single audit cite\n  against a \"≥3 of 4 transitions\" criterion. The criterion text alone\n  did not constrain the auditor.\n\nThis skill addresses the producer side: every behavior-changing\nlibrary edit gets a companion HYP whose YAML carries a\n**`verification_protocol`** field — explicit, free-form text telling\nfuture auditors exactly what shape of `--evidence` to emit. The\nconsumer side (auditor follows the protocol) lives in\n**review-hypothesis**.\n\n## Procedure\n\n### Step 1 — Behavior delta check (plan-stage)\n\nIn your task's `plan.md`, answer two questions explicitly:\n\n1. **Prior behavior?** What did agents observably do before this edit?\n2. **Post-change behavior?** What should they observably do after?\n\nBoth \"no observable change\" → **pure refactor**. Record the decision\nexplicitly in `plan.md` or via `rack transition --log` (one line:\n\"no behavior change — pure refactor: \u003Creason>\"). Skip the rest of this\nskill — no HYP needed, now or later.\n\nOtherwise → continue to Step 2 **at document-stage**, not now.\n\n### Step 2 — Author the HYP (document-stage, AFTER final commit)\n\n**Precondition:** the final implementing commit exists on\n`task\u002F\u003Cid>` and the task has been transitioned `execute → document`.\nIf you find yourself reaching for `hyp create` while the task is still\n`plan` or `execute`, **stop** — you're committing the precommitment\nanti-pattern.\n\n**First — is it already covered by an active HYP?** Check the active\nhypotheses (the reviewer's evidence block lists them, or `rack context\nHYP-NNN` per candidate) for one that already describes this change's\nmechanism. If one does,\n**do not file a new HYP** — that duplicates the backlog (the same\numbrella-first discipline as self-retrospective 4.5.a). Instead **fold\ninto it**: append an intervention marker to that HYP's `validation_log`\nand cross-link both ways (task resolution names the HYP; the marker\nnames the task + sha):\n\n```bash\nrack hyp append-verdict HYP-NNN --session-id \u003Cid> \\\n  --verdict n\u002Fa --recommendation keep \\\n  --evidence \"INTERVENTION (not an audit): \u003Ctask> (\u003Csha>) \u003Cwhat shipped>.\"\n```\n\nUse `--recommendation extend_window` instead of `keep` when your change\nmodifies the **very procedure\u002Fbehavior the HYP is measuring** — its\nwindow now straddles a pre\u002Fpost boundary and the reviewer must\nre-baseline. The `n\u002Fa` verdict + the `INTERVENTION (not an audit)`\nprefix stop the marker being read as an observation. Then **stop** — no\nnew HYP.\n\nOtherwise (no active HYP covers the change) → author a new companion HYP:\n\n```bash\nrack hyp create \"\u003Ctitle>\" --hypothesis \"…\" --baseline \"…\" \\\n  --observation-window \"…\" --success-criterion \"…\"\n\nrack transition HYP-NNN \\\n  --set verification_protocol=\"…\" \\\n  --link source_task:\u003CTASK-ID>\n```\n\n`hypothesis` is the one field the schema requires; `rack` owns `id`,\n`state` and `created`. A HYP missing `baseline`, `observation_window` or\n`success_criterion` is unfalsifiable (see Anti-Patterns).\n\n`verification_protocol` is undeclared by the schema, so it takes `--set`\nrather than a flag of its own. Never hand-write the card: an Edit\u002FWrite\nunder the tracker backlog is denied, and `rack` is its only writer.\n\n**`verification_protocol`** is a free-form string telling auditors how to\nshape their `--evidence` for this specific HYP. `rack context HYP-NNN`\nprints it back, and the session reviewer renders it into the auditor's\nhandoff. Examples below.\n\n> **Picking the data shape.** Apply `design-minimalism`'s\n> behavioral-delivery escalation ladder. An undeclared field under an\n> `allow` extras policy (rung 1) is almost always sufficient; lift to a\n> declared schema field (rung 6) only after a sweep shows the loose\n> shape produces unreadable verdicts.\n\n#### `verification_protocol` examples\n\n**Strict format** (auditor evidence is a tight machine-readable block):\n\n```yaml\nverification_protocol: |\n  Evidence MUST be exactly three lines, no prose:\n  Line 1: \"CRITERION: \u003Cverbatim string from this HYP's success_criterion>\"\n  Line 2: \"OBSERVED: \u003Cverbatim cite from audit.md or work_log, OR 'NOT OBSERVED'>\"\n  Line 3: \"VERDICT_REASON: satisfies | fails | silent\"\n```\n\n**Loose format** (auditor evidence is short prose):\n\n```yaml\nverification_protocol: |\n  Evidence: one paragraph (1–4 sentences). Address (a) what the\n  success_criterion asks for, (b) what the session showed, (c) whether\n  (b) satisfies, fails, or is silent on (a). Verbatim quotes encouraged\n  but optional.\n```\n\n**Window-counter format** (auditor maintains a running tally):\n\n```yaml\nverification_protocol: |\n  Evidence MUST start with \"WINDOW: \u003CN>\u002F\u003CM>\" where N = current sweep\n  count incl. this one, M = observation_window target. Then one line\n  citing whether this session moved the counter.\n```\n\nPick whichever protocol matches the kind of verdict you actually want\nto be able to read back in 4 weeks. Write the protocol so an auditor\nwho has never seen the task can comply.\n\n### Step 3 — Cross-link (document-stage)\n\n- Task description (or work_log entry) references the new `HYP-NNN`.\n- HYP `source_task` points back to this task.\n- The HYP-creation commit body (or the immediately-preceding ship\n  commit body) carries both IDs: e.g. `\u003CTASK-ID> \u002F HYP-NNN`.\n\n## Anti-Patterns\n\n### ✗ Plan-stage HYP filing (precommitment)\n\nCreating `HYP-NNN` while the task is still in `plan` or early `execute`.\nThe HYP locks in framing that the diff may diverge from; rollback later\nrequires `rack transition HYP-NNN stalled` + a re-creation.\n\n### ✗ HYP with empty baseline \u002F observation_window\n\nA HYP whose `baseline` is \"agents do X\" without specifying *which\nsessions* count as the baseline, or whose `observation_window` says\n\"a few sessions\" — both produce unfalsifiable verdicts. The fields\nexist because they constrain the auditor. If you can't fill them\nconcretely, the HYP isn't ready.\n\n### ✗ HYP filed for an unobservable change\n\nIf the diff has no behavior delta visible to a future agent session\n(e.g. doc-only typo fix, comment rewording), there's nothing to\nobserve. Mark as refactor at plan-stage and skip.\n\n### ✗ Duplicate HYP when an active one already covers it\n\nFiling a fresh `HYP-NNN` whose mechanism is already the subject of an\nactive HYP. Two failure shapes: (a) a near-duplicate that the supervisor\nmust merge (the same churn self-retro 4.5.c prevents); (b) recording the\ncross-link only on the **task** side (resolution) and leaving the\nexisting HYP's `validation_log` with no intervention marker — a\none-sided link a future auditor of that HYP never sees. Fold instead:\none `append-verdict` intervention marker, cross-linked both ways\n(Step 2, \"already covered\" branch).\n\n## Examples\n\n### ✓ Good (post-ship discipline)\n\nTask: rewrite `review-session` skill to add a new output field.\n\n- **Plan-stage:** prior = \"output has N fields\", post = \"N+1 fields\".\n  Recorded in `plan.md`. **No HYP yet.**\n- **Execute:** edit skill, run composition smoke, commit on\n  `task\u002F\u003Cid>`.\n- **Document-stage:** diff final. `rack hyp create \"…\" --hypothesis \"…\"`,\n  then `rack transition HYP-NNN --set verification_protocol=\"…\" --link\n  source_task:\u003CTASK-ID>`, the protocol reading \"Evidence MUST quote the\n  field name from session retro YAML and confirm it appears under\n  hypothesis_verdicts[*]\".\n\n### ✓ Good (refactor exemption)\n\nTask: dedup identical injection text between `trait-base` and\n`trait-analyst-base`. Plan-stage: prior = post = same observable\nbehavior. Record \"no behavior change — pure refactor: shared injection\ntext deduplicated, semantics unchanged\". No HYP filed — now or later.\n\n### ✗ Bad\n\nTask: add a new rule to `trait-base`. Ship without companion HYP. No\nrecord of expected behavior shift. Two weeks later, no way to tell if\nthe rule worked.\n\n**Correct response:** at document-stage (after the rule is committed),\nfile a HYP with `verification_protocol` describing what audit.md\nshould show; mention both IDs in the next commit body.\n\n### ✗ Bad (precommitment)\n\nTask: same as above, but the agent files `HYP-XXX` at plan-stage\nbefore any edit exists. Execute reveals that the rule alone is\ninsufficient; scope shifts to a new skill. The pre-filed HYP now\ndescribes a change that never shipped — must be moved to `stalled`\n(`rack transition HYP-NNN stalled`) and re-created post-ship. Wastes a\nHYP slot and produces a confusing audit trail.\n\n## Scope\n\nThis skill describes a **discipline**, not a gate. Nothing in the\nframework rejects a merge that lacks a companion HYP, nor rejects a\nHYP filed too early. If post-ship discipline slips repeatedly, a\nfollow-up task may add CI enforcement (reject `hyp create` when source\ntask is not yet in `document`\u002F`review`\u002F`done`).\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\u002Flibrary-change-hypothesis-protocol","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 library-change-hypothesis-protocol",{"tool":59,"command":60},"bunx","bunx skills add muratovv\u002Fai-hats --skill library-change-hypothesis-protocol",{"tool":62,"command":63},"pnpm","pnpm dlx skills add muratovv\u002Fai-hats --skill library-change-hypothesis-protocol","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Flibrary-change-hypothesis-protocol\u002FSKILL.md",true,[],[68,93,115,138,161,175],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"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",[],[19,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,38,91,92],"Evaluation","tool","tool evaluation protocol","testing","ml","libraries","adoption","methodology","Tools","use","dependency","up","frameworks","time","project","recommendation","bounded","candidate",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"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",[],[100,101,102,103,19,104,21,105,106,107,84,108,109,110,33,111,112,35,113,114],"systematic debugging","debugging","systematic","test","monitoring","verify","behavior","fix","evidence","bug","reports","users","error","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":126,"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",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[127,128,129,130,131,106,132,84,133,33,134,135,136,38,137],"template","skill template","validation","compliance","hats","guide","new skill","structural","canonical","which","Existing",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"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",[144],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[146,147,148,149,150,22,151,152,153,154,84,155,156,157,158,159,160],"Optimization","skill optimization","components","component","issues","audit","refactor","Budget","Rules","periodic","maintenance","token","token budget","role","high",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"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",[],[168,169,170,171,172,173,84,174,38],"gate","fallback","silent fallback gate","python","write","edit","hook",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"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",[181],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[183,184,185,23,149,186,187,188,154,106,84,189,190,89,191,192,193,194,195,196],"framework","retro","retro to framework","retrospective","projects","convert","incident","across","problem","about","more","skill update","single","generic"]