repo-meta-structurelisted

The canonical repo meta-structure standard — consult it whenever a question is about "what is the standard for X" in a repo's layout: the `_meta/` directory taxonomy (_archive/briefings/plans/operations/research + HANDOFF.md + README.md), the `.claude/` layout (what's tracked vs machine-local, commands/ as migration debt), the `.github/` template set, required root files, the gitignore conventions (track-by-default `_meta/` with the `operations/` ignore, `.env*` handling, the `.claude` stanza), the `_meta/plans/` planning-doc frontmatter schema, or where communication packages from the strategy desk land (`_meta/plans/inbox/`). Use when setting up or reviewing a repo's structure, answering layout questions, or checking what belongs where. This skill is reference content only — the compliance audit and mise-en-place scaffold are separate sibling skills that read this same content.
hsb3/dotfiles-agents · ★ 0 · Code & Development · score 70

Install: claude install-skill hsb3/dotfiles-agents

# Repo meta-structure standard The **single source** for the canonical repo layout. Three consumers read this identical content: a human/agent session (you, now), the repo-compliance-audit skill (checks against `references/checklist.md`), and the mise-en-place scaffold skill (produces from `assets/`). Nothing here is duplicated anywhere else — if the standard changes, it changes in these files. ## How to answer "what is the standard for X" | Question is about… | Read | |---|---| | Directory layout: `_meta/`, `.claude/`, `.github/`, root files, the AVOID list | `references/layout.md` | | A specific compliance check, its ID, or its pass condition | `references/checklist.md` | | Planning-doc frontmatter in `_meta/plans/`, or communication-package intake (`inbox/`) | `references/planning-docs.md` | | The exact `.gitignore` a conforming repo carries | `assets/gitignore.template` | | The `.github/` file set (issue forms, PR template, dependabot, workflows) | `assets/github/` | Answer from the reference content directly — do not reconstruct the standard from memory or from how some other repo happens to look. Repos deviate; the standard does not. Legitimate per-repo variance lives only in that repo's `_meta/mise-en-place.yml` manifest (owned by the mise-en-place scaffold skill), never as a silent exception to this content. ## What this skill does NOT do - **No auditing** — pass/gap verdicts come from the sibling `repo-compliance-audit` skill, which reads `references/checklis