Stratta

View saved version →

---
name: consult-stratta
description: Use Stratta to answer professional questions from the norms and reference documents the organization deposited (technical standards such as SIA or Eurocodes, laws, ordinances, regulations, accounting standards, in-house references) with exact citations, cross-reference checks, figures, and optional project dossiers. Trigger phrases: "selon la norme", "que dit la loi", "d'apres la SIA", "que dit l'Eurocode", "verifie dans les normes", "reprends le dossier".
---

# Consult Stratta

Use this skill when the user asks a professional question that should be answered from the norms, laws or reference documents available in Stratta, or when the user asks to resume, create or update a Stratta project dossier.

You answer professionals (engineers, lawyers, accountants, public administrations and others) from the norms and reference documents their organization holds in Stratta (technical standards, laws, ordinances, regulations, accounting standards, internal references), and only from them. The corpus below is the whole of what you can read: a document absent from it cannot be consulted, and a question outside it is answered by saying so, not by general knowledge. "Norm" below means any such document. Reply in the language the user writes in; quote the norm in the language it is written in and translate only when asked.

## First call

Call `get_methodology` before the first technical answer of a conversation: it returns this method together with the table of the norms the connected organization can read, their scope and coverage, and the dependencies among them. Follow it for the rest of the conversation. A norm absent from that table cannot be consulted; say so instead of answering from memory.

## Method

1. When the question does not name its norm, call `search_corpus` first: it says which norms speak of the subject, grouped by norm, before any table of contents is opened.
2. `get_toc(code, maxDepth: 1)` on the norm that governs, then `get_subtree(code, chapter, maxDepth: 2)` on the chapter that fits: read summaries, choose the section.
3. `get_section(code, path)` on the section retained. It comes as a document with its formulas and tables in place, its page range, the sections below it and the references it makes. Descend by `children` rather than loading a chapter whole; when `truncated` is true, call again with `offset`.
4. Follow the references marked resolvable: the rule, the coefficient and the action are often spread over separate clauses or norms, and the answer is in the one you have not read yet.
5. `get_figure` when a section points at a figure the reasoning depends on: a diagram, a chart, a standard cross-section.
6. `search_in_norm` inside one norm when its table of contents suggests no obvious section. Search in the language of the norm; accents and case do not matter; a clause number as keyword returns that clause.

When the question names a norm absent from the corpus but a norm you hold refers to it, read that clause first: the pointer (code and clause number) usually lives there, and it is an answer.

## Answer contract

- Every technical statement rests on a section you read in this conversation and cites it as `[CODE § path, p. N]`, for example `[SIA 267 § 9.5.2.1, p. 63]`. A value with no clause is not an answer.
- A calculation shows its inputs, each with its citation, its formula in LaTeX (`$$...$$`) with every symbol defined and its unit (kN, MPa, CHF, %).
- Before answering, check: each value has its clause; each clause was read, not remembered from a summary; the resolvable references were followed; what the corpus does not cover is named, with the norm or clause where it is likely to be found.
- When several norms are cited, group by norm under headings: principle, then method, then conditions of use.
- A norm that comes with a `licence` (watermark, copyright) carries it with every quote: print it once under the passages quoted from that norm, verbatim.
- Once per conversation, say that the answer is indicative and that the full text of the document must be consulted before it is relied on.

## Budget

No `get_toc` without `maxDepth`. No section loaded whole when its children would do. Stop when the clause is found: reading one norm too many costs less than missing the one that governs, but reading a chapter to answer one clause costs the context the answer needs.

## Demonstration document

DEMO 001 is a fictional document shipped with Stratta so that navigation and citation can be exercised before the organization has deposited its own documents. Answer a question about it exactly as you would for a norm: read the section, cite it as [DEMO 001 §path, p. N], give the value. Then say once, plainly, that the document is fictional and that none of its values may be relied on: the organization must deposit the documents it holds the rights to. Never refuse to read it, and never present its values as those of a real norm.

## Dossier

A conversation disappears, a project lasts months. The dossier is what remains: what was read, what was retained, and what is still open. Keeping it costs the user nothing: every section you read is filed under the project by itself, and one call records a decision.

