# Build Operation

You are building the first substantial Almanac wiki for this repository.

The base prompt modules define the wiki purpose, notability rules, page
structure, and writing syntax. Follow them.

Your job is to perform a deep first construction pass. Create a reusable
project memory layer, not a stub wiki and not a file-tree summary.

## Required Navigation Page

Always create `.almanac/pages/getting-started.md` as the canonical front door
to the wiki. This page is for navigation through the wiki, not repository setup
or install instructions.

Write it after the initial graph is mostly known so it can route through the
actual pages you created. It should help a future reader avoid overwhelm by
explaining where to start, which pages to read first, which dense clusters
matter, and what to read next for common work areas. Link directly to the most
important pages and local hubs with `[[...]]`.

Use `getting-started.md` for the required orientation role. `project-overview.md` is optional
and should only exist if a separate project-identity or product state page earns
its place in the graph.

## Tooling Boundary

Build/init creates a local Almanac wiki from the current filesystem. Do
not use MCP tools, OpenAlmanac tools, remote wiki search, or external page
search tools for this operation.

Use filesystem reads, shell/search commands, and direct writes under
`.almanac/pages/`. The wiki may start empty, so an unavailable or empty local
wiki search is not a blocker and is not evidence that the wiki cannot be
updated.

## Algorithm

1. Orient to the corpus: repo layout, commands, package/config files, docs,
   entrypoints, generated outputs, tests, schemas, data files, and external
   dependencies.
2. Build a working map of the repo from multiple angles: entities,
   subsystems, flows, contracts, data models, operations, external systems,
   product/project concepts, and dense clusters.
3. Investigate important areas deeply enough to explain how they work and how
   they connect. Tests are often the clearest source of intended behavior.
4. Compare code against existing docs and research. Do not copy docs; preserve
   the applied conclusions and project-specific meaning.
5. Identify page candidates by future value. Ask whether each page preserves
   understanding that would be costly, useful, or risky to reconstruct later.
6. Design the initial graph: pages, topics, links, and any local hubs.
7. Write detailed, grounded pages directly under `.almanac/pages/`.
8. Re-read the wiki as a future agent. Fix weak leads, duplicate pages,
   unsupported claims, missing links, topic noise, and thin placeholders.

Be thorough. Create many pages when many pages are justified. Do not stay tiny
to be safe. The quality gate is not page count; it is whether each page earns
its place in the project graph.

## Helper Agents

If the provider supports helper/subagents and the repo is broad enough, use
them for bounded investigation or draft fragments. Good helper tasks include
investigating one subsystem, tracing one flow, reading tests for one area,
checking an external dependency, or identifying page candidates for one
cluster.

The main agent owns final synthesis, page boundaries, topics, links, hubs, and
final prose. Do not let helpers independently create disconnected final wiki
structure.

Helper output is evidence, not completion. If a helper is asked to investigate
read-only or avoid editing files, that restriction applies to the helper's
task only. The main build agent is still responsible for writing the final wiki
under `.almanac/pages/`.

Do not end with page candidates, pages to add later, or an investigation
report. After helpers return, synthesize their findings into actual markdown
pages now.

## Output Standard

The output is a coherent `.almanac/` wiki. It should let a future agent form a
working model of the project faster than by starting from raw files.
