Update

Update the wiki

First: read the guide and Home

Before writing, read the page titled "How we write this wiki" (Team section of the Wiki, or Personal when there is no team) and the section's Home page, and follow them. The guide overrides the writing advice below wherever they disagree.

Find them with listPages (section: team or personal): it returns every page with its uri, which you read with readCollabDoc. If the project has no guide page, follow ../setup/references/wiki-guide.md and tell the person the setup skill (/wiki:setup) can install it as an editable page.

Before creating a page, search for an existing one with searchPages (query, optional section); extend or link to what it finds instead of adding a second page about the same thing.

The model

• Page. Markdown in the page tree. The Team section is shared and collaborative; the Personal section is local and works without an account. Any page can hold child pages; a page with an empty body works as a folder. A plain page's type is Page, with four fields of its own: status (draft, current, outdated), owner (an email), a one-line summary, and tags. The page shows its title above the body, so start the body with text, never with the title as a heading.
• Typed page. A page with a type. It is a tracker item: a few single-valued fields in its header and a collaborative markdown body. It can live anywhere in the tree; one not placed anywhere else sits under its type.
• Type. A tracker type the team defines (Module, Technology, Competitor). It is placed once in the tree, and its page shows prose about the type above a table of every page of that type. A subtype sets extends and nests inside its base (Libraries inside Technologies).
• Relation. A named predicate with an inverse name ("built on" and "underlies"), allowed between particular types. It is written on a link in the body. The Links section at the bottom of each page lists its relations, incoming ones under the inverse name.

The project decides its types and relations. Suggest common ones (module, technology, competitor, person) when they fit; never assume a fixed list.

Do not build any of these, even if older content or habits suggest them: claim, fact, finding or investigation items; qualifiers on links; generic relations such as "related to" or "depends on"; a decision record in place of the marked sentence, or decisions as subject-verb-object triples; lists or relationship chips in a page header; automatic rollup tables of every relation; approval steps for your own edits; large decision boxes.

What to write

Pages mainly hold what people said and decided. You can look everything else up, so write it down only when it helps a person see the whole problem.

