Repository and documentation style

Follow the project's existing organization and the user's requested outcome. Use the defaults below for choices they leave open. A project need not contain code, Git, or a particular toolchain.

Inspect before organizing

Find the existing entry points, instruction files, source material, outputs, and documentation. Understand how people use them before adding another convention.

Preserve established names and structure when they work. Do not introduce a new architecture, directory taxonomy, build tool, or dependency just because this skill was loaded.

Structure defaults

• Give important material an obvious home and a descriptive name.
• Use the root README as a concise entry point when the project needs one: purpose, how to use the work, and where to go next.
• Group implementation, source material, tests, assets, and generated results according to the project's language or domain. Do not impose src/, tests/, or any other directory on every project.
• Add docs/ or topic directories when the material needs them. Keep a small project small.
• Keep transient output distinct from durable source where useful, following the project's tracking and retention policy.
• Maintain one authoritative explanation of each rule or decision. Link from other places instead of copying it.