repo-harmonization

Repo Harmonization

If a slash or dollar invocation already added these instructions to the conversation, follow them directly. In that case, do not invoke this skill again through a skill tool.

Use a list of interdependent repositories to produce verified findings, user-approved decisions, and surgical changes. The audit covers two kinds of work:

• Alignment: drift, stale cross-references, duplicated content, and competing workflows among the repositories.
• Transfer: agent guidance, workflows, and dependencies that one repository uses well and another would benefit from. Adapt each transfer to the recipient's conventions.

Arguments

$ARGUMENTS is a whitespace-separated list of repository paths. Tilde expansion is allowed.

• Require at least two paths, each an existing Git repository root, resolving to distinct repositories. The inventory helper enforces these rules and exits 2 with the offending inputs. In that case, stop and relay its message.
• The user's request, not $ARGUMENTS, may narrow the focus to alignment or to transfers. Without such a request, do both. Pass only repository paths to the inventory helper. The one exception is the --drift flag in Template Drift.
• Do not infer additional repositories from links, remotes, or installed copies. The supplied list defines the audit boundary.

Contract

• Research before any edit and keep research strictly read-only. When the host supports subagents, parallelize across them. Otherwise, investigate serially.
• Verify every alignment or duplication claim mechanically with a diff, content hash, regeneration round-trip, or symlink resolution. Never rely on prose inspection alone. Attach file:line evidence to every finding.
• Treat every repository as both donor and recipient. Evaluate each transfer candidate per direction: donor, practice, recipient.
• A transfer unit is one practice: a guidance rule or project skill, a workflow (task recipe, script, CI job, hook, toolchain pin, lint, format, type-check, test, or release configuration), or a dependency together with the workflow or code that uses it. Never transfer a dependency the recipient would not use.
• Attach evidence to every transfer candidate. Include donor file:line showing the practice and that it is exercised (called by a task, CI, a hook, or code). Also include recipient search commands proving the gap, including functional equivalents under other names, and recipient evidence of the need the practice addresses.
• Classify each material finding exactly once, with the classes in Consolidate and Evaluate.
• Adapt rather than copy. Rewrite each transfer for the recipient's language, runtime versions, package manager, task runner, naming, file layout, formatting, and guidance voice. Transferred guidance names only commands, paths, and tools that exist in the recipient once the plan is applied.
• Never carry donor secrets, credentials, personal identifiers, hostnames, addresses, or project-specific names and assumptions into a recipient.
• Prefer surgical fixes to restructuring. Unless it removes more complexity than it adds, introduce no include pipeline, templating layer, shared reference, or other machinery.
• Prefer the smallest transfer that delivers the benefit: a task recipe over a new script, a config file over a wrapper, a short rule over a copied document. Shared packages, template repositories, sync pipelines, and submodules are judgment calls.
• Send every judgment call to the user before planning. Never expand beyond the approved decisions.
• Treat the approved outcome and resolved judgment calls, not the initial file manifest, as the implementation authorization boundary. When implementation discovers a related in-repository prerequisite needed to carry out those decisions, the orchestrator may extend the manifest, acquire coordination for the new scope, and delegate the smallest sufficient follow-on fix without asking again. Examples are a dev dependency, lockfile update, config stub, or ignore entry. Workers still stop at their assigned write scopes and return the evidence to the orchestrator.
• Respect every repository's generation pipelines and hooks. Edit canonical sources only. Regenerate artifacts through build-only non-committing paths. Let designed commit hooks run at commit time.
• Keep implementation agents from committing or pushing. The orchestrator commits per repository, scopes commits to task files, and honors the host's coordination and shared-worktree rules.
• Report progress at phase changes with measured counts (repositories inventoried, and findings found, verified, classified, and implemented) rather than elapsed time.