@elevasis/sdk 1.36.5 → 1.38.0

package/reference/claude-config/skills/save/SKILL.md

@@ -1,183 +1,183 @@
----
-name: save
-description: Auto-manage project documentation and persist task resume context from conversation
----
-
-# Save
-
-Auto-manage project documentation from conversation context, and fan out conversation signals to the canonical project system (`prj_tasks.resume_context`, `prj_notes`) via the `elevasis-sdk` CLI.
-
-## Canonical Sources of Truth
-
-- **Task resume context (DB):** `prj_tasks.resume_context` is canonical. Agents write it via `elevasis-sdk project:task:save`. Humans edit it via the inline task editor in Command Center. **Never** stash resume context into task-doc frontmatter.
-- **Task-doc frontmatter:** ONLY `title`, `description`, `status`. No `resume_context`, no files-modified, no next-steps arrays -- those belong in the DB.
-- **Project notes (DB):** `prj_notes` via `elevasis-sdk project:note:create`. Typed notes (`status_update` / `issue` / `blocker` / `call_note`) are the durable record of conversation signals.
-
-## Process
-
-### Step 1: Resolve Project + Task Context
-
-Before doing anything else, determine the active project / task:
-
-1. Look for an active task-doc frontmatter in the current conversation or the most recently edited file. Expected frontmatter:
-
-   ```yaml
-   ---
-   title: Short title
-   description: One-line summary
-   status: planned | in-progress | blocked | complete
-   ---
-   ```
-
-2. If the task doc references a project/task UUID anywhere in its body (link, callout, or prior save output), capture those IDs.
-3. If no task / project context is resolvable, PROMPT the user:
-   - "Which project is this work under?" (accepts slug or UUID)
-   - "Is there an existing task I should attach this to? (task UUID, or 'new')"
-
-   Do not guess. Without a task ID, skip Step 4 (DB resume-context save) but still perform Steps 2, 3, 5, 6, 7.
-
-### Step 2: Analyze Conversation
-
-Review the current conversation to identify:
-
-1. **New knowledge** -- architecture decisions, feature implementations, bug fixes, discoveries
-2. **Changed state** -- what was in-progress that is now complete, what new work started
-3. **Stale docs** -- information in existing docs that is now outdated
-4. **Signal events** -- blocker hit, status update worth recording, issue uncovered, call outcome
-5. **OS contract paths touched** -- scan files read/written/edited for any of these signals:
-   - `core/config/organization-model.ts` -> Foundations layer, Organization Model
-   - `core/types/index.ts` -> Foundations layer, Workflow Contracts
-   - `ui/src/routes/__root.tsx` -> UI Shell Runtime composition
-   - `ui/src/features/**/manifest.ts` or any file defining a `SystemModule` -> Systems layer
-   - `operations/src/index.ts` or `operations/elevasis.config.ts` -> core/Deployment (DeploymentSpec)
-   - Any file inside `ui/src/features/<feature>/` combined with manifest, nav, or sidebar changes -> Features + Toolkit layers
-
-   Record which OS layers were touched: `foundations`, `systems`, `shell-runtime`, `toolkit`, `deployment`. If none matched, OS awareness stays dormant for the rest of this run.
-
-### Step 3: Update Knowledge Docs
-
-Scan for unindexed or stale knowledge docs and draft creates / updates / moves. This template does not have a `docs/` tree — look for any local knowledge files (`.claude/rules/`, `operations/src/README.md`, `core/`, or project-specific docs the user has created). All edits are on knowledge/architecture/feature docs -- NOT on task resume state (that flows to the DB in Step 4).
-
-Determine what needs to happen:
-
-- **Create** new docs for significant new knowledge (new features, architecture decisions)
-- **Update** existing docs with corrections, completions, or new details
-- **Move** docs between directories (e.g., `ui/` to `operations/` when ownership shifts)
-- **Delete** docs that are fully obsolete (rare -- prefer updating)
-
-**Frontmatter requirement (all docs in `docs/`):**
-
-```markdown
----
-title: Short descriptive title
-description: One-line summary of what this doc covers
----
-```
-
-In-progress task docs additionally require `status`:
-
-```markdown
----
-title: Feature Name
-description: What this task is about
-status: planned | in-progress | blocked | complete
----
-```
-
-No other fields. Do NOT add `resume_context`, `files_modified`, or `next_steps` to frontmatter -- those flow to the DB via Step 4.
-
-**Doc structure rules:**
-
-- All docs are `.md` (not .mdx)
-- Keep docs focused -- one topic per file
-- Use markdown tables for structured data
-- Include "Last Updated: YYYY-MM-DD" at the bottom of modified docs
-
-**OS layer annotation:** If OS contract paths were touched (Step 2), include an `## Organization OS Impact` section in any newly created architecture doc:
-
-```markdown
-## Organization OS Impact
-
-Touched contracts: [list files]
-Affected layers: [list of layers]
-Cross-reference: `node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md`
-Downstream: template consumer adapters may need review.
-```
-
-Dispatch a `general-purpose` subagent with the plan, conversation context, and these rules. The subagent must read each target file before editing.
-
-### Step 4: Persist Task Resume Context to DB
-
-If Step 1 resolved a task ID, save the current state to `prj_tasks.resume_context` via the SDK CLI. This is the canonical persistence step and must run every `/save` invocation that has a task in scope:
-
-```bash
-pnpm elevasis-sdk project:task:save <task-uuid> \
-  --current-state "<concise prose summary of where we are>" \
-  --next-steps "<concise prose of the next concrete action>" \
-  --files-modified '["path/one.ts","path/two.tsx"]' \
-  --key-docs '["operations/src/foo/index.ts","core/config/organization-model.ts"]' \
-  --tools '["project:task:save","project:note:create"]'
-```
-
-Arg rules:
-
-- `--current-state` (required) -- terse, present-tense "what is true right now". Prefer latest state over accumulated history.
-- `--next-steps` -- single next concrete action another agent could execute without re-deriving intent.
-- `--files-modified` -- JSON array of uncommitted / just-changed file paths (relative to project root).
-- `--key-docs` -- JSON array of doc paths an agent should re-read to resume.
-- `--tools` -- JSON array of tool / CLI names used this session that are worth flagging.
-
-The endpoint is `PATCH /api/external/tasks/<id>/resume-context` and merges (does not replace) provided fields. Omit any arg that has nothing meaningful to record.
-
-### Step 5: Create Typed Project Notes on Signal Events
-
-For each signal event identified in Step 2, create a typed `prj_note`. One CLI call per note:
-
-```bash
-pnpm elevasis-sdk project:note:create \
-  --project <project-uuid> \
-  --task <task-uuid>          # optional, omit if not scoped to a task \
-  --type <note-type> \
-  --content "<what happened, why it matters, any next action>"
-```
-
-Note-type mapping (use the first type that matches, in this order):
-
-- **`blocker`** -- work cannot proceed without external action (decision, credential, fix elsewhere, upstream change). Always create if detected. Trigger phrases: "I'm stuck", "blocked on", "can't proceed until", "waiting on <X>". When detected AND a task ID is in scope, ALSO fire a status transition -- see Step 5a below.
-- **`issue`** -- bug, regression, unexpected failure, contract mismatch. Include reproduction context in `--content`.
-- **`status_update`** -- milestone-level progress worth flagging to the human operator (phase complete, substantial deliverable landed, direction change). Keep it substantive -- `/save` runs shouldn't emit a status_update every turn.
-- **`call_note`** -- only if the conversation is transcribing a live client / stakeholder call.
-
-If no signal rises to note-worthy, skip this step entirely. Do not create filler notes.
-
-### Step 5a: Blocker Signal -> Task Status Transition
-
-Run this ONLY when Step 5 created a `blocker` note AND Step 1 resolved a task ID. It's the second half of the "I'm stuck" fanout: the note captures the why, this call flips the task's lifecycle state so it surfaces as blocked in portfolio views.
-
-```bash
-pnpm elevasis-sdk project:task:update <task-uuid> --status blocked
-```
-
-Rules:
-
-- **Explicit task ID only** -- use the UUID resolved in Step 1. Do not re-derive or guess. If no task is in scope, skip this step (the blocker note still ships without it).
-- **Best-effort** -- if the CLI returns non-2xx, surface a single warning line in Step 7 ("Warning: could not transition task <id> to blocked: <reason>") and continue. Do not retry, do not block the rest of `/save`.
-- **Idempotent** -- if the task is already `blocked`, the update is a no-op. Fire it anyway; do not pre-check.
-- **Order** -- the `blocker` note (Step 5) creates first; this transition follows. Keeps the note attached to the task even if the status update later fails.
-
-### Step 6: Report
-
-Summarize:
-
-- Knowledge docs created / updated / moved / deleted
-- Task ID written to (Step 4): `resume_context.last_saved` timestamp from the CLI response
-- Notes created (Step 5): count, types, IDs
-- OS classification (if applicable): layers detected, contracts touched
-- Any files skipped due to missing frontmatter (Step 3 subagent should have added it)
-- Any follow-ups for the human operator
-
-## Failure Modes
-
-- **No task in scope + user declines to provide one:** proceed with Steps 2, 3, 6, 7; skip Step 4; still allow Step 5 if a `--project` UUID is available.
-- **`project:task:save` returns non-2xx:** surface the error in the report, do not retry silently; Step 5 and Step 6 still run.
-- **Knowledge doc edits fail to write:** surface the error; any edits already applied are on disk and not lost.
+---
+name: save
+description: Auto-manage project documentation and persist task resume context from conversation
+---
+
+# Save
+
+Auto-manage project documentation from conversation context, and fan out conversation signals to the canonical project system (`prj_tasks.resume_context`, `prj_notes`) via the `elevasis-sdk` CLI.
+
+## Canonical Sources of Truth
+
+- **Task resume context (DB):** `prj_tasks.resume_context` is canonical. Agents write it via `elevasis-sdk project:task:save`. Humans edit it via the inline task editor in Command Center. **Never** stash resume context into task-doc frontmatter.
+- **Task-doc frontmatter:** ONLY `title`, `description`, `status`. No `resume_context`, no files-modified, no next-steps arrays -- those belong in the DB.
+- **Project notes (DB):** `prj_notes` via `elevasis-sdk project:note:create`. Typed notes (`status_update` / `issue` / `blocker` / `call_note`) are the durable record of conversation signals.
+
+## Process
+
+### Step 1: Resolve Project + Task Context
+
+Before doing anything else, determine the active project / task:
+
+1. Look for an active task-doc frontmatter in the current conversation or the most recently edited file. Expected frontmatter:
+
+   ```yaml
+   ---
+   title: Short title
+   description: One-line summary
+   status: planned | in-progress | blocked | complete
+   ---
+   ```
+
+2. If the task doc references a project/task UUID anywhere in its body (link, callout, or prior save output), capture those IDs.
+3. If no task / project context is resolvable, PROMPT the user:
+   - "Which project is this work under?" (accepts slug or UUID)
+   - "Is there an existing task I should attach this to? (task UUID, or 'new')"
+
+   Do not guess. Without a task ID, skip Step 4 (DB resume-context save) but still perform Steps 2, 3, 5, 6, 7.
+
+### Step 2: Analyze Conversation
+
+Review the current conversation to identify:
+
+1. **New knowledge** -- architecture decisions, feature implementations, bug fixes, discoveries
+2. **Changed state** -- what was in-progress that is now complete, what new work started
+3. **Stale docs** -- information in existing docs that is now outdated
+4. **Signal events** -- blocker hit, status update worth recording, issue uncovered, call outcome
+5. **OS contract paths touched** -- scan files read/written/edited for any of these signals:
+   - `core/config/organization-model.ts` -> Foundations layer, Organization Model
+   - `core/types/index.ts` -> Foundations layer, Workflow Contracts
+   - `ui/src/routes/__root.tsx` -> UI Shell Runtime composition
+   - `ui/src/features/**/manifest.ts` or any file defining a `SystemModule` -> Systems layer
+   - `operations/src/index.ts` or `operations/elevasis.config.ts` -> core/Deployment (DeploymentSpec)
+   - Any file inside `ui/src/features/<feature>/` combined with manifest, nav, or sidebar changes -> Features + Toolkit layers
+
+   Record which OS layers were touched: `foundations`, `systems`, `shell-runtime`, `toolkit`, `deployment`. If none matched, OS awareness stays dormant for the rest of this run.
+
+### Step 3: Update Knowledge Docs
+
+Scan for unindexed or stale knowledge docs and draft creates / updates / moves. This template does not have a `docs/` tree — look for any local knowledge files (`.claude/rules/`, `operations/src/README.md`, `core/`, or project-specific docs the user has created). All edits are on knowledge/architecture/feature docs -- NOT on task resume state (that flows to the DB in Step 4).
+
+Determine what needs to happen:
+
+- **Create** new docs for significant new knowledge (new features, architecture decisions) -- place them wherever this project actually keeps such notes (a README next to the relevant code, or a project-created notes location); this template has no `docs/` tree, so do not create or assume one
+- **Update** existing docs with corrections, completions, or new details
+- **Move** docs between directories (e.g., `ui/` to `operations/` when ownership shifts)
+- **Delete** docs that are fully obsolete (rare -- prefer updating)
+
+**Frontmatter requirement (any doc this step creates or updates):**
+
+```markdown
+---
+title: Short descriptive title
+description: One-line summary of what this doc covers
+---
+```
+
+In-progress task docs additionally require `status`:
+
+```markdown
+---
+title: Feature Name
+description: What this task is about
+status: planned | in-progress | blocked | complete
+---
+```
+
+No other fields. Do NOT add `resume_context`, `files_modified`, or `next_steps` to frontmatter -- those flow to the DB via Step 4.
+
+**Doc structure rules:**
+
+- All docs are `.md` (not `.mdx` -- this template has no Fumadocs/MDX pipeline)
+- Keep docs focused -- one topic per file
+- Use markdown tables for structured data
+- Include "Last Updated: YYYY-MM-DD" at the bottom of modified docs
+
+**OS layer annotation:** If OS contract paths were touched (Step 2), include an `## Organization OS Impact` section in any newly created architecture doc:
+
+```markdown
+## Organization OS Impact
+
+Touched contracts: [list files]
+Affected layers: [list of layers]
+Cross-reference: `operations/node_modules/@elevasis/sdk/reference/scaffold/reference/glossary.md`
+Downstream: template consumer adapters may need review.
+```
+
+Dispatch a `general-purpose` subagent with the plan, conversation context, and these rules. The subagent must read each target file before editing.
+
+### Step 4: Persist Task Resume Context to DB
+
+If Step 1 resolved a task ID, save the current state to `prj_tasks.resume_context` via the SDK CLI. This is the canonical persistence step and must run every `/save` invocation that has a task in scope:
+
+```bash
+pnpm elevasis-sdk project:task:save <task-uuid> \
+  --current-state "<concise prose summary of where we are>" \
+  --next-steps "<concise prose of the next concrete action>" \
+  --files-modified '["path/one.ts","path/two.tsx"]' \
+  --key-docs '["operations/src/foo/index.ts","core/config/organization-model.ts"]' \
+  --tools '["project:task:save","project:note:create"]'
+```
+
+Arg rules:
+
+- `--current-state` (required) -- terse, present-tense "what is true right now". Prefer latest state over accumulated history.
+- `--next-steps` -- single next concrete action another agent could execute without re-deriving intent.
+- `--files-modified` -- JSON array of uncommitted / just-changed file paths (relative to project root).
+- `--key-docs` -- JSON array of doc paths an agent should re-read to resume.
+- `--tools` -- JSON array of tool / CLI names used this session that are worth flagging.
+
+The endpoint is `PATCH /api/external/tasks/<id>/resume-context` and merges (does not replace) provided fields. Omit any arg that has nothing meaningful to record.
+
+### Step 5: Create Typed Project Notes on Signal Events
+
+For each signal event identified in Step 2, create a typed `prj_note`. One CLI call per note:
+
+```bash
+pnpm elevasis-sdk project:note:create \
+  --project <project-uuid> \
+  --task <task-uuid>          # optional, omit if not scoped to a task \
+  --type <note-type> \
+  --content "<what happened, why it matters, any next action>"
+```
+
+Note-type mapping (use the first type that matches, in this order):
+
+- **`blocker`** -- work cannot proceed without external action (decision, credential, fix elsewhere, upstream change). Always create if detected. Trigger phrases: "I'm stuck", "blocked on", "can't proceed until", "waiting on <X>". When detected AND a task ID is in scope, ALSO fire a status transition -- see Step 5a below.
+- **`issue`** -- bug, regression, unexpected failure, contract mismatch. Include reproduction context in `--content`.
+- **`status_update`** -- milestone-level progress worth flagging to the human operator (phase complete, substantial deliverable landed, direction change). Keep it substantive -- `/save` runs shouldn't emit a status_update every turn.
+- **`call_note`** -- only if the conversation is transcribing a live client / stakeholder call.
+
+If no signal rises to note-worthy, skip this step entirely. Do not create filler notes.
+
+### Step 5a: Blocker Signal -> Task Status Transition
+
+Run this ONLY when Step 5 created a `blocker` note AND Step 1 resolved a task ID. It's the second half of the "I'm stuck" fanout: the note captures the why, this call flips the task's lifecycle state so it surfaces as blocked in portfolio views.
+
+```bash
+pnpm elevasis-sdk project:task:update <task-uuid> --status blocked
+```
+
+Rules:
+
+- **Explicit task ID only** -- use the UUID resolved in Step 1. Do not re-derive or guess. If no task is in scope, skip this step (the blocker note still ships without it).
+- **Best-effort** -- if the CLI returns non-2xx, surface a single warning line in Step 7 ("Warning: could not transition task <id> to blocked: <reason>") and continue. Do not retry, do not block the rest of `/save`.
+- **Idempotent** -- if the task is already `blocked`, the update is a no-op. Fire it anyway; do not pre-check.
+- **Order** -- the `blocker` note (Step 5) creates first; this transition follows. Keeps the note attached to the task even if the status update later fails.
+
+### Step 6: Report
+
+Summarize:
+
+- Knowledge docs created / updated / moved / deleted
+- Task ID written to (Step 4): `resume_context.last_saved` timestamp from the CLI response
+- Notes created (Step 5): count, types, IDs
+- OS classification (if applicable): layers detected, contracts touched
+- Any files skipped due to missing frontmatter (Step 3 subagent should have added it)
+- Any follow-ups for the human operator
+
+## Failure Modes
+
+- **No task in scope + user declines to provide one:** proceed with Steps 2, 3, 6, 7; skip Step 4; still allow Step 5 if a `--project` UUID is available.
+- **`project:task:save` returns non-2xx:** surface the error in the report, do not retry silently; Step 5 and Step 6 still run.
+- **Knowledge doc edits fail to write:** surface the error; any edits already applied are on disk and not lost.