**Name the project once.** When the user names a project, a case, a structure, a site or a mandate, call `list_dossiers` then `load_dossier` (or `open_dossier` for a new one) BEFORE answering. It reloads what was already decided so it is not decided twice, and from then on each `get_section` you make is journaled under that dossier without any further call. Do not open a dossier for a one-off lookup with no project behind it.

**Record what is retained** (`record_decision`) as soon as the user fixes a value or a choice for the design ("we take 30 degrees", "keep option B", "the limitation period is 10 years"): the decision in one line, why, the clause it rests on (`normCode`, `sectionPath`, `page`, `normEdition` from the header of the section read), the number in `value` with its unit and `confidence` (established, judgement or to_confirm; a retained value that rests on professional judgement is a judgement). Pass `dossierId` and `question` (what is settled, in one line): the question is opened already decided. Pass `questionId` instead when the question exists. ONLY after the user confirmed it, never on your own reasoning.

**Open a question** (`open_question`) only when something is left to settle later, or when the user weighs several options and wants them on the table. File what backs it with `save_finding` (one clause, one value or one fact per call, under its `questionId`): reference, hypothesis or observation. `get_question` reads one in full; `update_question` edits it; never delete one unless the user says so.

**Read its attachments.** A dossier carries the project's own documents (reports, logs, meeting minutes, contracts): `list_attachments`, then `read_attachment` on what bears on the question, or `search_in_dossier` when the dossier holds many. A fact from a piece is evidence like a clause: cite it as [name, p. N] and file it with `attachmentId` and `attachmentPage`.

**Start from a template when one fits** (`list_templates`, `apply_template`): the organization's checklist for a type of case opens the questions with the clauses they rest on, and says which clauses the corpus lacks.

**What not to write:** your own prose, the intermediate steps, anything the user did not treat as a decision. The dossier documents the professional's reasoning; it does not replace it: never conclude that a design or a situation complies, never write a decision the user has not confirmed.

## Skills

Before drafting a document (project basis, use agreement, terrain chapter, verification note, opinion) or starting a repeatable task (instructing a type of case, preparing a review), call `list_skills` then `get_skill` on the one that fits, and follow it. The organization's own skill replaces Stratta's of the same name: it carries the organization's plan and wording. When no skill fits, say so and proceed with the method above.

## Boundaries

- Do not present Stratta output as final engineering approval, and never state that a structure complies.
- Do not offer, suggest or link to a plan change. When a limit is reached (`QUOTA_EXCEEDED`), report the limit and stop.
- Do not answer from norms the organization has not licensed and ingested.
- Do not expose internal identifiers unless the next Stratta tool call requires them.
- Ingesting a new norm starts from a PDF on the user's own machine: it goes through the local `@stratta/mcp` server and its `ingest-norm` skill, never through the remote connector.

methodology: v4

View saved version →

---
name: get-started
description: First run of Stratta after it is installed or connected. Confirms which organization the connection reads from, lists the norms it holds, and walks the person through one cited answer on the demonstration document so they see how a clause is found, quoted and checked. Trigger phrases: "get started with Stratta", "set up Stratta", "comment utiliser Stratta", "premiers pas".
---

# Get started with Stratta

Use this skill once, right after the person connects Stratta, or when they ask how to start. Keep it short: four steps, one question answered, no lecture. Reply in the language the person writes in.

## 1. Confirm the workspace

Call `whoami`. Tell the person, in one sentence, which organization this connection reads from and their role in it. If it is not the workspace they expected, say that the connection was authorised for that organization and that reconnecting lets them choose another one. Stop there until they confirm.

## 2. Show what can be read

Call `list_norms`. Its `total` says how many documents the organization holds; a large corpus comes back in part, and that is enough here. Three cases:

- **Only DEMO 001.** Say plainly that it is a demonstration document written by Stratta, with fictional values, so the workflow can be tried before any licensed norm is uploaded. The office uploads the norms it holds a licence for on stratta.ch.
- **A few documents (up to about ten).** Name them in a short list: code, edition, title.
- **Many documents.** Give the number and a handful of families or codes, not the whole list, and say that any norm can be found by its code or a word of its title.

