Project Overview
Maintain concise, evidence-backed Markdown that gives contributors a useful
mental model of the project.
Workflow
- Use the user- or repository-defined path. Otherwise update an existing
matching document such as
docs/project-overview.md, ARCHITECTURE.md, or
docs/architecture.md; if none exists, create docs/project-overview.md.
Never create a competing overview.
- Build from the best available evidence. Before implementation, use stated
goals, constraints, and repository conventions. As code exists, inspect
relevant manifests, entry points, modules, configuration, persistence,
integrations, tests, and deployment files.
- Record rationale, assumptions, open decisions, and a high-level
implementation order where useful. Keep proposals distinguishable from
verified behavior without adding a project-status field.
- Preserve accurate manual context, correct stale claims, and remove confirmed
obsolete details. Check the diff for unsupported claims, broken relative
links, lost content, and needless reformatting.
Content
Adapt the structure to the project and document only useful, durable information:
- goals, scope, non-goals, and main capabilities;
- architecture, modules, responsibilities, and important flows;
- languages, frameworks, and notable libraries with roles and rationale;
- persistence, interfaces, integrations, and configuration;
- build, run, test, packaging, and deployment workflows;
- implementation phases, constraints, risks, open decisions, and key locations.
Prefer source evidence over folder-name guesses or stale prose. Use
repository-relative links and diagrams only when they improve understanding.
Avoid exhaustive inventories, speculative complexity, transient Git state,
timestamps, and versions that add no value. Mark proposals, inferences, and
unknowns; never invent implemented behavior.
Do not install dependencies, start services, or modify production code,
configuration, dependencies, or external systems for this documentation task.
1---2name: project-overview3description: Plan or document a project in one repository-local Markdown overview covering purpose, architecture, modules, key libraries, flows, configuration, and development workflows. Use before implementation to design a project, or afterward to refresh its living documentation against the codebase. Do not use for task-level implementation plans or production code changes.4---56# Project Overview78Maintain concise, evidence-backed Markdown that gives contributors a useful9mental model of the project.1011## Workflow12131. Use the user- or repository-defined path. Otherwise update an existing14 matching document such as `docs/project-overview.md`, `ARCHITECTURE.md`, or15 `docs/architecture.md`; if none exists, create `docs/project-overview.md`.16 Never create a competing overview.172. Build from the best available evidence. Before implementation, use stated18 goals, constraints, and repository conventions. As code exists, inspect19 relevant manifests, entry points, modules, configuration, persistence,20 integrations, tests, and deployment files.213. Record rationale, assumptions, open decisions, and a high-level22 implementation order where useful. Keep proposals distinguishable from23 verified behavior without adding a project-status field.244. Preserve accurate manual context, correct stale claims, and remove confirmed25 obsolete details. Check the diff for unsupported claims, broken relative26 links, lost content, and needless reformatting.2728## Content2930Adapt the structure to the project and document only useful, durable information:3132- goals, scope, non-goals, and main capabilities;33- architecture, modules, responsibilities, and important flows;34- languages, frameworks, and notable libraries with roles and rationale;35- persistence, interfaces, integrations, and configuration;36- build, run, test, packaging, and deployment workflows;37- implementation phases, constraints, risks, open decisions, and key locations.3839Prefer source evidence over folder-name guesses or stale prose. Use40repository-relative links and diagrams only when they improve understanding.41Avoid exhaustive inventories, speculative complexity, transient Git state,42timestamps, and versions that add no value. Mark proposals, inferences, and43unknowns; never invent implemented behavior.4445Do not install dependencies, start services, or modify production code,46configuration, dependencies, or external systems for this documentation task.
Lnscc