@elevasis/sdk 1.21.0 → 1.22.1

package/reference/claude-config/skills/submit-request/SKILL.md

@@ -1,180 +1,180 @@
----
-name: submit-request
-description: Submit a structured request report to the Elevasis platform via CLI — enforces pre-analysis before posting
----
-
-# Submit Request
-
-Submit a structured request report to the Elevasis platform. The agent performs a six-phase analysis before posting so that every submitted request includes meaningful context, not just a one-liner.
-
-**Usage:** `/submit-request [optional description]`
-
-If a description is provided, it is the primary signal for Phase 1. Otherwise the agent analyzes recent conversation context plus any active error context.
-
-## Env Requirements
-
-`ELEVASIS_PLATFORM_KEY` must be present in the project's root `.env` (the same key used by all other `elevasis-sdk` commands — no additional setup needed if deploy is already working).
-
-The organization and API base URL are resolved automatically by the CLI. No `ELEVASIS_API_KEY` or `ELEVASIS_API_URL` needed.
-
-## Pre-Analysis Phases
-
-Complete all six phases before assembling the report or asking for confirmation. Do not skip phases — they ensure the submitted record is actionable.
-
-### Phase 1: Collect Context
-
-Gather available context:
-
-- If the user provided a description with the command, treat it as the primary signal.
-- Otherwise review the last ~20 conversation messages for error output, failed commands, unexpected behavior, and any `explain_page` / active error context.
-- Ask one targeted follow-up question if a key detail is ambiguous. Do not fire multiple questions at once.
-
-### Phase 2: Identify Source
-
-Pinpoint where the request originates:
-
-- File paths (if a code or config file is involved)
-- Workflow or agent resource IDs (if a platform execution failed)
-- Execution IDs (if available in logs or prior output)
-- Route or page path (if a UI issue)
-
-Record these for the `evidence` and `affected_page` fields.
-
-### Phase 3: Gather Errors
-
-Extract concrete error signals (if applicable):
-
-- Full error messages and stack traces (truncated to the relevant portion)
-- HTTP status codes and response bodies
-- Log lines with timestamps if available
-- Screenshots or screenshot file references if the user provided them
-
-These go into the `evidence` object. For feature requests or questions, this phase may produce an empty `evidence` object — that is expected.
-
-### Phase 4: Select Type and Classify Severity and Category
-
-Select exactly one value for **type first**, then **severity**, then **category**:
-
-**Type:**
-
-| Value      | When to use                                        |
-| ---------- | -------------------------------------------------- |
-| `bug`      | Something is broken or behaving incorrectly        |
-| `feature`  | A new capability or enhancement request            |
-| `question` | Asking for clarification, guidance, or explanation |
-| `other`    | Doesn't fit the above                              |
-
-**Severity:**
-
-| Value      | When to use                                                         |
-| ---------- | ------------------------------------------------------------------- |
-| `critical` | Data loss, security breach, complete feature outage, blocked deploy |
-| `warning`  | Degraded behavior, partial failure, noticeable but recoverable      |
-| `info`     | Minor UX glitch, cosmetic bug, improvement suggestion               |
-
-**Category:**
-
-| Value                 | When to use                                            |
-| --------------------- | ------------------------------------------------------ |
-| `ui_bug`              | Frontend rendering or interaction problem              |
-| `data_inconsistency`  | DB records, API responses, or UI state don't match     |
-| `performance`         | Slow load, timeout, high resource usage                |
-| `error_pattern`       | Recurring or systematic error across executions        |
-| `configuration`       | Misconfigured resource, credential, env var, or policy |
-| `feature_request`     | New feature or enhancement being requested             |
-| `api_design`          | Feedback on API contract, naming, or behavior          |
-| `documentation`       | Missing, incorrect, or unclear documentation           |
-| `integration_request` | Request for a new integration or adapter               |
-| `other`               | Doesn't fit above                                      |
-
-### Phase 5: Build Structured Report
-
-Assemble the report body from phases 1–4:
-
-```json
-{
-  "title": "One-line summary — specific, not vague",
-  "description": "What happened. What was expected. Steps to reproduce if applicable.",
-  "type": "<bug|feature|question|other>",
-  "severity": "<critical|warning|info>",
-  "category": "<category value>",
-  "affected_page": "<route or page path, omit if not a UI issue>",
-  "evidence": {
-    "errors": ["<error message or stack trace excerpt>"],
-    "log_snippets": ["<relevant log lines>"],
-    "screenshot_refs": ["<file path if user provided a screenshot>"]
-  },
-  "context": {
-    "source_files": ["<file paths>"],
-    "resource_ids": ["<workflow or agent IDs>"],
-    "execution_ids": ["<execution IDs>"],
-    "summary": "<one-paragraph agent analysis summary>"
-  }
-}
-```
-
-Omit any field that has nothing meaningful to record. `project_id` and `task_id` are optional UUID fields — include them only if the request is clearly scoped to a specific project or task visible in context.
-
-Do NOT include `source` or `organization_id` — the server sets both automatically.
-
-### Phase 6: Confirm with User
-
-Unless the command was invoked with `--auto`, present the assembled report to the user before submitting:
-
-```
-Request Report (ready to submit)
-================================
-Title:    <title>
-Type:     <type>
-Severity: <severity>
-Category: <category>
-Page:     <affected_page or "—">
-
-Description:
-  <description>
-
-Evidence:
-  <summarized evidence>
-
-Context:
-  <summarized context>
-
-Submit? (yes / edit / cancel)
-```
-
-If the user says "edit", accept corrections and re-display the updated report before proceeding.
-If the user says "cancel", abort and confirm: "Submission cancelled."
-Auto-submit (`--auto`) skips this confirmation entirely — use only when the caller is a trusted agent pipeline.
-
-## Submit
-
-Once confirmed (or `--auto`), write the assembled JSON body to a temp file under the project-root `tmp/` directory, then submit via the SDK CLI:
-
-```bash
-# Write the report body to tmp/request-report.json from the project root
-# The template keeps tmp/ gitignored for transient CLI payloads
-
-pnpm elevasis-sdk request:submit -f tmp/request-report.json --cleanup-input --pretty
-```
-
-`--cleanup-input` removes the temp file automatically after a successful submission. If the command fails, leave the file in `tmp/` for inspection.
-
-## Report Back
-
-On success, the CLI prints the request ID. Surface it to the user:
-
-```
-Submitted — id: <uuid>
-Track it in Command Center > Requests.
-```
-
-## Troubleshooting
-
-| Error                           | Cause                                                             | Fix                                                                                                           |
-| ------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
-| `ELEVASIS_PLATFORM_KEY` missing | Key not set in root `.env`                                        | Add `ELEVASIS_PLATFORM_KEY=sk_...` to `.env`. Provision from Command Center > Settings > API Keys.            |
-| `401 Unauthorized`              | Key is malformed or revoked                                       | Verify the key starts with `sk_` and is 67 chars. Re-provision if needed.                                     |
-| `403 Forbidden`                 | Key's org lacks access to request reporting                       | Contact the platform operator to verify the key's org permissions.                                            |
-| `Invalid request body`          | Report failed CLI-side Zod validation before the request was sent | Read the field errors printed by the CLI. Common causes: missing `title`/`description`/`type`, invalid enum.  |
-| `400 Bad Request`               | Body passed CLI validation but failed server-side validation      | Read the response body for the specific field error.                                                          |
-| Connection refused              | API server unreachable                                            | Default target is `https://api.elevasis.io` — check network. For local dev, set `ELEVASIS_API_URL` in `.env`. |
+---
+name: submit-request
+description: Submit a structured request report to the Elevasis platform via CLI — enforces pre-analysis before posting
+---
+
+# Submit Request
+
+Submit a structured request report to the Elevasis platform. The agent performs a six-phase analysis before posting so that every submitted request includes meaningful context, not just a one-liner.
+
+**Usage:** `/submit-request [optional description]`
+
+If a description is provided, it is the primary signal for Phase 1. Otherwise the agent analyzes recent conversation context plus any active error context.
+
+## Env Requirements
+
+`ELEVASIS_PLATFORM_KEY` must be present in the project's root `.env` (the same key used by all other `elevasis-sdk` commands — no additional setup needed if deploy is already working).
+
+The organization and API base URL are resolved automatically by the CLI. No `ELEVASIS_API_KEY` or `ELEVASIS_API_URL` needed.
+
+## Pre-Analysis Phases
+
+Complete all six phases before assembling the report or asking for confirmation. Do not skip phases — they ensure the submitted record is actionable.
+
+### Phase 1: Collect Context
+
+Gather available context:
+
+- If the user provided a description with the command, treat it as the primary signal.
+- Otherwise review the last ~20 conversation messages for error output, failed commands, unexpected behavior, and any `explain_page` / active error context.
+- Ask one targeted follow-up question if a key detail is ambiguous. Do not fire multiple questions at once.
+
+### Phase 2: Identify Source
+
+Pinpoint where the request originates:
+
+- File paths (if a code or config file is involved)
+- Workflow or agent resource IDs (if a platform execution failed)
+- Execution IDs (if available in logs or prior output)
+- Route or page path (if a UI issue)
+
+Record these for the `evidence` and `affected_page` fields.
+
+### Phase 3: Gather Errors
+
+Extract concrete error signals (if applicable):
+
+- Full error messages and stack traces (truncated to the relevant portion)
+- HTTP status codes and response bodies
+- Log lines with timestamps if available
+- Screenshots or screenshot file references if the user provided them
+
+These go into the `evidence` object. For feature requests or questions, this phase may produce an empty `evidence` object — that is expected.
+
+### Phase 4: Select Type and Classify Severity and Category
+
+Select exactly one value for **type first**, then **severity**, then **category**:
+
+**Type:**
+
+| Value      | When to use                                        |
+| ---------- | -------------------------------------------------- |
+| `bug`      | Something is broken or behaving incorrectly        |
+| `feature`  | A new capability or enhancement request            |
+| `question` | Asking for clarification, guidance, or explanation |
+| `other`    | Doesn't fit the above                              |
+
+**Severity:**
+
+| Value      | When to use                                                         |
+| ---------- | ------------------------------------------------------------------- |
+| `critical` | Data loss, security breach, complete feature outage, blocked deploy |
+| `warning`  | Degraded behavior, partial failure, noticeable but recoverable      |
+| `info`     | Minor UX glitch, cosmetic bug, improvement suggestion               |
+
+**Category:**
+
+| Value                 | When to use                                            |
+| --------------------- | ------------------------------------------------------ |
+| `ui_bug`              | Frontend rendering or interaction problem              |
+| `data_inconsistency`  | DB records, API responses, or UI state don't match     |
+| `performance`         | Slow load, timeout, high resource usage                |
+| `error_pattern`       | Recurring or systematic error across executions        |
+| `configuration`       | Misconfigured resource, credential, env var, or policy |
+| `feature_request`     | New feature or enhancement being requested             |
+| `api_design`          | Feedback on API contract, naming, or behavior          |
+| `documentation`       | Missing, incorrect, or unclear documentation           |
+| `integration_request` | Request for a new integration or adapter               |
+| `other`               | Doesn't fit above                                      |
+
+### Phase 5: Build Structured Report
+
+Assemble the report body from phases 1–4:
+
+```json
+{
+  "title": "One-line summary — specific, not vague",
+  "description": "What happened. What was expected. Steps to reproduce if applicable.",
+  "type": "<bug|feature|question|other>",
+  "severity": "<critical|warning|info>",
+  "category": "<category value>",
+  "affected_page": "<route or page path, omit if not a UI issue>",
+  "evidence": {
+    "errors": ["<error message or stack trace excerpt>"],
+    "log_snippets": ["<relevant log lines>"],
+    "screenshot_refs": ["<file path if user provided a screenshot>"]
+  },
+  "context": {
+    "source_files": ["<file paths>"],
+    "resource_ids": ["<workflow or agent IDs>"],
+    "execution_ids": ["<execution IDs>"],
+    "summary": "<one-paragraph agent analysis summary>"
+  }
+}
+```
+
+Omit any field that has nothing meaningful to record. `project_id` and `task_id` are optional UUID fields — include them only if the request is clearly scoped to a specific project or task visible in context.
+
+Do NOT include `source` or `organization_id` — the server sets both automatically.
+
+### Phase 6: Confirm with User
+
+Unless the command was invoked with `--auto`, present the assembled report to the user before submitting:
+
+```
+Request Report (ready to submit)
+================================
+Title:    <title>
+Type:     <type>
+Severity: <severity>
+Category: <category>
+Page:     <affected_page or "—">
+
+Description:
+  <description>
+
+Evidence:
+  <summarized evidence>
+
+Context:
+  <summarized context>
+
+Submit? (yes / edit / cancel)
+```
+
+If the user says "edit", accept corrections and re-display the updated report before proceeding.
+If the user says "cancel", abort and confirm: "Submission cancelled."
+Auto-submit (`--auto`) skips this confirmation entirely — use only when the caller is a trusted agent pipeline.
+
+## Submit
+
+Once confirmed (or `--auto`), write the assembled JSON body to a temp file under the project-root `tmp/` directory, then submit via the SDK CLI:
+
+```bash
+# Write the report body to tmp/request-report.json from the project root
+# The template keeps tmp/ gitignored for transient CLI payloads
+
+pnpm elevasis-sdk request:submit -f tmp/request-report.json --cleanup-input --pretty
+```
+
+`--cleanup-input` removes the temp file automatically after a successful submission. If the command fails, leave the file in `tmp/` for inspection.
+
+## Report Back
+
+On success, the CLI prints the request ID. Surface it to the user:
+
+```
+Submitted — id: <uuid>
+Track it in Command Center > Requests.
+```
+
+## Troubleshooting
+
+| Error                           | Cause                                                             | Fix                                                                                                           |
+| ------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
+| `ELEVASIS_PLATFORM_KEY` missing | Key not set in root `.env`                                        | Add `ELEVASIS_PLATFORM_KEY=sk_...` to `.env`. Provision from Command Center > Settings > API Keys.            |
+| `401 Unauthorized`              | Key is malformed or revoked                                       | Verify the key starts with `sk_` and is 67 chars. Re-provision if needed.                                     |
+| `403 Forbidden`                 | Key's org lacks access to request reporting                       | Contact the platform operator to verify the key's org permissions.                                            |
+| `Invalid request body`          | Report failed CLI-side Zod validation before the request was sent | Read the field errors printed by the CLI. Common causes: missing `title`/`description`/`type`, invalid enum.  |
+| `400 Bad Request`               | Body passed CLI validation but failed server-side validation      | Read the response body for the specific field error.                                                          |
+| Connection refused              | API server unreachable                                            | Default target is `https://api.elevasis.io` — check network. For local dev, set `ELEVASIS_API_URL` in `.env`. |

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 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.