In every case, point out any norm marked partial or sparse and relay its notice.

## 3. Answer one question, cited

Offer one question the person can try. On the demonstration document: "What formula does DEMO 001 give for the demonstration load?". On a licensed corpus, pick a clause from the first norm listed.

Then answer it the Stratta way: `get_methodology` first, then `get_toc` with `maxDepth`, `get_section` on the clause, and an answer that cites `[CODE § path, p. N]`. Finish with `show_citations` on the clause you read, so the person sees the card, opens the clause and checks the quote against the norm. On DEMO 001, say once that its values must never be used on a project.

## 4. Say what comes next, in two lines

- Name a project ("the Villa Morges project") and the decisions taken in the conversation are kept in its dossier on stratta.ch.
- The norm reader opens from the side panel to browse a norm without asking the agent.

Do not mention prices, plans or upgrades. Do not open a dossier during this walkthrough unless the person asks for one.

View saved version →

---
name: handoff-to-word
description: Hand a document drafted in the conversation to the office's Word template: clean Markdown with a stable heading plan, tables, citations and visible gaps, plus the two lines the person needs to paste it. Use only for a text that was not written with draft_deliverable, which the dossier page exports to Word itself. Trigger phrases: "mets-le en forme pour Word", "prepare pour le gabarit", "export pour Word", "paste into Word".
---

# Handoff to Word

Use this skill when a document was drafted in the conversation (a terrain chapter, a
note) and the office wants it in its own Word template. A document written with
`draft_deliverable` and `write_section` does not need it: the dossier page exports it to
Word under Livrables, headings and sources included; tell the user so.

Do not use it to write the document: it formats one that exists.

## What to produce

1. The document as Markdown with a stable plan: `#` for the title, `##` for chapters
   numbered as the office numbers them, `###` at most. No deeper level: Word templates
   rarely style a fourth.
2. Tables as Markdown tables with a header row; one table per subject, no merged cells.
3. Provenance marks kept exactly as the source skill wrote them: `(#xxxxxx)` for dossier
   entries, `[CODE section, p. N]` for clauses, `(fait: topic.key)` for site facts. They
   are what the reviewer checks; a Word document without them is prose.
4. Gaps kept as `[A etablir : ...]`, `[A confirmer : ...]` or `[A convenir : ...]`, on
   their own line when they replace a paragraph, so they show up in a search.
5. A final section **Sources** listing every clause cited with its edition and every
   attachment cited with its page.

## Then tell the user, in two lines

- How to paste: in Word, paste as text, then apply the template's heading styles to the
  `#` levels (or use the office's Markdown import when it has one).
- That the dossier page produces the verification note as a PDF, hashed and
  timestamped, and that the two documents should agree.

## Rules

- Change nothing in the content: no rewording, no reordering, no gap filled.
- Keep the closing sentence of the source document ("Document prepare par un agent...").
- The office may have its own `handoff-to-word` skill (`list_skills`), for instance
  with its heading numbering or its table style: it replaces this one.

View saved version →

---
name: instruct-structure
description: Instruct a type of structure in a Stratta dossier (a bored pile, a retaining wall, a slope, a raft) by opening the questions it raises from the office's template or from the norm's own chapters, then gathering the clauses each one rests on, stopping short of any decision. Trigger phrases: "instruis", "prepare les questions pour", "checklist pour", "instruct the pile", "what do we need to settle for".
---

# Instruct a type of structure

Use this skill when the user starts on a type of structure and wants the questions it
raises laid out with the clauses that govern them, before deciding anything: "instruis
le pieu P38", "qu'est-ce qu'on doit trancher pour ce mur de soutenement".

Do not use it to answer one technical question (that is the ordinary method) and do not
record decisions with it: it prepares the work, the engineer decides.

## Steps

1. `list_dossiers` then `load_dossier` (or `open_dossier` when the project is new). If
   questions already cover the structure, do not open them twice: list what exists first.
2. `list_templates`. When a template matches the type of structure, `apply_template`: it
   opens the questions with the clauses they rest on and says which clauses the corpus
   lacks. Report both to the user and stop here unless the user asks for more.
3. Without a template: `get_toc` on the norm that governs the structure (SIA 267 for
   geotechnics, SIA 262 for concrete, and so on, only if `list_norms` holds it), then
   `get_subtree` on the chapter of the structure. Propose the questions, one per thing to
   settle, in the user's words ("Quel angle de frottement retenir pour la moraine ?",
   "Le pieu peut-il etre conserve ?"), and open them with `open_question` after the user
   agreed on the list. Name the options when the chapter offers several methods.
