agentleFS
luiseimanluiseiman/dotforge/skills/sync-template/SKILL.md

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

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
  1. Very specific:

    Update the current project's Claude Code configuration against the latest version of dotforge.

    line 8
  2. Very specific:

    NEVER overwrite existing files without confirmation.

    line 12
  3. Very specific:

    NEVER touch settings.local.json — it is the user's personal configuration.

    line 13
  4. Very specific:

    NEVER modify sections marked with <!-- forge:custom --> in CLAUDE.md.

    line 14
  5. Very specific:

    Before syncing the project, verify that ~/.claude/CLAUDE.md exists and contains behavior rules (communication, planning, autonomy).

    line 18
  6. Very specific:

    Read the current .claude/settings.json

    line 22
  7. Very specific:

    Read ~/.claude/CLAUDE.md to know which rules are already covered globally

    line 27
  8. Very specific:

    Run bash "$DOTFORGE_DIR/scripts/forge-doctor.sh" .

    line 31
  9. Distinctive:

    hooks: add missing hooks from template.

    line 49
  10. Very specific:

    attribution: if the project file holds the boolean form ("attribution": false, v2.1.281+), convert it to the object form {"commit": "", …

    line 51
  11. Distinctive:

    Verify that existing hooks are executable (chmod +x)

    line 65
  12. Distinctive:

    Only apply the changes the user approves.

    line 106
  13. Distinctive:

    If validation fails, show the exact error and DO NOT write the file.

    line 117
  14. Very specific:

    After applying changes, update (or create) .claude/.forge-manifest.json:

    line 123
  15. Distinctive:

    If manifest exists, read it

    line 125
  16. Very specific:

    Update dotforge_version, synced_at, and stacks (from detected stacks)

    line 130
  17. Distinctive:

    Write the updated manifest

    line 131
  18. Very specific:

    Run the /audit-project logic to confirm the score improved or held steady.

    line 156

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Read the current .claude/settings.json
  2. Read the current CLAUDE.md. If it is a symlink (e.g. to AGENTS.md), resolve it with realpath and apply every CLAUDE.md change to the target file — never replace the link with a regular file. If AGENTS.md exists next to a CLAUDE.md that has no @AGENTS.md line, 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
  3. Read existing .claude/rules/
  4. Read existing .claude/hooks/
  5. Detect stacks using $DOTFORGE_DIR/stacks/detect.md
  6. Read ~/.claude/CLAUDE.md to 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:

ClassMeaningSync action
intacthash equals the manifestoverwrite with the template version without asking (nothing local to lose)
driftedlocal edits since last syncshow the diff, propose a merge, apply only on confirmation
missingin manifest, deleted locallyoffer to recreate; treat deletion as intentional if the user declines
unmanagedunder .claude/ but not in the manifestnever 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.excludedCommands under a managed sandbox, telemetry/OTEL env, CLAUDE_CONFIG_DIR/TMPDIR env, modelPicker, instructionFiles. Claude Code ignores them in .claude/settings.json / settings.local.json (v2.1.252–v2.1.290) — they belong in ~/.claude/settings.json or managed settings. If a project already has one, warn in the sync report instead of propagating it. See domain/permission-managed-settings.md § Project/local scope cannot widen policy.

Rules

  • Is _common.md missing? → 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.sh missing? → 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 all
  • no → cancel
  • select → 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:

  1. If manifest exists, read it
  2. For each file created or modified during sync, recalculate hash:
    shasum -a 256 <file> | cut -d' ' -f1
  3. Update dotforge_version, synced_at, and stacks (from detected stacks)
  4. 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 date
  • dotforge_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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.