package/reference/claude-config/skills/setup/SKILL.md

@@ -17,7 +17,7 @@ First-time project setup for projects cloned directly from the template. Handles
 Before collecting any information or running any steps, determine which state the project is in. Read these files:
 
 - `package.json` — look for `__PROJECT_SLUG__` in the `name` field
-- `CLAUDE.md` — look for `TEMPLATE_PROJECT_NAME` AND check whether `{CLIENT_CONTEXT}` and `{USER_PREFERENCES}` are still literal placeholder strings
+- `CLAUDE.md` — look for `__PROJECT_NAME__` (the title) and `__PROJECT_DESCRIPTION__` (the Project section) AND check whether `{CLIENT_CONTEXT}` and `{USER_PREFERENCES}` are still literal placeholder strings
 - `ui/package.json` — look for `__PROJECT_SLUG__`
 - `ui/index.html` — look for `__PROJECT_NAME__`
 
@@ -106,9 +106,15 @@ Look good?
 
 Search ALL files in the project matching these extensions: `.ts`, `.tsx`, `.js`, `.mjs`, `.json`, `.md`, `.mdx`, `.html`, `.yaml`, `.yml`, `.css`, `.env.example`
 
-Exclude these directories and files: `node_modules/`, `dist/`, `.tanstack/`, `pnpm-lock.yaml`
+**HARD EXCLUSION -- `.claude/` is off-limits (read this before scanning any file list):**
 