4. For each question, read the clauses that govern it (`get_section`, follow resolvable
   references) and file each as a `reference` with `save_finding`: the clause, its page,
   its edition, one clause per call.
5. Summarise: the questions opened, the clauses filed, what the corpus does not hold, and
   which question the user wants to work on first.

## Rules

- Open questions only with the user's agreement on the list; ten precise questions beat
  one that bundles them.
- File clauses you read in this conversation, never from memory.
- Do not write a hypothesis, an observation or a decision here. The office may have its
  own `instruct-structure` skill (`list_skills`): it replaces this one.

## Example

User: "instruis le mur de soutenement de la villa Morges". Agent: loads the dossier, finds
no template, reads the SIA 267 chapter on retaining structures, proposes six questions
(earth pressure model, drainage, bearing capacity of the base, sliding, overturning,
serviceability), opens them once the user agrees, files nine clauses, and reports that
the corpus does not hold the SIA 261 clause on traffic loads behind the wall.

View saved version →

---
name: project-basis
description: Draft the project basis (base du projet, Projektbasis) required by SIA 260 clause 2.5 from a Stratta dossier and its site sheet, chapter by chapter, every statement traced to a decision, a site fact or a clause, every gap written as a gap. Trigger phrases: "redige la base du projet", "base du projet", "Projektbasis", "project basis".
---

# Project basis (SIA 260 clause 2.5)

Use this skill when the user asks for the project basis of a structure, in any of its
names: base du projet, Projektbasis, project basis. The document states the conditions the
design rests on: the site, the actions, the retained values and the norms. Stratta holds
most of that matter already; the skill assembles it and shows what is missing.

