[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PVC299S58482QJRWJ24JZ7":3,"skill-same:01M6PVC299S58482QJRWJ24JZ7":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":52,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6PVC299S58482QJRWJ24JZ7","hatrack",null,"Backlog lifecycle on the `rack` CLI — create \u002F ls \u002F context \u002F transition \u002F plan-extract, with field edits via `--set` and hypotheses\u002Fproposals on the `rack hyp` \u002F `rack proposal` groups. Use for any task lifecycle transition, backlog read, field edit, document, link, hypothesis, or proposal.","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\u002Fhatrack\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"task","transition","for","pip","ls","with","proposal","via","backlog","cli","document","use","proposals","hats","plan","lifecycle","SET","help","create","2026-11-10 10:12:30",false,"---\nname: hatrack\ndescription: >-\n  Backlog lifecycle on the `rack` CLI — create \u002F ls \u002F context \u002F transition\n  \u002F plan-extract, with field edits via `--set` and hypotheses\u002Fproposals on\n  the `rack hyp` \u002F `rack proposal` groups. Use for any task lifecycle\n  transition, backlog read, field edit, document, link, hypothesis, or\n  proposal.\nai_hats:\n  schema_version: 1\n  type: skill\n  # ADR-0016: this skill drives the ai-hats-rack `rack` CLI for the whole backlog\n  # surface — lifecycle, fields, documents, links, hypotheses, proposals. One\n  # DECLARED CLI need; verified-and-warned at compose time.\n  requires:\n    cli:\n      - name: ai-hats-rack\n        check: \"rack --help\"\n        hint: \"pip install ai-hats-rack\"\n    mcp: []\nlicense: MIT\n---\n\n# Hatrack\n\nDrive the **whole backlog** through the **rack** CLI (`ai-hats-rack`), the\nminimal backlog kernel — lifecycle, field edits, documents, links, hypotheses,\nand proposals. Same FSM, same `task.yaml` on disk, same per-task lock.\n\nThis skill has two sections: **Backlog operations** (the `rack` CLI surface —\nhow to read and write the backlog) and **Task lifecycle** (when to move a card\nand what to do at each edge). Lifecycle is where transition reliability lives —\nread it before advancing any card.\n\n## When to Use\n\nThis is the **rack** backlog manager, delivered by `trait-agent`. The boundary\nagainst its two siblings: **backlog-create** covers `rack create` alone, for\nroles that may file a card but never drive a lifecycle; **rack-advanced** covers\nauthoring a new backlog and cross-project roots. Everything else — lifecycle,\nfields, documents, links, hypotheses, proposals — is here.\n\n## Backlog operations — the `rack` CLI\n\nFive top-level verbs, each with `--json` (JSON-first):\n\n```bash\nrack create \"Title\" --id PROJ-042 --parent PROJ-014 --depends PROJ-041 --tag dx\nrack ls                       # backlog scan: --tag\u002F--state\u002F--parent match exactly; --grep last\nrack ls --grep id:PROJ-04     # --grep is substring over title+description; 'field:' narrows it\nrack ls --backlog hyp         # scan another backlog (repeatable; --all-backlogs for all)\nrack ls --backlog hyp --projects all  # sweep across projects (rack root add\u002Fls\u002Frm; --root \u003Cpath>)\nrack ls PROJ-042 --deep 1     # graph walk from a card\nrack context PROJ-042         # THE read package: card + links + document paths\nrack context PROJ-042 PROJ-043  # batch: ≥2 ids in one process → {\"contexts\":{id:…}}, skip-and-continue\nrack transition PROJ-042 execute      # sugar for --state execute\nrack plan-extract PROJ-042    # child cards from plan.md Subtasks\u002FSteps sections\n```\n\n`transition` is the one mutating verb: an ordered composite of ops run in argv\norder under ONE lock with a single persist (any abort rolls the whole sequence\nback). Compose ops on one line:\n\n```bash\nrack transition PROJ-042 --state execute --log \"impl started\" --link related:PROJ-040\nrack transition PROJ-042 --attach \u002Ftmp\u002Fdesign.md:design.md   # copy a file in as a document\nrack transition PROJ-042 --freeze design.md                  # pin {name,digest}\n```\n\nCommand flags: `--force` (needs `--reason`) relaxes the FSM arrow only;\n`--resolution` \u002F `--final-state` stamp terminal metadata; `--ack-frozen` is the\ntiered hatch for `--rm` \u002F `--freeze` on a pinned document.\n\n**Documents are fs-as-truth:** the only way to write one is to put a file into\n`tasks\u002F\u003CID>\u002F`; `rack context` live-scans and digests on the fly (no `doc put`).\nRead documents by the path `context` prints — never inline the body blind.\n\n**Work Policy.** A card's `work_policy` field is the work policy for the task and\nits children; `rack context \u003Cchild>` delivers every ancestor's `work_policy` up\nthe parent chain into the child's read (parent-context; structured\nfield). Set it with `rack create --work-policy \u003Ctext>` or update\nan existing card with `rack transition \u003Cid> --set work_policy=\u003Ctext>`. Only that\nfield travels — put per-stage child policy there, not in the whole card.\n\n### Field edits — `transition --set` \u002F `--append`\n\nThere is no `update` verb: field edits ride the one mutating `transition` as\n`--set`\u002F`--append` ops, schema-validated on the same lock as a state move (a bad\nchoice\u002Ftype is a typed refusal). `--set` replaces a field, `--append` adds to a\nlist one; a payload is JSON when it parses and plain text otherwise:\n\n```bash\nrack transition PROJ-042 --set priority=high --set reviewer=@lead\nrack transition PROJ-042 --set title=\"Sharper title\" --set role=implementer\nrack transition PROJ-042 --set description=\"$(cat body.md)\"   # verbatim body\nrack transition PROJ-042 --append tags=dx                     # add one tag\nrack transition PROJ-042 --append 'tags=[\"dx\",\"rack\"]'        # add each entry\nrack transition PROJ-042 --set 'tags=[\"dx\"]'                  # replace the list\nrack transition PROJ-042 --unlink parent_task:PROJ-010 --link parent_task:PROJ-014   # re-parent\n```\n\nA JSON array adds its **entries**, never itself — a list nested inside a list\nfield is not a card any reader can load.\n\nState and field ops compose in one call — `rack transition PROJ-042 --state\nexecute --set role=implementer` is one lock, one persist.\n\n### Fast-close — forced terminal transition\n\nThe classic `close` (fast-close from brainstorm\u002Fplan) is a forced edge to a\nterminal state; `--force` needs a `--reason` (journaled):\n\n```bash\nrack transition PROJ-042 --state done --force --reason \"shipped on master\"\n```\n\n`--force` relaxes the FSM **arrow**, never the question. Nothing added to\nthe command line turns it off. `plan → execute` and every road into `done`\nwait for the supervisor, the forced close included. Run the transition bare.\nIf the tool stops, its message is the whole instruction: say so and stop. A\nsentence in the chat is not a grant. The supervisor opens the move by typing\n`consent \u003Ctype> \u003Cminutes>`. An open grant window pays for later moves of that\ntype in silence.\n\n### Hypotheses & proposals — the `rack hyp` \u002F `rack proposal` groups\n\nMigrated HYP\u002FPROP catalogs mount as sibling backlogs; `rack` grows a group per\ncatalog (visible in `rack --help` once mounted). Ids route by prefix, so reads\ngo through the same `rack context \u003CID>` \u002F `rack ls \u003CID>`:\n\n```bash\nrack hyp create \"Agents batch transitions\" --hypothesis \"…\"\nrack hyp append-verdict HYP-009 --verdict refuted --evidence \"…\" --recommendation keep\nrack transition HYP-009 refute        # named edge (quorum-gated); or --state refuted\nrack hyp autoclose --dry-run          # close HYPs past the refuted-verdict quorum\n\nrack proposal create \"…\" --category rule --target rule_x --description \"…\" --rationale \"…\"\nrack proposal vote PROP-025 --reasoning \"…\"\nrack transition PROP-025 accept       # named edge; or --state accepted\n```\n\n`rack hyp --help` \u002F `rack proposal --help` carry each group's verbs and field\ncontracts. Cross-backlog links (`related_hypotheses`, `source_task`) mirror\nautomatically; the derived read-views refresh on every write — no manual `sync`.\n\n## Task lifecycle — edges, policy, cadence\n\n### Legal transitions (this backlog's FSM)\n\n`rack transition \u003CID> \u003Cstate>` walks ONE edge under guard; an illegal edge is\nrefused with the legal set. The complete edge set for this backlog — rendered\nlive from the FSM, so it is always authoritative:\n\n{{backlog_fsm_edges}}\n\n`done` and `cancelled` are terminal (`done` = completed; `cancelled` =\nadministratively closed). A parenthesised name is that edge's own name, typeable\nin place of the target state (`rack transition \u003CID> reclaim`); every named edge\nabove is legal but rare — do not walk one by reflex.\n\n### Per-edge policy — trigger → action\n\nFor each edge you drive: the trigger that fires it and what to do. The\ntransition is a live signal to the supervisor, so move the card **as each phase\ncompletes** — never batch every transition at the end. Finished work left in\n`execute` reads as \"still working\".\n\n| Edge                                         | Trigger                                            | Action (and the skill that owns it)                                                                                                                                         |\n| -------------------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `brainstorm → plan`                          | requirements clear enough to plan                  | **plan-gate** fills every required `plan.md` section, then transition                                                                                                       |\n| `plan → execute`                             | plan approved                                      | re-validate the premise first (below); rack auto-creates the `task\u002F\u003Cid>` worktree — `cd` into it (**worktree-isolation**)                                                   |\n| `execute → document`                         | code + tests done **and committed**                | `git status` clean; log a one-line summary; then advance — do not stall in `execute`                                                                                        |\n| `document → review`                          | work finished — this **signals \"awaiting review\"** | attach `summary.md` (**task-summary**), then advance to `review` and **WAIT** — do **not** self-advance to `done`                                                           |\n| `review → done`                              | the card `reviewer` approved with no rework asked  | the reviewer drives this edge, not you; it **auto-merges the worktree** (subscriber) — no `wt merge`                                                                        |\n| `review → execute` (rework)                  | review returned **WITH comments** to address       | transition `execute` (fires **no** merge — the worktree survives for the rework), address the comments, then `document` → `review` again; this is the loop, not a `--force` |\n| `brainstorm\u002Fplan\u002Fexecute\u002Fdocument → blocked` | an external dependency stalls progress             | log the blocker (**request-supervisor**), transition `blocked`; return to the prior state when unblocked — NB: `review` has no `blocked` edge (see the table above)         |\n| `execute\u002Freview → failed`                    | the task cannot be completed                       | **self-retrospective** (mandatory — why it failed), then `failed → brainstorm` to re-plan                                                                                   |\n| any non-terminal `→ cancelled`               | won't-fix \u002F duplicate \u002F obsolete                   | requires `--resolution \"\u003Cwhy>\"` (the audit trail); the worktree is discarded — work is not preserved                                                                        |\n\n**Before `plan → execute`, re-validate the premise:** scan the card for a\nretracted\u002Fsuperseded driver since the plan was authored; if the justification is\nstale, bounce to `brainstorm` instead of building on a dead premise\n(`rule_backlog_discipline §5`).\n\n### Completion\n\n- The whole backlog — lifecycle, fields, documents, links, hyp, proposal —\n  went through `rack`; the card's `work_log` reflects the work (log as you go,\n  not only at the end).\n- On finishing execute work, advance through `document` to **`review`** and\n  stop — the reviewer approves `review → done` first (see the policy table).\n- **Validation scenario (RED → GREEN).** RED: asked to advance `PROJ-042` from\n  plan to execute, the agent reaches for `ai-hats task transition` (classic\n  muscle memory), bypassing the rack dispatcher, journal, and worktree effects.\n  GREEN: it runs `rack transition PROJ-042 execute`, and keeps field edits on\n  `--set` and `hyp` \u002F `proposal` on the `rack hyp` \u002F `rack proposal` groups.\n\n## Anti-Patterns\n\n- Leaving finished work in `execute`, or advancing to `review` then self-jumping\n  to `done` — advance per phase, enter `review` to signal readiness, and **wait**.\n- Driving lifecycle through `ai-hats task transition` in a rack session — the\n  rack dispatcher\u002Fjournal\u002Fworktree path is what's being dogfooded; use `rack`.\n- Reaching for a `rack update` verb — there is none; field edits are\n  `rack transition \u003CID> --set \u003Cfield>=\u003Cvalue>` (replace) \u002F `--append` (add to a list).\n- Reaching back to the classic tracker CLI for fields \u002F hyp \u002F proposal — the\n  whole surface is on `rack` now (`--set`, `rack hyp`, `rack proposal`).\n- Inlining a document's body from `context` output — read it by the printed path.\n- `--force`-ing an edge the FSM refuses (e.g. `document → done` skipping `review`,\n  or `review → plan`) instead of taking the legal path or escalating.\n","# Hatrack\n\nDrive the **whole backlog** through the **rack** CLI (`ai-hats-rack`), the\nminimal backlog kernel — lifecycle, field edits, documents, links, hypotheses,\nand proposals. Same FSM, same `task.yaml` on disk, same per-task lock.\n\nThis skill has two sections: **Backlog operations** (the `rack` CLI surface —\nhow to read and write the backlog) and **Task lifecycle** (when to move a card\nand what to do at each edge). Lifecycle is where transition reliability lives —\nread it before advancing any card.\n\n## When to Use\n\nThis is the **rack** backlog manager, delivered by `trait-agent`. The boundary\nagainst its two siblings: **backlog-create** covers `rack create` alone, for\nroles that may file a card but never drive a lifecycle; **rack-advanced** covers\nauthoring a new backlog and cross-project roots. Everything else — lifecycle,\nfields, documents, links, hypotheses, proposals — is here.\n\n## Backlog operations — the `rack` CLI\n\nFive top-level verbs, each with `--json` (JSON-first):\n\n```bash\nrack create \"Title\" --id PROJ-042 --parent PROJ-014 --depends PROJ-041 --tag dx\nrack ls                       # backlog scan: --tag\u002F--state\u002F--parent match exactly; --grep last\nrack ls --grep id:PROJ-04     # --grep is substring over title+description; 'field:' narrows it\nrack ls --backlog hyp         # scan another backlog (repeatable; --all-backlogs for all)\nrack ls --backlog hyp --projects all  # sweep across projects (rack root add\u002Fls\u002Frm; --root \u003Cpath>)\nrack ls PROJ-042 --deep 1     # graph walk from a card\nrack context PROJ-042         # THE read package: card + links + document paths\nrack context PROJ-042 PROJ-043  # batch: ≥2 ids in one process → {\"contexts\":{id:…}}, skip-and-continue\nrack transition PROJ-042 execute      # sugar for --state execute\nrack plan-extract PROJ-042    # child cards from plan.md Subtasks\u002FSteps sections\n```\n\n`transition` is the one mutating verb: an ordered composite of ops run in argv\norder under ONE lock with a single persist (any abort rolls the whole sequence\nback). Compose ops on one line:\n\n```bash\nrack transition PROJ-042 --state execute --log \"impl started\" --link related:PROJ-040\nrack transition PROJ-042 --attach \u002Ftmp\u002Fdesign.md:design.md   # copy a file in as a document\nrack transition PROJ-042 --freeze design.md                  # pin {name,digest}\n```\n\nCommand flags: `--force` (needs `--reason`) relaxes the FSM arrow only;\n`--resolution` \u002F `--final-state` stamp terminal metadata; `--ack-frozen` is the\ntiered hatch for `--rm` \u002F `--freeze` on a pinned document.\n\n**Documents are fs-as-truth:** the only way to write one is to put a file into\n`tasks\u002F\u003CID>\u002F`; `rack context` live-scans and digests on the fly (no `doc put`).\nRead documents by the path `context` prints — never inline the body blind.\n\n**Work Policy.** A card's `work_policy` field is the work policy for the task and\nits children; `rack context \u003Cchild>` delivers every ancestor's `work_policy` up\nthe parent chain into the child's read (parent-context; structured\nfield). Set it with `rack create --work-policy \u003Ctext>` or update\nan existing card with `rack transition \u003Cid> --set work_policy=\u003Ctext>`. Only that\nfield travels — put per-stage child policy there, not in the whole card.\n\n### Field edits — `transition --set` \u002F `--append`\n\nThere is no `update` verb: field edits ride the one mutating `transition` as\n`--set`\u002F`--append` ops, schema-validated on the same lock as a state move (a bad\nchoice\u002Ftype is a typed refusal). `--set` replaces a field, `--append` adds to a\nlist one; a payload is JSON when it parses and plain text otherwise:\n\n```bash\nrack transition PROJ-042 --set priority=high --set reviewer=@lead\nrack transition PROJ-042 --set title=\"Sharper title\" --set role=implementer\nrack transition PROJ-042 --set description=\"$(cat body.md)\"   # verbatim body\nrack transition PROJ-042 --append tags=dx                     # add one tag\nrack transition PROJ-042 --append 'tags=[\"dx\",\"rack\"]'        # add each entry\nrack transition PROJ-042 --set 'tags=[\"dx\"]'                  # replace the list\nrack transition PROJ-042 --unlink parent_task:PROJ-010 --link parent_task:PROJ-014   # re-parent\n```\n\nA JSON array adds its **entries**, never itself — a list nested inside a list\nfield is not a card any reader can load.\n\nState and field ops compose in one call — `rack transition PROJ-042 --state\nexecute --set role=implementer` is one lock, one persist.\n\n### Fast-close — forced terminal transition\n\nThe classic `close` (fast-close from brainstorm\u002Fplan) is a forced edge to a\nterminal state; `--force` needs a `--reason` (journaled):\n\n```bash\nrack transition PROJ-042 --state done --force --reason \"shipped on master\"\n```\n\n`--force` relaxes the FSM **arrow**, never the question. Nothing added to\nthe command line turns it off. `plan → execute` and every road into `done`\nwait for the supervisor, the forced close included. Run the transition bare.\nIf the tool stops, its message is the whole instruction: say so and stop. A\nsentence in the chat is not a grant. The supervisor opens the move by typing\n`consent \u003Ctype> \u003Cminutes>`. An open grant window pays for later moves of that\ntype in silence.\n\n### Hypotheses & proposals — the `rack hyp` \u002F `rack proposal` groups\n\nMigrated HYP\u002FPROP catalogs mount as sibling backlogs; `rack` grows a group per\ncatalog (visible in `rack --help` once mounted). Ids route by prefix, so reads\ngo through the same `rack context \u003CID>` \u002F `rack ls \u003CID>`:\n\n```bash\nrack hyp create \"Agents batch transitions\" --hypothesis \"…\"\nrack hyp append-verdict HYP-009 --verdict refuted --evidence \"…\" --recommendation keep\nrack transition HYP-009 refute        # named edge (quorum-gated); or --state refuted\nrack hyp autoclose --dry-run          # close HYPs past the refuted-verdict quorum\n\nrack proposal create \"…\" --category rule --target rule_x --description \"…\" --rationale \"…\"\nrack proposal vote PROP-025 --reasoning \"…\"\nrack transition PROP-025 accept       # named edge; or --state accepted\n```\n\n`rack hyp --help` \u002F `rack proposal --help` carry each group's verbs and field\ncontracts. Cross-backlog links (`related_hypotheses`, `source_task`) mirror\nautomatically; the derived read-views refresh on every write — no manual `sync`.\n\n## Task lifecycle — edges, policy, cadence\n\n### Legal transitions (this backlog's FSM)\n\n`rack transition \u003CID> \u003Cstate>` walks ONE edge under guard; an illegal edge is\nrefused with the legal set. The complete edge set for this backlog — rendered\nlive from the FSM, so it is always authoritative:\n\n{{backlog_fsm_edges}}\n\n`done` and `cancelled` are terminal (`done` = completed; `cancelled` =\nadministratively closed). A parenthesised name is that edge's own name, typeable\nin place of the target state (`rack transition \u003CID> reclaim`); every named edge\nabove is legal but rare — do not walk one by reflex.\n\n### Per-edge policy — trigger → action\n\nFor each edge you drive: the trigger that fires it and what to do. The\ntransition is a live signal to the supervisor, so move the card **as each phase\ncompletes** — never batch every transition at the end. Finished work left in\n`execute` reads as \"still working\".\n\n| Edge                                         | Trigger                                            | Action (and the skill that owns it)                                                                                                                                         |\n| -------------------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `brainstorm → plan`                          | requirements clear enough to plan                  | **plan-gate** fills every required `plan.md` section, then transition                                                                                                       |\n| `plan → execute`                             | plan approved                                      | re-validate the premise first (below); rack auto-creates the `task\u002F\u003Cid>` worktree — `cd` into it (**worktree-isolation**)                                                   |\n| `execute → document`                         | code + tests done **and committed**                | `git status` clean; log a one-line summary; then advance — do not stall in `execute`                                                                                        |\n| `document → review`                          | work finished — this **signals \"awaiting review\"** | attach `summary.md` (**task-summary**), then advance to `review` and **WAIT** — do **not** self-advance to `done`                                                           |\n| `review → done`                              | the card `reviewer` approved with no rework asked  | the reviewer drives this edge, not you; it **auto-merges the worktree** (subscriber) — no `wt merge`                                                                        |\n| `review → execute` (rework)                  | review returned **WITH comments** to address       | transition `execute` (fires **no** merge — the worktree survives for the rework), address the comments, then `document` → `review` again; this is the loop, not a `--force` |\n| `brainstorm\u002Fplan\u002Fexecute\u002Fdocument → blocked` | an external dependency stalls progress             | log the blocker (**request-supervisor**), transition `blocked`; return to the prior state when unblocked — NB: `review` has no `blocked` edge (see the table above)         |\n| `execute\u002Freview → failed`                    | the task cannot be completed                       | **self-retrospective** (mandatory — why it failed), then `failed → brainstorm` to re-plan                                                                                   |\n| any non-terminal `→ cancelled`               | won't-fix \u002F duplicate \u002F obsolete                   | requires `--resolution \"\u003Cwhy>\"` (the audit trail); the worktree is discarded — work is not preserved                                                                        |\n\n**Before `plan → execute`, re-validate the premise:** scan the card for a\nretracted\u002Fsuperseded driver since the plan was authored; if the justification is\nstale, bounce to `brainstorm` instead of building on a dead premise\n(`rule_backlog_discipline §5`).\n\n### Completion\n\n- The whole backlog — lifecycle, fields, documents, links, hyp, proposal —\n  went through `rack`; the card's `work_log` reflects the work (log as you go,\n  not only at the end).\n- On finishing execute work, advance through `document` to **`review`** and\n  stop — the reviewer approves `review → done` first (see the policy table).\n- **Validation scenario (RED → GREEN).** RED: asked to advance `PROJ-042` from\n  plan to execute, the agent reaches for `ai-hats task transition` (classic\n  muscle memory), bypassing the rack dispatcher, journal, and worktree effects.\n  GREEN: it runs `rack transition PROJ-042 execute`, and keeps field edits on\n  `--set` and `hyp` \u002F `proposal` on the `rack hyp` \u002F `rack proposal` groups.\n\n## Anti-Patterns\n\n- Leaving finished work in `execute`, or advancing to `review` then self-jumping\n  to `done` — advance per phase, enter `review` to signal readiness, and **wait**.\n- Driving lifecycle through `ai-hats task transition` in a rack session — the\n  rack dispatcher\u002Fjournal\u002Fworktree path is what's being dogfooded; use `rack`.\n- Reaching for a `rack update` verb — there is none; field edits are\n  `rack transition \u003CID> --set \u003Cfield>=\u003Cvalue>` (replace) \u002F `--append` (add to a list).\n- Reaching back to the classic tracker CLI for fields \u002F hyp \u002F proposal — the\n  whole surface is on `rack` now (`--set`, `rack hyp`, `rack proposal`).\n- Inlining a document's body from `context` output — read it by the printed path.\n- `--force`-ing an edge the FSM refuses (e.g. `document → done` skipping `review`,\n  or `review → plan`) instead of taking the legal path or escalating.\n",{"name":5,"ai_hats":43,"license":15,"description":7},{"type":44,"requires":45,"schema_version":52},"skill",{"cli":46,"mcp":51},[47],{"hint":48,"name":49,"check":50},"pip install ai-hats-rack","ai-hats-rack","rack --help",[],1,"master","f922a7f627276366873d546942d9ad899a86f71a","packages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fhatrack","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats","https:\u002F\u002Fgithub.com\u002Fmuratovv","2026-11-05 20:59:10",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add muratovv\u002Fai-hats --skill hatrack",{"tool":65,"command":66},"bunx","bunx skills add muratovv\u002Fai-hats --skill hatrack",{"tool":68,"command":69},"pnpm","pnpm dlx skills add muratovv\u002Fai-hats --skill hatrack","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Fhatrack\u002FSKILL.md",true,[],[74,99,123,145,169,183],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":38},"01M6PVFB1SM738R2SRSRSF7CY6","tool-evaluation-protocol","Time-bounded protocol for evaluating new tools, libraries, or methodologies before adoption. Use when evaluating a candidate dependency for the project, researching a methodology (e.g. ML\u002FLLM frameworks, testing approaches), or following up on a hype-driven recommendation.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Ftool-evaluation-protocol\u002FSKILL.md",[],[81,82,83,84,85,86,87,88,89,90,30,91,92,93,94,95,96,21,97,98],"protocol","Evaluation","tool","tool evaluation protocol","testing","ml","libraries","adoption","methodology","Tools","dependency","up","frameworks","time","project","recommendation","bounded","candidate",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":38},"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",[],[106,107,108,109,81,110,111,112,113,114,30,115,116,117,118,119,120,24,121,122],"systematic debugging","debugging","systematic","test","monitoring","hypothesis","verify","behavior","fix","evidence","bug","reports","pattern","users","error","bug-fix","phase",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":134,"publishedAt":38},"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",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[135,136,137,138,32,113,139,30,140,118,141,142,143,21,144],"template","skill template","validation","compliance","guide","new skill","structural","canonical","which","Existing",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":38},"01M6PVF06SCV28QARM5MQPANC9","skill-optimization","Audit and refactor library components to eliminate redundancy and staleness. Use during periodic library maintenance, after adding multiple new skills or rules, when a role's token budget is too high, or after retrospectives identify component issues.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fskill-optimization\u002FSKILL.md",[151],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},[153,154,155,156,157,158,159,160,161,162,30,163,164,165,166,167,168],"Optimization","skill optimization","components","component","issues","library","audit","refactor","Budget","Rules","periodic","maintenance","token","token budget","role","high",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":38},"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",[],[176,177,178,179,180,181,30,182,21],"gate","fallback","silent fallback gate","python","write","edit","hook",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":190,"publishedAt":38},"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",[189],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},[191,192,193,194,156,195,196,197,162,113,30,198,199,95,200,201,202,203,204,205],"framework","retro","retro to framework","change","retrospective","projects","convert","incident","across","problem","about","more","skill update","single","generic"]