Standardize a newly entered or drifting repository for both humans and AI agents. Use this skill whenever a project lacks clear README/CONTRIBUTING/CHANGELOG or core runtime docs, lacks model-facing memory, or when code changes have likely invalidated docs or memory. On first entry, inspect the repository, identify maintained paths, core entry points, source-of-truth files, and output structure, then choose one mode: audit, bootstrap, or sync. Prefer this skill before deep development in unfamiliar repositories and whenever you want the project to remain easy for both humans and agents to understand.
Resources
16Install
npx skillscat add zitongzhaooo/repo-standardization-skill Install via the SkillsCat registry.
Repo Standardization
Standardize the repository before doing substantial work. The goal is not to generate generic documentation. The goal is to create and maintain:
- human-facing docs that explain the repository truthfully
- model-facing memory that is structured, traceable, and derived from real sources
Core Principles
- Treat code, tests, contracts, and authoritative docs as source of truth.
- Treat memory as a derived artifact for models, never as a second truth source.
- Prefer repository-specific summaries over boilerplate.
- Preserve existing conventions when the repository already has a clear style.
- Do not overwrite mature docs just because a template exists.
- Keep model memory compact, structured, and tied to source files.
Modes
Pick exactly one mode before making edits.
audit
Use when:
- you just entered a repository and want to assess readiness
- docs and memory exist but may be inconsistent
- the user asks for recommendations before changes
Expected outcome:
- a gap report
- a recommended mode (
bootstraporsyncornone) - a list of source-of-truth files and maintained paths
bootstrap
Use when:
- critical docs are missing
- there is no repository memory system
- the repository is new to the team or to the agent workflow
Expected outcome:
- minimal human docs or filled gaps in existing docs
memory/knowledge/skeleton.agent_memory/local structure recommendation- sync rules so future code changes update docs and memory
sync
Use when:
- docs and memory already exist
- code or contract files changed
- the repository likely drifted from its documentation or memory
Expected outcome:
- refreshed model memory
- targeted doc updates or a review list
- updated synchronization metadata
Decision Rules
Default mode selection:
- If critical human docs or model-memory roots are missing, use
bootstrap. - If they exist but source files changed, use
sync. - If the repository looks mature and the user asked for assessment, use
audit. - If the repository is already consistent and no change is needed, report that explicitly.
Do not treat every repo as needing a full bootstrap. Mature repos often need audit or a narrow sync.
Required Thinking Order
- Identify repository shape.
- Identify maintained path or primary execution path.
- Identify source-of-truth files.
- Decide which docs are human-facing and which memory files are model-facing.
- Decide what should be git-tracked and what should stay local.
- Only then scaffold or update files.
If the repository shape is unclear, read references/repo_shapes.md.
Human Docs vs Model Memory
Human docs usually include:
README.mdCONTRIBUTING.mdCHANGELOG.md- core runtime or architecture docs under
docs/
Model memory usually includes:
memory/knowledge/*.jsonmemory/schemas/*.json- local task or execution state under
.agent_memory/
Read references/doc_policy.md before writing human docs.
Read references/memory_policy.md before creating model memory.
Read references/sync_rules.md before choosing what to refresh after code changes.
Minimal Bootstrap Target
Bootstrap only the smallest useful set. Usually that means:
- add or refine
README.md - add or refine
CONTRIBUTING.md - add or refine
CHANGELOG.md - add one core runtime or architecture doc if the repo needs it
- create
memory/knowledge/ - create
memory/schemas/ - add local
.agent_memory/directory guidance and ignore rules
Do not create extra files such as skill-local README guides or redundant summaries.
Source-of-Truth Hierarchy
Use this order when facts conflict:
- runtime code and shared contracts
- tests that enforce current behavior
- maintained architecture docs
- README and contribution rules
- changelog entries
- derived memory
If derived memory disagrees with code or shared contracts, update memory.
Scripts
Use the bundled scripts when they help:
scripts/detect_repo_shape.py- summarize repository shape, entry points, docs, tests, and code layout
scripts/audit_repo.py- report readiness gaps and recommend a mode
scripts/bootstrap_repo.py- create missing standardization files conservatively
scripts/build_knowledge_memory.py- build or refresh model-facing knowledge cards
scripts/sync_repo.py- refresh knowledge memory and highlight doc review targets
Use script output as evidence, not as unquestioned truth. Review the results before finalizing changes.
Bootstrap Workflow
- Run
scripts/detect_repo_shape.py. - Identify maintained paths, entry points, and core contracts.
- Check whether
README.md,CONTRIBUTING.md,CHANGELOG.md, andmemory/knowledge/exist. - Create only the missing or clearly inadequate pieces.
- Materialize initial knowledge cards with
scripts/build_knowledge_memory.py. - Add or update ignore rules for local memory.
- Summarize what future code changes must sync.
Sync Workflow
- Identify changed source-of-truth files.
- Refresh derived knowledge memory.
- Update only docs whose facts are affected.
- Update changelog when user-facing behavior, architecture, or contract semantics changed.
- Report what was refreshed automatically and what still needs human review.
Audit Workflow
- Report repository shape and maintained path candidates.
- Report missing docs and memory.
- Report likely source-of-truth files.
- Recommend
bootstrap,sync, ornone. - If the user wants changes, continue with the recommended mode.
Quality Bar
- Docs must mention real modules, not placeholders.
- Memory must include source paths and a staleness rule.
- Generated content must be specific to the repository.
- Local memory must not leak secrets or raw chat transcripts.
- If the repository already has a strong standard, align with it instead of replacing it.
When Not To Use
Do not use this skill for:
- a one-file scratch script
- vendored or third-party code you should not standardize
- archived logs or generated outputs
- pure implementation work in a repo that already has good docs and memory, unless drift is suspected
Example Requests
- "Audit this repository and tell me whether it needs bootstrap or sync."
- "Standardize this repo for both humans and AI agents."
- "Create the initial docs and memory skeleton for this project."
- "Sync the repository docs and memory after the recent refactor."