-For each matching file, replace all occurrences of:
+Do NOT scan, read-for-replacement, or edit ANY file under `.claude/` -- this includes `.claude/skills/**` (including this very `setup/SKILL.md` file), `.claude/rules/**`, `.claude/agents/**`, `.claude/hooks/**`, `.claude/registries/**`, `.claude/sync-notes/**`, `.claude/logs/**`, `.claude/Overview.md`, and `.claude/settings.json`. These are agent scaffold, not template content -- they describe the agent's own tooling and must never have their placeholder text (e.g. `__PROJECT_NAME__`, `__DATE__`, tenant names used as worked examples) substituted. Substituting them corrupts the scaffold and breaks every future re-run of `/setup` and other skills that reference this file.
+
+The allowlist of directories to scan is exactly: project root files (`package.json`, `CLAUDE.md`, `.env.example`), `ui/**`, `operations/**`, `core/**`. Also exclude `node_modules/`, `dist/`, `.tanstack/`, `pnpm-lock.yaml`, and `.git/` within those trees.
+
+If you are about to open or write any file whose path starts with `.claude/`, stop -- that file is out of scope for this step, with zero exceptions.
+
+For each matching file (from the allowlist above, outside `.claude/`), replace all occurrences of:
 
 | Placeholder                    | Replace with            |
 | ------------------------------ | ----------------------- |

package/reference/claude-config/skills/status/SKILL.md

@@ -1,59 +1,59 @@
----
-name: status
-description: Quick project health check
----
-
-# Status
-
-Quick project health check.
-
-**Usage:** `/status`
-
-## Process
-
-### Step 1: Gather Data
-
-Run in parallel:
-
-1. `git status` - working tree state
-2. `git log --oneline -5` - recent commits
-3. `pnpm test` - test results
-4. `pnpm lint` - type check
-
-### Step 2: Check Active Work
-
-1. Query active project work via `pnpm elevasis-sdk project:list --status active --pretty` and `pnpm elevasis-sdk project:list --status blocked --pretty` - active project/task count lives in the DB
-
-### Step 3: Report
-
-```
-Project Status
-==============
-
-Git
----
-Branch: <branch>
-Clean: Yes/No (N uncommitted changes)
-Last commit: <hash> - <message> (<date>)
-
-Tests
------
-Result: All passing / N failures
-Details: [if failures, list them]
-
-Types
------
-Result: Clean / N errors
-Details: [if errors, list them]
-
-Docs
-----
-Architecture: N docs
-Features: N docs
-
-Active Work (DB)
-----------------
-Projects: N active, N blocked
-  - [client 1] (status)
-  - [client 2] (status)
-```
+---
+name: status
+description: Quick project health check
+---
+
+# Status
+
+Quick project health check.
+
+**Usage:** `/status`
+
+## Process
+
+### Step 1: Gather Data
+
+Run in parallel:
+
+1. `git status` - working tree state
+2. `git log --oneline -5` - recent commits
+3. `pnpm test` - test results (root `test` script runs `ui`, `operations`, and `core` checks/tests)
+4. `pnpm -C ui lint` - type check (root has no `lint` script; `lint` only exists in `ui/package.json`)
+
+### Step 2: Check Active Work
+
+1. Query active project work via `pnpm elevasis-sdk project:list --status active --pretty` and `pnpm elevasis-sdk project:list --status blocked --pretty` - active project/task count lives in the DB
+
+### Step 3: Report
+
+```
+Project Status
+==============
+
+Git
+---
+Branch: <branch>
+Clean: Yes/No (N uncommitted changes)
+Last commit: <hash> - <message> (<date>)
+
+Tests
+-----
+Result: All passing / N failures
+Details: [if failures, list them]
+
+Types
+-----
+Result: Clean / N errors
+Details: [if errors, list them]
+
+Docs
+----
+Architecture: N docs
+Features: N docs
+
+Active Work (DB)
+----------------
+Projects: N active, N blocked
+  - [client 1] (status)
+  - [client 2] (status)
+```