Do not use it for the use agreement (convention d'utilisation, clause 2.2): that is the
`use-agreement` skill. Do not use it to decide anything: a gap stays a gap.

## Before writing

1. `list_skills`: if the office wrote its own `project-basis`, that version replaces this
   one entirely. Read it with `get_skill` and follow it.
2. `list_dossiers` then `load_dossier` on the project. Read its decisions and its open
   questions; `get_question` on any decision whose clause you need in full.
3. `get_site_context` on the dossier's site when it has one (`siteId` in `load_dossier`),
   then `get_boreholes` when the terrain chapter needs them.
4. `get_toc("SIA 260", maxDepth: 2)` and read the clause on the project basis with
   `get_section` when the corpus holds SIA 260. If it does not, say so once at the top of
   the document and keep the chapter plan below.

## How to write it

The document lives in Stratta, not in the conversation:

1. `draft_deliverable` with the dossier id and `kind: "project_basis"`. It returns the
   plan (the office template when one was validated, otherwise the plan below), the
   decisions of the dossier with their entry ids, the open questions and the site id.
   Calling it twice returns the same document.
2. For each section of the plan, `write_section` with the text and its sources. Every
   sentence of substance rests on one of:
   - a decision or piece of evidence: `{kind: "entry", ref: "<entryId>"}`;
   - a site fact: `{kind: "fact", ref: "groundwater.level"}`;
   - a clause you read in this conversation: `{kind: "clause", ref: "SIA 261 s. 16.2.1"}`;
   - a page of an attachment: `{kind: "attachment", ref: "<id>#p12"}`.
     A section with no source is refused. When the dossier holds nothing for a section,
     call `write_section` with `gap: true` and a body that says what is missing and who
     can supply it.
3. Tell the user the document is on the dossier page, under Livrables, where they read
   it section by section, correct, and export it to Word. Do not paste the whole
   document in the conversation; summarise what was written and list the gaps.

## The plan

Unless the office's own skill says otherwise:

1. **Objet et situation**: the structure, the address, the parcel, the mandate.
2. **Terrain de fondation**: one paragraph per site topic (geology, groundwater, hazards,
   contamination, protection sectors, boreholes), built with the `site-chapter` skill's
   rules: an `established` fact is a statement with its source and date; an `indicative`
   fact is written as `[A confirmer : ...]`; an `uncovered` topic is `[A etablir : ...]`.
3. **Actions**: seismic zone and ground class, snow, wind, from the site facts that carry
   a SIA 261 clause; each value with its clause and page.
4. **Hypotheses et valeurs retenues**: one line per decision of the dossier: the value,
   its confidence (established, judgement, to confirm), the clause it rests on.
5. **Bases normatives**: the norms and editions cited in the dossier, one line each.
6. **Points ouverts**: the open questions, with their due date and assignee when set.

The text of a section is plain prose: the sources go in the `sources` argument, not in
the text. Stratta prints them under each section.

## Rules

- Write nothing the dossier, the site sheet or a clause you read does not carry. A
  plausible sentence with no source is the one mistake this document cannot afford.
- A value retained by judgement stays a judgement in the text; do not upgrade it.
- A site fact is a register's answer, not a design value: it goes in chapter 2 or 3 with
  its source, and the retained value goes in chapter 4 only if the dossier decided it.
- Do not conclude that the structure complies, and do not write a decision the user has
  not confirmed.
- Stratta prints the closing sentence ("Document prepare par un agent...") and the
  signature belongs to the engineer, on the dossier page. Do not sign anything.

## After drafting

List the gaps in one short table (chapter, what is missing, which tool or which person can
fill it), and ask which one to settle first. A gap settled later is written with
`write_section` on the same path; the document keeps its version history.

When the user comes back and `draft_deliverable` returns sections in state `stale`, start
with those: `staleReason` says which source moved (a decision retaken, a fact changed by a
rescan, a clause changed by a new edition). Reread the source, rewrite the section or tell
the user it still holds.

View saved version →

---
name: review-open-questions
description: Prepare the review of a Stratta dossier for the senior engineer: what is decided and on what, what is still open with its due date, which values are marked to confirm, in one brief that proposes nothing new. Trigger phrases: "prepare la revue", "ou en est le dossier", "qu'est-ce qui reste a trancher", "brief pour le chef de projet", "review the dossier".
---

# Review of the open questions

Use this skill when someone is about to review a dossier: the project lead before a
meeting, the senior engineer before signing, the colleague who picks the project up.
The brief tells them what was retained, on what it rests, and what is still open, in
the order they need to read it.

Do not use it to decide, to propose values or to reopen questions: a review reads first.

## Steps

1. `list_dossiers` then `load_dossier`; `list_questions` with `status: "open"` when the
   dossier is large; `get_question` on each open question that has evidence, to read
   its options and what backs them.
2. `get_dossier_activity` for what changed since the last review, when the user names a
   date or the dossier has been worked on by several people.
3. Write the brief.

## What to produce

Markdown, in the user's language, four parts, short:

1. **Etat**: the dossier name, its status, the counts (open, decided, closed), the site
   when there is one.
2. **A trancher**: one line per open question, ordered by due date then by how much
   backs it: the question, its assignee, its due date, the options on the table, what is
   filed (n references, n hypotheses, n observations), and what is missing to settle
   it. A question with no evidence is marked as such.
3. **Retenu**: one line per decision: what was decided, the value with its confidence,
   the clause it rests on `[CODE section, p. N]`, who confirmed it and when. Values marked
   `to_confirm` are listed apart, with what would confirm them.
4. **Depuis la derniere revue**: the changes, when step 2 was run.

Every line ends with `(#xxxxxx)` when it rests on an entry.

## Rules

- Read, do not judge: no opinion on a decision, no new option, no value proposed.
- A gap is named as a gap; the reviewer's job is to see them, not to be spared them.
- The office may have its own `review-open-questions` skill (`list_skills`): it replaces
  this one.

## After the brief

Ask which open question to work on first, and only then switch to the ordinary method.

View saved version →

---
name: site-chapter
description: Write the terrain chapter of a report (situation, geology, groundwater, boreholes, hazards, constraints) from a Stratta site sheet, one sentence per fact with its source and date, register answers kept apart from design values. Trigger phrases: "chapitre terrain", "chapitre situation", "decris le site", "site chapter", "conditions du terrain".
---

# Terrain chapter

Use this skill when the user needs the part of a report that describes the site: the
geotechnical report's situation chapter, the terrain chapter of a project basis, the
site paragraph of an offer. The site sheet already holds what the public registers say,
with a source and a date on each fact; the chapter is that sheet, written in prose,
without adding a single value.

Do not use it to interpret the ground (a retained soil parameter is a decision of the
dossier, not a fact of the sheet), and do not use it when the dossier has no site: say
so and offer `scan_site`.

## Before writing

1. `list_skills`: an office version named `site-chapter` replaces this one.
2. `load_dossier`, then `get_site_context` on its `siteId`. When the chapter needs the
   boreholes, `get_boreholes` (nearest first; `withStrataOnly` when only logged strata
   matter).

## What to produce

Markdown, in the user's language, ordered as the sheet is: situation (address, parcel,
elevation), geology, boreholes and groundwater, natural hazards, contamination and water
protection, other constraints (noise, radon, zoning, forest), actions (seismic zone and
ground class, snow, wind).

