> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qontext.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Structure files

> Instructions for folders and files

## Overview

A structure file tells Qontext how a folder is organized: what belongs in it, how files are named, and how careful automatic updates must be before changing anything. Agents read this guidance every time they work new information into your repository, so content keeps landing where your team expects it.

Any folder can carry one structure file, named `.qontext.structure.md` and stored directly in the folder. Structure files are folder configuration, not knowledge: they are never retrieved as content and never appear in the context your AI tools get from Qontext.

A self-maintaining repository is only useful if it stays organized. Structure files are how you keep control of the layout without reviewing every change yourself:

* **Consistent placement.** New information lands in the folders and files your team decided on, following your naming rules.
* **Per-folder confidence.** Strictness sets how sure an update must be before it touches a folder, so curated folders stay conservative while working areas stay flexible.
* **No forced fits.** Content that has no good home under your structure is skipped rather than squeezed into the wrong folder.

***

## Anatomy of a structure file

A structure file has two parts: a strictness level in the front-matter, and free-form guidance below it.

```md .qontext.structure.md theme={null}
---
strictness: firm
---

One file per customer, named after the company.
Every file follows the same outline: Overview, Stakeholders, Current status.
Meeting notes belong in the Meetings subfolder, not here.
```

* **Guidance** is plain prose. Describe placement rules, naming conventions, what goes where, and what explicitly doesn't belong.
* **Strictness** sets the bar an update must clear before it changes anything in the folder: placing new content, editing an existing file, or deleting one.

### Strictness levels

| Level                   | An update acts when                                                  |
| ----------------------- | -------------------------------------------------------------------- |
| `permissive`, `lenient` | the content plausibly fits; when in doubt, it acts                   |
| `moderate` (default)    | the case clearly holds                                               |
| `firm`, `strict`        | the fit is unambiguous; a marginal or partial match does not qualify |

A folder without a structure file, or without a recognizable strictness value, uses `moderate`. When new information clears no folder's bar, continuous updates skip it and explain why; they never force it in or invent a new folder for it.

### Inheritance

Guidance flows down the folder tree:

* A folder is governed by its own structure file plus those of its ancestor folders. Where they conflict, the closest folder wins.
* An ancestor's guidance can describe how its subfolders should be organized; subfolders without a structure file of their own follow it.

This means you can describe the broad layout once, high up in the tree, and only add structure files deeper down where a folder needs its own rules.

***

## Setting up a structure file

<Steps>
  <Step title="Find the Structure row">
    In the **Context** tab, every folder shows a **Structure** row at the top of its contents. A folder without a structure file shows a **Set up** label.
  </Step>

  <Step title="Write the guidance">
    Click the row to create or open the folder's `.qontext.structure.md`. Describe how the folder is organized, and set the strictness in the front-matter.
  </Step>

  <Step title="Let it work">
    From now on, continuous updates follow the guidance whenever they place or change content in this folder. Every update still shows up in the **Changes** tab, so you can watch the structure hold.
  </Step>
</Steps>

<Info>
  **Structure files stay put.**

  A structure file can't be moved or renamed; it always lives in the folder it describes. Deleting it retracts the guidance, and the folder's Structure row returns to **Set up**.
</Info>

Beyond that, structure files are ordinary Markdown files: edit them by hand like any other file, or ask a [context agent](/features/context-agents) to draft one for you.

***

## Examples

A curated folder that must stay clean:

```md Customers/.qontext.structure.md theme={null}
---
strictness: strict
---

One file per customer, named after the company (e.g. "acme-corp.md").
Every file follows the same outline: Overview, Stakeholders, Current status, Open items.
Meeting notes go to the customer's Meetings subfolder.
Pricing agreements belong in /Sales/Pricing, not here.
```

A working area where capturing matters more than precision:

```md Research notes/.qontext.structure.md theme={null}
---
strictness: permissive
---

Loose collection of research findings and early ideas.
One file per topic; extend related notes rather than creating near-duplicates.
Anything that matures into a decision moves to /Decisions.
```

***

## Best practices

* **Write for a new teammate.** The guidance should read like a short brief: concrete rules such as "one file per customer, named after the company" work better than "keep this folder tidy".
* **Say what doesn't belong.** Exclusions ("pricing agreements belong in /Sales/Pricing, not here") prevent slow drift better than inclusions alone.
* **Put guidance at the highest folder where it applies.** Inheritance carries it to every subfolder; add deeper structure files only where a folder needs its own rules.
* **Match strictness to the folder's sensitivity.** Use `firm` or `strict` for curated, canonical folders (policies, pricing, customer records) and `permissive` or `lenient` for working areas where capturing beats skipping.
* **Start with `moderate` and adjust.** Tighten a folder when misplaced content shows up in its changes; loosen it when too much gets skipped.

***

## Prompts to get started

You don't have to write structure files yourself. Ask a [context agent](/features/context-agents):

* "Look at how /Customers is organized today and write a structure file that keeps it that way."
* "Set up a structure file for /Sales: one file per customer named after the company, meeting notes in each customer's Meetings subfolder, strictness firm."
* "Which folders in my repository don't have a structure file yet? Suggest guidance for the three busiest ones."
