reliquary/plugins/tome/skills/init/SKILL.md

name, description, disable-model-invocation, allowed-tools

name	description	disable-model-invocation	allowed-tools
init	Initialize the tome knowledge layer for this repository — scaffold the wiki, build the project-specific overlay (navigate skill, folder guide, platform notes), and select which curation methods apply. Run once on a new project, or after major structural changes. Human-triggered.	true	Bash(just:*), Bash(uv run:*), Bash(git:*), Bash(ls:*), Bash(cat:*), Read, Write, Glob, Grep, Agent

Tome — Init

Tome is opt-in — it requires project-level setup to be useful. Install the tome plugin, then run this skill to scaffold the knowledge structure.

Three phases: deterministic scaffold, agent-authored project overlay, and curation method selection.

Phase 1 — Bootstrap the wiki scaffold

just tome init

(Without Justfile: uv run -q --script <tome-plugin-dir>/bin/knowledge.py bootstrap)

This creates the wiki/ tree, boot.md, and folder navigation. Review its output.

Phase 2 — Build the project-specific overlay

The real value is a project-specific skills directory that layers project knowledge on top of generic tome navigation. This can be a sibling skill directory or an overlay in the project's .claude/ configuration.

Pick a short project slug (e.g. myapp, acme). Create the overlay at a location appropriate for the project (e.g. .claude/skills/<slug>-tome/).

Step 2.1 — Detect the project stack

Investigate before writing anything:

• Language / framework: Read Cargo.toml, package.json, pyproject.toml, go.mod, or equivalent. Note major frameworks.
• Build tool / task runner: Check for Justfile, Makefile, Taskfile.yml, package.json scripts, etc.
• Shell / platform: Check the environment — $SHELL, $OS, platform in CLAUDE.local.md. Note any platform-specific quirks.
• Existing CLAUDE.md files: Glob for **/CLAUDE.md to understand what documentation already exists and how the project structures its knowledge.
• Top-level directories: ls the repo root. Note which directories hold source, assets, docs, config, build output, tests, scripts.

Step 2.2 — Create the overlay scaffold

Create these files in the overlay directory:

plugin.json (if creating a standalone plugin overlay):

{
  "name": "<slug>-tome",
  "version": "0.1.0",
  "description": "<Project>-specific navigation and project knowledge layer. Extends the generic tome with project-aware folder orientation, platform quirks, build conventions, and runtime probes."
}

Step 2.3 — Write the navigate skill

Create a navigate skill (e.g. skills/navigate/SKILL.md) with this structure:

---
name: navigate
description: >
  <Project>-specific navigation layer. Provides project-aware orientation ...
  on top of the generic tome:navigate skill.
allowed-tools: Bash(just:*), Bash(uv run:*)
---

The body must have three layers of decreasing certainty:

1. Layer 1 — Universal truths: Facts that never change. Path conventions, where source code lives, what each top-level directory means, which files are stubs vs real code. Things an agent must always know.

2. Layer 2 — Bounded possibilities: Things that vary but within known bounds. Platform targets, optional features/flags, environment variants, toolchain choices. Things that narrow the search space.

3. Layer 3 — Runtime probes: Commands the agent should run to resolve remaining uncertainty. just tome context "<path>", just --list, checking configs, reading specific CLAUDE.md files. Teach the agent how to self-serve.

End with a Reference documents section pointing to the folder guide, platform notes, wiki NAV files, glossary, and root CLAUDE.md.

Step 2.4 — Write the folder guide

Create references/folder-guide.md. This is NOT a file listing — it explains what each directory IS and WHY it matters.

Structure it as tables:

• Top-level directories (every directory at repo root worth mentioning)
• Key nested directories in the main source tree
• Key nested directories in secondary source locations (if any)
• Wiki structure (if wiki/ exists after Phase 1)

For each entry: folder path, what it is (one phrase), and notes (CLAUDE.md presence, gotchas, relationships to other directories).

