LLM Workspace Management

Maintain a global view and cross-wiki orchestration for a local multi-wiki workspace — single-wiki ingest / query / lint operations go to the

yzr-llm-wiki-management

skill. This skill sits above all wikis and handles tasks requiring cross-wiki judgment.

Two deliverables:

SKILL.md (this document) — workflows + boundaries
Deterministic execution is handled by llmw CLI — this skill is zero-code, converged into two commands; refer to the detector for inconsistencies:
- ```
llmw check-fixtures
```
  : Only detect (output drift report, no disk writes)
- ```
llmw upgrade
```
  : Workspace skeleton + per-wiki aggregated deterministic upgrade (dry-run by default)

Input / Output

Information Required at Startup

Information	Source	Notes
Workspace path	`$LLMW_WORKSPACE` or default `~/yzr-llm-wiki-workspace` or interactive query	CLI usually sets the variable on enter
Operation type	User natural language	scan / query / link / lint / upgrade
Query scope (query only)	User natural language or explicitly specified wiki names	Use global INDEX routing if not specified

Operation Products

scan → Write

<workspace>/INDEX.md

<workspace>/STATS.md

(format A2/A3)

query → Provide answers in conversation (with per-wiki references); optional archive to
```
<workspace>/cross_queries/<slug>.md
```
(format A4)
link → Add cross-wiki links in involved wikis via the
```
yzr-llm-wiki-management
```
ingest process
lint → Write
```
<workspace>/LINT.md
```
(format A5) + conversation summary
upgrade → Run
```
llmw upgrade
```
(dry-run by default; add
```
--apply [--yes]
```
to write to disk); 3 final-state JSON outputs from CLI; see §6 for details

Execution Principles / Boundaries

Boundary with Workspace CLI

When this skill is active, it can call

llmw

— directly execute read / detect / upgrade commands (see

llmw --help

for subcommands and parameters, no enumeration); for commands that modify workspace/wiki metadata or affect running sessions, provide the complete command to the user for confirmation before execution.

Do not write toml manually — Metadata writes must go through CLI (schema validation / atomic writes / uniqueness constraints guaranteed by CLI). Commands involving api_key must always be executed by the user personally (secrets do not pass through the agent).

Boundary with yzr-llm-wiki-management

All single-wiki operations (ingest / query / lint / write files within a wiki) are delegated to

yzr-llm-wiki-management

— this skill does not directly edit

