--- name: wiki-yylo description: Use YYLO Ledger wiki Records as durable project knowledge. Search before creating, classify information correctly, and make revision-safe Markdown updates without editing Ledger storage directly. category: project-management risk: safe source: https://github.com/yylo-dev/yylo-skills source_repo: yylo-dev/yylo-skills source_type: community date_added: '2026-09-19' license: MIT license_source: https://github.com/yylo-dev/yylo-skills/blob/main/LICENSE compatibility: Requires the `yy` CLI with the `wiki` record group installed (controller or standalone). Revision-safe Markdown updates only; never edit Ledger storage directly. argument-hint: '[wiki question or knowledge to find/create/update]' enable-shell-directives: true --- # Use YYLO wiki Records Treat Ledger as the source of truth. Use `yy ledger` in a YYLO controller and `yylo-ledger` in a standalone Ledger project. Inspect `COMMAND wiki --help` before acting; if `wiki` is absent, the installed Ledger version does not expose native Record commands and must not be bypassed with direct file edits. ## Choose the right record Before writing, decide where the information belongs: - **Wiki**: durable explanatory project or domain knowledge that future work must discover. - **Task**: scoped requested work, status, dependencies, acceptance criteria, and completion evidence. - **Workflow**: validated structured steps, not prose guidance. - **Artifact**: generated evidence, reports, receipts, logs, model output, or binary payloads. - **Source documentation**: documentation released and versioned with product code. Do not put secrets, caches, session transcripts, temporary status, bulky generated evidence, or owner-only operational receipts in a wiki. ## Discover before creating Use bounded summary searches first. Resolve records by immutable ID whenever one is known; slugs and aliases are discovery conveniences, not replacement identity. ```bash yy ledger wiki search --text "deployment policy" --projection summary --limit 20 -f json yy ledger wiki get RECORD_ID -f json yy ledger wiki get RECORD_ID --raw ``` Use `--scope archive|all` only when the request requires cold records. Request `full` projection only when payload bytes are necessary. ## Create durable Markdown Use a file or stdin for substantial or shell-sensitive content: ```bash yy ledger wiki create --title "Service ownership" --file ownership.md yy ledger wiki create --title "Incident notes" --file - < incident-notes.md ``` Choose a stable title, namespace, slug, aliases, and relations deliberately. Keep one topic per Record and link related immutable Record IDs rather than duplicating truth. ## Update safely 1. Read the current Record and revision. 2. Preserve its immutable ID and inspect history when intent is unclear. 3. Follow `wiki update --help` for the installed compare-and-replace controls. 4. Supply the expected revision and required preimage/digest evidence. 5. Use file transport; do not rewrite Ledger files yourself. 6. Read back the resulting revision and receipt. A revision or preimage mismatch means the source changed: reread and reconcile. Never force past concurrent edits. Archive is a lifecycle transition, not delete. Use `--front-matter` only for canonical front-matter interchange and `--rendered` for inert, HTML-escaped rendering. Use `history RECORD_ID` to understand revisions; do not infer history from the latest payload alone. ## Project wiki boundary Portable controller guidance may live under the controller wiki, while project and domain pages retain project-owned paths. Package-managed and project-owned pages can coexist. Migration, runtime replacement, exceptional merge recovery, release, deployment, and cold-archive maintenance remain authoritative runbooks, not content to summarize into an everyday global skill. ## Complete request $ARGUMENTS ## When to Use - You need durable project or domain knowledge as YYLO Ledger wiki Records (search, create, revision-safe update). - You must first decide the record belongs in the wiki rather than a task, workflow, artifact, or product docs. ## Limitations - Search before creating; one topic per Record, linked by immutable Record IDs. - Never store secrets, caches, session transcripts, temporary status, bulky generated evidence, or owner-only receipts in a wiki. - Updates bind to the expected revision/preimage; on mismatch reread and reconcile - never force past concurrent edits. Archive is a lifecycle transition, not deletion. - If the `wiki` group is absent, fail closed and request a Ledger upgrade. ### Example ```bash yy ledger wiki search --text "deployment policy" --projection summary --limit 20 -f json yy ledger wiki get RECORD_ID -f json ``` > Adapted from [yylo-dev/yylo-skills](https://github.com/yylo-dev/yylo-skills) (MIT) - v2.0.1; frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance.