Canonical Repo Structure

Concept of the skill

A repository is a map of ownership. Each artifact has one canonical source, zero or more generated projections, and at most one compatibility path per runtime that truly needs the old entrypoint.

Coverage

• Choosing the owning repo and canonical path before creating, moving, or deleting scripts, commands, prompts, docs, generated artifacts, skills, and compatibility entrypoints
• Separating authored source from generated projections so agents edit the real source and regenerate the output
• Preventing duplicate implementations: update the owner, convert one necessary compatibility path into a thin registered shim, or remove the extra path
• Deciding whether a legacy artifact is live, deprecated, confirmed dead, generated, historical, or a runtime-required compatibility entrypoint
• Deleting confirmed-dead code to git history instead of preserving _archive/, .legacy, commented-out blocks, or "kept just in case" copies
• Recording deprecation/removal reasons in the owning changelog with a date plus time-of-day when the owning repo requires timestamped prose
• Updating live references after moves/deletions while leaving frozen historical records accurate
• Committing path-limited in the repo that owns the changed files

Philosophy of the skill

A repo is not just storage. It is an operating map for future agents. When one command body lives in three places, no reader knows which behavior is real. When generated output is hand-edited, the next generation run destroys the change. When dead code is moved into _archive/, every grep, router, audit, and cold-start reader has to rediscover that the file is dead.