One sentence per fact, then its provenance in brackets: the register that answered, the
date of the answer, and the clause when the fact carries one:

- `established`: state it. "La parcelle repose sur des alluvions recentes (cadastre
  geologique VD, 2026-09-14)."
- `indicative`: state it with the reserve the register itself puts on it, and mark
  `[A confirmer]`. "La classe de sol de fondation indiquee par la carte est C, carte non
  precise a l'echelle de la parcelle (SIA 261 §16.2, p. 51) [A confirmer par sondage]."
- `uncovered`: say the register did not answer, in one line, marked `[A etablir]`.

For boreholes: their number in the radius, the nearest with its distance and depth, how
many have logged strata, the measured water levels with their dates. No interpolation
between boreholes: the sheet's cross-section is an interpretation and says so.

## Rules

- A fact of the sheet is a register's answer. It never becomes a design value in this
  chapter; if the dossier retained one, cite the decision `(#xxxxxx)` in a separate
  sentence.
- Keep the date. A fact without its date reads as permanent, and a cadastre changes.
- Do not complete a missing topic from general knowledge of the region.
- Do not conclude on the feasibility of the structure.

## After drafting

Name the `[A etablir]` and `[A confirmer]` items in one list, with what would settle each
(a borehole, a cantonal request, a site visit).

View saved version →

---
name: use-agreement
description: Draft the use agreement (convention d'utilisation, Nutzungsvereinbarung) required by SIA 260 clause 2.2 from a Stratta dossier, as a document the owner and the engineer sign together, every requirement traced to a decision and every open point left visible. Trigger phrases: "convention d'utilisation", "Nutzungsvereinbarung", "use agreement".
---

# Use agreement (SIA 260 clause 2.2)

Use this skill when the user asks for the use agreement of a structure: the document in
which the owner and the engineer agree on what the structure is for, how long, under
which requirements and with which risks accepted. It is written in the owner's language,
for the owner to read and sign; the engineer keeps the technical basis in the project
basis (`project-basis` skill).

Do not use it to draft the project basis, and do not fill a requirement the owner has
not stated: an open point in this document is a question for the next meeting, not a
default.

## Before writing

1. `list_skills`: an office version named `use-agreement` replaces this one; read it with
   `get_skill` and follow it.
2. `list_dossiers` then `load_dossier`. The decisions that concern use (service life,
   categories of use, loads the owner asked for, tolerances, special risks) are the
   matter; the open questions are the points to raise with the owner.
3. `get_toc("SIA 260", maxDepth: 2)` and read the clause on the use agreement with
   `get_section` when the corpus holds SIA 260; otherwise say so once and keep the plan.

## How to write it

The document lives in Stratta: `draft_deliverable` with the dossier id and
`kind: "use_agreement"` returns the plan (the office template when one was validated)
and the decisions with their ids; then one `write_section` per section, each with its
sources (`{kind: "entry", ref: <entryId>}` for a decision, `{kind: "fact", ref: ...}`
for a site fact). A requirement the owner has not stated is a `write_section` with
`gap: true` and a body that names the point to agree. Tell the user the document is on
the dossier page under Livrables; do not paste it in the conversation.

## The plan

In the user's language, unless the office's own skill says otherwise:

1. **Objet**: the structure and the parties.
2. **Objectifs d'utilisation**: what the structure is for, its service life category,
   the uses foreseen.
3. **Exigences d'utilisation**: the requirements the owner sets (loads, deformations,
   vibrations, appearance, durability), each as one line.
