/setup

name: setup
description: Create a project wiki with a useful Home, starter pages, and a writing guide.

<!-- GENERATED by scripts/build-wiki-plugin.mjs from packages/extensions/knowledge/skills-source. Do not edit; edit the source and re-run the script. Its references/ files are generated from the same source. -->

Wiki setup

Leave the person with a wiki they can read and navigate: a populated Home, useful starter pages, and a writing guide. Types and relations are optional; defining them alone is not setup. For a request limited to checking setup or adding a type or relation, do only that work.

Check what exists first. Create missing pages, fill empty bodies, and add missing context or links with small edits that preserve existing prose. Never delete, rename, archive, or replace a person's content without their approval. Re-running setup must not duplicate pages, sections, or links.

The base guide is `references/wiki-guide.md` next to this file. Example relations are in `../update/references/relations.yaml`.

0. Which project

On a local wiki, follow "On a local wiki" at the end of this skill instead of this step.

Setup works on a team project's pages on the Nimbalyst server. Follow the `connect` skill first: `pages_status` must report `bound`, and every call below takes the same `repo` and `project` arguments. A project created with `pages_create_project` already has its Home page. Types defined here are always the team's.

1. Look before adding

Read only; change nothing in this step.

• Read the project's README, relevant docs and the user's brief to learn its purpose, audience, and known choices. Read the existing Home, guide, and relevant overview pages using `listPages` and `readCollabDoc`. Follow the project's guide and the update skill (`/nimbalyst-wiki:update`) for all page writing, marks, citations, and links.
• Search with `searchPages` before deciding a page is missing; reuse equivalent pages even when their titles differ. If a listing is truncated, follow its continuation before concluding something does not exist. Keep all reads and writes in the chosen project and section.
• `tracker_list_types`: the types that exist, any `extends`, and the relations (predicates) that exist.
• **Content from the earlier knowledge graph:** types `entity`, `claim`, `question`, `finding`, `investigation`, `ontology-proposal`, project types that held decisions (`keystone`, `decision-exploration`), `.nimbalyst/labels.yaml`, predicates whose only `subjectKinds` is `entity`, and an `entity` titled "How we write this wiki". Report them as "earlier model, left in place". Do not edit or remove them, do not add labels or vocabulary packs, and never pass `labels` to `tracker_define_type`. Offer the move into pages as a separate job the person starts (`../update/references/migrating-v1.md`).

2. Understand what would make this wiki useful

For a new wiki or a substantial setup repair, have a short discovery conversation before writing. Use what the person already said and what the project contains; ask about the remaining choices that would change the result. Do not treat a repository's contents as proof of the person's intended audience or purpose. Skip this step for a narrow type/relation change or a check-only request unless a missing answer blocks that task.

Use the host's interactive question tool. Prefer one prompt with a few fields, suggested answers based on the project, and an escape hatch for the person's own answer. Pre-fill known preferences. Cover the useful gaps among:

• **Purpose and audience:** who will read it, and what should it help them do? Onboard teammates, guide coding agents, preserve product intent, or compare research are different starting points.
• **First useful result:** which questions should the wiki answer immediately, and which areas matter most? Let the person adjust a suggested page list instead of asking them to invent a hierarchy.
• **Sources and boundaries:** which existing docs, sessions, or other material should inform it, and what should stay outside the wiki? Ask about missing or ambiguous sources, not files you can locate yourself.
• **Depth and upkeep:** a concise orientation or a deeper reference; what should agents keep current as work happens? Discuss types in terms of things the person wants to browse or compare, not schema terminology.

Wait for the answers before making dependent choices. Ask a follow-up only when an answer leaves a consequential ambiguity; do not turn setup into a questionnaire or repeatedly confirm settled choices. If the brief already answers these questions, proceed. If the person explicitly delegates the choices, use project-grounded defaults and state the assumptions.

Use the answers to choose the pages, their depth, and any types. Reflect the intended audience and purpose in Home. A research wiki need not inherit a software project's Product/Design structure. Once the direction is clear, build the wiki; do not require a separate approval for each ordinary page creation.

3. Guide page

• **Base version:** 5. The base text is `references/wiki-guide.md`, unchanged; its last line names the version.
• **Find it.** `pages_status` returns its `guideLink` when the project has one; `listPages` gives its `uri`, which you read with `readCollabDoc`.
• **Missing:** create it with `createSharedDoc` (`section`, `title: How we write this wiki`, no parent, `after` the Home page's node when there is one, `initialContent` = the base text). Read it back at the returned `uri` and confirm the text is there.
• **Only the earlier guide exists** (an `entity` titled "How we write this wiki"): leave it. Offer to create the new page and carry over the team's own edits that still apply; create it only after the person approves the merged text.

If the guide page exists, **never overwrite it**. Compare it with the base, ignoring whitespace:

• Same text: "already present, matches base version 5".
• Different text, version line