sync-template
Skill8 starsChanged 7 months agoMITView on GitHub
Update an existing project's Claude Code configuration against the current dotforge template, without losing local customizations.
- Reads credentials
13 other projects use a version of this.
Adopted by
Most recently taken up by
- Littlpinguin/marketing-cockpit-templatetheir own version, first seen Nov 3, 2026
- AIBiz-Automatyzacje/claude-code-startertheir own version, first seen Nov 3, 2026
- AIBiz-Automatyzacje/claude-crontheir own version, first seen Nov 2, 2026
- dagonet/claude-code-toolkittheir own version, first seen Nov 1, 2026
- vandalsvq/edt1c-ai-templatetheir own version, first seen Oct 29, 2026
- mugnavo/tanstartertheir own version, first seen Oct 8, 2026
Other versions13 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 13
- dotnize/react-tanstarter★ 1.4ksame name
- mugnavo/tanstarter★ 1.4ksame name
- IcelandicIcecream/aphex★ 277same name
- josipjelic/orchestrated-project-template★ 96same name
- AIBiz-Automatyzacje/claude-code-starter★ 94same name
- tranhieutt/software_development_department★ 71same name
- vandalsvq/edt1c-ai-template★ 23same name
- lhpaul/ai-dev-framework-template★ 9same name
- Littlpinguin/marketing-cockpit-template★ 9same name
- dagonet/claude-code-toolkit★ 4same name
3 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository20 other files it gives its agents.
- .claude/rules/agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- audit-projectSkill
- bootstrap-projectSkill
- capture-practiceSkill
- diff-projectSkill
- domain-extractSkill
- export-configSkill
- forge-behaviorSkill
- init-projectSkill
- learn-projectSkill
- mcp-addSkill
- plugin-generatorSkill
- reset-projectSkill
- rule-effectivenessSkill
- scout-reposSkill
- session-insightsSkill
- sync-all-reposSkill
- update-practicesSkill
- watch-upstreamSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. 0 are common, 6 are distinctive, and 12 are very specific to this project.
0
Common
Most of the 8 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
12
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Update the current project's Claude Code configuration against the latest version of dotforge.
- Very specific: line 12
NEVER overwrite existing files without confirmation.
- Very specific: line 13
NEVER touch settings.local.json — it is the user's personal configuration.
- Very specific: line 14
NEVER modify sections marked with <!-- forge:custom --> in CLAUDE.md.
- Very specific: line 18
Before syncing the project, verify that ~/.claude/CLAUDE.md exists and contains behavior rules (communication, planning, autonomy).
- Very specific: line 22
Read the current .claude/settings.json
- Very specific: line 27
Read ~/.claude/CLAUDE.md to know which rules are already covered globally
- Very specific: line 31
Run bash "$DOTFORGE_DIR/scripts/forge-doctor.sh" .
- Distinctive: line 49
hooks: add missing hooks from template.
- Very specific: line 51
attribution: if the project file holds the boolean form ("attribution": false, v2.1.281+), convert it to the object form {"commit": "", … - Distinctive: line 65
Verify that existing hooks are executable (chmod +x)
- Distinctive: line 106
Only apply the changes the user approves.
- Distinctive: line 117
If validation fails, show the exact error and DO NOT write the file.
- Very specific: line 123
After applying changes, update (or create) .claude/.forge-manifest.json:
- Distinctive: line 125
If manifest exists, read it
- Very specific: line 130
Update dotforge_version, synced_at, and stacks (from detected stacks)
- Distinctive: line 131
Write the updated manifest
- Very specific: line 156
Run the /audit-project logic to confirm the score improved or held steady.
“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Sync Template
Update the current project's Claude Code configuration against the latest version of dotforge.
Principle: merge, not overwrite
NEVER overwrite existing files without confirmation. Compare and propose changes.
NEVER touch settings.local.json — it is the user's personal configuration.
NEVER modify sections marked with <!-- forge:custom --> in CLAUDE.md.
Step 0: Verify global
Before syncing the project, verify that ~/.claude/CLAUDE.md exists and contains behavior rules (communication, planning, autonomy). If global rules are active, the project's _common.md only needs technical rules (git, naming, testing, security). Do not duplicate what is already in global.
Step 1: Detect current state
- Read the current
.claude/settings.json - Read the current
CLAUDE.md. If it is a symlink (e.g. toAGENTS.md), resolve it withrealpathand apply every CLAUDE.md change to the target file — never replace the link with a regular file. IfAGENTS.mdexists next to aCLAUDE.mdthat has no@AGENTS.mdline, report it in the sync summary (AGENTS.md ignored by Claude Code — add "@AGENTS.md" to CLAUDE.md or run /import) but do not change either file without confirmation - Read existing
.claude/rules/ - Read existing
.claude/hooks/ - Detect stacks using
$DOTFORGE_DIR/stacks/detect.md - Read
~/.claude/CLAUDE.mdto know which rules are already covered globally
Step 1b: Classify managed files (forge-doctor)
Run bash "$DOTFORGE_DIR/scripts/forge-doctor.sh" . --json and apply this policy per file for the rest of the sync:
| Class | Meaning | Sync action |
intact | hash equals the manifest | overwrite with the template version without asking (nothing local to lose) |
drifted | local edits since last sync | show the diff, propose a merge, apply only on confirmation |
missing | in manifest, deleted locally | offer to recreate; treat deletion as intentional if the user declines |
unmanaged | under .claude/ but not in the manifest | never touch; list in the report |
Exit 2 = no manifest (pre-v2.x project): treat every file as drifted. Record the classification counts in the final report.
Step 2: Compare against template
For each component, compare with the dotforge version:
settings.json — Smart merge
- allow: union of sets. Add missing permissions from base template + stacks. NEVER remove local permissions the project already has.
- deny: union of sets. Add missing security denies. NEVER remove local denies.
- hooks: add missing hooks from template. Preserve custom project hooks.
- Other fields: preserve everything that is not allow/deny/hooks (e.g., MCP configs).
attribution: if the project file holds the boolean form ("attribution": false, v2.1.281+), convert it to the object form{"commit": "", "pr": "", "sessionUrl": false}— older CLIs skip a settings file containing the boolean, silently dropping every other key in it.- Never write project-scope-inert keys:
permissions.defaultMode: auto|bypassPermissions,sandbox.credentials,sandbox.ripgrep,sandbox.excludedCommandsunder a managed sandbox, telemetry/OTELenv,CLAUDE_CONFIG_DIR/TMPDIRenv,modelPicker,instructionFiles. Claude Code ignores them in.claude/settings.json/settings.local.json(v2.1.252–v2.1.290) — they belong in~/.claude/settings.jsonor managed settings. If a project already has one, warn in the sync report instead of propagating it. Seedomain/permission-managed-settings.md§ Project/local scope cannot widen policy.
Rules
- Is
_common.mdmissing? → propose adding it - Are rules for the detected stack missing? → propose adding them
- Are existing rules outdated? → show diff, propose update
- Custom project rules (not in template) → DO NOT TOUCH
.claude/rules/domain/→ NEVER TOUCH. Domain rules are project-owned knowledge, not template-managed. Skip entirely during sync.
Hooks
- Is
block-destructive.shmissing? → propose adding + chmod +x - Is the stack's lint hook missing? → propose adding + chmod +x
- Custom project hooks → DO NOT TOUCH
- Verify that existing hooks are executable (chmod +x)
CLAUDE.md
- Compare standard template sections with the project's sections
- Sections with
<!-- forge:custom -->→ SKIP entirely - Missing template sections → propose adding
- Custom project sections → DO NOT TOUCH
Step 3: Generate dry-run
Show the user what would change BEFORE applying anything:
═══ SYNC DRY-RUN: {{project}} ═══
dotforge: {{version}} (current project: {{previous_version or "unknown"}})
NEW FILES (will be created):
+ .claude/rules/_common.md
+ .claude/hooks/block-destructive.sh
UPDATED FILES (merge):
~ .claude/settings.json
+ allow: "Bash(docker *)", "Bash(docker compose *)"
+ deny: "**/.env.local"
(local permissions preserved: "Bash(custom-script *)")
~ .claude/rules/backend.md
diff: +3 lines (new common errors)
NO CHANGES:
= .claude/rules/frontend.md (already up to date)
= .claude/hooks/lint-ts.sh (already up to date)
IGNORED (custom):
⊘ .claude/rules/strategies.md (not in template)
⊘ CLAUDE.md section "<!-- forge:custom -->"
Apply changes? (yes/no/select)Step 4: Apply with confirmation
Only apply the changes the user approves.
yes→ apply allno→ cancelselect→ show each change and ask yes/no individually
For settings.json: build the final merged JSON. Before writing, validate that the JSON is valid:
echo '<json_content>' | python3 -c 'import json,sys; json.load(sys.stdin)'If validation fails, show the exact error and DO NOT write the file. Fix the JSON before continuing.
For hooks: copy + chmod +x.
Step 4b: Update manifest
After applying changes, update (or create) .claude/.forge-manifest.json:
- If manifest exists, read it
- For each file created or modified during sync, recalculate hash:
shasum -a 256 <file> | cut -d' ' -f1 - Update
dotforge_version,synced_at, andstacks(from detected stacks) - Write the updated manifest
Format:
{
"dotforge_version": "<version from $DOTFORGE_DIR/VERSION>",
"synced_at": "<current date YYYY-MM-DD>",
"stacks": ["<detected-stack-1>", "<detected-stack-2>"],
"files": {
".claude/settings.json": {"hash": "sha256:<hash>", "source": "template+stacks"},
".claude/rules/_common.md": {"hash": "sha256:<hash>", "source": "template"}
}
}Include ALL files in .claude/ that are managed by dotforge (not only those that changed in this sync).
Step 5: Update registry
Update in $DOTFORGE_DIR/registry/projects.local.yml:
last_sync:→ current datedotforge_version:→ current dotforge version
Step 6: Verify
Run the /audit-project logic to confirm the score improved or held steady.
Show score before and after.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