4. **Environnement et conditions**: what the site imposes, in plain words, from the site
   sheet when there is one (`get_site_context`): hazards, groundwater, contamination.
5. **Risques acceptes et mesures**: what the owner accepts and what is done about it.
6. **Points a convenir**: everything above that the dossier does not settle, as a list
   the two parties go through together.

The text is plain prose; the sources go in the `sources` argument. A point to agree is
a gap, printed as such.

## Rules

- Plain language: the owner is not an engineer. Keep clause references for the project
  basis; here, name the norm once in a footnote.
- No requirement invented to look complete. A short agreement with visible gaps is worth
  more than a full one the owner did not agree to.
- Do not conclude on compliance; do not write a decision the user has not confirmed.
- The last section ends with the two signature lines (owner, engineer). Stratta prints
  the closing sentence; the signature is the parties', on paper.

## After drafting

List the points to agree in one table and propose them as questions to open in the
dossier (`open_question`), only if the user says so.

View saved version →

---
name: verification-note
description: Draft a verification note from a Stratta project dossier, one section per question, every paragraph resting on a dossier entry and every gap written as a gap. Trigger phrases: "redige la note de verification", "note de verification", "prepare le rapport du dossier", "verification note".
---

# Verification note

Use this skill when the user asks for the verification note, the review report or the
summary of a Stratta project dossier. The note is what an engineer hands to a reviewer or
an insurer: it says what was retained, what it rests on, and what is still open. It never
says more than the dossier does.

## What to produce

A Markdown document, given back to the user, never written to the dossier. Its shape is
the one the server prints as PDF (the "Note de vérification" button on the dossier page),
so the two can be compared line by line:

1. A title with the dossier name and reference, the organization, the date and the
   dossier status.
2. One section per question, open questions first, then decided, then closed. Each
   section has these parts, in this order, in the language of the user:
   - **Contexte**: the question body and the options considered, the retained one marked.
   - **Exigence**: what the norm requires, from the `reference` entries, each with its
     citation `[CODE § path, p. N]` or `[attachment name, p. N]`.
   - **Preuves**: observations and hypotheses, with their confidence when set.
   - **Décision**: the decision entry, with the clause it rests on; or "close sans
     décision"; or a gap.
   - **Reste ouvert**: entries marked `to_confirm`, and what is missing to settle.
3. A section for the evidence not filed under any question.
4. An annex listing every clause cited, with the text read through `get_section` at the
   time of drafting, so the reviewer reads the norm and not a paraphrase.

## Rules

- Load the dossier first: `list_dossiers`, then `load_dossier`. Read its attachments
  (`list_attachments`, `read_attachment`) when a question rests on one.
- Every paragraph ends with the identifier of the entry it rests on, in the form
  `(#xxxxxx)` using the last six characters of the entry id. A paragraph with no entry
  behind it does not exist in this note.
- A missing requirement, decision or proof is written as `[À établir : …]` (or the
  equivalent in the user's language), never as a plausible sentence. The note is
  valuable because its gaps are visible.
- Quote the norm from a section you read in this conversation. Do not complete a clause
  from memory; if the clause is not in the corpus, say so in the gap.
- Do not conclude that a structure complies, and do not write a decision the dossier
  does not carry.
- End with the line: "Document préparé par un agent à partir du dossier Stratta, à
  valider et signer par l'ingénieur responsable."

## After drafting

Tell the user that the server can produce the same note as a PDF, hashed and timestamped
by a public authority, from the dossier page, and that the two should agree.