[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KH8RCFNVTCV3DQ0HTZTSHP":3,"skill-same:01M6KH8RCFNVTCV3DQ0HTZTSHP":82},{"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":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":43,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":45,"install":46,"resources":59},"01M6KH8RCFNVTCV3DQ0HTZTSHP","oma-scm",null,"SCM (software configuration management) and Git — branching, merges, conflicts, worktrees, baselines, audit readiness, plus Conventional Commits and safe staging.","wooloolies\u002Fedcurate","wooloolies","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F249394924?v=4","01M6KH5E2GYFK48H4CM2H72J5Y","01M6KH5E69S3MAQGE2WKEPZTMR",4,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32],"oma scm","scm","safe","git","audit","commits","management","conventional commits","worktrees","conflicts","configuration","configuration management","software","readiness","branching","2026-11-10 10:12:30",false,"---\nname: oma-scm\ndescription: SCM (software configuration management) and Git — branching, merges, conflicts, worktrees, baselines, audit readiness, plus Conventional Commits and safe staging.\n---\n\n# Software configuration management — SCM (`oma-scm`)\n\nThis skill is the **single** place for **configuration management (CM)** on a software repo and for **Conventional Commits** \u002F safe staging.\n\n## When to use\n\n- **Commits:** “commit this”, `\u002Fscm`, message type\u002Fscope, splitting staged changes into multiple commits.\n- **CM \u002F Git:** branching (gitflow, GitHub Flow, GitLab Flow, trunk-based), protected branches, merge queue, merge conflicts, rebase, cherry-pick, worktrees, submodules\u002Fsubtrees, tags and releases.\n- **Governance:** issue\u002FADR links, breaking-change footers, changelog or release-tool alignment.\n- **Audit posture:** signed commits, CI before merge, secret-sensitive paths.\n\n## Configuration\n\n| File | Role |\n|------|------|\n| `config\u002Fcommit-config.yaml` | Conventional Commit types, branch prefixes, message rules |\n| `config\u002Fcm-config.yaml` | CM pointers — documented process, branching model, baselines, changelog |\n\n## Operating mode (choose first)\n\n### Quick Path (commit-focused, default)\n\nUse this when the user intent is mainly \"commit this safely.\"\n\n1. Follow **Conventional Commits** section only\n2. Stage explicit files only\n3. Validate message type\u002Fscope\u002Flength from `commit-config.yaml`\n4. Stop after safe commit unless user asks CM\u002Fgovernance operations\n\n### Full CM Path (repo governance \u002F risky history operations)\n\nUse this when the user asks about branching strategy, merges, rebase\u002Fcherry-pick, worktrees, release refs, CODEOWNERS, or audit posture.\n\n1. Run CM workflows in order (Planning -> Identification -> Control -> Status accounting -> Verification)\n2. Add onboarding risk scan when inheriting or auditing a repository\n3. Include commit governance from Conventional Commits when creating commits\n4. For large-scope merge operations, use risk scoring and Ask Gate criteria from `..\u002F..\u002Fworkflows\u002Fscm.md`\n\n## CM process map (software)\n\n| CM function | Intent | Typical artefacts \u002F actions |\n|-------------|--------|------------------------------|\n| **Management & planning** | Agreed rules | `CONTRIBUTING.md`, `SECURITY.md`, `cm-config.yaml` |\n| **Configuration identification** | What is managed, naming | Branch\u002Ftag rules, version files, `.gitattributes`, LFS |\n| **Configuration control** | Reviewed change | PRs, checks, issue links, `BREAKING CHANGE` footers |\n| **Status accounting** | As-built truth | `main` \u002F release refs, `CHANGELOG`, tags, CI status |\n| **Verification & audit** | Evidence | CI logs, signed commits, lockfiles \u002F SBOM policy |\n\n## CM workflows (use before risky history operations)\n\n### 1) Planning\n\n1. Read `cm-config.yaml` and files listed under `documented_process`.\n2. If missing, infer from `CONTRIBUTING.md` \u002F `README`; state assumptions.\n3. Confirm **branching model** and whether **force-push** on shared branches is allowed (default: not without explicit approval).\n\n### 2) Identification\n\n1. Canonical refs: default branch, release branches\u002Ftags, version sources (`package.json`, etc.).\n2. `.gitattributes` \u002F LFS for binaries and generated assets.\n3. Branch names vs `commit-config.yaml` `branch_prefixes` when the project uses them.\n\n### 3) Control\n\n1. Small, reviewable units; align commits with PR \u002F issue intent.\n2. **Conflicts:** `merge-base`, `git status`, resolve markers, tests; suggest `rerere` when conflicts repeat.\n3. **Worktrees:** `git worktree add`; merge\u002Frebase from the **target branch’s** checkout; all worktrees share one object database.\n4. Do not rewrite **shared** history without maintainer approval; prefer `--force-with-lease` if force-push is unavoidable.\n\n### 4) Status accounting\n\n1. `git status -sb`: branch, remote tracking, ahead\u002Fbehind, merge state.\n2. Relate last tag \u002F release branch to `CHANGELOG` or tooling (semantic-release, release-please, changesets) if present.\n\n### 5) Verification & audit\n\n1. Required CI and `merge_group` when merge queue applies.\n2. Never stage\u002Fcommit secrets (`.env`, keys, raw tokens).\n3. Call out signed-commit expectations when the org cares about verification badges.\n\n#### CODEOWNERS maintenance checklist\n\n1. Validate CODEOWNERS file exists (prefer `.github\u002FCODEOWNERS`).\n2. Ensure critical paths are explicitly owned (not only fallback `*`).\n3. Ensure owners are active and mapped to current teams.\n4. Confirm branch protection requires CODEOWNERS review where needed.\n5. Flag overlapping\u002Fambiguous rules that can hide intended owners.\n\nRead `change_governance.require_codeowners` and `ownership.*` in `cm-config.yaml` when present.\n\n### 6) Onboarding risk scan (optional, recommended)\n\nUse this quick scan when joining or inheriting a repository to identify risky areas before major changes.\n\n1. High churn files in `lookback` window.\n2. Ownership concentration \u002F bus-factor signals.\n3. Bug hotspot files from fix-related history.\n4. Velocity trend by month.\n5. Revert\u002Fhotfix\u002Femergency frequency.\n\nRead thresholds from `cm-config.yaml` `onboarding_metrics` when present and cite caveats:\n- squash merge teams can distort ownership metrics,\n- weak commit labeling reduces hotspot accuracy,\n- monorepo commit counts can bias subsystem interpretation.\n\n---\n\n## Conventional Commits\n\n### Commit types\n\n| Type | Description | Branch Prefix |\n|------|-------------|---------------|\n| feat | New feature | feature\u002F |\n| fix | Bug fix | fix\u002F |\n| refactor | Code improvement | refactor\u002F |\n| docs | Documentation changes | docs\u002F |\n| test | Test additions\u002Fmodifications | test\u002F |\n| chore | Build, configuration, etc. | chore\u002F |\n| style | Code style changes | style\u002F |\n| perf | Performance improvements | perf\u002F |\n\n### Commit format\n\n```\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\n```\n\n### Commit workflow\n\n#### Step 1: Analyze changes\n\n```bash\ngit status\ngit diff --staged\ngit log --oneline -5\n```\n\n#### Step 1.5: Split by feature (if needed)\n\nIf changes span multiple features\u002Fdomains, **split commits by feature**.\n\n**Split when:** different scopes, different types, logically independent work.\n\n**Do not split when:** one feature, few files (≤5), or user asked for a single commit.\n\n#### Step 2: Determine type\n\n- New capability → `feat` · Bug fix → `fix` · Structure-only → `refactor` · Docs only → `docs` · Tests → `test` · Build\u002Fconfig → `chore`\n\n#### Step 3: Scope\n\nUse module\u002Fcomponent: `feat(auth):`, `fix(api):`, or omit: `chore: update dependencies`\n\n#### Step 4: Description\n\n≤72 chars (per `commit-config.yaml`), imperative mood, lowercase start, no trailing period.\n\n#### Step 5: Execute commit\n\nShow the message, then commit with explicit paths:\n\n```bash\ngit add \u003Cspecific-files>\ngit commit -m \"$(cat \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\nEOF\n)\"\n```\n\nIf HEREDOC is unstable in your shell (or body is long), use file-based commit input:\n\n```bash\ngit add \u003Cspecific-files>\ncat > \u002Ftmp\u002Foma-commit-msg.txt \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\nEOF\ngit commit -F \u002Ftmp\u002Foma-commit-msg.txt\n```\n\nUse HEREDOC by default, and switch to `-F` for long or flaky terminal sessions.\n\n## References\n\n- `config\u002Fcommit-config.yaml`\n- `config\u002Fcm-config.yaml`\n- `resources\u002Fconventional-commits.md`\n- `resources\u002Fonboarding-risk-signals.md`\n- `resources\u002Fcodeowners-playbook.md`\n\n## Important notes\n\n- **NEVER** `git add -A` or `git add .` without explicit user permission.\n- **NEVER** commit likely-secret material.\n- **ALWAYS** stage by explicit paths; tie non-trivial CM work to the five CM rows above, even briefly.\n","# Software configuration management — SCM (`oma-scm`)\n\nThis skill is the **single** place for **configuration management (CM)** on a software repo and for **Conventional Commits** \u002F safe staging.\n\n## When to use\n\n- **Commits:** “commit this”, `\u002Fscm`, message type\u002Fscope, splitting staged changes into multiple commits.\n- **CM \u002F Git:** branching (gitflow, GitHub Flow, GitLab Flow, trunk-based), protected branches, merge queue, merge conflicts, rebase, cherry-pick, worktrees, submodules\u002Fsubtrees, tags and releases.\n- **Governance:** issue\u002FADR links, breaking-change footers, changelog or release-tool alignment.\n- **Audit posture:** signed commits, CI before merge, secret-sensitive paths.\n\n## Configuration\n\n| File | Role |\n|------|------|\n| `config\u002Fcommit-config.yaml` | Conventional Commit types, branch prefixes, message rules |\n| `config\u002Fcm-config.yaml` | CM pointers — documented process, branching model, baselines, changelog |\n\n## Operating mode (choose first)\n\n### Quick Path (commit-focused, default)\n\nUse this when the user intent is mainly \"commit this safely.\"\n\n1. Follow **Conventional Commits** section only\n2. Stage explicit files only\n3. Validate message type\u002Fscope\u002Flength from `commit-config.yaml`\n4. Stop after safe commit unless user asks CM\u002Fgovernance operations\n\n### Full CM Path (repo governance \u002F risky history operations)\n\nUse this when the user asks about branching strategy, merges, rebase\u002Fcherry-pick, worktrees, release refs, CODEOWNERS, or audit posture.\n\n1. Run CM workflows in order (Planning -> Identification -> Control -> Status accounting -> Verification)\n2. Add onboarding risk scan when inheriting or auditing a repository\n3. Include commit governance from Conventional Commits when creating commits\n4. For large-scope merge operations, use risk scoring and Ask Gate criteria from `..\u002F..\u002Fworkflows\u002Fscm.md`\n\n## CM process map (software)\n\n| CM function | Intent | Typical artefacts \u002F actions |\n|-------------|--------|------------------------------|\n| **Management & planning** | Agreed rules | `CONTRIBUTING.md`, `SECURITY.md`, `cm-config.yaml` |\n| **Configuration identification** | What is managed, naming | Branch\u002Ftag rules, version files, `.gitattributes`, LFS |\n| **Configuration control** | Reviewed change | PRs, checks, issue links, `BREAKING CHANGE` footers |\n| **Status accounting** | As-built truth | `main` \u002F release refs, `CHANGELOG`, tags, CI status |\n| **Verification & audit** | Evidence | CI logs, signed commits, lockfiles \u002F SBOM policy |\n\n## CM workflows (use before risky history operations)\n\n### 1) Planning\n\n1. Read `cm-config.yaml` and files listed under `documented_process`.\n2. If missing, infer from `CONTRIBUTING.md` \u002F `README`; state assumptions.\n3. Confirm **branching model** and whether **force-push** on shared branches is allowed (default: not without explicit approval).\n\n### 2) Identification\n\n1. Canonical refs: default branch, release branches\u002Ftags, version sources (`package.json`, etc.).\n2. `.gitattributes` \u002F LFS for binaries and generated assets.\n3. Branch names vs `commit-config.yaml` `branch_prefixes` when the project uses them.\n\n### 3) Control\n\n1. Small, reviewable units; align commits with PR \u002F issue intent.\n2. **Conflicts:** `merge-base`, `git status`, resolve markers, tests; suggest `rerere` when conflicts repeat.\n3. **Worktrees:** `git worktree add`; merge\u002Frebase from the **target branch’s** checkout; all worktrees share one object database.\n4. Do not rewrite **shared** history without maintainer approval; prefer `--force-with-lease` if force-push is unavoidable.\n\n### 4) Status accounting\n\n1. `git status -sb`: branch, remote tracking, ahead\u002Fbehind, merge state.\n2. Relate last tag \u002F release branch to `CHANGELOG` or tooling (semantic-release, release-please, changesets) if present.\n\n### 5) Verification & audit\n\n1. Required CI and `merge_group` when merge queue applies.\n2. Never stage\u002Fcommit secrets (`.env`, keys, raw tokens).\n3. Call out signed-commit expectations when the org cares about verification badges.\n\n#### CODEOWNERS maintenance checklist\n\n1. Validate CODEOWNERS file exists (prefer `.github\u002FCODEOWNERS`).\n2. Ensure critical paths are explicitly owned (not only fallback `*`).\n3. Ensure owners are active and mapped to current teams.\n4. Confirm branch protection requires CODEOWNERS review where needed.\n5. Flag overlapping\u002Fambiguous rules that can hide intended owners.\n\nRead `change_governance.require_codeowners` and `ownership.*` in `cm-config.yaml` when present.\n\n### 6) Onboarding risk scan (optional, recommended)\n\nUse this quick scan when joining or inheriting a repository to identify risky areas before major changes.\n\n1. High churn files in `lookback` window.\n2. Ownership concentration \u002F bus-factor signals.\n3. Bug hotspot files from fix-related history.\n4. Velocity trend by month.\n5. Revert\u002Fhotfix\u002Femergency frequency.\n\nRead thresholds from `cm-config.yaml` `onboarding_metrics` when present and cite caveats:\n- squash merge teams can distort ownership metrics,\n- weak commit labeling reduces hotspot accuracy,\n- monorepo commit counts can bias subsystem interpretation.\n\n---\n\n## Conventional Commits\n\n### Commit types\n\n| Type | Description | Branch Prefix |\n|------|-------------|---------------|\n| feat | New feature | feature\u002F |\n| fix | Bug fix | fix\u002F |\n| refactor | Code improvement | refactor\u002F |\n| docs | Documentation changes | docs\u002F |\n| test | Test additions\u002Fmodifications | test\u002F |\n| chore | Build, configuration, etc. | chore\u002F |\n| style | Code style changes | style\u002F |\n| perf | Performance improvements | perf\u002F |\n\n### Commit format\n\n```\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\n\nCo-Authored-By: First Fluke \u003Cour.first.fluke@gmail.com>\n```\n\n### Commit workflow\n\n#### Step 1: Analyze changes\n\n```bash\ngit status\ngit diff --staged\ngit log --oneline -5\n```\n\n#### Step 1.5: Split by feature (if needed)\n\nIf changes span multiple features\u002Fdomains, **split commits by feature**.\n\n**Split when:** different scopes, different types, logically independent work.\n\n**Do not split when:** one feature, few files (≤5), or user asked for a single commit.\n\n#### Step 2: Determine type\n\n- New capability → `feat` · Bug fix → `fix` · Structure-only → `refactor` · Docs only → `docs` · Tests → `test` · Build\u002Fconfig → `chore`\n\n#### Step 3: Scope\n\nUse module\u002Fcomponent: `feat(auth):`, `fix(api):`, or omit: `chore: update dependencies`\n\n#### Step 4: Description\n\n≤72 chars (per `commit-config.yaml`), imperative mood, lowercase start, no trailing period.\n\n#### Step 5: Execute commit\n\nShow the message, then commit with explicit paths:\n\n```bash\ngit add \u003Cspecific-files>\ngit commit -m \"$(cat \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\nEOF\n)\"\n```\n\nIf HEREDOC is unstable in your shell (or body is long), use file-based commit input:\n\n```bash\ngit add \u003Cspecific-files>\ncat > \u002Ftmp\u002Foma-commit-msg.txt \u003C\u003C'EOF'\n\u003Ctype>(\u003Cscope>): \u003Cdescription>\n\n[optional body]\nEOF\ngit commit -F \u002Ftmp\u002Foma-commit-msg.txt\n```\n\nUse HEREDOC by default, and switch to `-F` for long or flaky terminal sessions.\n\n## References\n\n- `config\u002Fcommit-config.yaml`\n- `config\u002Fcm-config.yaml`\n- `resources\u002Fconventional-commits.md`\n- `resources\u002Fonboarding-risk-signals.md`\n- `resources\u002Fcodeowners-playbook.md`\n\n## Important notes\n\n- **NEVER** `git add -A` or `git add .` without explicit user permission.\n- **NEVER** commit likely-secret material.\n- **ALWAYS** stage by explicit paths; tie non-trivial CM work to the five CM rows above, even briefly.\n",{"name":5,"description":7},"main","239752f2aaad461ba7abb70cd87445cc268ca5ff",".agents\u002Fskills\u002Foma-scm",1,"https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate","https:\u002F\u002Fedcurate-2026.vercel.app","https:\u002F\u002Fgithub.com\u002Fwooloolies","2026-05-19 18:27:03",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add wooloolies\u002Fedcurate --skill oma-scm",{"tool":52,"command":53},"bunx","bunx skills add wooloolies\u002Fedcurate --skill oma-scm",{"tool":55,"command":56},"pnpm","pnpm dlx skills add wooloolies\u002Fedcurate --skill oma-scm","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002FSKILL.md",true,[60,66,70,74,78],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"config\u002Fcm-config.yaml","REFERENCE","参考文档",1139,"https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002Fconfig\u002Fcm-config.yaml",{"path":67,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":68,"sourceHtmlUrl":69},"config\u002Fcommit-config.yaml",880,"https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002Fconfig\u002Fcommit-config.yaml",{"path":71,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":72,"sourceHtmlUrl":73},"resources\u002Fcodeowners-playbook.md",1230,"https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002Fresources\u002Fcodeowners-playbook.md",{"path":75,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":76,"sourceHtmlUrl":77},"resources\u002Fconventional-commits.md",3938,"https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002Fresources\u002Fconventional-commits.md",{"path":79,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":80,"sourceHtmlUrl":81},"resources\u002Fonboarding-risk-signals.md",2067,"https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Foma-scm\u002Fresources\u002Fonboarding-risk-signals.md",[83,103,116,137,153,163],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":33},"01M6KHBR2FHN1VRRFV7FH8ENKS","work","Coordinate multiple agents for a complex multi-domain project using PM planning, parallel agent spawning, and QA review","https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwork\u002FSKILL.md",[],[85,90,91,92,93,94,95,96,97,98,99,100,101,102],"qa review","for","true","multi","project","pm","domain","coordinate","multi-domain","parallel","qa","planning","review",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":33},"01M6KHBP5914PZ3RXE6T1B3PX1","ultrawork","Ultrawork - high-quality 5-phase development workflow with 11 review steps out of 17","https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fultrawork\u002FSKILL.md",[],[105,102,110,111,112,92,113,114,115],"workflow","development","quality","development workflow","high","with",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":127,"publishedAt":33},"01M6KHBK93J4MPCQEW08K9DAFC","tools","Manage MCP tools with natural language commands — list, enable, disable tools and tool groups","https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftools\u002FSKILL.md",[122],{"categoryNo":123,"categoryName":124,"taxonomyType":125,"taxonomyTypeDesc":126},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[128,115,92,129,130,131,132,133,134,135,136],"Tools","commands","natural language","language","manage","list","MCP","tool","mcp tools",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":33},"01M6KHBF33ZBM85JAMKFH17WER","stack-set","Auto-detect project tech stack and generate stack-specific references for domain skills","https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fstack-set\u002FSKILL.md",[],[144,145,146,147,148,149,96,94,150,151,92,91,152],"SET","stack","stack set","generate","auto","references","tech","detect","auto-detect",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":33},"01M6KHBD7SDS6HCK1A79DNK4AZ","setup","oh-my-agent project setup verification and configuration","https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsetup\u002FSKILL.md",[],[155,94,160,161,28,92,162],"verification","project setup","my",{"skillNo":164,"name":19,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":33},"01M6KHBAFKX9WWN5N3WE06MX97","SCM workflow for Git operations (branching\u002Fmerge\u002Fconflict\u002Fworktree) plus Conventional Commit execution.","https:\u002F\u002Fgithub.com\u002Fwooloolies\u002Fedcurate\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fscm\u002FSKILL.md",[],[19,169,170,21,171,172,173,174,175,176,32,92,91,110],"commit","merge","worktree","conventional commit","execution","operations","conflict","git operations"]