[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71F2BP2MZNCTNNPDFMME5M8":3,"skill-same:01M71F2BP2MZNCTNNPDFMME5M8":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71F2BP2MZNCTNNPDFMME5M8","worktree-flow",null,"Isolated git worktree workflow for ai-specs change work. Create a dedicated worktree under .worktrees\u002F for any change that writes files, keep pure exploration outside a worktree, and clean up merged worktrees safely after topologies via the CLI-owned [project].repo_topology and topology-aware gate scope via recipes.worktree-flow.config.gate_scope.","parada1104\u002Fai-specs-cli","parada1104","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F57575053?v=4","01M71EZZV71KAFZKJ47FQ99ZVS","01M71EZZW7JJBY2VAWA5HRD944",0,"MIT","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Fcatalog\u002Frecipes\u002Fworktree-flow\u002Fskills\u002Fworktree-flow\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"worktree flow","worktree","flow","branch","scope","project","exploration","clean","worktrees","files","up","write","cli","work","git worktree","code","create","config","change","workflow","2026-11-10 10:12:30",false,"---\nname: worktree-flow\ndescription: >\n  Isolated git worktree workflow for ai-specs change work. Create a dedicated\n  worktree under .worktrees\u002F for any change that writes files, keep pure\n  exploration outside a worktree, and clean up merged worktrees safely after\n  topologies via the CLI-owned [project].repo_topology and topology-aware\n  gate scope via recipes.worktree-flow.config.gate_scope.\nlicense: MIT\nmetadata:\n  author: ai-specs\n  version: \"1.2\"\n  scope: runtime\n  auto_invoke:\n    - \"Starting a change that will write files or modify code\"\n    - \"Cleaning up worktrees after a branch is merged\"\n---\n\n# Worktree Flow\n\nRun file-writing change work in an isolated git worktree under `.worktrees\u002F`,\nand remove worktrees safely once their branch is merged. Pure exploration that\nwrites nothing does not need a worktree.\n\n## When to create a worktree\n\n| Situation | Worktree? |\n|---|---|\n| Exploration \u002F reading \u002F answering a question (no files written) | No |\n| Implementing a change, writing artifacts, editing code | Yes |\n| Planning or SDD artifact phases that write files | Yes |\n| Any phase that produces committed output | Yes |\n\n## Topology matrix\n\n| Resolved topology | Create | Clean |\n|---|---|---|\n| `standalone` | `git worktree add \u003Cworktrees_dir>\u002F\u003Cslug> -b \u003Cbranch> \u003Cintegration_branch>` | Single-repo `worktree list` + flush (unchanged) |\n| `monorepo-apps` | Same as standalone (naming-only) | Same as standalone |\n| `monorepo-submodules` | `git -C \u003Csubrepo_path> worktree add \u003Cabsolute-super>\u002F\u003Cworktrees_dir>\u002F\u003Csubrepo>-\u003Cslug> -b \u003Cbranch> \u003Cintegration_branch>` | Enumerate each initialized submodule (`git -C` \u002F `submodule foreach`); never superproject `worktree list` alone |\n\nTopology is CLI-owned: `[project].repo_topology = \"auto\"` (default) detects\ninitialized `.gitmodules` entries → `monorepo-submodules`, else `standalone`.\nIt never auto-selects `monorepo-apps`, it resolves even when this recipe is\ndisabled, and the deprecated `recipes.worktree-flow.config.repo_topology` alias\nis read only for one migration window (the project field wins).\n\n## Gate scope and repository ownership\n\n`gate_scope` is separate from `gate_mode` and `repo_topology`. Classification\nrequires effective `repo_topology=monorepo-submodules`; explicit\n`standalone`\u002F`monorepo-apps` never create a topology bypass:\n\n| Value | Protected owner enforced | Runtime behavior |\n|---|---|---|\n| `auto` | Proven superrepo and subrepo | Default topology-derived protection; only canonical superrepo planning is excepted. |\n| `superrepo` | Proven superrepo only | Subrepo writes are outside this selected enforcement scope. |\n| `subrepo` | Proven initialized subrepo only | Superrepo writes are outside this explicit Melón scope. |\n\nBefore any write-capable delegation in a cross-repository layout, identify the\nowning repository and branch, not just the current directory:\n\n```bash\ngit rev-parse --show-toplevel\ngit rev-parse --absolute-git-dir\ngit rev-parse --git-common-dir\ngit branch --show-current\n```\n\nCentral planning artifacts belong to the proven superrepo canonical subtree\n`\u003Csuperrepo>\u002Fopenspec\u002Fchanges\u002F**`; subrepo code remains subject to its own\nprotected branch and the separate `plan-build-flow` authorization. If sync or\ndoctor reports a stale materialized hook without the scope stamp, refresh it\nexplicitly with `rm \u003Chook-path> && ai-specs sync`; customized hook bytes are\nnever silently overwritten. The runtime hook is a defense in depth, not the\nsole guard for delegated or subprocess writes.\n\n## Request context\n\nResolve one ai-specs request context with `util.resolve_request_context` before\nany create or artifact write: `owner_root` (the repository owning code\u002FVCS for\nthe request) is distinct from `planning_root` (the canonical planning tree). A\nsubrepo request owns the submodule but plans under the proven superproject; a\nsuperrepo request owns and plans under the superproject. Missing, ambiguous,\ndetached, or uninitialized topology fails safe — no owner inference beyond the\ntoplevel, no planning-root exception. `\u002Fworktree-new` is generated Markdown\nexecuted by the agent; there is NO executable `\u002Fworktree-new` helper.\n\n## Conventions\n\n- Shared layout: worktrees live under the **superproject**\n  `\u003Cworktrees_dir>\u002F\u003C…>` (default `.worktrees\u002F`). Under submodules the directory\n  is `\u003Csubrepo>-\u003Cslug>`.\n- Branch off the integration branch declared in recipe config\n  (`integration_branch`, default `main`).\n- Branch name and directory slug match so cleanup can map them 1:1.\n- Add `\u003Cworktrees_dir>\u002F` to the superproject `.gitignore`.\n- Before dispatching a write-capable subagent or task, verify **which git\n  repository**, worktree, and branch yourself (`git rev-parse --show-toplevel`,\n  `git branch --show-current`, `git worktree list`). Under\n  `monorepo-submodules`, confirming the toplevel (which submodule \u002F linked wt)\n  is mandatory — not only branch + worktree list. Runtime pre-tool-use hooks\n  may not fire for delegated\u002Fsubprocess tool calls on opencode\u002Fpi\u002Fomp — do not\n  treat the gate as the sole guard for delegated writes.\n- If a structured Edit\u002FWrite\u002FMultiEdit call is blocked or errors for any\n  reason while on a protected branch, that is never grounds to retry the\n  write via bash\u002Fshell (heredoc, `python3 -c`, `cat >`, `tee`, `sed -i`) —\n  using bash to write bypasses the worktree gate entirely.\n  - `gate_mode = always`: create a dedicated worktree\n    (`\u002Fworktree-new`) and write there instead.\n  - `gate_mode = ask`: **ask the user** which destination to use and\n    wait — a dedicated worktree (recommended), a feature branch in the\n    current checkout, or an explicit override to write on the protected\n    branch. Do not pick a destination yourself, and do not re-run with\n    `WORKTREE_GATE_MODE=off` as a self-authorization shortcut.\n  - `gate_mode = off`: the gate does not block; work where the user directs.\n\n## Asking the user (per harness)\n\nWhen `gate_mode = ask` blocks a write, surface the three destinations with\nthe harness's **native user-question mechanism** and stop until the user\nanswers:\n\n| Harness | Mechanism |\n|---|---|\n| pi | `ask_user_question` (structured options) |\n| claude | `AskUserQuestion` (or a direct conversational question) |\n| opencode \u002F cursor \u002F omp | the interactive user prompt \u002F inline question |\n\nThe user's answer decides the destination; never decide for them, and never\ntreat the block as permission to bypass the guard.\n\n## Creating a worktree\n\nPrefer the `\u002Fworktree-new` command.\n\n### standalone \u002F monorepo-apps\n\n```bash\ngit worktree add \u003Cworktrees_dir>\u002F\u003Cslug> -b \u003Cbranch> \u003Cintegration_branch>\n```\n\n### monorepo-submodules (locked contract)\n\nDestination MUST be absolute. Infer or require `\u003Csubrepo>`; validate path-then\nunique name; reject uninitialized (`git submodule update --init \u003Cpath>`).\n`\u003Csubrepo>` selection and the owner\u002Fplanning-root split are validated by\n`util.resolve_request_context` \u002F `util.resolve_subrepo`. A request whose\ncontext is the **superrepo** MUST NOT infer a subrepo: an explicit, validated\n`\u003Csubrepo>` is required, otherwise hard-error **before any `git worktree add`**.\n\n```bash\nsuper_abs=\"$(git -C \"$super_root\" rev-parse --show-toplevel)\"\ngit -C \"$super_abs\u002F\u003Csubrepo_path>\" worktree add \\\n  \"$super_abs\u002F\u003Cworktrees_dir>\u002F\u003Csubrepo>-\u003Cslug>\" \\\n  -b \u003Cbranch> \u003Cintegration_branch>\n```\n\ncwd inference uses `git -C`\u002F`rev-parse --show-toplevel` and, for linked\nworktrees named `\u003Cpath>-\u003Cslug>`, the **longest** matching submodule path\nprefix (see `util.resolve_subrepo`).\n\n## Post-merge cleanup\n\nAfter a branch is merged into the integration branch, reclaim its worktree.\n\n### Leave the worktree first (hard rule)\n\nNever run `git worktree remove` (or the cleanup script) while `$PWD` is inside\nthe worktree being removed — that yields `fatal: Unable to read current working\ndirectory`. Always:\n\n```bash\ncd \u003Cmain-repo-root>\n```\n\n### Script-first (preferred)\n\nPrefer the materialized verified-Go cleanup launcher (or `\u002Fworktree-clean`) over\nad-hoc remove sequences. Run it from the main repository worktree; it owns\npost-merge remote deletion and independently verifies remote absence:\n\n\n```bash\nbash ai-specs\u002Frecipes\u002Fworktree-flow\u002Foverrides\u002Fbin\u002Fworktree-cleanup.sh \\\n  --dir \u003Cworktrees_dir> --base \u003Cintegration_branch>\n```\n\nOptional `--submodule` \u002F `--subrepo` scopes to one module; default = all\ninitialized. Run with `--dry-run` first to preview removals.\n\nThe launcher is conservative by design:\n\n- **Removes** a worktree only when its branch is fully merged into the base —\n  detecting both regular\u002Ffast-forward merges (ancestry) and squash\u002Frebase merges\n  (all of the branch's changes already present in base by patch-id).\n- **Preserves** worktrees with uncommitted changes (reported as `dirty`).\n- **Preserves** worktrees whose branch is not yet merged (`unmerged`).\n- **Never touches** the main worktree or detached-HEAD worktrees.\n- Refuses loudly before every worktree, local-branch, or remote-branch delete\n  when the branch is protected (`main`, `master`, `development`, `staging`,\n  or configured base\u002Fintegration names).\n- Deletes the remote branch only after local cleanup and verifies absence with\n  `git ls-remote --heads`; failure is not reported as success.\n- Under submodules, enumerates per-module lists; uninitialized modules are\n  skipped.\n\n### Manual fallback\n\nOnly if the script is unavailable: from the main repo root, `git worktree\nremove \u003Cpath>`, then `git branch -D \u003Cbranch>` after squash\u002Frebase merges.\nStop without deleting if the worktree is dirty.\n\nThis honors the project rule: never revert or discard changes you did not make.\n\n### Candidate-view store (separate)\n\nThis cleanup covers `.worktrees\u002F` only. Native review candidate views live under\nthe shared git dir (`.git\u002Fgentle-ai\u002Fcandidate-views`) and are controller-owned.\nAfter the merged-worktree pass, load the `worktree-candidate-cleanup` skill to\naudit that store and, only when every eligibility proof holds, reap stale\ncandidate views and their matching `*.owner.json` markers. Never delete candidate\nviews or markers ad hoc.\n","# Worktree Flow\n\nRun file-writing change work in an isolated git worktree under `.worktrees\u002F`,\nand remove worktrees safely once their branch is merged. Pure exploration that\nwrites nothing does not need a worktree.\n\n## When to create a worktree\n\n| Situation | Worktree? |\n|---|---|\n| Exploration \u002F reading \u002F answering a question (no files written) | No |\n| Implementing a change, writing artifacts, editing code | Yes |\n| Planning or SDD artifact phases that write files | Yes |\n| Any phase that produces committed output | Yes |\n\n## Topology matrix\n\n| Resolved topology | Create | Clean |\n|---|---|---|\n| `standalone` | `git worktree add \u003Cworktrees_dir>\u002F\u003Cslug> -b \u003Cbranch> \u003Cintegration_branch>` | Single-repo `worktree list` + flush (unchanged) |\n| `monorepo-apps` | Same as standalone (naming-only) | Same as standalone |\n| `monorepo-submodules` | `git -C \u003Csubrepo_path> worktree add \u003Cabsolute-super>\u002F\u003Cworktrees_dir>\u002F\u003Csubrepo>-\u003Cslug> -b \u003Cbranch> \u003Cintegration_branch>` | Enumerate each initialized submodule (`git -C` \u002F `submodule foreach`); never superproject `worktree list` alone |\n\nTopology is CLI-owned: `[project].repo_topology = \"auto\"` (default) detects\ninitialized `.gitmodules` entries → `monorepo-submodules`, else `standalone`.\nIt never auto-selects `monorepo-apps`, it resolves even when this recipe is\ndisabled, and the deprecated `recipes.worktree-flow.config.repo_topology` alias\nis read only for one migration window (the project field wins).\n\n## Gate scope and repository ownership\n\n`gate_scope` is separate from `gate_mode` and `repo_topology`. Classification\nrequires effective `repo_topology=monorepo-submodules`; explicit\n`standalone`\u002F`monorepo-apps` never create a topology bypass:\n\n| Value | Protected owner enforced | Runtime behavior |\n|---|---|---|\n| `auto` | Proven superrepo and subrepo | Default topology-derived protection; only canonical superrepo planning is excepted. |\n| `superrepo` | Proven superrepo only | Subrepo writes are outside this selected enforcement scope. |\n| `subrepo` | Proven initialized subrepo only | Superrepo writes are outside this explicit Melón scope. |\n\nBefore any write-capable delegation in a cross-repository layout, identify the\nowning repository and branch, not just the current directory:\n\n```bash\ngit rev-parse --show-toplevel\ngit rev-parse --absolute-git-dir\ngit rev-parse --git-common-dir\ngit branch --show-current\n```\n\nCentral planning artifacts belong to the proven superrepo canonical subtree\n`\u003Csuperrepo>\u002Fopenspec\u002Fchanges\u002F**`; subrepo code remains subject to its own\nprotected branch and the separate `plan-build-flow` authorization. If sync or\ndoctor reports a stale materialized hook without the scope stamp, refresh it\nexplicitly with `rm \u003Chook-path> && ai-specs sync`; customized hook bytes are\nnever silently overwritten. The runtime hook is a defense in depth, not the\nsole guard for delegated or subprocess writes.\n\n## Request context\n\nResolve one ai-specs request context with `util.resolve_request_context` before\nany create or artifact write: `owner_root` (the repository owning code\u002FVCS for\nthe request) is distinct from `planning_root` (the canonical planning tree). A\nsubrepo request owns the submodule but plans under the proven superproject; a\nsuperrepo request owns and plans under the superproject. Missing, ambiguous,\ndetached, or uninitialized topology fails safe — no owner inference beyond the\ntoplevel, no planning-root exception. `\u002Fworktree-new` is generated Markdown\nexecuted by the agent; there is NO executable `\u002Fworktree-new` helper.\n\n## Conventions\n\n- Shared layout: worktrees live under the **superproject**\n  `\u003Cworktrees_dir>\u002F\u003C…>` (default `.worktrees\u002F`). Under submodules the directory\n  is `\u003Csubrepo>-\u003Cslug>`.\n- Branch off the integration branch declared in recipe config\n  (`integration_branch`, default `main`).\n- Branch name and directory slug match so cleanup can map them 1:1.\n- Add `\u003Cworktrees_dir>\u002F` to the superproject `.gitignore`.\n- Before dispatching a write-capable subagent or task, verify **which git\n  repository**, worktree, and branch yourself (`git rev-parse --show-toplevel`,\n  `git branch --show-current`, `git worktree list`). Under\n  `monorepo-submodules`, confirming the toplevel (which submodule \u002F linked wt)\n  is mandatory — not only branch + worktree list. Runtime pre-tool-use hooks\n  may not fire for delegated\u002Fsubprocess tool calls on opencode\u002Fpi\u002Fomp — do not\n  treat the gate as the sole guard for delegated writes.\n- If a structured Edit\u002FWrite\u002FMultiEdit call is blocked or errors for any\n  reason while on a protected branch, that is never grounds to retry the\n  write via bash\u002Fshell (heredoc, `python3 -c`, `cat >`, `tee`, `sed -i`) —\n  using bash to write bypasses the worktree gate entirely.\n  - `gate_mode = always`: create a dedicated worktree\n    (`\u002Fworktree-new`) and write there instead.\n  - `gate_mode = ask`: **ask the user** which destination to use and\n    wait — a dedicated worktree (recommended), a feature branch in the\n    current checkout, or an explicit override to write on the protected\n    branch. Do not pick a destination yourself, and do not re-run with\n    `WORKTREE_GATE_MODE=off` as a self-authorization shortcut.\n  - `gate_mode = off`: the gate does not block; work where the user directs.\n\n## Asking the user (per harness)\n\nWhen `gate_mode = ask` blocks a write, surface the three destinations with\nthe harness's **native user-question mechanism** and stop until the user\nanswers:\n\n| Harness | Mechanism |\n|---|---|\n| pi | `ask_user_question` (structured options) |\n| claude | `AskUserQuestion` (or a direct conversational question) |\n| opencode \u002F cursor \u002F omp | the interactive user prompt \u002F inline question |\n\nThe user's answer decides the destination; never decide for them, and never\ntreat the block as permission to bypass the guard.\n\n## Creating a worktree\n\nPrefer the `\u002Fworktree-new` command.\n\n### standalone \u002F monorepo-apps\n\n```bash\ngit worktree add \u003Cworktrees_dir>\u002F\u003Cslug> -b \u003Cbranch> \u003Cintegration_branch>\n```\n\n### monorepo-submodules (locked contract)\n\nDestination MUST be absolute. Infer or require `\u003Csubrepo>`; validate path-then\nunique name; reject uninitialized (`git submodule update --init \u003Cpath>`).\n`\u003Csubrepo>` selection and the owner\u002Fplanning-root split are validated by\n`util.resolve_request_context` \u002F `util.resolve_subrepo`. A request whose\ncontext is the **superrepo** MUST NOT infer a subrepo: an explicit, validated\n`\u003Csubrepo>` is required, otherwise hard-error **before any `git worktree add`**.\n\n```bash\nsuper_abs=\"$(git -C \"$super_root\" rev-parse --show-toplevel)\"\ngit -C \"$super_abs\u002F\u003Csubrepo_path>\" worktree add \\\n  \"$super_abs\u002F\u003Cworktrees_dir>\u002F\u003Csubrepo>-\u003Cslug>\" \\\n  -b \u003Cbranch> \u003Cintegration_branch>\n```\n\ncwd inference uses `git -C`\u002F`rev-parse --show-toplevel` and, for linked\nworktrees named `\u003Cpath>-\u003Cslug>`, the **longest** matching submodule path\nprefix (see `util.resolve_subrepo`).\n\n## Post-merge cleanup\n\nAfter a branch is merged into the integration branch, reclaim its worktree.\n\n### Leave the worktree first (hard rule)\n\nNever run `git worktree remove` (or the cleanup script) while `$PWD` is inside\nthe worktree being removed — that yields `fatal: Unable to read current working\ndirectory`. Always:\n\n```bash\ncd \u003Cmain-repo-root>\n```\n\n### Script-first (preferred)\n\nPrefer the materialized verified-Go cleanup launcher (or `\u002Fworktree-clean`) over\nad-hoc remove sequences. Run it from the main repository worktree; it owns\npost-merge remote deletion and independently verifies remote absence:\n\n\n```bash\nbash ai-specs\u002Frecipes\u002Fworktree-flow\u002Foverrides\u002Fbin\u002Fworktree-cleanup.sh \\\n  --dir \u003Cworktrees_dir> --base \u003Cintegration_branch>\n```\n\nOptional `--submodule` \u002F `--subrepo` scopes to one module; default = all\ninitialized. Run with `--dry-run` first to preview removals.\n\nThe launcher is conservative by design:\n\n- **Removes** a worktree only when its branch is fully merged into the base —\n  detecting both regular\u002Ffast-forward merges (ancestry) and squash\u002Frebase merges\n  (all of the branch's changes already present in base by patch-id).\n- **Preserves** worktrees with uncommitted changes (reported as `dirty`).\n- **Preserves** worktrees whose branch is not yet merged (`unmerged`).\n- **Never touches** the main worktree or detached-HEAD worktrees.\n- Refuses loudly before every worktree, local-branch, or remote-branch delete\n  when the branch is protected (`main`, `master`, `development`, `staging`,\n  or configured base\u002Fintegration names).\n- Deletes the remote branch only after local cleanup and verifies absence with\n  `git ls-remote --heads`; failure is not reported as success.\n- Under submodules, enumerates per-module lists; uninitialized modules are\n  skipped.\n\n### Manual fallback\n\nOnly if the script is unavailable: from the main repo root, `git worktree\nremove \u003Cpath>`, then `git branch -D \u003Cbranch>` after squash\u002Frebase merges.\nStop without deleting if the worktree is dirty.\n\nThis honors the project rule: never revert or discard changes you did not make.\n\n### Candidate-view store (separate)\n\nThis cleanup covers `.worktrees\u002F` only. Native review candidate views live under\nthe shared git dir (`.git\u002Fgentle-ai\u002Fcandidate-views`) and are controller-owned.\nAfter the merged-worktree pass, load the `worktree-candidate-cleanup` skill to\naudit that store and, only when every eligibility proof holds, reap stale\ncandidate views and their matching `*.owner.json` markers. Never delete candidate\nviews or markers ad hoc.\n",{"name":5,"license":14,"metadata":43,"description":50},{"scope":44,"author":45,"version":46,"auto_invoke":47},"runtime","ai-specs","1.2",[48,49],"Starting a change that will write files or modify code","Cleaning up worktrees after a branch is merged","Isolated git worktree workflow for ai-specs change work. Create a dedicated worktree under .worktrees\u002F for any change that writes files, keep pure exploration outside a worktree, and clean up merged worktrees safely after topologies via the CLI-owned [project].repo_topology and topology-aware gate scope via recipes.worktree-flow.config.gate_scope.\n","main","c092fc1f51280350a4434827e2f6d6d99e3431ca","catalog\u002Frecipes\u002Fworktree-flow\u002Fskills\u002Fworktree-flow",2,"https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli","https:\u002F\u002Fgithub.com\u002Fparada1104","2026-11-08 05:20:31",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add parada1104\u002Fai-specs-cli --skill worktree-flow",{"tool":64,"command":65},"bunx","bunx skills add parada1104\u002Fai-specs-cli --skill worktree-flow",{"tool":67,"command":68},"pnpm","pnpm dlx skills add parada1104\u002Fai-specs-cli --skill worktree-flow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Fcatalog\u002Frecipes\u002Fworktree-flow\u002Fskills\u002Fworktree-flow\u002FSKILL.md",true,[],[73,95,109,117,126,139],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":87,"publishedAt":38},"01M71F2TF9TS9DNCJ68M7C3B5S","test-skill","Test skill for fixture purposes.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Frecipes\u002Ftest-fixture\u002Fskills\u002Ftest-skill\u002FSKILL.md",[79,84],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":85,"categoryName":86,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发",[88,89,90,91,92,93,94],"Test Skill","test","for","root","fixtures","fixture","testing",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":104,"publishedAt":38},"01M71F2RTH94ZB7XEAW4P6ZG0D","obsidian-markdown","Fixture skill for obsidian-markdown.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fobsidian-markdown\u002FSKILL.md",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000002","文档处理",[105,106,107,90,93,108],"markdown","obsidian markdown","obsidian","fixture skill",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":38},"01M71F2R20CPTJXD9F7DP4JPP6","obsidian-cli","Fixture skill for obsidian-cli.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fobsidian-cli\u002FSKILL.md",[],[116,107,30,90,93,108],"obsidian cli",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":38},"01M71F2PCH4NWVTT1J57SHJX33","obsidian-bases","Fixture skill for obsidian-bases.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fobsidian-bases\u002FSKILL.md",[],[124,125,107,90,93,108],"bases","obsidian bases",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":135,"publishedAt":38},"01M71F2MSS6EVFEYVYAA1KBYCC","json-canvas","Fixture skill for json-canvas.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fjson-canvas\u002FSKILL.md",[132],{"categoryNo":133,"categoryName":134,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000015","视觉设计",[136,137,138,108,93,90],"json","json canvas","canvas",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":38},"01M71F2KY5QVNEN1Q3REFB0MQZ","defuddle","Fixture skill for defuddle.","https:\u002F\u002Fgithub.com\u002Fparada1104\u002Fai-specs-cli\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fkepano-obsidian-skills\u002Fskills\u002Fdefuddle\u002FSKILL.md",[],[141,108,93,90]]