1. Decisions are marked sentences in the page they affect. Wrap the sentence that states the decision in brackets and follow it with its attributes: who decided (name and email), the date, and what was not chosen. [We store and evaluate flags in Flagship.]{decided by="Dana Lee" email=dana@example.com on=2026-09-30 over="our own Durable Object store"} The email is how marks are found by person, so take it from a citation snapshot or the team member list (findOrgMembers); never guess one. The page shows a small chip before the sentence and a faint who/when/not-chosen line after it. Mark only the sentence itself, never a paragraph, and never put a decision in its own box or section. Mark by default. Also add a decision record (a tracker item) when no single page owns the decision, work or commits hang off it, it is not settled, or its reasons don't fit in the mark; the guide page has the details. A record never replaces the mark: keep the mark and put the record's key right after it as a link. Not every choice needs either.
2. Open questions, the same way. [Do we need a mobile SDK for launch?]{open by="Dana Lee" email=dana@example.com}, where by is who owns it. When a page or a spike owns it, leave out the email: {open by="Spike 6"}. When it is answered, change the mark to decided with the date and what was not chosen.
3. Cite the person. When a statement came from a person, follow it with a citation. Get it from list_citable_inputs, which lists this session's human prompts, answered questions and comments on shared pages, each with ready citation markdown (an https://console.nimbalyst.com/app/cite/... link whose title holds who, email, when and the quote). Paste it unchanged; never write or edit one by hand, and attach a person's words only when they support the sentence. If that tool is not available, name the person and the session in prose: (Dana Lee, in the session "Flag storage", 2026-10-01). Never invent a decision, a reason or a quote.
4. Context, with sources. Facts the team weighs (limits, pricing, maturity, what a competitor ships) carry a source and the date you checked it. Cite a web page or document as an ordinary link titled cite: [TanStack Table docs](https://tanstack.com/table "cite"); the page lists its sources at the bottom. A table on a type's page or a landscape page is good context; a copy of a vendor's documentation is not. To show a type's pages inside another page, place a view (below) instead of copying rows by hand.
5. Short. A page is a few paragraphs. The page shows its title above the body, so start the body with text, never with the title as a heading. Update the page instead of adding a second page about the same thing. When a decision changes, rewrite the sentence and say what it replaced and when.

Typed page example

Header fields are set in fields ({ "maturity": "beta", "inStack": true }). The body, exactly as the editor stores it:

markdownCopy code
Cloudflare's feature flag service. Built on [CFS-2](https://console.nimbalyst.com/org/<orgId>/project/<projectId>/page/item/CFS-2 "rel=built-on") and KV, with OpenFeature evaluation inside Workers ([Flagship docs](https://developers.cloudflare.com/ "cite"), checked 2026-10-01). Public beta since May 2026.

[We store and evaluate flags in Flagship and add profile context, exposure logging and statistics on top.]{decided by="Dana Lee" email=dana@example.com on=2026-09-30 over="our own Durable Object store"} <citation markdown from the citation tool>

[Do we need a mobile SDK for launch?]{open by="Dana Lee" email=dana@example.com}

## Limits we inherit

10,000 apps per account and 5,000 flags per app, soft limits ([limits](https://developers.cloudflare.com/ "cite"), checked 2026-10-01). Changes reach every location within 30 seconds.

Links and relations

Links in page content are https console links; the app opens them in place and teammates' browsers land on the same thing. Copy each one from the link (or a type's viewLink) that listPages returns, or from the link createSharedDoc returns. For a typed page that is not in the tree, build the link from the consoleScope (orgId, projectId) that listPages returns; never guess or reuse an id from elsewhere. Older nimbalyst:// links and .../trackers/item/... links still work, but write the forms below.

• Team: a page is https://console.nimbalyst.com/org/<orgId>/project/<projectId>/document/<documentId>, a typed page .../page/item/<KEY>, a type .../page/type/<typeId>.
• Personal: https://console.nimbalyst.com/app/page/<id> and .../app/item/<KEY>.
• A link to a typed page uses its issue key as the label: [CFS-2](<link>). The label is replaced by the key when the editor saves.
• A link that carries a relation adds rel=<predicate id> as the title: [CFS-2](https://console.nimbalyst.com/org/<orgId>/project/<projectId>/page/item/CFS-2 "rel=built-on"). An embedded card puts the view first: "view=card rel=built-on".
• A link to a plain page uses its title as the label and never carries a relation.
• Relations exist only between typed pages, and nothing checks rel= when you write it. Before writing one, read the project's predicate registry (.nimbalyst/predicates.yaml) and confirm the predicate has valueShape: entity, its subjectKinds include the linking page's type and its objectKinds (when present) include the linked page's type, counting base types through extends. If none fits, write a plain link. If a relation is genuinely missing, add it with the setup skill (/wiki:setup) rather than inventing an id.
• Write the relation in a sentence that says why ("Built on Durable Objects and KV"), because the Links section shows that sentence when expanded.
• Only link keys and pages you created or looked up.

Diagrams and files

Teammates read a Team page on their own machines, so whatever the page shows has to be a page too. A link to a file path (docs/architecture.excalidraw, /Users/...) opens nothing for them.

• A diagram, mind map, data model, mockup or spreadsheet is its own Team page, placed under the page it explains, and linked from it with the link the tool returns. Create it empty with createSharedDoc (documentType: 'excalidraw' for a drawing), then build it with that editor's tools (excalidraw_add_elements and the rest), passing the page's uri as their filePath.
• A file the page needs that already exists (a design drawing, a schema) is copied in with importFileToPages the same way; never link its path.
• A Personal page can be a drawing or another editor type too, but the editors' tools reach Team pages only: build a Personal drawing in a file and copy it in with importFileToPages (section: 'personal'), or use a fenced mermaid code block in the page.

Placed views

A view is a table of one type, placed in a page on purpose. It is a link on its own line, with the type's viewLink from listPages as the target and the definition in the title: [Modules](https://console.nimbalyst.com/org/<orgId>/project/<projectId>/view/type/module "cols=title,status,owner sort=title"), with optional filter=. A view can also be a 2x2 of a type by two number fields (mode=2x2 x=<field> y=<field>). A list of open marks across pages uses the openMarksViewLink from listPages (.../view/marks?kind=open; kind=decided for decisions). Editing a cell edits the page the row points at. Place a view only where a person reading the page needs the whole set; never as an automatic rollup of every relation. If a view link does not render as a table in this version, leave it as a link and tell the person.

Personal views are https://console.nimbalyst.com/app/view/....

Tools

Your edits apply directly; there is no review step and no undo. The transcript shows one "Updated " line per edit, and the page's history is how a person reverts. Keep each edit small, never delete or rewrite what a person wrote without asking, and tell the person which pages you changed.

Every wiki tool takes section (team, the default, or personal, which works with no account). Ids come from listPages: pages by id, typed pages by issue key, types by type id, and any node by its nodeId (document:<id>, item:<id>, type:<id>).

A move that would put a node inside itself is refused, also through a type; read the error and pick another parent.

Migrating older wiki content

Projects that used the earlier knowledge graph have entity, claim, question, finding, investigation and decision items, label registries and perhaps project-specific types such as keystone. Follow references/migrating-v1.md. In short: turn each item into prose on the page it is about, keep every source, and never delete or archive the old items until a person approves.