project-sync
Fan out the current repo's CLAUDE.md, .claude/commands, and .claude/skills into Codex, Gemini, and Copilot project-scope analogues (.codex/skills, .gemini/skills, .github/prompts, .github/instructions) plus refresh AGENTS.md, GEMINI.md, and .github/copilot-instructions.md from the project's rule floor. Wraps `dotbabel project-sync`. Use when adopting cross-CLI workflows in a repo for the first time, or when adding a new command/skill that needs to be visible to Codex/Gemini/Copilot. Triggers on: "sync this repo", "project sync", "fan out commands", "wire up gemini for this project", "add this command to codex", "make this skill available in copilot", "regenerate AGENTS.md for this project".
- License 许可
- MIT
- 最近更新
- 2026-10-26
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- project-sync
- description
- Fan out the current repo's CLAUDE.md, .claude/commands, and .claude/skills into Codex, Gemini, and Copilot project-scope analogues (.codex/skills, .gemini/skills, .github/prompts, .github/instructions) plus refresh AGENTS.md, GEMINI.md, and .github/copilot-instructions.md from the project's rule floor. Wraps `dotbabel project-sync`. Use when adopting cross-CLI workflows in a repo for the first time, or when adding a new command/skill that needs to be visible to Codex/Gemini/Copilot. Triggers on: "sync this repo", "project sync", "fan out commands", "wire up gemini for this project", "add this command to codex", "make this skill available in copilot", "regenerate AGENTS.md for this project".
- argument-hint
- [--dry-run] [--all] [--repo <path>]
02 资源文件 1
- 参考文档references/copilot-mapping.md2.3 KB
03 SKILL.md 正文
project-sync — Repo-local cross-CLI fan-out
Thin wrapper around dotbabel project-sync. The binary owns all writes; this
skill maps natural-language requests to the right invocation and surfaces
dry-run output before mutating the repo.
When to invoke
- The user wants to adopt cross-CLI workflows in a repo that already has
.claude/commands/*or.claude/skills/*, but noAGENTS.md/GEMINI.md/.github/prompts//.github/instructions/wiring. - A new command or skill was just added to
.claude/, and the user wants Codex/Gemini/Copilot to see it without leaving the editor. - The user asks for "drift check" or "is this repo synced" — run
dotbabel check-project-syncinstead and surface the diff. - First-time setup: if
.dotbabel.jsonis missing, suggestdotbabel project-initfirst.
Workflow
- Pre-flight. Confirm cwd is a git repo and contains
CLAUDE.md(with or without rule-floor markers) plus at least one of.claude/commands/or.claude/skills/. If.dotbabel.jsonis absent, mention that defaults will apply (nocli_substitutions, full fan-out to codex/gemini/copilot, gating on each CLI'scommand -vcheck). - Dry-run first. Always run
dotbabel project-sync --dry-runbefore mutating. Summarize the planned actions to the user (count of instruction files, count of new symlinks per CLI). Pause for confirmation unless the user already said "do it" or "go ahead" in the same turn. - Apply. Run
dotbabel project-sync(no--dry-run). If the user passed--all, propagate it. - Verify. Run
dotbabel check-project-syncand reportok/missing/stalecounts. Exit non-zero output should be surfaced. The check applies the samegate_on_cli_presencegate as the sync, so a CLI absent fromPATHis reported asskipped <cli>: not on PATHrather than as drift. Propagate--allhere too when the user passed it in step 3, so both commands cover the same CLIs.
Triggers and invocations
| Trigger phrase | Invocation |
|---|---|
| "sync this repo", "project sync", "fan out commands" | dotbabel project-sync --dry-run then apply |
| "wire up gemini for this project" | dotbabel project-sync --all (covers all) |
| "is this repo synced", "drift check the project sync" | dotbabel check-project-sync (read-only) |
| "regenerate AGENTS.md for this project" | dotbabel project-sync (instructions are part of the run) |
| "set up project sync here", "first-time project sync" | dotbabel project-init then project-sync |
Reference: Copilot mapping
The Copilot CLI fan-out targets .github/prompts/*.prompt.md (commands) and
.github/instructions/*.instructions.md (skills) inside the target repo.
See references/copilot-mapping.md for the
full layout and rationale.
Boundaries
- Always operate on the user's current working directory unless they pass an
explicit
--repo <path>. Never silently target a different repo. - Never run
--force. The plan reserves it for collision overrides; defer to the binary's existing collision warnings. - For consumer repos with no
.dotbabel.json, the convention path applies (entireCLAUDE.mdbecomes the rule floor when markers are absent). fan_outaccepts onlycodex,gemini, andcopilot. A typo aborts the run withCONFIG_UNKNOWN_CLI; fix the name rather than dropping the gate.fan_out_layoutisper-cliby default. Undershared, Codex and Gemini both point at one.cli/skills/tree, so describe changes by the canonical path instead of naming each CLI directory twice. Switching an existing repo leaves.codex/skills.bak-<timestamp>behind — say so, so the user can delete it. An unknown value aborts withCONFIG_UNKNOWN_LAYOUT.cli_excludedmaps a CLI to command basenames and skill ids it must not receive. Suggest it when a command describes a Claude-only flow. The sync removes an excluded link it wrote earlier and reportsremoved: <path>; mention that so the user expects the deletion in the diff. Undershared, an exclusion forcodexorgeminiapplies to both and the sync warns when the lists differ. A malformed value aborts withCONFIG_INVALID_EXCLUSION.- This skill is for project-scope sync. For user-scope (
~/.claude/,~/.codex/,~/.gemini/) bootstrap, usedotbabel bootstrapinstead.
04 同仓库更多 Skills
yolo
Start temporary autonomy for the current task or an explicit scope with a required --for expiry. Codex permits scoped pushes, merges, deploys, and releases after strict testing and validation; Full access is a separate runtime setting. Claude Code uses a session permission hook with a protected-action denylist.
veracity-audit
Audit a data pipeline for Veracity and Value. Dispatches data-scientist, compliance-auditor, and data-engineer agents with project context injected at dispatch time. All source paths are supplied via flags — no defaults, no project assumptions. Subcommands: audit (full pipeline walk), score-check (scoring math only), gate-check (gate coverage only), source-trace <label> (single source end-to-end). Invoke when: "audit pipeline", "veracity check", "scoring math correct?", "check gates", "trace source", "verify quality gates", "formula correct?".
validate-spec
Audit an already-implemented spec against the codebase. Walks each constraint (ARCH-N, PERF-N, KD-N, etc.) and acceptance criterion, grounds findings in file:line evidence, runs the spec.json acceptance_commands, and writes a single audit doc to docs/audits/. Use whenever the user asks to "validate a spec", "audit a spec", "check if spec is implemented", "verify the spec is done", "is this spec really done", or otherwise wants closure on spec-driven work. Read-only against the spec — produces an audit, never modifies the spec itself.
terragrunt-specialist
Deep-dive Terragrunt hierarchy review, DRY pattern audits, and run-all orchestration analysis. Use for structured investigations of multi-environment Terragrunt layouts, dependency graphs, remote state config, and hook correctness. Triggers on: "Terragrunt audit", "run-all review", "dependency block", "DRY pattern review", "env hierarchy audit", "mock_outputs", "terragrunt hooks".
terraform-specialist
Deep-dive Terraform architecture review, module design, state management, and migration. Use for structured investigations of Terraform workspaces, provider configuration, module coupling, import workflows, and test coverage. Triggers on: "Terraform audit", "module review", "state management", "Terraform import", "workspace design", "provider config review", "Terraform testing".
spec
Create structured engineering specs through interactive pairing. Use when the user wants to create a spec, design doc, technical specification, architecture document, RFC, or engineering plan. Triggers on "let's spec this out", "create a spec", "design doc", "write a technical plan", "plan the architecture". Works for greenfield and brownfield projects. Outputs to docs/specs/.