Step 2.5 — Write platform notes

Create references/platform-notes.md. Cover what agents need to avoid common mistakes:

• Paths: Slash conventions, absolute vs relative expectations
• Task runner: Canonical way to build/run/test, key recipes
• Language toolchain: Version pinning, workspace structure, known quirks
• Optional integrations: Feature flags, external services, SDKs
• Scripting: Where helper scripts live, how to run them
• Key binaries / entry points: How to run the app in different modes

Only include sections that apply. Be specific — generic advice wastes tokens.

Step 2.6 — (Optional) Curation rules

If the project has enough CLAUDE.md files or wiki content to warrant curation conventions, create references/curation-rules.md describing when to create vs update CLAUDE.md files, what status markers mean, and how the wiki relates to inline docs.

Skip this for small projects — but proceed to Phase 3 regardless, as method selection applies to projects of all sizes.

Phase 3 — Curation method selection

Detect what the project has and record which curation methods apply. This determines what /tome:curate can do for this project.

Step 3.1 — Detect signals

Detection signal	Method	Check
Source code exists	code-digest	Always true if there's a repo
Authored reference docs exist	reference-digest	docs/topics/, docs/design/, doc/, or similar
Any project	explorer	Always available
Domain knowledge without code	concept-author	Business rules, taxonomy, domain jargon
Workpad/research notes exist	workpad-graduate	docs/workpad/, notes/, research/
Wiki has content	seal	Available once other methods have produced content

Step 3.2 — Propose methods

Present the user with a table of detected methods and entry points:

Detected curation methods for <project>:

| Method | Entry points | Signal |
|--------|-------------|--------|
| code-digest | codebase/ | Source tree with N modules |
| reference-digest | design/ | M docs in docs/topics/ |
| explorer | wiki root | Always available |
| concept-author | concepts/ | Project has domain knowledge |
| workpad-graduate | (varies) | docs/workpad/ has research notes |
| seal | (all folders) | Available after content exists |

Proceed with these? [confirm/adjust]

Step 3.3 — Record in curation rules

Add an Active Curation Methods section to the project's curation rules (references/curation-rules.md). If no curation rules file exists yet, create one. The section declares:

• Which methods are active
• What entry points each method feeds (wiki folder names)
• What source locations each method reads from
• Any project-specific notes per method

Example:

## Active Curation Methods

| Method | Entry Points | Source | Notes |
|--------|-------------|--------|-------|
| code-digest | `codebase/` | `src/`, `lib/` | Baseline. |
| reference-digest | `design/` | `docs/topics/` | Reference docs to digest. |
| explorer | wiki root | Entire project | Replace generated README.md with authored narrative. |
| concept-author | `concepts/` | User knowledge | Domain rules, taxonomy. |
| workpad-graduate | (varies) | `docs/workpad/` | Available path. Graduation is user-triggered. |
| seal | (all folders) | Wiki structure | Run after other methods produce content. |

Step 3.4 — Scaffold entry points

For each active method that feeds a wiki entry point that doesn't exist yet:

1. Create the directory (e.g. wiki/design/, wiki/concepts/)
2. Create a NAV.md with status: stub front matter
3. Do NOT create content — that's what the curation methods themselves do

Phase 4 — CLAUDE.md routing convention

If the project's root CLAUDE.md (or any module CLAUDE.md) has routing tables exceeding ~15 lines, propose splitting them into @AGENTS.md includes:

# Module Name
@AGENTS.md

This keeps CLAUDE.md small and readable while AGENTS.md carries the machine- readable routing. Works in Claude Code (@-includes) and other agent frameworks.

Do not force this — propose it when it would reduce CLAUDE.md size meaningfully.

Verification

After creating all files:

1. Confirm the overlay is loadable: check that any plugin.json is valid JSON
2. Run just tome check to verify knowledge-layer health
3. Read back the navigate skill and verify the three layers make sense for the project you just analyzed
4. Verify that the curation rules list the right methods for what you detected