[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PVDNCYM4WMZ3SP94GRZ3DE":3,"skill-same:01M6PVDNCYM4WMZ3SP94GRZ3DE":107},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":51,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6PVDNCYM4WMZ3SP94GRZ3DE","worktree-isolation",null,"Isolated development using git worktrees so the main branch stays clean. Use when starting any non-trivial task (execute state), doing parallel work on multiple tasks, making risky changes you might want to discard, or delegating to a sub-agent (automatic via ai-hats agent --isolation).","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\u002Fworktree-isolation\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,39,40,41,42,43],"worktree isolation","worktree","isolation","git worktrees","changes","you","Using git","main","task","clean","use","using git worktrees","risky changes","branch","work","parallel","work on","state","development","tasks","2026-11-10 10:12:30",false,"---\nname: worktree-isolation\ndescription: >-\n  Isolated development using git worktrees so the main branch stays clean.\n  Use when starting any non-trivial task (execute state), doing parallel\n  work on multiple tasks, making risky changes you might want to discard,\n  or delegating to a sub-agent (automatic via ai-hats agent --isolation).\nai_hats:\n  schema_version: 1\n  type: skill\nlicense: MIT\n---\n\n# Worktree Isolation\n\nIsolated development using git worktrees. Each task gets its own working copy — main branch stays clean.\n\n> **Worktree Python Environment & Interpreter Trap.** The main venv's editable install points at the MAIN checkout, so **any** command run with that interpreter observes the main checkout — not only tests. `ai-hats` CLI invocations and compose smokes count, and so does anything else you would call verification.\n>\n> - **Run everything through the worktree's own interpreter**: `.\u002F.venv\u002Fbin\u002Fpython -m pytest …`, where a project provisions one per worktree. If it is missing, mint it: `uv venv .venv && VIRTUAL_ENV=.venv uv pip install -e .` (plus any workspace sub-packages `-e packages\u002F...`).\n> - **Verifying a library-DATA change is the dangerous case.** For a code change the session tripwire (`tests\u002Fconftest.py`) refuses the run, so the trap is loud. For `SKILL.md` \u002F trait \u002F role `config.yaml` there is no tripwire: a compose smoke run against the main venv succeeds, exits 0, and validates a tree your change never touched. Validate the worktree file directly, or put the worktree venv on PATH.\n\n## Workflow\n\n1. **Start task** → create worktree:\n   ```\n   ai-hats wt create feat\u002FPROJ-004\n   cd \u003Cworktree-path>\n   ```\n\n   **Claude surface only — enter with `cd`, never the `EnterWorktree` tool.** It\n   builds a rival worktree outside ai-hats (no state, no locks, no venv, wrong\n   branch name), or raises an approval prompt nothing can suppress. The\n   `wt_entry_gate.py` PreToolUse hook denies it and repeats this recipe.\n   No other surface has the tool — skip this paragraph there.\n\n   **Claude surface only — delegate with `ai-hats agent --isolation`, never the\n   Agent tool's `isolation: \"worktree\"`.** A subagent that writes leaves its\n   worktree on disk on a `worktree-agent-\u003Chex>` branch — registered in git,\n   invisible to `ai-hats wt list` (measured). A read-only subagent\n   needs no isolation at all. No other surface has the parameter — skip this\n   paragraph there.\n\n   A **PreToolUse gate** (`hooks\u002Fwt_gate.py`) **hard-denies** a code\u002Fconfig Edit\u002FWrite in\n   the **main checkout** — interactive and headless (the old nudge was ignored).\n   On a deny, move into a worktree and re-apply: `ai-hats wt status` for an\n   active one, else `ai-hats wt create \u003Ctype>\u002F\u003Cname>` from `master`. Don't ask to skip a\n   worktree (making one is one command); ask the supervisor only for a genuine\n   direct-master change. Bypass is supervisor-only (`AI_HATS_WT_GATE_OFF=1`, never\n   agent-set). Docs, non-trigger extensions, and gitignored paths (tracker, `ai-hats.yaml`)\n   are exempt (trigger set: `hooks\u002Fcode_extensions.json`).\n\n   A second gate (`hooks\u002Fwt_git_gate.py`) does the same for **git state**: a\n   command that discards uncommitted work or moves a branch ref is denied where\n   it would act on the main checkout. A leading `cd` and a `git -C` are read\n   first, so the same command aimed at a worktree runs, and the refusal names\n   the recipe. Bypass is supervisor-only (`AI_HATS_WT_GIT_OFF=1`, never\n   agent-set).\n\n2. **Work** — commit freely in the worktree. Main tree is untouched.\n\n3. **Finish** → hand off for review; the merge is review-gated.\n   In an interactive session, the external consent wrapper turns the canonical\n   `rack transition … done` or direct `ai-hats wt merge` command into a\n   supervisor question. The agent never exports an acknowledgement flag and\n   never grants itself consent. The canonical close:\n   ```\n   cd \u003Cproject-dir>\n   rack transition \u003Cid> review    # then STOP — supervisor reviews the diff\n   # after review passed, the reviewer drives the consent-gated edge;\n   # its one authorization also covers the nested worktree merge.\n   rack transition \u003Cid> done\n   ```\n   The supervisor may instead run a direct merge; it is a separate top-level\n   consent operation and therefore gets its own question.\n\n   **The merge happens only on the review→done road.** The review diff is\n   computed against the merge-base with the base branch, so a `--no-ff` merge\n   of the task branch into that base before review empties the diff — merge-base\n   becomes the branch tip.\n\n   - A raw `git merge` of a `task\u002F\u003Cprefix>-\u003Cn>` ref is hard-denied at PreToolUse\n     when the checkout that merge runs in is `master` or `main`. `git -C` and a\n     leading `cd` count. The refusal names `ai-hats wt merge`. Merging one task\n     branch into another is allowed.\n   - `ai-hats wt merge` refuses while the card is before `review`. A card cannot\n     enter `review` when its tip is already a non-first parent of a merge on the\n     base recorded at worktree create (`--no-ff`, the road `wt merge` takes). A\n     branch that never carried a commit still enters review.\n\n   These two do not catch a command that hides the branch name in a variable, a\n   cherry-pick, a fast-forward that already happened outside the guard, or a\n   human merging from their own terminal.\n\n   If `wt merge` refuses with `Refused (drift)`, the base holds commits\n   your branch never took in (another agent's worktree merged, or\n   `origin\u002F\u003Cbase>` received commits). Re-verify your changes against the\n   new base (re-run grep-verify, re-check moved\u002Frenamed paths), then\n   **rebase in the worktree** — `git rebase \u003Cbase>` clears the guard, no\n   flag needed, so `rack transition \u003Cid> done` works again.\n   `--accept-drift` is for the other case: merging a stale baseline you\n   accept knowingly. **Do not** pass `--force` for drift — `--force` only\n   bypasses uncommitted changes; drift has its own override.\n   Neither `--force` nor `--accept-drift` bypasses the session wrapper.\n\n4. **Abandon** → discard:\n   ```\n   cd \u003Cproject-dir>\n   ai-hats wt discard\n   ```\n\n## Pre-merge checklist (long-lived tasks)\n\nFor tasks that span multiple sessions OR multiple review rounds,\nthe base branch (usually `master`) can drift forward while you work\n— other agents' worktrees merge in parallel, or `origin\u002F\u003Cbase>`\nreceives commits. `rack transition \u003Cid> done` will then\nfail with `WorktreeDriftError` and you'll need an ad-hoc recovery.\n\nRebase **before** closing so drift never accumulates past your\nverification window. Do the rebase IN the worktree, but run the close\nfrom the MAIN checkout:\n\n```bash\n# Rebase the task branch in the worktree (git work is fine here):\ncd \u003Cworktree-path>\ngit fetch --all\ngit rebase \u003Cbase-branch>         # usually master\n# resolve any conflicts; re-run the affected tests\n\n# Close from the MAIN checkout — NOT from inside the worktree. A\n# worktree-backed `transition done` issued from inside its own worktree\n# is refused: the merge runs `git worktree remove` on the cwd\n# you are standing in, which would orphan your shell and desync the tracker.\ncd \u003Cproject-dir>\nrack transition \u003Cid> done   # ack-free once the branch is merged; do NOT `git merge` by hand\n```\n\nThe merge itself is review-gated (step 3 above) — never `git merge \u003Ctask-branch>`\nyourself (a manual pre-merge collides with the FSM merge, HYP-023). If the close\nstill reports drift, you skipped the rebase above — do it, then re-run the\ntransition. Only a baseline you knowingly leave stale needs\n`ai-hats wt merge --accept-drift` from the main repo.\n\n**Skip this for short tasks** (\u003C ~2 hours wall-clock, no review\nrounds). Drift typically only matters on multi-session work; for a\n30-minute task the base hasn't moved.\n\nIf you skipped the checklist and hit `WorktreeDriftError` anyway,\nthe recovery is the same rebase — see the drift block in step 3 of\nthe Workflow above.\n\n## Commands\n\n| Command                      | What it does                                            |\n| ---------------------------- | ------------------------------------------------------- |\n| `ai-hats wt create \u003Cbranch>` | Create worktree on new branch                           |\n| `ai-hats wt merge`           | Squash-merge changes back, clean up                     |\n| `ai-hats wt discard`         | Delete worktree and branch                              |\n| `ai-hats wt list`            | Show all worktrees                                      |\n| `ai-hats wt status`          | Show active worktree                                    |\n| `ai-hats wt exec -- \u003Ccmd>`   | Run command in worktree, where you stand (+ PYTHONPATH) |\n| `ai-hats wt env [\u003Cbranch>]`  | Print `export WT=... PYTHONPATH=...` for eval           |\n\n## Teardown runs lifecycle hooks\n\n`ai-hats wt merge` \u002F `wt discard` \u002F `cleanup` run any composed **`wt_out`\nlifecycle hooks** *before* removing the worktree — e.g. the `hunk-review-comments`\nskill drains its review sidecar so notes aren't lost. They are **fail-closed**: if a\nhook fails, the teardown **aborts** and the worktree + branch are preserved (nothing\ngitignored is destroyed). Force past a genuinely broken hook with\n`ai-hats wt … --skip-hooks` only if you accept the loss. (`wt create` likewise runs\n`wt_in` hooks to seed gitignored data — e.g. `.env` — into the fresh worktree.) These\nare *component-declared* hooks, distinct from the FSM merge-locks\u002Fdrift guards; to\nauthor one see `docs\u002Fhow-to-extend.md` → \"Worktree lifecycle hooks\".\n\n## Running Commands in Worktree\n\n**Use `wt exec` instead of manual WT=\u002FPYTHONPATH= boilerplate.** It is an\nenvironment wrapper, not a teleporter: it runs your command **where you stand**\nwhen your cwd is inside the worktree, and at the worktree root otherwise.\n\n**It swaps the import path, not the interpreter**. Measured:\n\n```bash\nai-hats wt exec task\u002Fhats-1 -- python -c 'import sys, ai_hats; print(sys.executable, ai_hats.__file__)'\n#   sys.executable   -> \u003CMAIN checkout>\u002F.venv\u002Fbin\u002Fpython\n#   ai_hats.__file__ -> \u003Cworktree>\u002Fsrc\u002Fai_hats\u002F...     (via PYTHONPATH)\n```\n\nThat is enough for in-process imports and nothing else. Any subprocess that does\nnot inherit `PYTHONPATH`, and any `ai-hats` binary found on `PATH`, sees the MAIN\ncheckout. **So for pytest — and for anything that spawns subprocesses — use the\nworktree's own interpreter**; the cost of not doing so is not a quiet false green\nbut a loud false red, a wall of `Test suite would test the WRONG checkout`\ntripwire errors about a mismatch you did not cause.\n\nA PreToolUse gate (`hooks\u002Fwt_interpreter_gate.py`) nudges — never blocks — when it\ncan prove the interpreter resolves outside the worktree; kill switch\n`AI_HATS_WT_INTERP_OFF=1`.\n\n```bash\n# CORRECT — pytest and anything spawning subprocesses, from inside the worktree:\n.\u002F.venv\u002Fbin\u002Fpython -m pytest tests\u002Ftest_foo.py -xvs\n\n# CORRECT — wt exec for in-process, single-shot commands:\nai-hats wt exec -- ruff check src\u002F\nai-hats wt exec -- python -c 'import ai_hats; print(ai_hats.__file__)'\n\n# WRONG — hand-rolled paths, and one dead permission grant per worktree:\nWT=\u002Fvar\u002Ffolders\u002F...\u002Fai-hats-wt-...\nPYTHONPATH=$WT\u002Fsrc python -m pytest tests\u002Ftest_foo.py -xvs\n```\n\n**Subprojects.** A worktree may hold a subproject with its own `pyproject.toml`\nand venv. `cd` into it and carry on, or name it with `-C` from outside — never\n`cd` to an absolute worktree path:\n\n```bash\ncd packages\u002Fai-hats-wt && ..\u002F..\u002F.venv\u002Fbin\u002Fpython -m pytest    # from inside the worktree\nai-hats wt exec task\u002Fhats-1 -C packages\u002Fai-hats-wt -- ruff check .  # from the main checkout\n```\n\nReaching a subproject's *tests* from the main checkout means standing in the\nworktree first — `-C` moves the cwd, not the interpreter.\n\nPYTHONPATH follows the project that **owns** the directory you run in: the\nnearest ancestor with a `pyproject.toml`, bounded by the worktree root. So a\nsubproject gets its own `src`, and a plain subdirectory keeps the worktree-root\nworkspace.\n\nPass `--` before any command that has its own `-C` (e.g. `make -C`).\n\n**Reaching another worktree.** A leading token naming an active branch is a\nselector and always beats cwd, so this works from inside a *different* worktree\ntoo. Without a selector the worktree comes from cwd, else the sole\nactive one; with several active and no selector, `wt exec` refuses and lists them.\n\nFor interactive shell work (rare) — bare, or named to reach another worktree:\n\n```bash\neval \"$(ai-hats wt env)\"\neval \"$(ai-hats wt env task\u002Fhats-1)\"\ncd $WT\n```\n\n## When to Use\n\nThe cost (a separate working copy) is justified by **parallelism, risky-discard,\nor sub-agent isolation** — not by every edit. Skip it for read-only exploration\nor a trivial single-file fix on a throwaway branch. The git operations *inside*\nthe worktree (rebase, conflict resolution, commit conventions) are\n**git-mastery**'s remit; this skill owns the worktree's create → merge → discard\nlifecycle.\n\n## Conventions\n\n- Branch naming: `type\u002FTICKET-ID` (e.g., `feat\u002FPROJ-004`, `fix\u002FPROJ-012`)\n- One active worktree at a time (per project)\n- Always `cd` back to project dir before merge\u002Fdiscard\n- Commit your work in the worktree before merging\n\n## Anti-Patterns\n\n- Working directly on main branch for non-trivial changes — use a worktree\n- Forgetting to `cd` back to project dir before merge\u002Fdiscard — commands fail silently\n- Multiple active worktrees without tracking — leads to forgotten branches\n- Running `ai-hats wt create` \u002F `wt merge` \u002F `wt discard` \u002F `rack transition \u003Cid> done|failed|cancelled` from inside a linked worktree — all blocked. The teardown commands run `git worktree remove` on the very cwd you are standing in, orphaning your shell so every later `ai-hats` mis-resolves the tracker. Always `cd` back to the main repo first; use `ai-hats wt exec` \u002F `ai-hats wt env` to act on a worktree without leaving it.\n- Mixing manual `wt create` with `rack transition \u003Cid> execute` from the main repo — if you created a worktree manually and want the task to use it, `cd` into the worktree first, then transition. Otherwise the transition errors out with a clear remediation message.\n- Invoking `ai-hats wt create` (or `rack transition \u003CID> execute`) while the main repo's HEAD is not on the worktree merge target — blocked with a \"Refused: … not the worktree merge target\" error. The worktree inherits its merge target from the current branch, so creating from the wrong branch causes `wt merge` to silently land on it. The target is `master`\u002F`main` by default, or a configured `worktree.merge_target` (see the fork-workflow note below). Recovery: the error names the branch — `git checkout \u003Cthat branch>` in the main repo, then retry.\n- **Working without committing inside a worktree** — uncommitted work in a worktree is NOT protected. The worktree is a filesystem directory that parallel sessions, cleanup hooks, or `git worktree remove --force` can destroy without warning, and there is **no recovery** for uncommitted changes. Commit at every meaningful checkpoint (every passing test run, every completed sub-task). If a step could be reverted with `git checkout HEAD -- .`, you've waited too long to commit.\n- **Finishing the worktree cycle with raw git** — running `git merge --no-ff \u003Ctask-branch>`, `git worktree remove`, or a manual `git push` to the base branch instead of `ai-hats wt merge` \u002F `rack transition \u003Cid> done`. The CLI wrappers run the FSM lifecycle hooks — per-branch + base-branch merge-locks, drift-check, stale-lock recovery, state cleanup. Raw git skips every one of them and re-opens the race\u002Fdrift bugs those epics closed; a manual merge *before* FSM-`done` also produces a double-merge conflict that then needs `--force` (HYP-023). **Scope:** this targets the **lifecycle transitions only** (merge-to-base + cleanup + done). Raw git for *inspection* (`git status`\u002F`log`\u002F`diff`, `git worktree list`) and for *in-worktree conflict resolution* during a rebase stays fine.\n\n## Specific base or target branch\n\nFork\u002Fdogfood repos can cut worktrees from one branch and merge them into another\n(base ≠ merge-target) via the `worktree` block in `ai-hats.yaml`. Rarely needed;\nfull contract in `docs\u002Fhow-to-configure.md`, section \"The `worktree` block\"\n— for a project whose dev trunk is not its upstream default branch.\n\n## If You End Up With a Stray Worktree\n\n```\ngit worktree list                 # audit\ngit worktree remove \u003Cpath>        # remove a stray linked worktree\ngit worktree prune                # clean stale metadata\nrm \u003Cai_hats_dir>\u002Fsessions\u002Fworktree.json           # if ai-hats state is stale\n```\n\nRule of thumb: one task, one worktree, one `\u003Cai_hats_dir>\u002Fsessions\u002Fworktree.json` (in the main repo).\n\n## Shipped on Master (Retrospective Close)\n\nWork shipped on the base out-of-band? From `brainstorm`\u002F`plan`, fast-close with a\nforced terminal transition: `rack transition \u003Cid> --state done --force --reason \"…\"`.\nFrom `execute`\u002F`document`\u002F`review`: `rack transition \u003Cid> done` finalizes an\nalready-merged branch even if the worktree\u002Fstate is gone.\n","# Worktree Isolation\n\nIsolated development using git worktrees. Each task gets its own working copy — main branch stays clean.\n\n> **Worktree Python Environment & Interpreter Trap.** The main venv's editable install points at the MAIN checkout, so **any** command run with that interpreter observes the main checkout — not only tests. `ai-hats` CLI invocations and compose smokes count, and so does anything else you would call verification.\n>\n> - **Run everything through the worktree's own interpreter**: `.\u002F.venv\u002Fbin\u002Fpython -m pytest …`, where a project provisions one per worktree. If it is missing, mint it: `uv venv .venv && VIRTUAL_ENV=.venv uv pip install -e .` (plus any workspace sub-packages `-e packages\u002F...`).\n> - **Verifying a library-DATA change is the dangerous case.** For a code change the session tripwire (`tests\u002Fconftest.py`) refuses the run, so the trap is loud. For `SKILL.md` \u002F trait \u002F role `config.yaml` there is no tripwire: a compose smoke run against the main venv succeeds, exits 0, and validates a tree your change never touched. Validate the worktree file directly, or put the worktree venv on PATH.\n\n## Workflow\n\n1. **Start task** → create worktree:\n   ```\n   ai-hats wt create feat\u002FPROJ-004\n   cd \u003Cworktree-path>\n   ```\n\n   **Claude surface only — enter with `cd`, never the `EnterWorktree` tool.** It\n   builds a rival worktree outside ai-hats (no state, no locks, no venv, wrong\n   branch name), or raises an approval prompt nothing can suppress. The\n   `wt_entry_gate.py` PreToolUse hook denies it and repeats this recipe.\n   No other surface has the tool — skip this paragraph there.\n\n   **Claude surface only — delegate with `ai-hats agent --isolation`, never the\n   Agent tool's `isolation: \"worktree\"`.** A subagent that writes leaves its\n   worktree on disk on a `worktree-agent-\u003Chex>` branch — registered in git,\n   invisible to `ai-hats wt list` (measured). A read-only subagent\n   needs no isolation at all. No other surface has the parameter — skip this\n   paragraph there.\n\n   A **PreToolUse gate** (`hooks\u002Fwt_gate.py`) **hard-denies** a code\u002Fconfig Edit\u002FWrite in\n   the **main checkout** — interactive and headless (the old nudge was ignored).\n   On a deny, move into a worktree and re-apply: `ai-hats wt status` for an\n   active one, else `ai-hats wt create \u003Ctype>\u002F\u003Cname>` from `master`. Don't ask to skip a\n   worktree (making one is one command); ask the supervisor only for a genuine\n   direct-master change. Bypass is supervisor-only (`AI_HATS_WT_GATE_OFF=1`, never\n   agent-set). Docs, non-trigger extensions, and gitignored paths (tracker, `ai-hats.yaml`)\n   are exempt (trigger set: `hooks\u002Fcode_extensions.json`).\n\n   A second gate (`hooks\u002Fwt_git_gate.py`) does the same for **git state**: a\n   command that discards uncommitted work or moves a branch ref is denied where\n   it would act on the main checkout. A leading `cd` and a `git -C` are read\n   first, so the same command aimed at a worktree runs, and the refusal names\n   the recipe. Bypass is supervisor-only (`AI_HATS_WT_GIT_OFF=1`, never\n   agent-set).\n\n2. **Work** — commit freely in the worktree. Main tree is untouched.\n\n3. **Finish** → hand off for review; the merge is review-gated.\n   In an interactive session, the external consent wrapper turns the canonical\n   `rack transition … done` or direct `ai-hats wt merge` command into a\n   supervisor question. The agent never exports an acknowledgement flag and\n   never grants itself consent. The canonical close:\n   ```\n   cd \u003Cproject-dir>\n   rack transition \u003Cid> review    # then STOP — supervisor reviews the diff\n   # after review passed, the reviewer drives the consent-gated edge;\n   # its one authorization also covers the nested worktree merge.\n   rack transition \u003Cid> done\n   ```\n   The supervisor may instead run a direct merge; it is a separate top-level\n   consent operation and therefore gets its own question.\n\n   **The merge happens only on the review→done road.** The review diff is\n   computed against the merge-base with the base branch, so a `--no-ff` merge\n   of the task branch into that base before review empties the diff — merge-base\n   becomes the branch tip.\n\n   - A raw `git merge` of a `task\u002F\u003Cprefix>-\u003Cn>` ref is hard-denied at PreToolUse\n     when the checkout that merge runs in is `master` or `main`. `git -C` and a\n     leading `cd` count. The refusal names `ai-hats wt merge`. Merging one task\n     branch into another is allowed.\n   - `ai-hats wt merge` refuses while the card is before `review`. A card cannot\n     enter `review` when its tip is already a non-first parent of a merge on the\n     base recorded at worktree create (`--no-ff`, the road `wt merge` takes). A\n     branch that never carried a commit still enters review.\n\n   These two do not catch a command that hides the branch name in a variable, a\n   cherry-pick, a fast-forward that already happened outside the guard, or a\n   human merging from their own terminal.\n\n   If `wt merge` refuses with `Refused (drift)`, the base holds commits\n   your branch never took in (another agent's worktree merged, or\n   `origin\u002F\u003Cbase>` received commits). Re-verify your changes against the\n   new base (re-run grep-verify, re-check moved\u002Frenamed paths), then\n   **rebase in the worktree** — `git rebase \u003Cbase>` clears the guard, no\n   flag needed, so `rack transition \u003Cid> done` works again.\n   `--accept-drift` is for the other case: merging a stale baseline you\n   accept knowingly. **Do not** pass `--force` for drift — `--force` only\n   bypasses uncommitted changes; drift has its own override.\n   Neither `--force` nor `--accept-drift` bypasses the session wrapper.\n\n4. **Abandon** → discard:\n   ```\n   cd \u003Cproject-dir>\n   ai-hats wt discard\n   ```\n\n## Pre-merge checklist (long-lived tasks)\n\nFor tasks that span multiple sessions OR multiple review rounds,\nthe base branch (usually `master`) can drift forward while you work\n— other agents' worktrees merge in parallel, or `origin\u002F\u003Cbase>`\nreceives commits. `rack transition \u003Cid> done` will then\nfail with `WorktreeDriftError` and you'll need an ad-hoc recovery.\n\nRebase **before** closing so drift never accumulates past your\nverification window. Do the rebase IN the worktree, but run the close\nfrom the MAIN checkout:\n\n```bash\n# Rebase the task branch in the worktree (git work is fine here):\ncd \u003Cworktree-path>\ngit fetch --all\ngit rebase \u003Cbase-branch>         # usually master\n# resolve any conflicts; re-run the affected tests\n\n# Close from the MAIN checkout — NOT from inside the worktree. A\n# worktree-backed `transition done` issued from inside its own worktree\n# is refused: the merge runs `git worktree remove` on the cwd\n# you are standing in, which would orphan your shell and desync the tracker.\ncd \u003Cproject-dir>\nrack transition \u003Cid> done   # ack-free once the branch is merged; do NOT `git merge` by hand\n```\n\nThe merge itself is review-gated (step 3 above) — never `git merge \u003Ctask-branch>`\nyourself (a manual pre-merge collides with the FSM merge, HYP-023). If the close\nstill reports drift, you skipped the rebase above — do it, then re-run the\ntransition. Only a baseline you knowingly leave stale needs\n`ai-hats wt merge --accept-drift` from the main repo.\n\n**Skip this for short tasks** (\u003C ~2 hours wall-clock, no review\nrounds). Drift typically only matters on multi-session work; for a\n30-minute task the base hasn't moved.\n\nIf you skipped the checklist and hit `WorktreeDriftError` anyway,\nthe recovery is the same rebase — see the drift block in step 3 of\nthe Workflow above.\n\n## Commands\n\n| Command                      | What it does                                            |\n| ---------------------------- | ------------------------------------------------------- |\n| `ai-hats wt create \u003Cbranch>` | Create worktree on new branch                           |\n| `ai-hats wt merge`           | Squash-merge changes back, clean up                     |\n| `ai-hats wt discard`         | Delete worktree and branch                              |\n| `ai-hats wt list`            | Show all worktrees                                      |\n| `ai-hats wt status`          | Show active worktree                                    |\n| `ai-hats wt exec -- \u003Ccmd>`   | Run command in worktree, where you stand (+ PYTHONPATH) |\n| `ai-hats wt env [\u003Cbranch>]`  | Print `export WT=... PYTHONPATH=...` for eval           |\n\n## Teardown runs lifecycle hooks\n\n`ai-hats wt merge` \u002F `wt discard` \u002F `cleanup` run any composed **`wt_out`\nlifecycle hooks** *before* removing the worktree — e.g. the `hunk-review-comments`\nskill drains its review sidecar so notes aren't lost. They are **fail-closed**: if a\nhook fails, the teardown **aborts** and the worktree + branch are preserved (nothing\ngitignored is destroyed). Force past a genuinely broken hook with\n`ai-hats wt … --skip-hooks` only if you accept the loss. (`wt create` likewise runs\n`wt_in` hooks to seed gitignored data — e.g. `.env` — into the fresh worktree.) These\nare *component-declared* hooks, distinct from the FSM merge-locks\u002Fdrift guards; to\nauthor one see `docs\u002Fhow-to-extend.md` → \"Worktree lifecycle hooks\".\n\n## Running Commands in Worktree\n\n**Use `wt exec` instead of manual WT=\u002FPYTHONPATH= boilerplate.** It is an\nenvironment wrapper, not a teleporter: it runs your command **where you stand**\nwhen your cwd is inside the worktree, and at the worktree root otherwise.\n\n**It swaps the import path, not the interpreter**. Measured:\n\n```bash\nai-hats wt exec task\u002Fhats-1 -- python -c 'import sys, ai_hats; print(sys.executable, ai_hats.__file__)'\n#   sys.executable   -> \u003CMAIN checkout>\u002F.venv\u002Fbin\u002Fpython\n#   ai_hats.__file__ -> \u003Cworktree>\u002Fsrc\u002Fai_hats\u002F...     (via PYTHONPATH)\n```\n\nThat is enough for in-process imports and nothing else. Any subprocess that does\nnot inherit `PYTHONPATH`, and any `ai-hats` binary found on `PATH`, sees the MAIN\ncheckout. **So for pytest — and for anything that spawns subprocesses — use the\nworktree's own interpreter**; the cost of not doing so is not a quiet false green\nbut a loud false red, a wall of `Test suite would test the WRONG checkout`\ntripwire errors about a mismatch you did not cause.\n\nA PreToolUse gate (`hooks\u002Fwt_interpreter_gate.py`) nudges — never blocks — when it\ncan prove the interpreter resolves outside the worktree; kill switch\n`AI_HATS_WT_INTERP_OFF=1`.\n\n```bash\n# CORRECT — pytest and anything spawning subprocesses, from inside the worktree:\n.\u002F.venv\u002Fbin\u002Fpython -m pytest tests\u002Ftest_foo.py -xvs\n\n# CORRECT — wt exec for in-process, single-shot commands:\nai-hats wt exec -- ruff check src\u002F\nai-hats wt exec -- python -c 'import ai_hats; print(ai_hats.__file__)'\n\n# WRONG — hand-rolled paths, and one dead permission grant per worktree:\nWT=\u002Fvar\u002Ffolders\u002F...\u002Fai-hats-wt-...\nPYTHONPATH=$WT\u002Fsrc python -m pytest tests\u002Ftest_foo.py -xvs\n```\n\n**Subprojects.** A worktree may hold a subproject with its own `pyproject.toml`\nand venv. `cd` into it and carry on, or name it with `-C` from outside — never\n`cd` to an absolute worktree path:\n\n```bash\ncd packages\u002Fai-hats-wt && ..\u002F..\u002F.venv\u002Fbin\u002Fpython -m pytest    # from inside the worktree\nai-hats wt exec task\u002Fhats-1 -C packages\u002Fai-hats-wt -- ruff check .  # from the main checkout\n```\n\nReaching a subproject's *tests* from the main checkout means standing in the\nworktree first — `-C` moves the cwd, not the interpreter.\n\nPYTHONPATH follows the project that **owns** the directory you run in: the\nnearest ancestor with a `pyproject.toml`, bounded by the worktree root. So a\nsubproject gets its own `src`, and a plain subdirectory keeps the worktree-root\nworkspace.\n\nPass `--` before any command that has its own `-C` (e.g. `make -C`).\n\n**Reaching another worktree.** A leading token naming an active branch is a\nselector and always beats cwd, so this works from inside a *different* worktree\ntoo. Without a selector the worktree comes from cwd, else the sole\nactive one; with several active and no selector, `wt exec` refuses and lists them.\n\nFor interactive shell work (rare) — bare, or named to reach another worktree:\n\n```bash\neval \"$(ai-hats wt env)\"\neval \"$(ai-hats wt env task\u002Fhats-1)\"\ncd $WT\n```\n\n## When to Use\n\nThe cost (a separate working copy) is justified by **parallelism, risky-discard,\nor sub-agent isolation** — not by every edit. Skip it for read-only exploration\nor a trivial single-file fix on a throwaway branch. The git operations *inside*\nthe worktree (rebase, conflict resolution, commit conventions) are\n**git-mastery**'s remit; this skill owns the worktree's create → merge → discard\nlifecycle.\n\n## Conventions\n\n- Branch naming: `type\u002FTICKET-ID` (e.g., `feat\u002FPROJ-004`, `fix\u002FPROJ-012`)\n- One active worktree at a time (per project)\n- Always `cd` back to project dir before merge\u002Fdiscard\n- Commit your work in the worktree before merging\n\n## Anti-Patterns\n\n- Working directly on main branch for non-trivial changes — use a worktree\n- Forgetting to `cd` back to project dir before merge\u002Fdiscard — commands fail silently\n- Multiple active worktrees without tracking — leads to forgotten branches\n- Running `ai-hats wt create` \u002F `wt merge` \u002F `wt discard` \u002F `rack transition \u003Cid> done|failed|cancelled` from inside a linked worktree — all blocked. The teardown commands run `git worktree remove` on the very cwd you are standing in, orphaning your shell so every later `ai-hats` mis-resolves the tracker. Always `cd` back to the main repo first; use `ai-hats wt exec` \u002F `ai-hats wt env` to act on a worktree without leaving it.\n- Mixing manual `wt create` with `rack transition \u003Cid> execute` from the main repo — if you created a worktree manually and want the task to use it, `cd` into the worktree first, then transition. Otherwise the transition errors out with a clear remediation message.\n- Invoking `ai-hats wt create` (or `rack transition \u003CID> execute`) while the main repo's HEAD is not on the worktree merge target — blocked with a \"Refused: … not the worktree merge target\" error. The worktree inherits its merge target from the current branch, so creating from the wrong branch causes `wt merge` to silently land on it. The target is `master`\u002F`main` by default, or a configured `worktree.merge_target` (see the fork-workflow note below). Recovery: the error names the branch — `git checkout \u003Cthat branch>` in the main repo, then retry.\n- **Working without committing inside a worktree** — uncommitted work in a worktree is NOT protected. The worktree is a filesystem directory that parallel sessions, cleanup hooks, or `git worktree remove --force` can destroy without warning, and there is **no recovery** for uncommitted changes. Commit at every meaningful checkpoint (every passing test run, every completed sub-task). If a step could be reverted with `git checkout HEAD -- .`, you've waited too long to commit.\n- **Finishing the worktree cycle with raw git** — running `git merge --no-ff \u003Ctask-branch>`, `git worktree remove`, or a manual `git push` to the base branch instead of `ai-hats wt merge` \u002F `rack transition \u003Cid> done`. The CLI wrappers run the FSM lifecycle hooks — per-branch + base-branch merge-locks, drift-check, stale-lock recovery, state cleanup. Raw git skips every one of them and re-opens the race\u002Fdrift bugs those epics closed; a manual merge *before* FSM-`done` also produces a double-merge conflict that then needs `--force` (HYP-023). **Scope:** this targets the **lifecycle transitions only** (merge-to-base + cleanup + done). Raw git for *inspection* (`git status`\u002F`log`\u002F`diff`, `git worktree list`) and for *in-worktree conflict resolution* during a rebase stays fine.\n\n## Specific base or target branch\n\nFork\u002Fdogfood repos can cut worktrees from one branch and merge them into another\n(base ≠ merge-target) via the `worktree` block in `ai-hats.yaml`. Rarely needed;\nfull contract in `docs\u002Fhow-to-configure.md`, section \"The `worktree` block\"\n— for a project whose dev trunk is not its upstream default branch.\n\n## If You End Up With a Stray Worktree\n\n```\ngit worktree list                 # audit\ngit worktree remove \u003Cpath>        # remove a stray linked worktree\ngit worktree prune                # clean stale metadata\nrm \u003Cai_hats_dir>\u002Fsessions\u002Fworktree.json           # if ai-hats state is stale\n```\n\nRule of thumb: one task, one worktree, one `\u003Cai_hats_dir>\u002Fsessions\u002Fworktree.json` (in the main repo).\n\n## Shipped on Master (Retrospective Close)\n\nWork shipped on the base out-of-band? From `brainstorm`\u002F`plan`, fast-close with a\nforced terminal transition: `rack transition \u003Cid> --state done --force --reason \"…\"`.\nFrom `execute`\u002F`document`\u002F`review`: `rack transition \u003Cid> done` finalizes an\nalready-merged branch even if the worktree\u002Fstate is gone.\n",{"name":5,"ai_hats":49,"license":15,"description":7},{"type":50,"schema_version":51},"skill",1,"master","f922a7f627276366873d546942d9ad899a86f71a","packages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats","https:\u002F\u002Fgithub.com\u002Fmuratovv","2026-11-05 20:59:10",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add muratovv\u002Fai-hats --skill worktree-isolation",{"tool":64,"command":65},"bunx","bunx skills add muratovv\u002Fai-hats --skill worktree-isolation",{"tool":67,"command":68},"pnpm","pnpm dlx skills add muratovv\u002Fai-hats --skill worktree-isolation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation\u002FSKILL.md",true,[72,78,84,88,91,95,99,103],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"hooks\u002Fbypass_journal.py","SCRIPT","脚本",35,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation\u002Fhooks\u002Fbypass_journal.py",{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"hooks\u002Fcode_extensions.json","REFERENCE","参考文档",985,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation\u002Fhooks\u002Fcode_extensions.json",{"path":85,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":86,"sourceHtmlUrl":87},"hooks\u002Fshell_walk.py",31,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation\u002Fhooks\u002Fshell_walk.py",{"path":89,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":76,"sourceHtmlUrl":90},"hooks\u002Ftest_runners.json","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation\u002Fhooks\u002Ftest_runners.json",{"path":92,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":93,"sourceHtmlUrl":94},"hooks\u002Fwt_entry_gate.py",3707,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation\u002Fhooks\u002Fwt_entry_gate.py",{"path":96,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":97,"sourceHtmlUrl":98},"hooks\u002Fwt_gate.py",9083,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation\u002Fhooks\u002Fwt_gate.py",{"path":100,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":101,"sourceHtmlUrl":102},"hooks\u002Fwt_git_gate.py",10577,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation\u002Fhooks\u002Fwt_git_gate.py",{"path":104,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":105,"sourceHtmlUrl":106},"hooks\u002Fwt_interpreter_gate.py",13551,"https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fworktree-isolation\u002Fhooks\u002Fwt_interpreter_gate.py",[108,134,159,178,202,216],{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":44},"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",[],[115,116,117,118,119,120,121,122,123,124,34,125,126,127,128,129,130,131,132,133],"protocol","Evaluation","tool","tool evaluation protocol","testing","ml","libraries","adoption","methodology","Tools","dependency","up","frameworks","time","project","recommendation","for","bounded","candidate",{"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":140,"publishedAt":44},"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",[],[141,142,143,144,115,145,146,147,148,149,34,150,151,152,153,154,155,156,157,158],"systematic debugging","debugging","systematic","test","monitoring","hypothesis","verify","behavior","fix","evidence","bug","reports","pattern","users","error","with","bug-fix","phase",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":166,"publishedAt":44},"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",[165],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[167,168,169,170,171,148,172,34,173,153,174,175,176,131,177],"template","skill template","validation","compliance","hats","guide","new skill","structural","canonical","which","Existing",{"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":44},"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",[184],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[186,187,188,189,190,191,192,193,194,195,34,196,197,198,199,200,201],"Optimization","skill optimization","components","component","issues","library","audit","refactor","Budget","Rules","periodic","maintenance","token","token budget","role","high",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":208,"publishedAt":44},"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",[],[209,210,211,212,213,214,34,215,131],"gate","fallback","silent fallback gate","python","write","edit","hook",{"skillNo":217,"name":218,"nameZh":6,"description":219,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":220,"categories":221,"keywords":223,"publishedAt":44},"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",[222],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[224,225,226,227,189,228,229,230,195,148,34,231,232,129,233,234,235,236,237,238],"framework","retro","retro to framework","change","retrospective","projects","convert","incident","across","problem","about","more","skill update","single","generic"]