<wiki>/wiki/**

(maintain invariants such as log.md synchronization and frontmatter). This skill only handles workspace-level tasks: scan aggregation / routing / cross-wiki synthesis and comparison / cross-wiki link suggestions / workspace lint / cross-wiki memory.

Products This Skill Can Write (Invariants, Mandatory)

File / Directory	Writer	Boundary
`<workspace>/INDEX.md`	This skill	Aggregated write during scan
`<workspace>/STATS.md`	This skill	Aggregated write during scan
`<workspace>/cross_queries/`	This skill	Archive for cross-wiki synthetic Q&A
`<workspace>/LINT.md`	This skill	Workspace-level lint report
`*.md` in `<workspace>/MEMORY/` + synchronized `MEMORY.md` index	This skill	Only cross-wiki experience (single-wiki experience belongs to `<wiki>/MEMORY/` )

Violating ownership = bug. Complete ownership table + quadrant table can be found in the "Boundaries of This Workspace" + "Discipline of This File Itself" sections (byte-owned template rendering) of

<workspace>/AGENTS.md

Workflows / Steps

0. Startup Check

Every time this skill is entered:

Locate workspace path:
```
$LLMW_WORKSPACE
```
→ default
```
~/yzr-llm-wiki-workspace
```
→ interactive query
Verify that
```
<workspace>/workspace.toml
```
exists — if not, prompt the user "Workspace not initialized yet, run
```
llmw init
```
to initialize" (do not run it for the user)
Load cross-wiki MEMORY index: Automatically loaded via
```
@MEMORY/MEMORY.md
```
import in
```
<workspace>/AGENTS.md
```
when working in the workspace root; if working in a non-root directory / reading AGENTS.md natively without expanding
```
@
```
agents → explicitly
```
Read <$LLMW_WORKSPACE>/MEMORY/MEMORY.md
```
to supplement
Load scope boundaries: When the agent's cwd is within a
```
<wiki>/
```
subdirectory and switches to running
```
yzr-llm-wiki-management
```
, this skill's discipline does not take over; instead, the single-wiki discipline in
```
<wiki>/AGENTS.md
```
takes effect
Do not run
```
scan
```
automatically — wait for user's operation intent

1. Scan / refresh-index

Triggers: "Scan workspace" / "Update INDEX.md" / User says "Workspace needs to be refreshed".

Process:

Read
```
<workspace>/workspace.toml
```
to get the
```
[wikis]
```
registry
For each wiki:
- Read
```
<wiki>/wiki_metadata.toml
```
  (maintained by CLI)
- Read the "Boundaries of This Wiki" section in
```
<wiki>/AGENTS.md
```
  (get boundaries)
- Read
```
<wiki>/wiki/index.md
```
  (existing content + paragraph skeleton)
- Scan
```
<wiki>/wiki/{entities,concepts,sources,comparisons,syntheses}/
```
  to get page counts
- Recursively scan
```
<wiki>/raw/
```
  to count raw materials (only count, do not read content)
- Read the last entry in
```
<wiki>/wiki/log.md
```
  to get last activity
- Read
```
<wiki>/MEMORY/
```
  to count memory files (only file names)
Read the
```
<workspace>/MEMORY/MEMORY.md
```
index, aggregate according to A2 sorting rules, write INDEX.md + STATS.md (format A2/A3)
Atomic write (POSIX
```
tmp + fsync + rename
```
)
Report in conversation: "INDEX.md / STATS.md refreshed, X wikis, Y pages, Z raw materials"

When not to scan: If the user only wants to perform a query → use the existing INDEX.md first; if INDEX.md is missing or obviously outdated (does not cover newly added wikis), prompt to scan first.

2. Query (Cross-wiki Q&A)

Triggers: "Summarize content about X across all my wikis" / "Compare A and B on Y" / "Which wiki should I check for X".

4 modes + priority: local > compare > route > synthesis:

Mode	Trigger Keywords	Process
local	"Only look at wiki X" / "Search Y in X"	Delegate query to `yzr-llm-wiki-management`
compare	"Compare A and B" / "Differences between A and B"	Read both wiki/index.md → query → diff-style comparison
route	"Which wiki should I check" / "Which wiki does this belong to"	Read INDEX.md → match by topic / tag / description → return 1-3 candidate wikis
synthesis	"Summarize all" / "Synthesize all wikis" / fallback	Route → query each candidate wiki → merge + label per-wiki sources

Good queries must include an "archive or not" step — archive location:

If the answer involves a single wiki →

<wiki>/wiki/syntheses/<slug>.md

(via

yzr-llm-wiki-management

)

If the answer involves multiple wikis →
```
<workspace>/cross_queries/<slug>.md
```
(directly written by this skill, format A4)

When archiving content that references upstream volatile facts, pass perception tests — SSOT rules can be found in the "Stability of Body References" section of

yzr-llm-wiki-management

references/ingest-workflow.md

3. Link (Cross-wiki Cross-referencing)

Triggers: "Entity X in wiki A also exists in wiki B, add a link" / "Scan for cross-wiki duplicate entities".

Process:

Scan: For each wiki's
```
wiki/entities/
```
+
```
wiki/concepts/
```
, extract all entity names (frontmatter
```
title
```
or filename slug)
Deduplicate and aggregate: Collect cross-wiki entities with the same name / similar meaning (compared by description) as candidate pairs
Suggest: List candidate pairs in conversation and let the user select which ones need cross-wiki links
Write: After user confirmation, for each involved wiki, call the ingest process of
```
yzr-llm-wiki-management
```
to update the corresponding entity / concept page — append a "Cross-wiki References" section (xref format see the "Cross-wiki Agreements" section of
```
<workspace>/AGENTS.md
```
)

4. Lint (Workspace-level)

Triggers: "Workspace lint" / "Workspace health check" / Periodically (e.g., alongside each scan).

Process:

Workspace-level deterministic checks (inline in agent):
- Cross-wiki duplicate entities (pairs with same name but different slugs)
- Invalid cross-wiki links (paths in
```
sources
```
  of cross_queries/*.md do not exist;
```
../<another-wiki>/...
```
  paths in
```
<wiki>/wiki/**
```
  do not exist)
- Unregistered wiki subdirectories (
```
<wiki>/AGENTS.md
```
  exists on disk but not registered in workspace.toml)
- Wikis registered in workspace.toml but not present on disk (orphaned registrations)
- Consistency between wiki lists in STATS.md and INDEX.md
- MEMORY index consistency: Scan
```
<workspace>/MEMORY/*.md
```
  (excluding
```
MEMORY.md
```
  ), if any file is not listed in
```
MEMORY/MEMORY.md
```
  index → report
```
memory-not-indexed
```
  (severity = info)
Semi-qualitative checks:
- Whether wikis with overlapping topics need to be merged
- Whether the tag system is chaotic (same tag with different meanings / same meaning with different tag names)
What this skill does not do: Single-wiki internal lint — delegate to
```
yzr-llm-wiki-management
```
Output: Write
```
<workspace>/LINT.md
```
(format A5) + report in conversation

When not to lint: If the user only asks a query → do not lint; if the user says "Scan" → perform scan instead of lint.

5. Memory (Cross-wiki Agent Private Memory)

Triggers: Actively write when identifying cross-wiki information worth preserving during scan / query / link / lint processes.

One-line judgment: Cross-wiki preferences/associations/patterns/experiences → write; Single-wiki observations → delegate to

yzr-llm-wiki-management

; Cross-wiki synthetic answers themselves → archive to

cross_queries/

; One-time observations → directly chat.

The complete "when to write/not write" + judgment scale canonical = "Memory Discipline" section (byte-owned template rendering) of

<workspace>/AGENTS.md

, not repeated in this appendix.

Process:

Identify observations worth preserving → self-check scope to confirm cross-wiki
Determine entry format (full / short)
Write to
```
MEMORY/<slug>.md
```
(full entry) or append a short entry line directly to
```
MEMORY/MEMORY.md
```
Synchronize one line in MEMORY.md index (missing write = unreadable next time, lint
```
memory-not-indexed
```
as fallback)

Do not modify

<workspace>/INDEX.md

STATS.md

LINT.md

/ any

<wiki>/MEMORY/

6. Upgrade (Upgrade Workspace Skeleton)

Triggers: "Upgrade workspace / Check workspace version / Format upgrade".

llmw upgrade

(CLI) = All deterministic operations — workspace skeleton + per-wiki aggregated two-stage processing, handled according to the "Discipline of This File Itself" section (including skeleton ownership quadrant table) of

<workspace>/AGENTS.md

llmw check-fixtures

only detects (no disk writes). Agent = run command + interpret output.

Process:

```
llmw upgrade
```
defaults to dry-run → output workspace + processing plan for each wiki + 3 final-state JSON (add
```
--json
```
for machine-readable)
Interpret 3 final states:
- ```
done
```
  → Wrap up, prompt user "Workspace upgrade completed, X wikis upgraded"
- ```
blocked_drift
```
  → Move custom content to
```
MEMORY/
```
  according to the
```
hint
```
  field, then re-run
```
llmw upgrade --apply --yes
```
- ```
verify_failed
```
  → Report to user, escalate to manual processing
Subsequent content migration for each wiki uses the
```
yzr-llm-wiki-management
```
workflow — this skill does not run it on behalf of the user

Do not write to

INDEX.md

STATS.md

LINT.md

(upgrade is not a scan / lint event). Upgrade only modifies byte/block/header-owned files, does not touch confidential configurations.

Reference Examples

Example 1: Cross-wiki Synthetic Q&A

User: "What records do I have about RAID across all my wikis?"

Skill reads
```
<workspace>/INDEX.md
```
→ finds that
```
huawei_storage_wiki
```
's description contains "storage"
Mode = synthesis

Delegates query "RAID" to

yzr-llm-wiki-management

for

huawei_storage_wiki

Gets answer (with source page references), provides it to user in conversation, and asks "This only involves 1 wiki, should we archive it to
```
huawei_storage_wiki/wiki/syntheses/raid-overview.md
```
?"
User confirms → uses
```
yzr-llm-wiki-management
```
to write synthesis page + log entry

Example 2: Routing

User: "I just downloaded an LLM inference paper, which wiki should I put it in?"

Skill reads INDEX.md + reads description / tags of each wiki
Mode = route
Returns: "
```
huawei_storage_wiki
```
focuses on storage, not relevant;
```
test
```
wiki focuses on test, not relevant; recommend creating a new wiki (
```
llmw wiki --name=llm-inference add ...
```
)"
Offers to run
```
llmw wiki --name=llm-inference add
```
on behalf of the user — execute after user confirmation (skill handles routing and closes the loop)

Reference Documents

Required Reading:
```
<workspace>/AGENTS.md
```
(= rendered from
```
workspace-agents-md-template.md
```
template, byte-owned) — canonical workspace-level contract
Single-wiki Contract:
```
yzr-llm-wiki-management
```
SKILL.md + references/ (this skill reads wiki files according to its contract, does not write directly)
CLI Documentation: Workspace CLI (command
```
llmw
```
, maintained in the same repo as this skill) — reference for commands like
```
init / add / remove / config / enter / model ...
```
here

Appendix: Product Format Contracts and Reading Contracts

This appendix carries format contracts for files written to disk by the skill. Reading contracts and instance ownership can be found in
<workspace>/AGENTS.md
.

A1. workspace.toml Reading Contract

Path:
```
<workspace-root>/workspace.toml
```
Complete schema authority is in CLI code;
```
workspace-toml-reads-satisfied
```
check verifies reading contract integrity

Fields actually read by the skill (used in

scan

upgrade

Field	Purpose
`templates_version`	`llmw upgrade` version comparison + automatic bump (includes `workspace_format` / `wiki_format` dual components)
`[wikis.<name>].path`	Skill `scan` traverses wiki subdirectories
`[wikis.<name>].created_at`	Wiki sorting within INDEX

A2. INDEX.md

Maintainer: Skill writes during
```
scan
```
; CLI does not write

Required frontmatter (A7) +

type: workspace-index

;

title

recommended as

"Workspace Index"

;

tags

recommended as

[workspace, index]

Body skeleton:

markdown

# <Workspace Display Name> — Workspace Index

> Workspace entry document. One section per wiki, sorted alphabetically by wiki name; sorted by `created_at` ascending within the same alphabetical group.

## Wikis

### <wiki-name>

- **display_name**: ...
- **topic**: ...
- **description**: ...
- **tags**: [...]
- **created**: YYYY-MM-DD
- **last activity**: YYYY-MM-DD (log entry kind)
- **page counts**: 0 entities / 0 concepts / ...
- **key entities**: [...]
- **one-line summary**: ...

## Cross-wiki Links
...(short description)
## Recent Activity (across all wikis)
...

A3. STATS.md

Maintainer: Skill writes alongside
```
scan
```
; difference from INDEX.md: structured (table)
Required frontmatter (A7) +
```
type: workspace-stats
```
Body skeleton:
```
# <Workspace> — Workspace Stats
```
+
```
## Overview
```
summary table +
```
## Per-wiki
```
section with per-wiki sub-tables (pages / entities / concepts / sources / comparisons / syntheses / raw_files / last_log_entry / tags / memory_files)
Skill write scenario:
```
scan
```
(same refresh as INDEX.md)

A4. cross_queries/

Maintainer: Skill writes when query output is suitable for archiving
File naming:
```
<slug>.md
```
, kebab-case
```
^[a-z0-9][a-z0-9-]*$
```
(A8)
Required frontmatter (A7) +
```
type: cross-query
```
;
```
tags
```
recommended as
```
[workspace, cross-query, <tags of involved wikis>...]
```
; required
```
sources
```
(array of paths to wiki pages referenced, relative to workspace root) +
```
wikis
```
(array of involved wiki names)
Skill write scenario: When user confirms archiving of query output

A5. LINT.md

Maintainer: Skill writes the latest report during
```
lint
```
(does not accumulate, overwrites each time, is a snapshot)
Required frontmatter (A7) +
```
type: workspace-lint
```
Body skeleton:
```
# <Workspace> — Lint Report (<YYYY-MM-DD>)
```
+
```
## Per-wiki Issues
```
(one section per wiki, single-wiki lint goes to yzr-llm-wiki-management) +
```
## Workspace-level Issues
```
(cross-wiki duplicate entities / unregistered subdirectories / outdated STATS / MEMORY index consistency / ...)
Skill write scenario:
```
lint
```
(overwrites each time)

A6. workspace MEMORY/

Maintainer: CLI creates empty directory and writes
```
MEMORY/MEMORY.md
```
index placeholder during init; subsequent entries are written by skill + synchronized to append one line to MEMORY.md index. Humans do not write; CLI does not write
MEMORY is not mandatory to be listed in INDEX.md (private agent entry)
Entry format (full / short) + when to write/not write + index line format canonical = "Memory Discipline" section (byte-owned template rendering) of
```
<workspace>/AGENTS.md
```
, not repeated in this appendix

A6.1 MEMORY/MEMORY.md (Index)

No frontmatter (loaded inline via

@MEMORY/MEMORY.md

@import

<workspace>/AGENTS.md

); body: 1 introductory paragraph at the top +

## Index

section (coexistence of full/short entry formats).

A6.2 MEMORY/*.md (excluding MEMORY.md)

Only

title

is required in frontmatter;

type

can be fixed as

workspace-memory

(aligned with wiki-side MEMORY decoupling specification);

created

updated

tags

description

wikis

are all optional. Lint

memory-not-indexed

as fallback; no mandatory inbound links, not listed in INDEX.md.

A7. General Frontmatter Field Rules

5 general required fields (workspace-level markdown, except MEMORY/*.md — see A6.2):

Field	Type	Description
`title`	string	Without file extension
`type`	enum	See table below
`tags`	array	Can be empty
`created`	date	`YYYY-MM-DD`
`updated`	date	`YYYY-MM-DD`

type
values (workspace-level markdown):

`type`	Notes
`workspace-index`	`<workspace>/INDEX.md` (unique)
`workspace-stats`	`<workspace>/STATS.md` (unique)
`workspace-lint`	`<workspace>/LINT.md` (unique)
`cross-query`	`<workspace>/cross_queries/<slug>.md`
`workspace-memory`	`<workspace>/MEMORY/*.md` (if type is written; optional)

Type-specialized fields:

Field	Applicable type	Required	Meaning
`sources`	`cross-query`	Yes	Array of paths to referenced wiki pages (relative to workspace root)
`wikis`	`cross-query` / `workspace-memory`	Required for `cross-query` / recommended for `workspace-memory`	List of involved wiki names
`description`	All	Recommended	One-sentence description

Semantic writing rules for fields (how to write good

title

description

tags

) SSOT = §1 of

yzr-llm-wiki-management

page-templates.md.

A8. Naming Constraints

This table only carries naming constraints for files written to disk by the skill (these files are not read/written by CLI, no mechanical gate; the only constraint carrier = this section). Wiki names (validated when created via

llmw wiki add

) and CLI internal identifiers belong to CLI; recommended wiki naming style can be found in the "Cross-wiki Agreements" section of

<workspace>/AGENTS.md

Dimension	Rule	Applicable Object
cross_query slug	kebab-case `^[a-z0-9][a-z0-9-]*$`	`cross_queries/<slug>.md`
MEMORY filename	kebab-case `^[a-z0-9][a-z0-9-]*$`	`<workspace>/MEMORY/*.md` (except MEMORY.md)
frontmatter field name	Strict lowercase + underscore	All workspace-level markdown
frontmatter `type` value	Strict lowercase + hyphen (e.g., `workspace-index` / `workspace-memory` )	All workspace-level markdown

yzr-llm-workspace-management

NPX Install

Tags

SKILL.md Content (Chinese)

LLM Workspace Management

Input / Output

Information Required at Startup

Operation Products

Execution Principles / Boundaries

Boundary with Workspace CLI

Boundary with yzr-llm-wiki-management

Products This Skill Can Write (Invariants, Mandatory)

Workflows / Steps

0. Startup Check

1. Scan / refresh-index

2. Query (Cross-wiki Q&A)

3. Link (Cross-wiki Cross-referencing)

4. Lint (Workspace-level)

5. Memory (Cross-wiki Agent Private Memory)

6. Upgrade (Upgrade Workspace Skeleton)

Reference Examples

Example 1: Cross-wiki Synthetic Q&A

Example 2: Routing

Reference Documents

Appendix: Product Format Contracts and Reading Contracts

A1. workspace.toml Reading Contract

A2. INDEX.md

A3. STATS.md

A4. cross_queries/

A5. LINT.md

A6. workspace MEMORY/

A6.1 MEMORY/MEMORY.md (Index)

A6.2 MEMORY/*.md (excluding MEMORY.md)

A7. General Frontmatter Field Rules

A8. Naming Constraints