@elevasis/sdk 1.44.3 → 1.45.0

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

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

@@ -1,259 +0,0 @@
----
-name: tutorial
-description: |
-  Persona-aware onboarding tutorial that forks into a vibe-coder track (zero technical
-  vocabulary, agent does all the work) or a technical track (full SDK depth, code-first).
-  On first invocation, asks one gate question to determine the user's track and persists the
-  choice to .claude/memory/profile.md. Subsequent invocations skip the question and display
-  the track menu with current progress markers. Supports /tutorial switch (flip track) and
-  /tutorial status (display-only).
-argument-hint: "[switch | status]"
-context: fork
-allowed-tools: Read, Write, Edit, Bash, Glob, Grep
----
-
-# Tutorial
-
-Persona-aware onboarding. Forks at first invocation into a **vibe-coder track** (non-technical,
-agent handles everything silently) or a **technical track** (developer-focused, full SDK depth).
-
-**Usage:** `/tutorial` | `/tutorial switch` | `/tutorial status`
-
----
-
-## Architecture Note
-
-`profile.md` is read at session start alongside `.claude/rules/agent-start-here.md`. The rules
-layer uses the track choice to adjust tone, vocabulary, and tool-call visibility project-wide.
-This router does not enforce that tone -- it only writes profile.md and loads the right track
-file. The project-wide tone effect is handled by the rules layer reading profile.md on each
-session start.
-
-Track separation is explicit:
-
-- The vibe-coder track teaches the underlying coordination idea through business language only:
-  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
-  `operations/node_modules/@elevasis/sdk/reference/spine/spine-primer.md` when lessons discuss shared stage,
-  status, or catalog vocabularies.
-
----
-
-## Step 1: Parse the Argument
-
-Check whether the invocation included an argument:
-
-- `/tutorial switch` -- go to [Switch Track](#switch-track)
-- `/tutorial status` -- go to [Status Display](#status-display) (no prompt afterward)
-- `/tutorial` (no argument) -- continue to Step 2
-
----
-
-## Step 2: Check for Existing Profile
-
-Read `.claude/memory/profile.md`.
-
-- **File does not exist (first invocation):** go to [First Invocation](#first-invocation)
-- **File exists:** go to [Returning Invocation](#returning-invocation)
-
----
-
-## First Invocation
-
-### Ask the Gate Question
-
-Print verbatim:
-
-> "Are you here to **build automations by describing what you want** (and I handle the technical
-> side), or are you a **developer** who'll edit code directly?"
-
-Wait for the user's answer. Accept natural-language replies -- map to one of two tracks:
-
-| User says (examples)                                             | Track        |
-| ---------------------------------------------------------------- | ------------ |
-| "describe what I want", "non-technical", "you handle it", "vibe" | `vibe-coder` |
-| "developer", "edit code", "technical", "build myself", "code"    | `technical`  |
-
-If the answer is ambiguous, ask once: "Just to confirm -- do you want me to handle the technical
-side, or will you be editing code directly?"
-
-### Persist the Profile
-
-Write `.claude/memory/profile.md` using the template below. Select the tone-implications block
-that matches the chosen track.
-
-**For vibe-coder track:**
-
-```markdown
-# Project Profile
-
-**Track:** vibe-coder
-**Selected at:** YYYY-MM-DD
-**Switch tracks:** Run `/tutorial switch` to change.
-
-## Tone Implications
-
-In this project, always:
-- Say "automation" instead of workflow / agent / resource
-- Say "the information your automation needs" instead of schema / Zod / type
-- Say "make it live" or "publish" instead of deploy
-- Say "your business profile" instead of organization model / config
-- Say "account connection" instead of credential
-- Say "your dashboard" or "your map" instead of Operations / Command Center / Command View
-- Say "your approval queue" instead of HITL / approval gate
-- Never mention repo / monorepo / git
-- Never mention TypeScript / pnpm / CLI
-- Say "the tool the automation uses" instead of adapter / platform tool
-- Say "updating your profile together" instead of /om ceremony
-- Run slash commands silently on the user's behalf -- never expose command names or code
-```
-
-**For technical track:**
-
-```markdown
-# Project Profile
-
-**Track:** technical
-**Selected at:** YYYY-MM-DD
-**Switch tracks:** Run `/tutorial switch` to change.
-
-## Tone Implications
-
-Code-first communication. Use current command names, SDK terminology, and OM spine vocabulary
-without hand-holding. No vocabulary substitutions. Slash commands may be surfaced directly. Full
-technical depth.
-```
-
-### Initialize Progress File
-
-Read `.claude/memory/tutorial-progress.md`.
-
-- If the file does not exist, read `.claude/skills/tutorial/progress-template.md` and write its
-  contents verbatim to `.claude/memory/tutorial-progress.md`. If `progress-template.md` is also
-  missing (sibling agent has not yet created it), write a minimal stub:
-
-```markdown
-# Tutorial Progress
-
-**Vibe-coder track**
-
-- [ ] 1 Welcome
-- [ ] 2 How to talk to me
-- [ ] 3 Your business profile
-- [ ] 4 Your first automation
-- [ ] 5 Your dashboard
-- [ ] 6 Your approval queue
-- [ ] 7 Changing things later
-- [ ] 8 When things go wrong
-
-**Technical track**
-
-- [ ] 1 What is this workspace
-- [ ] 2 The skill layer
-- [ ] 3 The vibe layer
-- [ ] 4 Echo workflow tour
-- [ ] 5 Custom workflow with schemas
-- [ ] 6 Platform tools and credentials
-- [ ] 7 Multi-step and conditionals
-- [ ] 8 Going to production
-- [ ] 9 /om ceremony
-- [ ] 10 Features and labels
-- [ ] 11 Entity extensions
-- [ ] 12 HITL
-- [ ] 13 Schedules
-- [ ] 14 Notifications + integrations
-- [ ] 15 Error handling
-- [ ] 16 LLM and agents
-- [ ] 17 Composition
-- [ ] 18 Rules, memory, scaffold registry, OM spine
-- [ ] 19 Template lifecycle and /git-sync
-```
-
-- If the file already exists, leave it unchanged.
-
-### Load Track and Show Menu
-
-Read the matching track file:
-
-- `vibe-coder` track: `.claude/skills/tutorial/vibe-coder.md`
-- `technical` track: `.claude/skills/tutorial/technical.md`
-
-Read `.claude/memory/tutorial-progress.md` and apply progress markers to the menu (see
-[Progress Markers](#progress-markers)). Display the menu. Prompt: "Pick a number to start."
-
----
-
-## Returning Invocation
-
-Read `.claude/memory/profile.md` and extract the **Track** field.
-
-Read `.claude/memory/tutorial-progress.md`.
-
-Load the matching track file:
-
-- `vibe-coder` track: `.claude/skills/tutorial/vibe-coder.md`
-- `technical` track: `.claude/skills/tutorial/technical.md`
-
-Apply progress markers to the menu (see [Progress Markers](#progress-markers)). Display the
-menu. Prompt: "Pick a number to continue, or type a number to jump to any lesson."
-
-Wait for the user to pick a number, then follow that lesson's instructions from the track file.
-
----
-
-## Progress Markers
-
-When rendering any menu, annotate each item using the markers from `tutorial-progress.md`:
-
-| Marker in progress file | Menu display |
-| ----------------------- | ------------ |
-| `[ ]`                   | `[ ]`        |
-| `[>]`                   | `[>]`        |
-| `[x] YYYY-MM-DD`        | `[x]`        |
-
-Read the progress file, match items by lesson number and track section, and substitute the
-marker inline. Items with no matching entry display `[ ]`.
-
----
-
-## Switch Track
-
-Print:
-
-> "You're currently on the **{current-track}** track. Switching will show you the
-> **{other-track}** menu. Your progress for each track is saved separately and will not be lost.
-> Switch?"
-
-Wait for confirmation. On yes:
-
-1. Read `.claude/memory/profile.md`.
-2. Update the **Track** field to the other track name.
-3. Update the **Selected at** date to today.
-4. Replace the Tone Implications block with the block for the new track (see [First Invocation](#first-invocation) for both blocks).
-5. Write the updated profile.md.
-6. Load the new track file and display the menu with current progress markers.
-7. Prompt: "Pick a number to start, or press Enter to begin at lesson 1."
-
-On no: print "No change made." and stop.
-
-Do not modify `tutorial-progress.md` -- it tracks per-track progress independently.
-
----
-
-## Status Display
-
-Same as [Returning Invocation](#returning-invocation) but do not show a number-prompt afterward.
-If no profile exists yet, print:
-
-> "No track selected yet. Run `/tutorial` to get started."
-
----
-
-## Error States
-
-- **Track file missing** (`vibe-coder.md` or `technical.md` not found): print "Track content
-  file is not yet available. It may still be generating -- try again in a moment." Do not
-  attempt to generate the content; it belongs to the sibling track files.
-- **progress-template.md missing**: write the minimal stub documented in [First Invocation](#first-invocation). Do not fail.
-- **profile.md malformed**: treat as missing and run the gate question again.

package/reference/claude-config/skills/tutorial/progress-template.md

@@ -1,74 +0,0 @@
-# Tutorial Progress
-
-This file lives at `.claude/memory/tutorial-progress.md` once `/tutorial` runs for the first time.
-It tracks per-track progress separately so users can switch tracks without losing state.
-
-**Started:** {YYYY-MM-DD}
-**Last session:** {YYYY-MM-DD}
-
----
-
-## Vibe-Coder Track
-
-```
-Your Tutorial
-==============
-1  Welcome -- what this place does for you             [ ]
-2  How to talk to me                                   [ ]
-3  Your business profile                               [ ]
-4  Your first automation                               [ ]
-5  Your dashboard -- where everything lives            [ ]
-6  Your approval queue -- signing off on things        [ ]
-7  Changing things later                               [ ]
-8  When things go wrong                                [ ]
-```
-
----
-
-## Technical Track
-
-```
-SECTION A -- The workspace                              (3 items)
-  1  What is this workspace                              [ ]
-  2  The skill layer -- slash commands you'll use        [ ]
-  3  The vibe layer -- ambient intent classification     [ ]
-
-SECTION B -- Build your first thing                     (5 items)
-  4  Echo workflow tour                                  [ ]
-  5  Custom workflow with schemas                        [ ]
-  6  Platform tools and credentials                      [ ]
-  7  Multi-step and conditionals                         [ ]
-  8  Going to production                                 [ ]
-
-SECTION C -- The Organization Model                     (3 items)
-  9  /om ceremony -- identity, customers,         [ ]
-     offerings via the layered flow
- 10  Features and labels                                 [ ]
- 11  Entity extensions -- BaseProject, BaseDeal          [ ]
-
-SECTION D -- Modules (load on demand)                   (6 items)
- 12  HITL                                                [ ]
- 13  Schedules                                           [ ]
- 14  Notifications + integrations                        [ ]
- 15  Error handling                                      [ ]
- 16  LLM and agents                                      [ ]
- 17  Composition (execution.trigger)                     [ ]
-
-SECTION E -- Power user                                 (2 items)
- 18  Rules, memory, scaffold registry                    [ ]
- 19  Template lifecycle and /git-sync                    [ ]
-```
-
----
-
-## Completed Lessons
-
-| Track      | Item | Title | Completed | Duration |
-| ---------- | ---- | ----- | --------- | -------- |
-| _none yet_ |      |       |           |          |
-
----
-
-## Capability Observations
-
-(The teaching agent jots brief notes here, e.g. "user navigated Command Center confidently" or "user wanted code shown in lesson 4 -- flagged as candidate for /tutorial switch")