package/reference/claude-config/skills/sync/SKILL.md

@@ -1,47 +1,47 @@
----
-name: sync
-description: Fresh reinstall and cache reset after local dependency or cache drift
----
-
-# Sync
-
-Fresh reinstall and cache reset for local dependency or cache drift.
-
-**Usage:** `/sync`
-
-Use this when: packages feel stale, Vite cache is serving old code, or `pnpm install` didn't fully clean up after a package version bump.
-
-For pulling template updates, surfacing new `.claude/sync-notes/` guidance, and running the baseline post-pull verification flow, use `/git-sync` instead.
-
-## Process
-
-### Step 1: Wipe
-
-Remove all `node_modules` and build caches across the workspace in parallel:
-
-```bash
-rm -rf node_modules
-rm -rf ui/node_modules
-rm -rf ui/node_modules/.vite
-rm -rf operations/node_modules
-rm -rf shared/node_modules
-```
-
-### Step 2: Reinstall
-
-```bash
-pnpm install
-```
-
-Report success or any errors.
-
-### Step 3: Report
-
-```text
-Sync Complete
-=============
-Wiped:   node_modules (root, ui, operations, shared) + Vite cache
-Install: success
-```
-
-If `pnpm install` fails, report the error and stop - do not attempt to start the dev server.
+---
+name: sync
+description: Fresh reinstall and cache reset after local dependency or cache drift
+---
+
+# Sync
+
+Fresh reinstall and cache reset for local dependency or cache drift.
+
+**Usage:** `/sync`
+
+Use this when: packages feel stale, Vite cache is serving old code, or `pnpm install` didn't fully clean up after a package version bump.
+
+For pulling template updates, surfacing new `.claude/sync-notes/` guidance, and running the baseline post-pull verification flow, use `/git-sync` instead.
+
+## Process
+
+### Step 1: Wipe
+
+Remove all `node_modules` and build caches across the workspace in parallel:
+
+```bash
+rm -rf node_modules
+rm -rf ui/node_modules
+rm -rf ui/node_modules/.vite
+rm -rf operations/node_modules
+rm -rf core/node_modules
+```
+
+### Step 2: Reinstall
+
+```bash
+pnpm install
+```
+
+Report success or any errors.
+
+### Step 3: Report
+
+```text
+Sync Complete
+=============
+Wiped:   node_modules (root, ui, operations, core) + Vite cache
+Install: success
+```
+
+If `pnpm install` fails, report the error and stop - do not attempt to start the dev server.

package/reference/claude-config/skills/tutorial/SKILL.md

@@ -35,7 +35,7 @@ Track separation is explicit:
   business profile, saved progress, automations, dashboard, and reports. Do not name the technical
   pattern in vibe-coder menus, lessons, prompts, or progress labels.
 - The technical track may name OM spine vocabulary and can point developers at
-  `node_modules/@elevasis/sdk/reference/spine/spine-primer.md` when lessons discuss shared stage,
+  `operations/node_modules/@elevasis/sdk/reference/spine/spine-primer.md` when lessons discuss shared stage,
   status, or catalog vocabularies.
 
 ---