@younndai/lyt-skills 0.10.0 → 0.11.0

package/README.md

@@ -24,41 +24,36 @@
 
 ## What is this?
 
-`@younndai/lyt-skills` is where [Lyt™](https://github.com/YounndAI/lyt)'s **AI-first** design becomes tangible: sixteen harness skills that let AI agents — Claude Code, Codex, and generic agent runtimes — drive your markdown vaults as **first-class operators**. Install once and your agent can capture notes, search your pod, record decisions, write plans, retros, and handoffs, explore meshes, and sync vaults — through the same governed operation set you use, under the same permission semantics. This is the "install once, every agent runtime knows Lyt" layer.
+`@younndai/lyt-skills` is where [Lyt™](https://github.com/YounndAI/lyt)'s **AI-first** design becomes tangible: eleven harness skills that let AI agents — Claude Code, Codex, and generic agent runtimes — drive your markdown vaults as **first-class operators**. Install once and your agent can capture notes, search your pod, prime on context, adopt a vault, explore meshes, and sync vaults — through the same governed operation set you use, under the same permission semantics. This is the "install once, every agent runtime knows Lyt" layer.
 
-Most skills wrap a pattern verb from the `lyt pattern run` runtime, so structured knowledge work (plans, results, decisions, captures) shows up as first-class agent skills inside any vault; the read/orient + addressing skills (`/lyt-pod`, `/lyt-search`, `/lyt-primer-context`, `/lyt-mesh-explore`, `/lyt-sync`, `/lyt-alias`) wrap the corresponding CLI verbs directly. Pairs with [`@younndai/lyt-vault`](https://www.npmjs.com/package/@younndai/lyt-vault), which ships the four default patterns the skills resolve against.
+The `/lyt-capture` skill wraps the `knowledge-capture` pattern verb from the `lyt pattern run` runtime, so structured note capture shows up as a first-class agent skill inside any vault; the read/orient + addressing + lifecycle skills (`/lyt-pod`, `/lyt-search`, `/lyt-recall`, `/lyt-primer-context`, `/lyt-mesh-explore`, `/lyt-sync`, `/lyt-alias`, `/lyt-adopt`, `/lyt-update`) wrap the corresponding CLI verbs directly. Pairs with [`@younndai/lyt-vault`](https://www.npmjs.com/package/@younndai/lyt-vault), which ships the bundled `knowledge-capture` pattern the capture/recall skills resolve against (workflow patterns are bring-your-own via `lyt pattern install`).
 
 ## Install
 
 ```bash
 npm install -g @younndai/lyt@alpha   # the meta package bundles lyt-skills
-lyt skills install                   # links the 16 SKILL.md files into your harness(es)
+lyt skills install                   # links the 11 SKILL.md files into your harness(es)
 ```
 
 Tri-runtime: the installer detects Claude Code, Codex, and generic agent runtimes, and installs per-runtime (symlink by default, `--copy` for regular directories).
 
-## The 16 skills
+## The 11 skills
 
 | Skill                 | Wraps                                              | Use it when                                                  |
 | --------------------- | -------------------------------------------------- | ------------------------------------------------------------ |
 | `/lyt-capture`        | knowledge-capture + capture                        | Saving a Figment (markdown note) into a vault.               |
-| `/lyt-recall`         | knowledge-capture + recall                         | Keyword search across a single vault.                        |
+| `/lyt-recall`         | `lyt search --vault` (tiered cascade)              | Ranked search across a single vault.                         |
 | `/lyt-search`         | `lyt search` (tiered cascade)                      | Ranked search across the whole pod, a mesh, or a vault.      |
 | `/lyt-pod`            | `lyt mesh list` + `lyt vault list`                 | Enumerating every mesh + vault on the machine.               |
 | `/lyt-mesh-explore`   | `lyt mesh info`                                    | Drilling into one mesh's members and metadata.               |
 | `/lyt-alias`          | `lyt alias` set/`--list`/`--remove`                | Managing pod-local vault aliases (name → rid).               |
 | `/lyt-primer-context` | `lyt primer` + `lyt vault info`                    | Priming an agent with vault/mesh/pod context.                |
 | `/lyt-sync`           | gated git pull/commit/push                         | Syncing a vault with its remote under the writable gate.     |
-| `/lyt-plan`           | work-management + plan                             | Drafting a multi-phase plan before implementation.           |
-| `/lyt-progress`       | work-management + progress                         | Mid-session progress update or blocker write-up.             |
-| `/lyt-result`         | work-management + result                           | Session-end result with per-clause acceptance.               |
-| `/lyt-retro`          | work-management + retro                            | Post-implementation retrospective.                           |
-| `/lyt-insight`        | work-management + insight                          | Promoting a result into a durable insight.                   |
-| `/lyt-handoff`        | work-management + handoff                          | Writing the next session's handoff brief.                    |
-| `/lyt-decision`       | decision-log + decision                            | Recording a decision + rationale pair.                       |
+| `/lyt-adopt`          | `lyt vault adopt`                                  | Bringing an existing Obsidian vault into the pod.            |
+| `/lyt-update`         | `lyt outdated` + `lyt update`                      | Checking for and installing a newer Lyt release.             |
 | `/lyt-pattern`        | meta-skill over `lyt pattern *`                    | Listing, installing, linking patterns from an agent context. |
 
-Each skill autodetects the active vault + project via `lyt vault info --by-path`, the `LYT_ACTIVE_VAULT` env var, or an explicit `--vault` flag, then calls `lyt pattern run <pattern> <verb>` to write the file at the resolved path.
+Each skill autodetects the active vault via `lyt vault info --by-path`, the `LYT_ACTIVE_VAULT` env var, or an explicit `--vault` flag, then calls the CLI verb (or `lyt pattern run <pattern> <verb>` for `/lyt-capture`) at the resolved path.
 
 ## The capture contract
 
@@ -81,7 +76,7 @@ On an interactive terminal, `/lyt-capture` also resolves **where** the note land
 - A **pattern** is data: a `pattern.yon` descriptor + a `templates/` folder of markdown templates with frontmatter. Patterns live at `~/lyt/patterns/`.
 - A **skill** is a thin SKILL.md adapter an agent harness loads; it calls the pattern runtime.
 
-Fork any default pattern (`lyt pattern fork work-management --as wm-custom`) without modifying the master. See `lyt help patterns` and `lyt help skills`.
+Fork any installed pattern (`lyt pattern fork knowledge-capture --as kc-custom`) without modifying the master. See `lyt help patterns` and `lyt help skills`.
 
 ## The Lyt toolchain
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@younndai/lyt-skills",
-  "version": "0.10.0",
-  "description": "Lyt harness skills — 16 skills (/lyt-plan, /lyt-progress, /lyt-result, /lyt-retro, /lyt-insight, /lyt-handoff, /lyt-decision, /lyt-pattern, /lyt-capture, /lyt-recall, /lyt-pod, /lyt-mesh-explore, /lyt-primer-context, /lyt-search, /lyt-sync, /lyt-alias) symlinked tri-runtime into ~/.claude/skills/, ~/.codex/skills/, ~/.agents/skills/. Composed into the `lyt skills install` and `lyt skills list` meta-CLI verbs.",
+  "version": "0.11.0",
+  "description": "Lyt harness skills — 11 skills (/lyt-capture, /lyt-recall, /lyt-pattern, /lyt-pod, /lyt-mesh-explore, /lyt-primer-context, /lyt-search, /lyt-sync, /lyt-alias, /lyt-adopt, /lyt-update) symlinked tri-runtime into ~/.claude/skills/, ~/.codex/skills/, ~/.agents/skills/. Composed into the `lyt skills install` and `lyt skills list` meta-CLI verbs.",
   "homepage": "https://linkyourthink.com",
   "repository": {
     "type": "git",
@@ -49,7 +49,7 @@
     "prepublishOnly": "node ../../scripts/check-no-vendored-deps.mjs --root ../.. && node ../../scripts/public-release/scan-tarball.mjs lyt-skills"
   },
   "dependencies": {
-    "@younndai/lyt-vault": "^0.10.0",
+    "@younndai/lyt-vault": "^0.11.0",
     "commander": "^12.1.0"
   },
   "devDependencies": {

package/skills/lyt-adopt/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: lyt-adopt
+description: >
+  Guided adopt of an existing Obsidian vault into a Lyt pod. Trigger when the user runs /lyt-adopt, or says "adopt this vault", "bring this vault into Lyt", "upgrade this Obsidian vault", "make this folder a Lyt vault", or similar phrasing on an existing local vault directory. Additive-only: it creates `.lyt/` and NEVER touches the user's `.md` files. Gathers {name, mesh (default `personal`), backfill (offer-only), remote (deferred)} then calls `lyt vault adopt <path> [--name <name>] [--mesh <mesh>]`. Homes the vault into `personal/<leaf>` by default instead of leaving it orphan. Companion to /lyt-sync (once a remote exists) and the inverse of `lyt vault abandon`.
+visibility: public
+lyt-version: 0.11.0
+capabilities: [write]
+runtimes: [claude, codex, agents]
+requires_writable_vault: false
+---
+
+# /lyt-adopt
+
+Guided adopt of an existing Obsidian vault into the user's Lyt pod. Adopt is **additive-only**: it creates the `.lyt/` derived-state directory and registers the vault, but it **never touches the user's `.md` files**. It is the inverse of `lyt vault abandon` (the clean anti-lock-in leave, which removes only `.lyt/`).
+
+Under the hood this wraps `lyt vault adopt <path> [--name <name>] [--mesh <mesh>]`. The verb registers the vault, homes it into a mesh, rebuilds per-machine pattern links under `.lyt/patterns/`, and rebuilds the content caches so `/lyt-search` and `/lyt-recall` hit immediately.
+
+## When to invoke
+
+When the user runs `/lyt-adopt`, or says something like:
+
+- "adopt this vault"
+- "bring this Obsidian vault into Lyt"
+- "upgrade this folder into a Lyt vault"
+- "make this a Lyt vault"
+
+## When NOT to invoke
+
+- The directory is **already a Lyt vault** (`.lyt/vault.yon` exists) — use `lyt vault join <path>` to register an already-Lyt-aware vault instead. Adopt refuses with a clear message in this case.
+- The user wants to **create a brand-new** vault from scratch — use `lyt vault init <mesh>/<vault>` (create-if-missing).
+- The user wants to **clone a remote** vault — use `lyt vault clone <url>`.
+
+## Phase 1 — Resolve the target path
+
+The adopt argument is a **filesystem path** to the existing vault directory (not a vault name). Resolve it:
+
+1. If the user passed a path in the invocation, use it (resolve relative → absolute).
+2. Otherwise ask which directory to adopt. Do **not** guess from cwd.
+
+If the resolved path does not exist or is not a directory, stop and tell the user. If it already contains `.lyt/vault.yon`, stop and point them at `lyt vault join`.
+
+## Phase 2 — Gather the adopt parameters
+
+Gather these before calling adopt. Only **name** and **mesh** feed the command today; **backfill** and **remote** are DEFERRED and OFFER-ONLY (see Phase 4).
+
+| Parameter    | Default                                                             | How to resolve                                                                                                                          |
+| ------------ | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
+| **name**     | owner/repo when the path is under `~/lyt/vaults`, else folder basename | Accept a user-supplied `{mesh}/{vault}` name or leaf. Pass via `--name`. Omit to accept the default.                                    |
+| **mesh**     | `personal`                                                         | The home mesh. A bare adopt homes the vault into `personal/<leaf>` (find-or-create the `personal` mesh). Override with `--mesh <name>`. |
+| **backfill** | OFFER-ONLY (deferred)                                              | Do NOT run it. Only mention it as a possible future step (see Phase 4).                                                                 |
+| **remote**   | OFFER-ONLY (deferred)                                              | Do NOT wire a remote. Adopt never contacts a remote (see Phase 4).                                                                      |
+
+If the user does not signal a non-default mesh or name, use the defaults — do not over-prompt.
+
+## Phase 3 — Run adopt
+
+```
+lyt vault adopt <path> [--name <name>] [--mesh <mesh>]
+```
+
+- Omit `--name` to accept the default (owner/repo or basename).
+- Omit `--mesh` to home the vault into `personal/<leaf>` (the guided default). Pass `--mesh <name>` to home it elsewhere; the mesh is find-or-created.
+
+The command prints the adopted name, path, rid, registry status, and the resolved home mesh (or `orphan (unassigned)` if assignment was deferred). On success the vault is registered, homed, pattern-linked (under `.lyt/patterns/`, machine-local + gitignored), and indexed.
+
+Confirm to the user in one line:
+
+> Adopted `<name>` at `<path>`, homed into `<mesh>`.
+
+## Phase 4 — Offer the deferred follow-ups (do NOT run them)
+
+Adopt already rebuilds the content caches on the way in, so search/recall work immediately. Two further steps are **deferred** — OFFER them as future options only; this skill does NOT implement them:
+
+- **Backfill** — a deeper re-index of historical figments beyond the on-adopt index. Offer it as a possible future step; do not run any backfill command.
+- **Remote** — wiring a GitHub remote and first push. Adopt never contacts a remote. Once a remote exists, point the user at `/lyt-sync` for pull/commit/push (gated on the writable verdict).
+
+Frame both as "available later," never as something this adopt performed.
+
+## Rules
+
+- **Additive-only.** Adopt creates `.lyt/` and registers the vault; it NEVER modifies, moves, or deletes the user's `.md` files.
+- **Default mesh is `personal`.** A bare adopt homes the vault into `personal/<leaf>` rather than leaving it orphan. Only override on an explicit `--mesh`.
+- **Backfill + remote are deferred.** Offer them as future steps; never claim this adopt ran them.
+- **Pattern links live under `.lyt/patterns/`** — machine-local, gitignored, Lyt-owned. Adopt rebuilds them per-machine; the user never touches them.
+- **Refuse an already-Lyt-aware directory** — point at `lyt vault join` instead of adopt.
+
+## Companion skills
+
+- `/lyt-sync` — pull/commit/push once the vault has a remote.
+- `/lyt-pod` — see the vault in the pod overview after adopt.
+- `/lyt-primer-context` — prime an agent on the freshly-adopted vault.

package/skills/lyt-capture/SKILL.md

@@ -6,7 +6,7 @@ visibility: public
 lyt-version: 0.2.0
 capabilities: [write]
 runtimes: [claude, codex, agents]
-requires_writable_vault: true
+requires_writable_vault: false
 ---
 
 # /lyt-capture
@@ -27,15 +27,9 @@ When the user runs `/lyt-capture`, or says something like:
 
 If the user pastes content and only says "save it," interpret as `/lyt-capture` on the pasted content.
 
-## When NOT to invoke
+## Scope — the single capture skill
 
-`/lyt-capture` writes a **plain Figment note** — not a work-management artifact. When the durable thing is a structured type, defer to the dedicated skill (each writes the same 8-field ceremony to its own home, with type-specific framing):
-
-- A distilled, durable **project lesson** ("this is an insight", "lesson learned about Lyt") → `/lyt-insight`.
-- A locked **decision** ("lock this decision", "record the decision") → `/lyt-decision`.
-- A **plan / progress / result / retro / handoff** → the matching `/lyt-plan` · `/lyt-progress` · `/lyt-result` · `/lyt-retro` · `/lyt-handoff`.
-
-Use `/lyt-capture` only for a free-form note that doesn't fit one of those work-management types. When in doubt between a plain note and a typed artifact, prefer the typed skill — it carries the right frontmatter and lands in the right folder.
+`/lyt-capture` writes a **Figment note** into the vault under the 8-field frontmatter ceremony. It is the one capture skill: durable notes of every kind — a free-form thought, a distilled project lesson, a locked decision, a plan, a result — all land through `/lyt-capture`. Use the `topic:` field to categorize (e.g. `insight`, `decision`, `planning`, `result`) so the note stays legible and searchable; there are no separate per-type skills.
 
 ## Phase 1 — Resolve the target vault
 

package/skills/lyt-pattern/SKILL.md

@@ -24,13 +24,12 @@ Manage Lyt patterns: install, link/unlink, fork for customization, list availabl
 
 ## When NOT to invoke
 
-For the common write-a-Figment-of-type-X flow, use the dedicated skill:
+For the common write-a-Figment flow, use the dedicated skill:
 
-- `/lyt-plan`, `/lyt-progress`, `/lyt-result`, `/lyt-retro`, `/lyt-insight`, `/lyt-handoff` (work-management)
-- `/lyt-capture`, `/lyt-recall` (knowledge-capture)
-- `/lyt-decision` (decision-log)
+- `/lyt-capture` (knowledge-capture) — save any Figment note (use `topic:` to categorize)
+- `/lyt-recall`, `/lyt-search` — read/search the vault or pod
 
-Use `/lyt-pattern` for pattern management itself OR for verbs that don't yet have a dedicated skill wrapper (e.g., `project-lifecycle/project-init`, `project-lifecycle/checkpoint`, `decision-log/rationale`).
+Use `/lyt-pattern` for pattern management itself OR for verbs that have no dedicated skill wrapper — i.e. verbs from patterns you install yourself (`lyt pattern install --from <dir>`). Lyt bundles only `knowledge-capture` (wrapped by `/lyt-capture` + `/lyt-recall`); opinionated workflow patterns are not shipped. Invoke any installed pattern's verb via `/lyt-pattern run <pattern> <verb>` (e.g. `/lyt-pattern run <your-pattern> <verb>`).
 
 ## The verb surface
 
@@ -47,15 +46,15 @@ lyt pattern run <pattern> <verb> --vault <v> [--project <p>] [--slug <s>] [--var
 
 ## Symlink + fork mechanics
 
-Patterns live at `~/lyt/patterns/<name>/` (per-machine, per-user, like the registry). `pattern link` creates `<vault>/Patterns/<name>` as a junction symlink to the master. Symlinks are gitignored from vault repos — `lyt vault adopt` and `lyt vault join` auto-rebuild them per-machine.
+Patterns live at `~/lyt/patterns/<name>/` (per-machine, per-user, like the registry). `pattern link` creates `<vault>/.lyt/patterns/<name>` as a junction symlink to the master. Symlinks are gitignored from vault repos (via the `.lyt/patterns/` rule) — `lyt vault adopt` and `lyt vault join` auto-rebuild them per-machine.
 
 To customize without touching the master, use `pattern fork`:
 
 ```bash
-lyt pattern fork work-management --as wm-custom
-# edit ~/lyt/patterns/wm-custom/
-lyt pattern unlink work-management --vault <v>
-lyt pattern link wm-custom --vault <v>
+lyt pattern fork knowledge-capture --as kc-custom
+# edit ~/lyt/patterns/kc-custom/
+lyt pattern unlink knowledge-capture --vault <v>
+lyt pattern link kc-custom --vault <v>
 ```
 
 ## Version migration (v1 caveat)
@@ -64,7 +63,7 @@ Newer pattern versions replace the master at `~/lyt/patterns/<name>/`. Files alr
 
 ## Verb-name conflicts
 
-If two installed patterns both declare a `plan` verb, address via explicit qualification: `lyt pattern run work-management plan` (not just `lyt pattern run plan`). Skills wrap by pattern convention: `/lyt-plan` ties to work-management; a second pattern with `plan` would generate as `/lyt-<pattern2-id>-plan`.
+If two installed patterns both declare the same verb (e.g. a `note` verb), address via explicit qualification: `lyt pattern run <pattern-id> note` (not just `lyt pattern run note`). The pattern id is always the disambiguator — the qualified `lyt pattern run <pattern> <verb>` form never guesses.
 
 ## Companion skills
 

package/skills/lyt-update/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: lyt-update
+description: >
+  Keep the installed Lyt current — check whether a newer version is published on the npm alpha channel and, if so, update it. Trigger when the user runs /lyt-update, or says "is my Lyt up to date", "check for lyt updates", "update lyt", "am I on the latest lyt", "upgrade lyt", or similar phrasing. Wraps the `lyt outdated` (read-only check) and `lyt update` (install, confirmation-gated) CLI verbs. Read-only by default; the install step changes the global npm install and always confirms first. Offline / unreachable-registry is reported, never an error. Pairs with /lyt-sync.
+visibility: public
+lyt-version: 0.11.0
+capabilities: [read]
+runtimes: [claude, codex, agents]
+requires_writable_vault: false
+---
+
+# /lyt-update
+
+Keep the installed Lyt current. `lyt outdated` reports whether a newer version is published (read-only); `lyt update` installs it, after confirming — it changes the user's **global** npm install, so it is never silent. An unreachable registry (offline / rate-limited) is reported plainly, never treated as an error.
+
+## When to invoke
+
+When the user runs `/lyt-update`, or says something like:
+
+- "is my Lyt up to date" / "am I on the latest lyt"
+- "check for lyt updates"
+- "update lyt" / "upgrade lyt"
+
+Also invoke **proactively** (offer, don't auto-run) when the handler hits behavior that smells version-related — a verb the docs describe but the CLI doesn't have, or a bug that a newer release may have fixed.
+
+## Phase 1 — Check currency (read-only)
+
+Run the check verb:
+
+```
+lyt outdated --json
+```
+
+Parse the JSON result: `{ installed, latest, stale, offline, fromCache, checkedAt }`.
+
+- `stale: true` → a newer version (`latest`) is available. Exit code is `1` (npm-`outdated` convention).
+- `stale: false`, `offline: false` → up to date. Exit code `0`.
+- `offline: true` → the npm registry could not be reached. **Not an error** — tell the handler the check couldn't run (offline / rate-limited) and stop; do not proceed to update.
+
+The check forces a fresh probe (it does not rely on the throttled doctor/init cache).
+
+## Phase 2 — Offer the update (only when stale)
+
+If `stale` is true, surface the finding and OFFER to update — never update without an explicit go:
+
+> Your Lyt is `<installed>`; `<latest>` is published. Want me to update? (`lyt update` runs `npm i -g @younndai/lyt@alpha`.)
+
+On the handler's yes, run:
+
+```
+lyt update --yes
+```
+
+`lyt update` re-checks currency itself, then installs. Without `--yes` it prompts interactively; with `--yes` it proceeds (still refuses to run when *not* stale). It streams npm's own output and sets a non-zero exit code on failure.
+
+After a successful update, confirm with `lyt --version`.
+
+## Rules
+
+- **MUST NOT run `lyt update` without the handler's explicit go.** It mutates the global install. `lyt outdated` (Phase 1) is always safe to run unprompted.
+- **MUST treat `offline: true` as informational, not a failure.** Report that the check couldn't reach the registry and stop; never retry-loop.
+- **MUST NOT claim an update happened without confirming** — re-read `lyt --version` (or `lyt outdated`) after `lyt update`, per verify-don't-trust.
+- **SHOULD prefer the CLI verbs over a raw `npm i -g`** so the confirmation gate + currency logic stay in one place; only fall back to the raw command if the verbs are unavailable (a very old install).
+
+## Companion skills
+
+- **/lyt-sync** — sync a vault's content. Unrelated to version currency, but the two are the common "keep everything current" pair.
+- **/lyt-primer-context** — prime an agent; a good moment to also check currency on a fresh session.

package/skills/lyt-decision/SKILL.md

@@ -1,52 +0,0 @@
----
-name: lyt-decision
-description: >
-  Record a locked architectural or product decision as a Lyt Figment. Trigger when the user runs /lyt-decision, or says "lock this decision", "record the decision", "decide between options", "this is decided". Wraps `lyt pattern run decision-log decision`. Writes to <vault>/Projects/<project>/work/<date>-decision-<slug>.md.
-visibility: public
-lyt-version: 0.2.0
-capabilities: [write]
-runtimes: [claude, codex, agents]
-requires_writable_vault: true
----
-
-# /lyt-decision
-
-Record a locked decision — the choice, the alternatives, the reasoning. Use when a decision is durable enough that future-you (or a future agent) will need to read it cold.
-
-## When to invoke
-
-- `/lyt-decision` slash trigger
-- "lock this decision"
-- "we decided X — record it"
-- after a structured assessment or review lands a locked verdict
-- before starting work whose direction depends on a non-obvious choice
-
-## Phase 1 — Resolve target
-
-Same chain as `/lyt-plan`. Slug describes the decision (e.g., `transclusion-priming-files`, `gh-prefix-soft`).
-
-## Phase 2 — Run the verb
-
-```
-lyt pattern run decision-log decision --vault <vault> --project <project> --slug <slug>
-```
-
-## Phase 3 — Fill the body
-
-Sections to fill:
-
-- **The decision** — one sentence, imperative voice
-- **Context** — what forced this decision
-- **Alternatives considered** — A / B / C with one-line each
-- **Why this option won** — one paragraph; reference rationale if long-form
-- **Reversibility** — how hard to undo, what downstream work depends on this
-- **Cross-references** — wikilinks to rationale file (if separate), related decisions
-
-## Long-form reasoning
-
-If the reasoning is too long for the decision file, write a separate `<date>-rationale-<slug>.md` via `lyt pattern run decision-log rationale --vault <v> --project <p> --slug <s>` and link from the decision file's `supports-decision:` (in the rationale) and `Cross-references` (in the decision).
-
-## Companion skills
-
-- `/lyt-insight` — for distilled lessons LEARNED from acting on decisions
-- `/lyt-handoff` — handoffs often reference locked decisions

package/skills/lyt-handoff/SKILL.md

@@ -1,52 +0,0 @@
----
-name: lyt-handoff
-description: >
-  Write an inter-session handoff brief — what a fresh agent or human needs to pick up the work. Trigger when the user runs /lyt-handoff, or says "write a handoff", "brief the next session", "hand this off", "what does the next agent need". Wraps `lyt pattern run work-management handoff`. Writes to <vault>/Handoffs/<project>/<date>-<slug>.md.
-visibility: public
-lyt-version: 0.2.0
-capabilities: [write]
-runtimes: [claude, codex, agents]
-requires_writable_vault: true
----
-
-# /lyt-handoff
-
-Write a handoff brief — a self-contained document a fresh agent (or person) can pick up cold to continue work. Distinct from `/lyt-result` (which is about THIS session); a handoff is forward-looking for the NEXT session.
-
-## When to invoke
-
-- `/lyt-handoff` slash trigger
-- "write a handoff brief for the next agent"
-- "I need to leave a brief"
-- end of a multi-session arc when a fresh session needs to pick up
-
-## Phase 1 — Resolve target
-
-Same chain as `/lyt-plan`. Slug describes the work being handed off (e.g., `phase-7-session-3-npm-precheck-readmes`).
-
-## Phase 2 — Run the verb
-
-```
-lyt pattern run work-management handoff --vault <vault> --project <project> --slug <slug>
-```
-
-The verb writes to `<vault>/Handoffs/<project>/<date>-<slug>.md` (not under `work/` — handoffs live at vault root in their own folder per Work-Management convention).
-
-## Phase 3 — Fill the body
-
-A good handoff has:
-
-- **Acceptance sentence** — one paragraph that captures what "done" looks like
-- **State snapshot (@CONTINUATION)** — current branch, last commit, modified files, in-flight artifacts, pushed/unpushed state, test count
-- **Sources (@SOURCES.required + .optional)** — every file the next agent MUST read before drafting any plan
-- **Resume command** — numbered steps the next agent should follow
-- **Sign-off** — canonical retro path; structured @SESSION_REPORT format if applicable
-- **Activation phrase** — the prompt to paste into the fresh session to resume the work
-
-The frontmatter `acceptance` field is load-bearing: the executing agent walks its clauses to verify the work matches the brief.
-
-## Companion skills
-
-- a fresh agent session — consumes the brief written by this skill
-- `/lyt-result` — what the prior session shipped (context for the handoff)
-- `/lyt-retro` — usually written alongside or after the next-session retro

package/skills/lyt-insight/SKILL.md

@@ -1,55 +0,0 @@
----
-name: lyt-insight
-description: >
-  Capture a distilled project-specific learning as a Lyt Figment. Trigger when the user runs /lyt-insight, or says "this is a project insight", "promote this lesson", "make this durable", "extract the lesson". Wraps `lyt pattern run work-management insight`. Writes to <vault>/Projects/<project>/work/<date>-insight-<slug>.md. For project-agnostic lessons use Nuggets instead.
-visibility: public
-lyt-version: 0.2.0
-capabilities: [write]
-runtimes: [claude, codex, agents]
-requires_writable_vault: true
----
-
-# /lyt-insight
-
-Distilled learning specific to THIS project. Promotion target from a `result-` or `retro-` when the lesson earns durable value.
-
-## When to invoke
-
-- `/lyt-insight` slash trigger
-- "this is a project insight"
-- "promote this"
-- "we keep learning this — write it down"
-
-If the lesson is project-AGNOSTIC (applies to any future project), use `/lyt-capture` with a `Nuggets/<subject>/` target instead.
-
-## Phase 1 — Resolve target
-
-Same chain as `/lyt-plan`. If promoting from a result, prefer renaming the existing result file in place: `<date>-result-<slug>.md` → `<date>-insight-<slug>.md`, update `type:` in frontmatter, set `derived_from_session:`. No folder move; no wikilink rot.
-
-If writing a fresh insight that doesn't promote from a specific result, run the verb to create a new file.
-
-## Phase 2 — Run the verb (when creating fresh)
-
-```
-lyt pattern run work-management insight --vault <vault> --project <project> --slug <slug>
-```
-
-## Phase 3 — Fill the body
-
-Sections to fill:
-
-- **The insight** — state the lesson sharply, one paragraph
-- **Why it matters** — where this changes future decisions
-- **Evidence** — sessions, commits, decisions that support it
-- **Edge cases / qualifiers** — when this does NOT apply
-- **Related** — wikilinks to source results, decisions, plans
-
-## Promotion to Nuggets
-
-If after writing the insight you realize the lesson is project-agnostic, ALSO write a `Nuggets/<subject>/<date>-nugget-<slug>.md` at vault root. (Or: rename in place to the Nuggets folder if it's exclusively agnostic.) Two files are fine when the lesson is project-specific in flavor but applies elsewhere too.
-
-## Companion skills
-
-- `/lyt-result` — source of most insight promotions
-- `/lyt-retro` — source of retro-derived insights
-- `/lyt-decision` — for choices that warrant a separate decision artifact

package/skills/lyt-plan/SKILL.md

@@ -1,60 +0,0 @@
----
-name: lyt-plan
-description: >
-  Write a pre-action plan as a Lyt Figment. Trigger when the user runs /lyt-plan, or says "plan this", "write a plan", "design before coding", "let's plan first". Wraps `lyt pattern run work-management plan` under the hood. Writes to <vault>/Projects/<project>/work/<date>-plan-<slug>.md with frontmatter (date, slug, project, owner).
-visibility: public
-lyt-version: 0.2.0
-capabilities: [write]
-runtimes: [claude, codex, agents]
-requires_writable_vault: true
----
-
-# /lyt-plan
-
-Capture a pre-action plan as a structured Work-Management artifact in a Lyt vault. Plans answer: what are you about to do, why, how, and what does success look like.
-
-## When to invoke
-
-When the user runs `/lyt-plan`, or says something like:
-
-- "let's plan this out"
-- "design before coding"
-- "what's the plan"
-- "write a plan for X"
-
-## Phase 1 — Resolve vault + project + slug
-
-1. **Vault resolution:** `--vault <name>` arg → `$LYT_ACTIVE_VAULT` env → cwd-based detection via `lyt vault info --by-path <cwd>` → default `<handle>/main`.
-2. **Project:** `--project <name>` arg → infer from current directory name → ask the user.
-3. **Slug:** ask the user, or generate from the plan's title (lowercase kebab-case, ≤7 words).
-
-## Phase 2 — Run the verb
-
-Invoke the CLI:
-
-```
-lyt pattern run work-management plan --vault <vault> --project <project> --slug <slug>
-```
-
-The CLI fills frontmatter (`date`, `slug`, `project`, `owner`) and writes to the resolved path: `<vault>/Projects/<project>/work/<date>-plan-<slug>.md`.
-
-If the file already exists, the CLI returns `ALREADY-EXISTS` and the path; do not overwrite. Append a `-2` slug or pick a different slug.
-
-## Phase 3 — Fill in the body
-
-After the file is created, edit it to fill in:
-
-- **Goal** — one-paragraph statement of intent
-- **Background** — context, references, prior decisions
-- **Approach** — steps, sequence, who/what does each
-- **Risks + open questions**
-- **Success criteria**
-- **Estimate**
-
-Use Obsidian-flavored markdown. Use `[[wikilinks]]` to cross-reference prior plans, results, or thoughts.
-
-## Companion skills
-
-- `/lyt-progress` — mid-session status update on this plan
-- `/lyt-result` — post-action outcome closing this plan
-- `/lyt-retro` — deliberate retrospective after the plan executes

package/skills/lyt-progress/SKILL.md

@@ -1,48 +0,0 @@
----
-name: lyt-progress
-description: >
-  Write a mid-session progress update as a Lyt Figment. Trigger when the user runs /lyt-progress, or says "write a progress update", "log where we are", "status update", "I'm blocked". Wraps `lyt pattern run work-management progress`. Writes to <vault>/Projects/<project>/work/<date>-progress-<slug>.md.
-visibility: public
-lyt-version: 0.2.0
-capabilities: [write]
-runtimes: [claude, codex, agents]
-requires_writable_vault: true
----
-
-# /lyt-progress
-
-Capture mid-session status — where we are, what's done, what's in flight, blockers, next steps. Superseded by `/lyt-result` at session end.
-
-## When to invoke
-
-- `/lyt-progress` slash trigger
-- "where are we"
-- "log progress" / "checkpoint" / "status update"
-- when a session has been running >2hr OR has hit a blocker
-
-## Phase 1 — Resolve target
-
-Same chain as `/lyt-plan`: `--vault` arg → `$LYT_ACTIVE_VAULT` → cwd detect → `<handle>/main` default. Project + slug similarly resolved.
-
-## Phase 2 — Run the verb
-
-```
-lyt pattern run work-management progress --vault <vault> --project <project> --slug <slug>
-```
-
-## Phase 3 — Fill the body
-
-Sections to fill:
-
-- **Where we are** — one-paragraph state of play
-- **What's done** — bullets
-- **What's in flight** — bullets
-- **Blockers** — bullets
-- **Next steps** — bullets
-
-If this progress closes a plan, set `parent_plan:` frontmatter to the wikilink of the plan.
-
-## Companion skills
-
-- `/lyt-plan` — pre-action design (parent)
-- `/lyt-result` — post-action outcome (closes this progress)

package/skills/lyt-result/SKILL.md

@@ -1,49 +0,0 @@
----
-name: lyt-result
-description: >
-  Write a post-action result as a Lyt Figment — the default catch-all at session end. Trigger when the user runs /lyt-result, or says "write a result", "what shipped", "wrap up the session", "log the outcome". Wraps `lyt pattern run work-management result`. Writes to <vault>/Projects/<project>/work/<date>-result-<slug>.md.
-visibility: public
-lyt-version: 0.2.0
-capabilities: [write]
-runtimes: [claude, codex, agents]
-requires_writable_vault: true
----
-
-# /lyt-result
-
-Capture the post-action outcome — what was delivered, what changed, what didn't get done. The default catch-all artifact at the end of every meaningful session.
-
-## When to invoke
-
-- `/lyt-result` slash trigger
-- session end: "wrap this up", "log the outcome"
-- after a commit / push / deploy
-
-## Phase 1 — Resolve target
-
-Same chain as `/lyt-plan`. Slug usually matches the parent plan's slug (set `parent_plan` frontmatter wikilink).
-
-## Phase 2 — Run the verb
-
-```
-lyt pattern run work-management result --vault <vault> --project <project> --slug <slug>
-```
-
-## Phase 3 — Fill the body
-
-Sections to fill:
-
-- **Outcome** — what got delivered. Reference commits if applicable (set `commits:` frontmatter array).
-- **What changed** — files, behaviors, decisions
-- **What didn't get done** — deferred / blocked / cut
-- **Cross-references** — plan link, commits, follow-ups
-
-## Promotion
-
-If the result teaches something durable about THIS project, **rename in place** to `<date>-insight-<slug>.md` and update `type: insight` in frontmatter — no folder move, no link rot. If the lesson is project-agnostic, write a `Nuggets/<subject>/<date>-nugget-<slug>.md` instead.
-
-## Companion skills
-
-- `/lyt-plan` — pre-action design (parent of this result)
-- `/lyt-insight` — promoted result with durable project lesson
-- `/lyt-retro` — deliberate retrospective after a meaningful arc

package/skills/lyt-retro/SKILL.md

@@ -1,54 +0,0 @@
----
-name: lyt-retro
-description: >
-  Write a deliberate retrospective on a session, sprint, or completed plan. Trigger when the user runs /lyt-retro, or says "retro this", "what did we learn", "lessons from this sprint", "post-mortem". Wraps `lyt pattern run work-management retro`. Writes to <vault>/Projects/<project>/work/<date>-retro-<slug>.md.
-visibility: public
-lyt-version: 0.2.0
-capabilities: [write]
-runtimes: [claude, codex, agents]
-requires_writable_vault: true
----
-
-# /lyt-retro
-
-Capture a deliberate retrospective. What worked. What didn't. What we'd change next time. Distinct from `/lyt-result` (which records WHAT shipped); a retro records WHY it went the way it did.
-
-## When to invoke
-
-- `/lyt-retro` slash trigger
-- "let's retro this"
-- end of a sprint, arc, project, or contentious decision
-- after a meaningful handoff (often required by the handoff-execute protocol)
-
-## Phase 1 — Resolve target
-
-Same chain as `/lyt-plan`. Slug usually matches the artifact being retro'd (e.g., `phase-7-session-2-bulk-init-patterns-skills-retro`).
-
-If retro'ing a specific session/sprint/handoff, set `retro-of:` frontmatter to its wikilink.
-
-## Phase 2 — Run the verb
-
-```
-lyt pattern run work-management retro --vault <vault> --project <project> --slug <slug>
-```
-
-## Phase 3 — Fill the body
-
-Sections to fill:
-
-- **What worked** — bullets, specific
-- **What didn't** — bullets, specific (no euphemisms)
-- **What we'd change next time** — bullets, actionable
-- **Lessons (durable enough to keep)** — if any rise to insight-level, promote
-
-## Promotion
-
-A retro's durable lessons promote either to:
-
-- `<date>-insight-<slug>.md` in the same `work/` folder (project-specific)
-- `Nuggets/<subject>/<date>-nugget-<slug>.md` at vault root (project-agnostic)
-
-## Companion skills
-
-- `/lyt-result` — what shipped (this retro reflects on)
-- `/lyt-insight` — durable lessons promoted from this retro