菜单
Promote rules, skills, or agents from project scope to parent or user-global scope. Use when reorganizing .claude/ directories or when sibling repos hold near-duplicate rules.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/laurigates/claude-plugins --skill meta-promote命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| created | "2026-05-09T00:00:00.000Z" |
| modified | "2026-07-18T00:00:00.000Z" |
| compatibility | claude-code |
| reviewed | "2026-05-09T00:00:00.000Z" |
| allowed-tools | Glob, Read, Edit, Write, Bash(git status *), Bash(git diff *), Bash(git mv *), Bash(diff *), Bash(rm *), AskUserQuestion, TodoWrite |
| model | opus |
| description | Promote rules, skills, or agents from project scope to parent or user-global scope. Use when reorganizing .claude/ directories or when sibling repos hold near-duplicate rules. |
| args | [scope-path] |
| argument-hint | [scope-path] |
| name | meta-promote |
| Use this skill when... | Use a different skill when... |
|---|---|
Two or more sibling .claude/ scopes hold rules/skills/commands with the same name or topic, and you want to decide whether to lift them up to a shared parent | You want to copy a project's config into your user-global config (use meta-assimilate) |
A portfolio root (e.g. ~/repos/) has children whose configs overlap and you want to promote the common kernel | You want to review existing agent configs for security and frontmatter completeness without changing scopes (use meta-audit) |
| You suspect a rule is duplicated across sibling repos and want a structured promotion / extraction / keep-scoped decision per file | You want to author a brand-new skill from scratch (use custom-agent-definitions) |
pwd.claude/ tree: !find . -path '*/.claude/*' -maxdepth 4 -type f -name '*.md' -not -path '*/node_modules/*' -not -path '*/.claude/worktrees/*'.claude/ trees (one level down): !find . -mindepth 2 -maxdepth 4 -type d -name '.claude' -not -path '*/node_modules/*'Parse $ARGUMENTS:
scope-path (optional, default .) — the directory whose children's .claude/ trees should be evaluated for promotion up to this directory. The skill always treats scope-path as the target scope and its immediate .claude/-bearing children as the source scopes.Execute this evaluation and (with approval) apply it. Do not promote anything without explicit per-candidate confirmation — promotion is a write to shared state and easy to get wrong.
Walk three layers:
| Layer | Path | Role |
|---|---|---|
| Target | <scope-path>/.claude/{rules,skills,commands,agents}/ |
| Where promoted files would land |
| Sources | <scope-path>/*/.claude/{rules,skills,commands,agents}/ | Children whose contents are candidates |
| Upstream | User-global .claude/rules/ (resolve $HOME/.claude/rules during execution, not in the Context block) and any plugin skills already loaded for this session | Already-covered material — promotion to the target would just duplicate this |
For the upstream layer, run Glob(pattern="$HOME/.claude/rules/**/*.md") during execution and read filenames + first heading of each match. The plugin-skill list is already in the session prompt — scan it for relevant entries by name.
For each source file, record (scope, kind, name, path) where kind ∈ {rule, skill, command, agent} and name is the filename or skill directory name.
Group source files by (kind, name). Three kinds of overlap matter:
ci-cd-workflows.md in both OrgA/.claude/rules/ and OrgB/.claude/rules/)commits.md and commit-conventions.md)Files that appear in only one source and have no target-scope sibling are not promotion candidates — they are correctly scoped already.
For each candidate group, read every file and apply this checklist. Every "yes" makes promotion less appropriate:
| Signal | What to look for |
|---|---|
| Owner-specific identifiers | Org or user names (OrgA, some-user), GH repo URLs, container registry paths (ghcr.io/<org>/...), GitHub App IDs, secret names, named workspaces (Terraform Cloud, Spacelift) |
| Owner-specific conventions | Label sets (docs vs documentation), reviewer usernames (@user vs bare user), project-routing tables, CI tool choices (Renovate vs Dependabot) |
| Path-scoped frontmatter that differs | A paths: glob that genuinely targets a different directory shape per source |
| Tooling assumptions | Helm chart names, image-updater configurations, deploy-values schemas tied to one stack |
| Already covered upstream | A user-global rule, a plugin skill, or a friction-findings note already says the same thing — promoting would duplicate, not consolidate |
Then ask the inverse: what's generic about this file? Is there a kernel (a self-review guard, a "use conventional commits" preamble, a generic checklist) that applies regardless of owner?
Pick exactly one of four:
| Action | When | What it does |
|---|---|---|
| Promote as-is | All sources have effectively identical content; no owner-specific signals; not already upstream | git mv one source copy to the target scope; delete siblings |
| Extract kernel | Sources share a generic core but each carries owner-specific deltas | Write the generic content as a new file at the target scope; trim each source down to only the deltas, with a one-line link back to the target file |
| Keep scoped | Content genuinely differs per owner; a unified version would force one set of conventions on the others | Leave files where they are; optionally add a one-line frontmatter comment explaining the divergence so future readers don't re-evaluate |
| No action (already upstream) | The user-global rule or a plugin skill already covers this | Optionally delete the redundant source copies; do not write to the target |
For each candidate group, present:
diff <a> <b> for two-source cases; a 3-way summary for more)AskUserQuestionOnly proceed on explicit approval. Do not bundle multiple candidate decisions into one prompt — each gets its own approval round-trip so the user can redirect on any single one.
| Action | Mechanics |
|---|---|
| Promote as-is | git mv <source-1> <target> to preserve history, then rm the other sources. If the source repos are independent (separate .git per scope), use cp + rm instead of git mv. |
| Extract kernel | Use Write to create the target file with the generic content. Use Edit on each source to remove the now-shared content, replacing it with one line of the form > Generic guidance: see [\`]().` |
| Keep scoped | Optionally Edit each source to add an HTML comment <!-- intentionally scoped: <reason> --> near the top so the next pass through this skill skips it quickly. |
| No action | Optionally rm the redundant sources; never write to the target. |
After every write, run git status against each affected repo so the user sees exactly what changed before any commit happens.
Emit a final summary table:
| Source files | Action | Target | Notes |
|---|---|---|---|
OrgA/.claude/rules/foo.md, OrgB/.claude/rules/foo.md | Keep scoped | — | Org-specific label conventions |
OrgA/.claude/rules/bar.md, OrgB/.claude/rules/bar.md | Promote as-is | ./.claude/rules/bar.md | Identical content, no owner signals |
End with the next step the user should take (typically: review git status in each affected repo, then commit per-repo with conventional-commit messages — meta-promote itself does not commit).
Occasionally a rule lives at user-global scope but is genuinely owner- or project-specific. The same evaluation applies in reverse: if a ~/.claude/rules/<x>.md references one org's tooling and would mislead anyone outside that org, propose moving it down to the appropriate <owner>/.claude/rules/. Use the same four-action menu — "Promote" becomes "Demote", "Extract kernel" stays the same.
| Don't | Do |
|---|---|
| Promote two same-named files just because the names match | Diff their contents and apply the checklist — same name often hides genuinely different rules |
| Bundle "promote A and B" into one approval prompt | One candidate, one prompt — the user may agree on A and reject B |
Use rm -rf on a scope's .claude/ to "clean up" after promotion | Remove only the specific files you're promoting; leave the rest of the scope alone |
| Commit the promotion as part of the skill | Leave commits to the user — the skill produces a clean working tree the user can review and split into per-repo commits |
| Promote when an upstream rule already covers it | Recommend "no action" and (with approval) delete the redundant source(s) |
.claude/ scope under scope-path; the write phase touches only the specific files the user approved.meta-audit for a follow-up sanity check after promotion: meta-audit will catch any frontmatter that broke during the move.