Project structure

Every active project needs a predictable place for orientation, operation, and durable reasoning. The structure can stay small:

Projects/
└── ProjectName/
    ├── PROJECT.md
    ├── README.md
    ├── TASKS.md
    ├── DECISIONS.md
    ├── repository files
    └── supporting material

Core documents

PROJECT.md

The short briefing: purpose, current state, important constraints, known context, and what information is still missing. It should orient a new collaborator without becoming a full history.

README.md

The deliverable-facing guide. In a software project this normally contains setup, development, testing, and deployment instructions. In a creative project it may instead describe the production workflow and asset conventions.

TASKS.md

The operational horizon: active work, next steps, loose ends, and recently completed milestones. It changes frequently and should not be mistaken for a permanent record.

DECISIONS.md

The durable reasoning: what was decided, why, alternatives considered, and consequences. This prevents future sessions from reopening settled questions without new evidence.

Keep responsibilities separate

A common failure is copying the same state into all four files. Instead, update the document responsible for that kind of information and link to it when necessary.

The structure is deliberately plain. A project should remain navigable using a file browser and text search, even when no specialized knowledge tool or agent is available.

Important memory documents can add a small frontmatter trust layer so readers can distinguish current facts, provisional plans, decisions, and historical records before relying on them.