@elevasis/sdk 1.44.3 → 1.45.0

package/reference/claude-config/skills/run-ui/SKILL.md

@@ -1,73 +0,0 @@
----
-name: run-ui
-description: Start the project's Vite UI dev server on port 4300 in the background, surfacing the URL once it's ready. Detects port conflicts and asks before killing the holder.
----
-
-# Run UI
-
-Start `ui/` dev server (`pnpm -C ui dev`) in the background on port 4300 and surface the URL when Vite reports ready.
-
-**Usage:** `/run-ui`
-
-The Vite config in `ui/vite.config.ts` pins port 4300 with `strictPort: true`, so a conflict is a hard fail — the skill resolves the conflict before launching.
-
-## Process
-
-### Step 1: Probe port 4300
-
-Run via PowerShell tool (Windows-native, cleanest):
-
-```powershell
-$conn = Get-NetTCPConnection -LocalPort 4300 -State Listen -ErrorAction SilentlyContinue | Select-Object -First 1
-if ($conn) {
-  $proc = Get-Process -Id $conn.OwningProcess -ErrorAction SilentlyContinue
-  $cmd = (Get-CimInstance Win32_Process -Filter "ProcessId = $($conn.OwningProcess)" -ErrorAction SilentlyContinue).CommandLine
-  "PID=$($conn.OwningProcess) NAME=$($proc.ProcessName) CMD=$cmd"
-} else {
-  "FREE"
-}
-```
-
-### Step 2: Branch on probe result
-
-- **`FREE`** → go to Step 3.
-- **Holder is our Vite** (CMD contains `vite` or `node` running from this project's `ui/`) → port is already serving the app. Skip launch and surface `http://localhost:4300/` directly. Done.
-- **Holder is something else** → ask the user:
-
-  > "Port 4300 is held by `<NAME>` (PID `<PID>`). Kill it and start the dev server? (y/n)"
-
-  On `n`, abort with no further action. On `y`, run `Stop-Process -Id <PID> -Force` then continue to Step 3.
-
-### Step 3: Launch dev server in background
-
-Use Bash tool with `run_in_background: true`:
-
-```bash
-pnpm -C ui dev
-```
-
-Capture the returned shell ID.
-
-### Step 4: Wait for ready signal
-
-Poll the background shell output (read every ~2s) for Vite's ready line — typically:
-
-```
-  ➜  Local:   http://localhost:4300/
-```
-
-or `ready in <N>ms`.
-
-Stop polling on the first match. Hard cap: ~15 seconds (≈7 reads). If no ready signal arrives, surface the last 20 lines of background output so the user can debug, and leave the background process running.
-
-### Step 5: Report
-
-On success:
-
-```
-UI dev server running
-  Local:  http://localhost:4300/
-  Shell:  <bg-shell-id>
-```
-
-On timeout, prepend a one-line note ("Vite did not report ready within 15s — last output:") before the captured tail.

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

@@ -1,183 +0,0 @@
----
-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

@@ -1,290 +0,0 @@
----
-name: setup
-description: First-time project setup — detect and replace template placeholders, install dependencies, verify build, then hand off to /om for org-model configuration
-argument-hint: ""
----
-
-# Setup
-
-First-time project setup for projects cloned directly from the template. Handles placeholder replacement, dependency install, and build verification. After bootstrap, delegates org-model configuration to `/om`.
-
-**Usage:** `/setup`
-
----
-
-## State Detection (Run Before Anything Else)
-
-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 `__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__`
-
-**State A — Virgin (placeholders present):** One or more of the above placeholder strings is found. Run the full bootstrap flow (Steps 1–7 below), then hand off to `/om`.
-
-**State B — Already bootstrapped, org-model at defaults:** No placeholders found, but `core/config/organization-model.ts` contains only the default display naming override (just `identity.organizationName`, `identity.productName`, `identity.shortName`, with legacy `branding.*` fallback values — no customers, offerings, roles, goals, or techStack overrides). Print:
-
-```
-This project is already set up. The organization model has not been configured yet.
-Running /om to set up your organization profile...
-```
-
-Then execute `/om` (the full layered flow) and stop.
-
-**State C — Fully configured:** No placeholders found AND `core/config/organization-model.ts` has at least one non-default business domain populated (customers, offerings, roles, goals, techStack, or identity fields beyond display naming/client brief). Print:
-
-```
-This project is already configured. To update your organization profile, run /om.
-To re-verify the build, run the checks below.
-```
-
-Offer to run the verification checks (Steps 6b–6e) if the user wants them. Do not re-ask any questions. Do not re-run placeholder replacement. Stop after verification.
-
----
-
-## Full Bootstrap Flow (State A Only)
-
-### Step 1: Collect Project Info
-
-Ask the user for three values:
-
-1. **Slug** — lowercase, hyphens only (e.g., `acme-dashboard`). Default to the basename of the current working directory.
-2. **Human-readable name** — used in titles, docs, and CLAUDE.md (e.g., `Acme Dashboard`).
-3. **Short description** — one sentence, used in `package.json` and CLAUDE.md (e.g., `Client dashboard for Acme Corp.`).
-
-Confirm the values before proceeding:
-
-```
-Configuring project with:
-  Slug:        <slug>
-  Name:        <name>
-  Description: <description>
-  Date:        <YYYY-MM-DD>
-
-Proceed? (yes/no)
-```
-
-### Step 2: Get to Know the User and Client
-
-Transition naturally after confirming the project values: "Now let me learn a bit about you and the client so I can be more helpful going forward."
-
-**About the user (ask conversationally, one at a time):**
-
-1. **Name** -- "What's your first name?"
-2. **Role** -- "What's your role?" (e.g., founder, developer, project lead)
-3. **Technical level** -- "How comfortable are you with technical stuff? No wrong answer -- just helps me know how to explain things."
-4. **Communication style** -- "When I explain things or write docs, do you prefer short and to-the-point, or more detailed with context?"
-
-Use their name naturally from this point on.
-
-**About the client/company this project is for:**
-
-5. **Company name** -- "Who's this project for? What's the company name?"
-6. **What they do** -- "What does {company} do? Just a sentence or two."
-7. **Industry** -- "What industry or space are they in?"
-8. **Key context** -- "Anything else that would help me understand the project context? Key stakeholders, business goals, important constraints -- whatever comes to mind. (Totally fine to skip, we can add this as we go.)"
-
-React to what they share, ask natural follow-ups if something is interesting or unclear. Don't make it feel like a form.
-
-After gathering, confirm:
-
-```
-Got it! Here's what I captured:
-
-User: {name} ({role}, {technical level}, prefers {style})
-
-Client: {company}
-  {what they do}
-  Industry: {industry}
-  {any additional context}
-
-Look good?
-```
-
-### Step 3: Replace Placeholders
-
-Search ALL files in the project matching these extensions: `.ts`, `.tsx`, `.js`, `.mjs`, `.json`, `.md`, `.mdx`, `.html`, `.yaml`, `.yml`, `.css`, `.env.example`
-
-**HARD EXCLUSION -- `.claude/` is off-limits (read this before scanning any file list):**
-
-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            |
-| ------------------------------ | ----------------------- |
-| `__PROJECT_NAME__`             | human-readable name     |
-| `__PROJECT_SLUG__`             | slug                    |
-| `__PROJECT_DESCRIPTION__`      | description             |
-| `__DATE__`                     | today's date YYYY-MM-DD |
-| `TEMPLATE_PROJECT_NAME`        | human-readable name     |
-| `TEMPLATE_PROJECT_DESCRIPTION` | description             |
-
-Use the Read tool to read each file, then the Edit tool (with `replace_all: true`) or Write tool to apply the replacements. Read each file before writing.
-
-After all replacements, re-scan the four key files from State Detection to verify zero placeholders remain. If any are still present, report them by file and fix immediately.
-
-### Step 4: Populate CLAUDE.md Knowledge Sections
-
-**Idempotency check (MANDATORY before writing):** Read `CLAUDE.md` and check whether `{CLIENT_CONTEXT}` and `{USER_PREFERENCES}` are still literal placeholder strings. Only write if they are still placeholders. If either section is already filled in (user or a previous run already populated it), skip that section entirely — do not overwrite.
-
-**`{CLIENT_CONTEXT}`** -- replace with a single line (only if still a placeholder):
-
-```markdown
-**{company name}** — {what they do, one sentence}
-```
-
-**`{USER_PREFERENCES}`** -- replace with a table (only if still a placeholder):
-
-```markdown
-| Name   | Role   | Technical Level | Communication |
-| ------ | ------ | --------------- | ------------- |
-| {name} | {role} | {level}         | {preference}  |
-```
-
-If the user skipped any knowledge questions, fill in what was provided and omit what wasn't -- don't leave placeholder text behind.
-
-### Step 5: Write Client Brief to Org Model
-
-**Idempotency check:** Read `core/config/organization-model.ts` and inspect `identity.clientBrief`. If the field is already a non-empty string, skip this step entirely — do not overwrite.
-
-If the field is empty or absent, compose the client brief from the information gathered in Step 2:
-
-```markdown
-**Company:** {company name}
-**Industry:** {industry}
-**Description:** {what they do}
-
-## Additional Context
-
-{any additional context shared — key stakeholders, business goals, constraints, etc. If nothing was shared, write "No additional context provided yet. Update this as the project evolves."}
-```
-
-Propose the composed content to the user before writing (read → propose → confirm → write — the same ceremony `/om` uses):
-
-```
-Here's the client brief I'll write into identity.clientBrief:
-
----
-{composed content}
----
-
-Write this? (yes/no)
-```
-
-On confirmation, use the Edit tool to replace the `clientBrief: ''` value in `core/config/organization-model.ts` with a template literal containing the composed markdown. Use a regular string (backtick or single-quoted multi-line) — ensure the closing quote and trailing comma are correct TypeScript.
-
-After the edit, run:
-
-```bash
-pnpm -C core test
-```
-
-If type-check fails, report the error and do not proceed to Step 6 until it is resolved.
-
-### Step 6: Install and Verify
-
-#### Step 6a: Install Dependencies
-
-```bash
-pnpm install
-```
-
-This generates the project's own `pnpm-lock.yaml`. Report success or any errors.
-
-#### Step 6b–6e: Verify Build
-
-Run all checks sequentially (stop and report on first failure, but attempt all):
-
-```bash
-pnpm -C ui check-types
-pnpm -C ui build
-pnpm -C operations check
-pnpm -C operations check-types
-```
-
-For each check, record PASS or FAIL. If a check fails, read the output and report the error clearly. Do not silently skip failures.
-
-### Step 7: Bootstrap Report
-
-```
-You're all set, {name}!
-========================
-Project: <Human Name>
-Slug:    <slug>
-Client:  <company name> (<industry>)
-
-Verification:
-  [PASS/FAIL] Type-check (ui)
-  [PASS/FAIL] Production build (ui)
-  [PASS/FAIL] Resource validation (operations)
-  [PASS/FAIL] Type-check (operations)
-```
-
-If any verification step failed, add an Errors section listing each failure with its output.
-
-### Step 8: Hand Off to /om
-
-After a successful bootstrap, transition to the org-model configuration flow. Print:
-
-```
-Bootstrap complete. Now let's set up your organization profile.
-```
-
-Then execute `/om` (the full layered flow, no argument). This is where identity, customers, offerings, roles, goals, and techStack are configured. Do not attempt to collect or write org-model data here — that ceremony belongs entirely to /om.
-
-If the user wants to skip org-model setup for now, they can stop here and run `/om` later.
-
----
-
-## Error Recovery
-
-If placeholder replacement leaves stragglers:
-
-```
-Placeholder Cleanup Required
-=============================
-Remaining: <list files and placeholders>
-Action: Re-applying replacements to affected files...
-```
-
-Fix each remaining occurrence before proceeding to Step 6a.
-
----
-
-## Idempotency Guarantees
-
-Running `/setup` more than once is safe:
-
-- **Placeholder replacement** only runs when placeholders are detected (State A). It is skipped entirely in States B and C.
-- **CLAUDE.md knowledge sections** (`{CLIENT_CONTEXT}`, `{USER_PREFERENCES}`) are checked before writing. If already replaced, the write is skipped.
-- **`identity.clientBrief`** is only written when the field is empty. A non-empty field is never overwritten by `/setup`. The write uses a read → propose → confirm ceremony before touching the file.
-- **All other org-model fields** (`core/config/organization-model.ts`) are never written by `/setup`. All other org-model edits go through `/om`, which has its own diff-preview and confirm ceremony.
-
----
-
-## Relationship to /om
-
-`/setup` is a thin bootstrap wrapper. It:
-
-1. Replaces scaffold placeholders (project name, slug, description)
-2. Fills lightweight CLAUDE.md knowledge sections (user and client basics, idempotent)
-3. Writes the client brief into `identity.clientBrief` in the org model (confirm-before-write, idempotent)
-4. Installs dependencies and verifies the build
-5. Hands off to `/om` for full org-model configuration
-
-`/om` owns all other structural org-model editing (identity fields beyond clientBrief, customers, offerings, roles, goals, techStack, systems, actions, labels, and legacy feature compatibility). It is idempotent, confirm-before-overwrite, and includes a runtime validation gate. Re-run `/om` any time organizational reality changes — no need to re-run `/setup`.
-
----
-
-## Capability Surface
-
-When a user asks what skills or commands are available, do NOT answer from recollection.
-
-- **Skill inventory:** Read `.claude/Overview.md` — it is the authoritative list of skills available in this project.
-- **Live CLI capability:** Run `pnpm elevasis-sdk cli` — it outputs every command and domain currently registered in the SDK, grouped by domain.

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

@@ -1,59 +0,0 @@
----
-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)
-```