[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HEMJ3WM0NQGHMSBY3VAY1":3,"skill-same:01M71HEMJ3WM0NQGHMSBY3VAY1":71},{"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":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M71HEMJ3WM0NQGHMSBY3VAY1","git-worktree",null,"Use git worktrees for parallel feature branches without stashing or cloning. Creates isolated working directories from a single local clone. EN triggers: \u002Fworktree, git worktree, parallel branches, multiple features, isolate work. PT triggers: \u002Fworktree, branches paralelas, trabalho isolado, múltiplas features. Do NOT use for: simple single-branch work, fixing merge conflicts, or repos where disk space is extremely constrained.","runecraftai\u002Farcanum","runecraftai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F279098826?v=4","01M71HBGS1RCAJ490RAYST7M00","01M71HBGT1CB94MNS6T6SGAZKW",1,"CC-BY-4.0","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fgit-worktree\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"worktree","git","git worktree","do","parallel","clone","repos","features","worktrees","merge","cloning","work","conflicts","disk","git worktrees","branches","local","pt","directories","branch","2026-11-10 10:12:30",false,"---\nname: git-worktree\ndescription: >\n  Use git worktrees for parallel feature branches without stashing or cloning.\n  Creates isolated working directories from a single local clone.\n  EN triggers: \u002Fworktree, git worktree, parallel branches, multiple features, isolate work.\n  PT triggers: \u002Fworktree, branches paralelas, trabalho isolado, múltiplas features.\n  Do NOT use for: simple single-branch work, fixing merge conflicts, or repos where disk space is extremely constrained.\nlicense: CC-BY-4.0\n---\n\n# git-worktree\n\nUse git worktrees to work on multiple branches simultaneously from a single local clone — no stashing, no cloning, no context-switching friction. Each worktree is an independent working directory on its own branch, sharing the same `.git` repository.\n\n```\nDECIDE BRANCH → ADD WORKTREE → WORK INDEPENDENTLY → MERGE → CLEAN UP\n```\n\n---\n\n## Overview\n\nA git worktree is an additional working directory attached to the same local repository. Instead of cloning the repo again or stashing unfinished work to switch branches, you create a worktree — a separate directory that checks out a different branch — and work there independently.\n\nEach worktree shares the same object database (`.git`), so commits made in one worktree are immediately visible to all others. There is no duplication of git history, only a sparse checkout of the working tree for each branch.\n\n**Benefits:**\n- No stashing — keep your current branch exactly as-is while starting something else\n- No re-cloning — disk cost per worktree is only the checked-out files, not the full history\n- True parallelism — run tests, builds, and edits in different branches side by side\n- Hotfix safety — ship a critical fix from a clean `main` checkout while your feature branch sits untouched\n\n---\n\n## When to Use\n\n| Scenario | Why worktrees help |\n|----------|-------------------|\n| Parallel epics or features | Each epic gets its own directory; no branch-switching or stashing |\n| Hotfix while on a feature branch | Checkout `main` in a new worktree, fix, push, and return to your feature — nothing stashed |\n| Reviewing or testing another branch | Checkout a PR branch in a worktree, build and test without touching your current work |\n| CI isolation | Run a long build or test suite in one worktree while continuing development in another |\n| Comparing branches | Have two branches checked out side by side for diffing or manual verification |\n\n**Do not use when:**\n- You're working on a single branch — standard git workflow is simpler\n- You need to fix merge conflicts — worktrees don't help with conflict resolution\n- Disk space is extremely constrained — each worktree costs the checkout size of that branch\n\n---\n\n## Process\n\n### Step 1: Create a Worktree\n\nFrom your main repository directory, use `git worktree add`:\n\n```bash\n# Create a worktree from the current HEAD (starts on same commit)\ngit worktree add ..\u002Fpath-to-worktree\n\n# Create a worktree on an existing branch\ngit worktree add ..\u002Fpath-to-worktree existing-branch\n\n# Create a worktree with a new branch\ngit worktree add -b new-branch-name ..\u002Fpath-to-worktree base-branch\n```\n\n**Convention:** Place worktrees as siblings to your main repo directory (e.g., `..\u002Fproject-hotfix`, `..\u002Fproject-epic-2`). Avoid nesting worktrees inside other worktrees.\n\n### Step 2: List Worktrees\n\n```bash\ngit worktree list\n```\n\nOutput shows the path, HEAD commit, and branch for every worktree. The main worktree is marked with `[main]` or `[bare]`.\n\n### Step 3: Work Independently\n\nNavigate to the new directory and work as usual:\n\n```bash\ncd ..\u002Fpath-to-worktree\n# Edit, stage, commit, push — all commands work the same\ngit add .\ngit commit -m \"feat(epic-2): start new feature\"\ngit push origin new-branch-name\n```\n\nThe main worktree is unaffected. You can run builds, tests, or linters in each worktree independently.\n\n### Step 4: Clean Up\n\nWhen the branch is merged or no longer needed:\n\n```bash\n# Remove the worktree and its directory\ngit worktree remove ..\u002Fpath-to-worktree\n\n# Prune stale worktree references (if a worktree directory was deleted manually)\ngit worktree prune\n```\n\n`git worktree remove` fails if the branch has unmerged changes — this is a safety check. Force with `--force` only if you're certain.\n\n---\n\n## Safety Rules\n\n- **Never nest worktrees.** A worktree must not be created inside another worktree's directory. Nesting corrupts the relationship between `.git` files.\n- **One worktree per branch.** Git refuses to check out the same branch in two worktrees simultaneously. If you need a second checkout of the same branch, create a new branch from it.\n- **Shared `.git` means shared state.** Commits, fetches, and branch updates in one worktree are visible in all others. If you delete a branch in worktree A, it's gone everywhere.\n- **Clean up stale worktrees.** If you delete a worktree directory manually (without `git worktree remove`), run `git worktree prune` to remove the stale reference.\n- **Prune periodically.** After merging branches, run `git worktree prune` to keep the worktree list clean.\n- **Bare repositories.** Worktrees also work from bare repos, but the commands differ. This skill focuses on standard (non-bare) use.\n\n---\n\n## Common Patterns\n\n### Parallel Epics\n\nStart multiple epics from `main`, each in its own directory:\n\n```bash\ngit worktree add -b epic-payments ..\u002Fepic-payments main\ngit worktree add -b epic-notifications ..\u002Fepic-notifications main\ngit worktree add -b epic-search ..\u002Fepic-search main\n```\n\nWork on each independently. When one is ready, push and open a PR. The others continue unaffected.\n\n### Hotfix from Main\n\nYou're deep in a feature branch with uncommitted changes. A critical bug needs an immediate fix on `main`:\n\n```bash\n# Create hotfix worktree from main — your feature branch stays untouched\ngit worktree add -b hotfix\u002Fcritical-bug ..\u002Fhotfix main\n\n# Navigate, fix, commit, push\ncd ..\u002Fhotfix\n# ... make the fix ...\ngit add .\ngit commit -m \"fix(billing): prevent double charge on retry\"\ngit push origin hotfix\u002Fcritical-bug\n\n# Return to your feature — nothing was stashed, nothing was interrupted\ncd ..\u002Fproject\n```\n\n### Review a PR Locally\n\nCheckout and test a PR branch without disrupting your work:\n\n```bash\ngit worktree add ..\u002Freview-pr-billing main\ncd ..\u002Freview-pr-billing\ngit fetch origin pull\u002F42\u002Fhead:pr-42\ngit checkout pr-42\n# Build, test, review — your main working directory is untouched\n```\n\n### CI \u002F Long-Running Tasks\n\nRun a full test suite or build in an isolated worktree while you keep coding:\n\n```bash\ngit worktree add ..\u002Fci-build main\ncd ..\u002Fci-build\nbun test  # runs while you continue editing in the main directory\n```\n\n---\n\n## Merge Strategy\n\nAfter worktrees finish their work:\n\n1. **Merge in dependency order.** If epic-1 depends on epic-2, merge epic-2 first.\n2. **Resolve conflicts in the main worktree.** Conflicts must be resolved before the branch can be merged. Standard merging applies — worktrees don't change this.\n3. **Push and open PRs** from each worktree as usual.\n4. **Clean up** after merge:\n\n```bash\n# After the branch is merged on the remote\ngit branch -d branch-name       # delete local branch (from any worktree)\ngit worktree remove ..\u002Fpath     # remove the worktree directory\n```\n\n5. **Prune periodically** to remove stale worktree references:\n\n```bash\ngit worktree prune\n```\n\n---\n\n## Verification\n\nAfter setting up a worktree:\n\n- [ ] `git worktree list` shows the new worktree with the correct branch and path\n- [ ] Navigating to the worktree directory shows the expected branch's files\n- [ ] `cd` into the worktree and run `git status` — clean state on the target branch\n- [ ] Commits made in the worktree appear in `git log` from the main directory\n- [ ] The main worktree is unaffected — your original work is exactly as you left it\n- [ ] After merging, the branch is deleted and `git worktree remove` cleans up the directory\n- [ ] `git worktree prune` confirms no stale references remain\n\n---\n\n## See Also\n\n- [Git Worktree Documentation](https:\u002F\u002Fgit-scm.com\u002Fdocs\u002Fgit-worktree)\n- [Git Worktree Tutorial (Atlassian)](https:\u002F\u002Fwww.atlassian.com\u002Fgit\u002Ftutorials\u002Fgit-worktree)\n- `git-worktree` man page: `man git-worktree` or `git worktree --help`\n- For learning patterns from your project's git history, see the `git-commit-learning` spell\n","# git-worktree\n\nUse git worktrees to work on multiple branches simultaneously from a single local clone — no stashing, no cloning, no context-switching friction. Each worktree is an independent working directory on its own branch, sharing the same `.git` repository.\n\n```\nDECIDE BRANCH → ADD WORKTREE → WORK INDEPENDENTLY → MERGE → CLEAN UP\n```\n\n---\n\n## Overview\n\nA git worktree is an additional working directory attached to the same local repository. Instead of cloning the repo again or stashing unfinished work to switch branches, you create a worktree — a separate directory that checks out a different branch — and work there independently.\n\nEach worktree shares the same object database (`.git`), so commits made in one worktree are immediately visible to all others. There is no duplication of git history, only a sparse checkout of the working tree for each branch.\n\n**Benefits:**\n- No stashing — keep your current branch exactly as-is while starting something else\n- No re-cloning — disk cost per worktree is only the checked-out files, not the full history\n- True parallelism — run tests, builds, and edits in different branches side by side\n- Hotfix safety — ship a critical fix from a clean `main` checkout while your feature branch sits untouched\n\n---\n\n## When to Use\n\n| Scenario | Why worktrees help |\n|----------|-------------------|\n| Parallel epics or features | Each epic gets its own directory; no branch-switching or stashing |\n| Hotfix while on a feature branch | Checkout `main` in a new worktree, fix, push, and return to your feature — nothing stashed |\n| Reviewing or testing another branch | Checkout a PR branch in a worktree, build and test without touching your current work |\n| CI isolation | Run a long build or test suite in one worktree while continuing development in another |\n| Comparing branches | Have two branches checked out side by side for diffing or manual verification |\n\n**Do not use when:**\n- You're working on a single branch — standard git workflow is simpler\n- You need to fix merge conflicts — worktrees don't help with conflict resolution\n- Disk space is extremely constrained — each worktree costs the checkout size of that branch\n\n---\n\n## Process\n\n### Step 1: Create a Worktree\n\nFrom your main repository directory, use `git worktree add`:\n\n```bash\n# Create a worktree from the current HEAD (starts on same commit)\ngit worktree add ..\u002Fpath-to-worktree\n\n# Create a worktree on an existing branch\ngit worktree add ..\u002Fpath-to-worktree existing-branch\n\n# Create a worktree with a new branch\ngit worktree add -b new-branch-name ..\u002Fpath-to-worktree base-branch\n```\n\n**Convention:** Place worktrees as siblings to your main repo directory (e.g., `..\u002Fproject-hotfix`, `..\u002Fproject-epic-2`). Avoid nesting worktrees inside other worktrees.\n\n### Step 2: List Worktrees\n\n```bash\ngit worktree list\n```\n\nOutput shows the path, HEAD commit, and branch for every worktree. The main worktree is marked with `[main]` or `[bare]`.\n\n### Step 3: Work Independently\n\nNavigate to the new directory and work as usual:\n\n```bash\ncd ..\u002Fpath-to-worktree\n# Edit, stage, commit, push — all commands work the same\ngit add .\ngit commit -m \"feat(epic-2): start new feature\"\ngit push origin new-branch-name\n```\n\nThe main worktree is unaffected. You can run builds, tests, or linters in each worktree independently.\n\n### Step 4: Clean Up\n\nWhen the branch is merged or no longer needed:\n\n```bash\n# Remove the worktree and its directory\ngit worktree remove ..\u002Fpath-to-worktree\n\n# Prune stale worktree references (if a worktree directory was deleted manually)\ngit worktree prune\n```\n\n`git worktree remove` fails if the branch has unmerged changes — this is a safety check. Force with `--force` only if you're certain.\n\n---\n\n## Safety Rules\n\n- **Never nest worktrees.** A worktree must not be created inside another worktree's directory. Nesting corrupts the relationship between `.git` files.\n- **One worktree per branch.** Git refuses to check out the same branch in two worktrees simultaneously. If you need a second checkout of the same branch, create a new branch from it.\n- **Shared `.git` means shared state.** Commits, fetches, and branch updates in one worktree are visible in all others. If you delete a branch in worktree A, it's gone everywhere.\n- **Clean up stale worktrees.** If you delete a worktree directory manually (without `git worktree remove`), run `git worktree prune` to remove the stale reference.\n- **Prune periodically.** After merging branches, run `git worktree prune` to keep the worktree list clean.\n- **Bare repositories.** Worktrees also work from bare repos, but the commands differ. This skill focuses on standard (non-bare) use.\n\n---\n\n## Common Patterns\n\n### Parallel Epics\n\nStart multiple epics from `main`, each in its own directory:\n\n```bash\ngit worktree add -b epic-payments ..\u002Fepic-payments main\ngit worktree add -b epic-notifications ..\u002Fepic-notifications main\ngit worktree add -b epic-search ..\u002Fepic-search main\n```\n\nWork on each independently. When one is ready, push and open a PR. The others continue unaffected.\n\n### Hotfix from Main\n\nYou're deep in a feature branch with uncommitted changes. A critical bug needs an immediate fix on `main`:\n\n```bash\n# Create hotfix worktree from main — your feature branch stays untouched\ngit worktree add -b hotfix\u002Fcritical-bug ..\u002Fhotfix main\n\n# Navigate, fix, commit, push\ncd ..\u002Fhotfix\n# ... make the fix ...\ngit add .\ngit commit -m \"fix(billing): prevent double charge on retry\"\ngit push origin hotfix\u002Fcritical-bug\n\n# Return to your feature — nothing was stashed, nothing was interrupted\ncd ..\u002Fproject\n```\n\n### Review a PR Locally\n\nCheckout and test a PR branch without disrupting your work:\n\n```bash\ngit worktree add ..\u002Freview-pr-billing main\ncd ..\u002Freview-pr-billing\ngit fetch origin pull\u002F42\u002Fhead:pr-42\ngit checkout pr-42\n# Build, test, review — your main working directory is untouched\n```\n\n### CI \u002F Long-Running Tasks\n\nRun a full test suite or build in an isolated worktree while you keep coding:\n\n```bash\ngit worktree add ..\u002Fci-build main\ncd ..\u002Fci-build\nbun test  # runs while you continue editing in the main directory\n```\n\n---\n\n## Merge Strategy\n\nAfter worktrees finish their work:\n\n1. **Merge in dependency order.** If epic-1 depends on epic-2, merge epic-2 first.\n2. **Resolve conflicts in the main worktree.** Conflicts must be resolved before the branch can be merged. Standard merging applies — worktrees don't change this.\n3. **Push and open PRs** from each worktree as usual.\n4. **Clean up** after merge:\n\n```bash\n# After the branch is merged on the remote\ngit branch -d branch-name       # delete local branch (from any worktree)\ngit worktree remove ..\u002Fpath     # remove the worktree directory\n```\n\n5. **Prune periodically** to remove stale worktree references:\n\n```bash\ngit worktree prune\n```\n\n---\n\n## Verification\n\nAfter setting up a worktree:\n\n- [ ] `git worktree list` shows the new worktree with the correct branch and path\n- [ ] Navigating to the worktree directory shows the expected branch's files\n- [ ] `cd` into the worktree and run `git status` — clean state on the target branch\n- [ ] Commits made in the worktree appear in `git log` from the main directory\n- [ ] The main worktree is unaffected — your original work is exactly as you left it\n- [ ] After merging, the branch is deleted and `git worktree remove` cleans up the directory\n- [ ] `git worktree prune` confirms no stale references remain\n\n---\n\n## See Also\n\n- [Git Worktree Documentation](https:\u002F\u002Fgit-scm.com\u002Fdocs\u002Fgit-worktree)\n- [Git Worktree Tutorial (Atlassian)](https:\u002F\u002Fwww.atlassian.com\u002Fgit\u002Ftutorials\u002Fgit-worktree)\n- `git-worktree` man page: `man git-worktree` or `git worktree --help`\n- For learning patterns from your project's git history, see the `git-commit-learning` spell\n",{"name":5,"license":14,"description":43},"Use git worktrees for parallel feature branches without stashing or cloning. Creates isolated working directories from a single local clone. EN triggers: \u002Fworktree, git worktree, parallel branches, multiple features, isolate work. PT triggers: \u002Fworktree, branches paralelas, trabalho isolado, múltiplas features. Do NOT use for: simple single-branch work, fixing merge conflicts, or repos where disk space is extremely constrained.\n","main","33b040feb49e126600394272a8e321a3cd279e8b","packages\u002Fspells\u002Fskills\u002Fgit-worktree",0,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum","https:\u002F\u002Fgithub.com\u002Frunecraftai","2026-07-29 22:08:52",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add runecraftai\u002Farcanum --skill git-worktree",{"tool":57,"command":58},"bunx","bunx skills add runecraftai\u002Farcanum --skill git-worktree",{"tool":60,"command":61},"pnpm","pnpm dlx skills add runecraftai\u002Farcanum --skill git-worktree","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fgit-worktree\u002FSKILL.md",true,[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"README.md","REFERENCE","参考文档",579,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fgit-worktree\u002FREADME.md",[72,102,126,152,172,196],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":83,"publishedAt":38},"01M71HGTN9FRQ3WEZMVVX7C3VZ","using-agent-skills","Discovers and invokes the right @runecraft\u002Fspells skill for the current task. Use when starting a session, when a request is ambiguous about which workflow to apply, or when you need to pick among the 13-skill Arcanum catalog. EN triggers: \u002Fskill, which skill, pick a skill, what skill should I use, skill discovery, meta skill. PT triggers: qual skill, qual habilidade, descobrir skill, qual fluxo usar. Do NOT use for: actual implementation work (route to the specific skill instead), unrelated standalone tasks outside the Arcanum catalog, or runtime-specific configuration (e.g., opencode.json \u002F Claude Code plugin paths).","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fusing-agent-skills\u002FSKILL.md",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[84,85,86,35,87,88,89,90,91,92,93,94,95,29,96,97,98,99,100,101],"using agent skills","standalone","which","pick","Meta","when","workflow","you","code","tasks","skill discovery","route","unrelated","opencode","request","paths","a skill","ambiguous",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":38},"01M71HGPD6N9JH2G8EVBXJR77X","typescript-patterns","TypeScript best practices and patterns for type-safe, maintainable code. Covers discriminated unions, generics, const assertions, type narrowing, and common anti-patterns. Extends (does not override) project tsconfig. EN triggers: \u002Ftypescript, TypeScript patterns, TS best practices, type safety, discriminated unions, generics, type narrowing. PT triggers: \u002Ftypescript, padrões TypeScript, boas práticas TS, segurança de tipos, unions discriminadas, genéricos. Do NOT use for: JavaScript-only projects, runtime performance, or replacing project tsconfig rules.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftypescript-patterns\u002FSKILL.md",[],[109,110,111,21,112,113,35,114,115,116,117,118,119,120,121,122,123,124,92,125],"typescript","patterns","typescript patterns","projects","for","runtime","project","performance","en","maintainable code","triggers","only","use","assertions","Rules","best practices","common",{"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":138,"publishedAt":38},"01M71HGJAKX4TFN0PECYPJ9S38","test-driven-development","Drives development with tests — fail first, then make them pass, then refactor. Use when implementing any logic, fixing any bug, or changing any behavior. EN triggers: \u002Ftest, write tests first, TDD, prove it, 80\u002F15\u002F5 pyramid, Beyonce Rule. PT triggers: \u002Fteste, testes primeiro, provar com teste, pirâmide 80\u002F15\u002F5. Do NOT use for: production incident triage (use \u002Fdebug), or cosmetic-only changes with no behavioral surface.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[132,135],{"categoryNo":133,"categoryName":134,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":136,"categoryName":137,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000008","测试与质量",[139,140,141,142,35,143,144,145,120,89,146,147,148,149,150,21,113,117,119,151],"test driven development","development","test","driven","incident","implementing","write tests","write","bug","refactor","behavioral","make","tests",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":38},"01M71HGC1H4JQFJWH613XTJC59","spec-driven","Feature planning and implementation with 4 adaptive phases — Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, and requirement traceability. Features an independent Verifier (author != verifier, evidence-or-zero), persistent decision log (STATE.md), and test-coverage-matrix-driven tests, plus a self-improving lessons layer that turns verification failures into reusable project-local guidance. Stack-agnostic. Use when planning features (requirements, design, task breakdown), implementing with verification and atomic commits, or validating\u002Fverifying an implementation against a spec. Triggers (PT\u002FEN): \"specify feature\", \"vamos especificar\", \"discutir feature\", \"discutir este caso\", \"design\", \"design da feature\", \"tarefas\", \"quebrar em tarefas\", \"implementar\", \"build\", \"validar\", \"verify work\", \"UAT\", \"validar implementação\", \"record decision\", \"pause work\", \"pausar trabalho\", \"resume work\", \"retomar trabalho\". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (treat as Complex scope: discuss gray areas + architecture-focused design).","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002FSKILL.md",[],[159,160,142,161,162,163,164,35,115,165,144,34,166,167,168,169,89,170,93,171],"spec driven","spec","coverage","complexity","task breakdown","scope","decision","design","self-improving","auto","atomic commits","analysis","architecture",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":182,"publishedAt":38},"01M71HG5CSP04F29HRAG7XVYKG","skill-forge","Designs, authors, validates, and optimizes new Agent Skills from scratch. Use when creating a new skill, packaging a workflow as a skill, improving a skill's triggering accuracy, or evaluating whether a skill improves output quality. Covers the full lifecycle: DISCOVER, DESIGN, AUTHOR, VALIDATE, OPTIMIZE, DELIVER. Produces skills that follow the open SKILL.md format (YAML frontmatter + Markdown body, progressive disclosure, validation loops). EN triggers: \u002Fforge, create a skill, write a skill, build a skill, new skill, author a skill, package this as a skill, validate a skill, improve skill triggering, optimize skill description, evaluate skill quality. PT triggers: \u002Fforge, criar uma skill, escrever uma skill, construir uma skill, nova skill, empacotar como skill, validar skill, melhorar disparo, otimizar descrição de skill. Do NOT use for: discovering which existing skill to apply (use a dispatch\u002Fmeta skill), planning feature implementation, or designing software architecture.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fskill-forge\u002FSKILL.md",[178,181],{"categoryNo":179,"categoryName":180,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},[183,184,185,86,186,187,35,188,88,189,190,166,171,191,192,146,193,100,194,195],"forge","skill forge","deliver","new agent","feature implementation","packaging","improve","open","create","de","software","new skill","full",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":202,"publishedAt":38},"01M71HG1RAQY3GXX0Q5TMW0XD6","shipping-and-launch","Prepares production launches with a pre-launch checklist, staged rollout, monitoring, and a rollback strategy — plus feature flag lifecycle (off → internal → beta → GA). Use when deploying a feature to production for the first time, releasing a significant change, or planning a rollout. EN triggers: \u002Fship, pre-launch checklist, staged rollout, feature flag, rollback plan, monitoring. PT triggers: \u002Fshippar, checklist pré-lançamento, rollout gradual, feature flag, plano de rollback. Do NOT use for: pre-production development work, or one-off internal tools with no user exposure.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fshipping-and-launch\u002FSKILL.md",[],[203,204,205,35,206,207,89,208,209,210,211,29,212,213,214,215,192,216,217,218],"shipping and launch","shipping","launch","time","beta","rollout","rollback plan","monitoring","rollback strategy","plan","change","exposure","plano","ship","Tools","pre-launch"]