cross-repo-standard-sync

Cross-repository standards synchronization

Keep a development rule consistent without pretending every repository has the same owner, stack, commands, or exceptions. A canonical source is selected by who owns the rule, not by which copy happens to be easiest to find.

Classify ownership before choosing a source

For each rule, identify its scope:

• Personal defaults: preferences the user wants applied across their work.

Store them in a user-owned, private, versioned source when they include personal or confidential context.

• Organization policy: rules owned by a team or organization. Use that

organization's maintained source; do not recast it as an individual preference or move it into a public repository.

• Repository facts: actual commands, dependencies, CI, local services,

architecture, and approved exceptions. These remain authoritative in the repository that owns them.

• Public reusable guidance: portable, sanitized practices only. A public

skills collection is not the canonical home for private preferences or organization-specific policy.

One rule may combine a shared default with repository-specific facts. Keep the shared principle in its owner source and keep local values in the repository; do not duplicate the whole document just to carry a few local differences.

Discover the canonical source

When asked to find or define a source of truth:

1. Inventory candidate documents, skill files, generated copies, repository

remotes, and configured agent skill/rule locations. Start read-only.

1. Compare content and metadata, but do not treat matching hashes, newest

timestamps, a global install, or a public catalog as proof of ownership.

1. For each rule, record its owner, canonical path/repository, audience, and

intended targets. Distinguish source files from generated or installed copies.

1. If ownership is unclear or two sources conflict, show the conflict and ask

the user which source should win. Do not silently appoint a canonical copy.

1. Keep secrets, private identifiers, and confidential source text out of

command output, reports, and public files.

Audit drift

Compare each target with only the rules that apply to it. Classify differences as:

• stale shared guidance that should be updated;
• valid repository-specific facts or exceptions that must remain local;
• an intentional team or project override with an identified owner; or
• an unresolved conflict requiring a decision.

Report drift with file/section references and a concise description. Redact private paths, URLs, identifiers, and sensitive content when the report may be shared. An audit is read-only unless the user also authorizes changes.

Synchronize only approved targets

Before writing, establish the canonical revision, target repositories and agent configurations, and which files/sections are managed. Then:

1. Show a per-target plan or diff before broad propagation.
2. Prefer a generator, package/install mechanism, or clearly marked generated

blocks over manually editing many copies. Use symlinks only where the target agent and deployment environment support them reliably.

1. Never overwrite repository-specific commands, facts, credentials, or

intentional exceptions with generic text. Preserve unmanaged content exactly.

1. Do not modify a dirty file or a target with an unresolved ownership conflict

without resolving the conflict with the user first.

1. Apply only to the repositories and configuration roots the user approved.

Synchronizing a policy does not authorize committing, pushing, publishing, or installing globally.

1. Validate generated files, links, frontmatter, and relevant local checks.

Provide a check/dry-run mode or drift report when the existing tooling supports it; do not invent a command and claim it ran.

Precedence and exceptions

Do not impose one universal precedence for every organization. Use the owners' documented hierarchy. In general:

• mandatory security, legal, and organization policy cannot be weakened by a

personal preference;

• a repository's verified technical facts determine its local commands and

setup;

• personal preferences apply where compatible with those constraints;
• exceptions should be local, explicit, narrowly scoped, and have an owner or

reason so they do not become accidental forks of shared policy.

If two applicable rules cannot be reconciled, stop before changing files and ask which policy governs.

Completion report

Summarize the canonical source selected (or state that it remains undecided), the targets audited or changed, local exceptions preserved, unresolved conflicts, and validation performed. Do not claim synchronization is complete if any approved target was skipped or could not be verified.