standardize-repo

name	standardize-repo
description	Apply the harmon-init Copier template's conventions (DevOps tooling, CI/CD, lint, security, git hooks, Taskfile) to a repo. Use whenever the user wants to "apply harmon-init", "scaffold a new repo with my conventions", "set up a new project", "adopt the template", "bring this repo up to my standards", "standardize this repo", or "audit this repo against my standards / check what's missing". Covers three modes: scaffolding a brand-new/empty repo, retrofitting an existing repo with git history, and auditing a repo for drift from the standards. Trigger it even if the user doesn't say the word "skill".
allowed-tools	Bash, Read, Write, Edit, Grep, Glob, Task, WebFetch

Standardize Repo (apply harmon-init conventions)

Bring a repo in line with the harmon-init Copier template — the shared baseline of DevOps tooling, CI/CD, linting, secrets scanning, lefthook git hooks, and a Taskfile.yml task runner. harmon-init is the template repo of harmon-platform (siblings: harmon-devkit, harmon-dotfiles, harmon-ops, harmon-infra); this skill is how an agent consumes that template to scaffold new repos or standardize existing ones. harmon-init is NOT an application — it is used via Copier, so the heavy lifting is copier copy / copier update, not hand-copying files.

Preconditions

Verify these before doing anything; stop and tell the user if one is unmet.

• copier installed — copier --version (needs >= 9.4.0, per _min_copier_version).
• harmon-init cloned locally at ~/git/harmon-init. If missing: git clone https://github.com/evanharmon1/harmon-init ~/git/harmon-init.
• task (go-task) on PATH — task --version — for the verification gate.
• gh authenticated (gh auth status) — only needed for the GitHub side-effect steps (remote create, release init). Not required for local scaffolding.

Mode routing

Detect the situation, then follow the matching reference file end to end.

Situation	Mode	Reference
Target dir is empty / does not exist yet (new project)	new-repo	references/mode-new-repo.md
Target is an existing repo with git history (retrofit)	adopt-existing	references/mode-adopt-existing.md
Repo already generated from harmon-init (v3+, has .copier-answers.yml) and user wants the latest template changes ("update", "keep in sync", "pull latest harmon-init")	update	references/mode-update.md
User says "audit" / "check" / "what's missing" / "bring up to standard" / drift report	audit	references/mode-audit.md

If it is ambiguous (e.g. a non-empty dir that is not a git repo), ask the user which mode they want rather than guessing — copier copy vs copier update behave very differently.

Cardinal copier rules (read before running any copier command)

These are load-bearing. Full rationale and edge cases in references/copier-gotchas.md.

• When rendering from a local path (copier copy), always pass --vcs-ref=HEAD. Without it, copier renders the latest git tag of harmon-init and silently ignores all uncommitted and committed-but-untagged work. With it, copier auto-includes dirty/untracked changes via a throwaway commit in a temp clone (DirtyLocalWarning) — the working tree is never touched. This rule is about which ref to render, not where the template lives — and it applies to copier copy, not copier update. An update reuses the recorded _src_path and tracks released tags: a generated repo's committed _src_path should be the GitHub URL (not a machine-local path), and a normal copier update takes no --vcs-ref. See copier-gotchas.md gotchas 1 (render ref) & 8 (_src_path).

• Side-effectful answers default to no in copier.yml (github_remote_create, github_release_init, bunch_add, obsidian_project_add, run_task_install). Leave them off unless the user explicitly asks; only flip them on with confirmation.

• Run non-interactively with --data key=value for known answers and --defaults for the rest, so runs are reproducible and CI-safe. Use --trust (the template has _tasks). Example shape:

  copier copy ~/git/harmon-init ./new-project \
    --vcs-ref=HEAD --trust \
    --data project_name="My Project" --data project_type=general --defaults
  

• Validate after every apply. Re-running copier or changing answers can churn files — confirm the result with the verification step below before committing.

The asked questions live in ~/git/harmon-init/copier.yml (e.g. project_name, project_slug, project_description, github_org, project_type [general / web-astro / web-app / iac / docs], snyk_scan_schedule [off / weekly / daily], include_terraform, include_ansible, ci_runner, license, use_release_please, devcontainer, git_init). Read that file to confirm names/choices/defaults before scaffolding — do not invent answers.

Standards catalog

The authoritative, itemized list of what "standardized" means — every tool, config file, Taskfile target, hook, and CI workflow the template provides, and how to check each — is references/standards-catalog.md. The audit mode and any manual retrofit work off that catalog. Treat the generated template output (and that catalog) as the source of truth, not memory.

Verification

After applying any mode, run the bundled check:

assets/verify-applied.sh <target-repo-dir>

It confirms the expected files/tooling landed and then runs the repo's own gate (task verify = lint + template/output checks; task check for lint only; task install:hooks to wire lefthook). Report what passed and surface any gaps against references/standards-catalog.md. Never bypass hooks (--no-verify is prohibited); commit on a feature branch and open a PR — no direct commits to main.