@elevasis/sdk 1.21.0 → 1.22.1

package/reference/claude-config/skills/deploy/{SKILL.md → skill.md}

@@ -1,156 +1,156 @@
----
-name: deploy
-description: Test, build, fix issues, then commit and push
----
-
-# Deploy
-
-Test, build, fix issues, then commit and push.
-
-**Usage:** `/deploy [--skip] [--minor | --major] [commit message]`
-
-## Flags
-
-- `--skip` -- Skip tests, type checking, and build (Steps 2-4). Go straight from pre-flight to commit and push.
-- `--minor` -- Bump the minor version instead of patch (e.g. 1.0.0 -> 1.1.0).
-- `--major` -- Bump the major version instead of patch (e.g. 1.0.0 -> 2.0.0).
-
-## Process
-
-### Step 1: Pre-flight Check
-
-Run in parallel:
-
-```bash
-git status
-git diff --stat
-```
-
-If there are no changes, report "Nothing to deploy" and stop.
-
-### Step 1b: Version Bump
-
-Read the current version from `package.json`, then bump it:
-
-- Default: bump **patch** (e.g. 1.0.0 -> 1.0.1)
-- `--minor`: bump **minor** (e.g. 1.0.0 -> 1.1.0)
-- `--major`: bump **major** (e.g. 1.0.0 -> 2.0.0)
-
-Use the Edit tool to update the `"version"` field in `package.json` directly. Do not use `npm version` or any CLI command.
-
-### Step 2: Run Tests
-
-```bash
-pnpm test
-```
-
-If tests fail:
-
-1. Read the failing test output
-2. Attempt to fix the issue
-3. Re-run tests
-4. If still failing after 2 attempts, stop and report the failures
-
-### Step 3: Type Check
-
-```bash
-pnpm lint
-```
-
-If type errors exist:
-
-1. Read the errors
-2. Attempt to fix
-3. Re-run
-4. If still failing after 2 attempts, stop and report
-
-### Step 4: Build
-
-```bash
-pnpm build
-```
-
-If build fails:
-
-1. Read the error output
-2. Attempt to fix
-3. Re-run
-4. If still failing after 2 attempts, stop and report
-
-### Step 5: Commit
-
-1. Stage all changed files: `git add -A`
-2. Create commit with the provided message (or auto-generate from changes)
-3. Format: conventional commits (feat:, fix:, chore:, docs:, etc.)
-
-```bash
-git add -A
-git commit -m "<message>"
-```
-
-### Step 6: Push
-
-```bash
-git push
-```
-
-If push fails (e.g., remote has new commits):
-
-1. `git pull --rebase`
-2. Re-run tests to verify no conflicts broke anything
-3. `git push`
-
-### Step 7: Report
-
-```
-Deploy Complete
-===============
-Version: <old> -> <new>
-Tests:   passed
-Types:   clean
-Build:   success
-Commit:  <hash> - <message>
-Push:    pushed to <branch>
-```
-
-### Step 8: Project Task Status Transition
-
-After a successful push, mark any linked project task as `submitted`. This is a best-effort fanout -- it must never fail the deploy.
-
-1. **Resolve the task ID.** Look for a `prj_tasks` UUID tied to the current work, in this order:
-   - A task UUID explicitly captured in the current conversation (e.g. from a previous `/save`, `/project work`, or `project:task:*` invocation).
-   - The most recent in-progress task on the most-recently-touched project, via:
-
-     ```bash
-     pnpm elevasis-sdk project:list --status active --pretty
-     pnpm elevasis-sdk project:list --status blocked --pretty
-     pnpm elevasis-sdk project:task:list --project <project-id> --status in_progress --pretty
-     ```
-
-   - If the session produced an ambiguous or empty result, PROMPT the user once: "Mark a project task as submitted? (task UUID, or 'skip')". Default is skip.
-
-2. **Fire the transition** (only when a single confident task ID is resolved):
-
-   ```bash
-   pnpm elevasis-sdk project:task:update <task-id> --status submitted
-   ```
-
-3. **Failure handling.** If the CLI call errors, no task ID can be resolved, or the user declines, emit a single warning line and continue:
-
-   ```
-   Warning: skipped project:task status transition (<reason>). Deploy itself succeeded.
-   ```
-
-   Never retry, never block the deploy report, never exit non-zero on this step.
-
-## Error Recovery
-
-If any step fails and cannot be auto-fixed:
-
-```
-Deploy Failed at Step N: [step name]
-=====================================
-Error: [description]
-Attempted fixes: [what was tried]
-Manual action needed: [what the user should do]
-```
+---
+name: deploy
+description: Test, build, fix issues, then commit and push
+---
+
+# Deploy
+
+Test, build, fix issues, then commit and push.
+
+**Usage:** `/deploy [--skip] [--minor | --major] [commit message]`
+
+## Flags
+
+- `--skip` -- Skip tests, type checking, and build (Steps 2-4). Go straight from pre-flight to commit and push.
+- `--minor` -- Bump the minor version instead of patch (e.g. 1.0.0 -> 1.1.0).
+- `--major` -- Bump the major version instead of patch (e.g. 1.0.0 -> 2.0.0).
+
+## Process
+
+### Step 1: Pre-flight Check
+
+Run in parallel:
+
+```bash
+git status
+git diff --stat
+```
+
+If there are no changes, report "Nothing to deploy" and stop.
+
+### Step 1b: Version Bump
+
+Read the current version from `package.json`, then bump it:
+
+- Default: bump **patch** (e.g. 1.0.0 -> 1.0.1)
+- `--minor`: bump **minor** (e.g. 1.0.0 -> 1.1.0)
+- `--major`: bump **major** (e.g. 1.0.0 -> 2.0.0)
+
+Use the Edit tool to update the `"version"` field in `package.json` directly. Do not use `npm version` or any CLI command.
+
+### Step 2: Run Tests
+
+```bash
+pnpm test
+```
+
+If tests fail:
+
+1. Read the failing test output
+2. Attempt to fix the issue
+3. Re-run tests
+4. If still failing after 2 attempts, stop and report the failures
+
+### Step 3: Type Check
+
+```bash
+pnpm lint
+```
+
+If type errors exist:
+
+1. Read the errors
+2. Attempt to fix
+3. Re-run
+4. If still failing after 2 attempts, stop and report
+
+### Step 4: Build
+
+```bash
+pnpm build
+```
+
+If build fails:
+
+1. Read the error output
+2. Attempt to fix
+3. Re-run
+4. If still failing after 2 attempts, stop and report
+
+### Step 5: Commit
+
+1. Stage all changed files: `git add -A`
+2. Create commit with the provided message (or auto-generate from changes)
+3. Format: conventional commits (feat:, fix:, chore:, docs:, etc.)
+
+```bash
+git add -A
+git commit -m "<message>"
+```
+
+### Step 6: Push
+
+```bash
+git push
+```
+
+If push fails (e.g., remote has new commits):
+
+1. `git pull --rebase`
+2. Re-run tests to verify no conflicts broke anything
+3. `git push`
+
+### Step 7: Report
+
+```
+Deploy Complete
+===============
+Version: <old> -> <new>
+Tests:   passed
+Types:   clean
+Build:   success
+Commit:  <hash> - <message>
+Push:    pushed to <branch>
+```
+
+### Step 8: Project Task Status Transition
+
+After a successful push, mark any linked project task as `submitted`. This is a best-effort fanout -- it must never fail the deploy.
+
+1. **Resolve the task ID.** Look for a `prj_tasks` UUID tied to the current work, in this order:
+   - A task UUID explicitly captured in the current conversation (e.g. from a previous `/save`, `/project work`, or `project:task:*` invocation).
+   - The most recent in-progress task on the most-recently-touched project, via:
+
+     ```bash
+     pnpm elevasis-sdk project:list --status active --pretty
+     pnpm elevasis-sdk project:list --status blocked --pretty
+     pnpm elevasis-sdk project:task:list --project <project-id> --status in_progress --pretty
+     ```
+
+   - If the session produced an ambiguous or empty result, PROMPT the user once: "Mark a project task as submitted? (task UUID, or 'skip')". Default is skip.
+
+2. **Fire the transition** (only when a single confident task ID is resolved):
+
+   ```bash
+   pnpm elevasis-sdk project:task:update <task-id> --status submitted
+   ```
+
+3. **Failure handling.** If the CLI call errors, no task ID can be resolved, or the user declines, emit a single warning line and continue:
+
+   ```
+   Warning: skipped project:task status transition (<reason>). Deploy itself succeeded.
+   ```
+
+   Never retry, never block the deploy report, never exit non-zero on this step.
+
+## Error Recovery
+
+If any step fails and cannot be auto-fixed:
+
+```
+Deploy Failed at Step N: [step name]
+=====================================
+Error: [description]
+Attempted fixes: [what was tried]
+Manual action needed: [what the user should do]
+```

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

@@ -1,66 +1,66 @@
----
-name: dsp
-description: Dispatch subagents in parallel for implementation tasks
----
-
-# DSP -- Dispatch Subagents in Parallel
-
-Parallel agent dispatch for implementation tasks. Orchestrate, then delegate to subagents.
-
-**Usage:** `/dsp <instructions>`
-
-## Rules
-
-1. **Always dispatch, never self-execute** -- the purpose is to offload work to subagents
-2. **Parallel within waves** -- all agents in a wave dispatched in a SINGLE message
-3. **Orient first** -- read `.claude/rules/agent-start-here.md` before planning to understand project structure and task routing
-
-## Process
-
-### Step 1: Understand Context
-
-1. Read `.claude/rules/agent-start-here.md` for project structure, task-class routing, and boundary resolution
-2. Read relevant architecture/feature docs based on the task domain
-3. If the task touches code, explore the relevant `src/` directories
-
-### Step 2: Analyze Complexity
-
-**Single-Wave** -- all tasks independent, dispatch everything at once
-**Multi-Wave** -- tasks have dependencies, execute waves sequentially
-
-### Step 3: Plan
-
-For each unit of work, identify:
-
-- What files/areas are affected
-- What context the subagent needs
-- Whether it depends on another task's output
-
-Print the plan:
-
-```
-DSP Plan: N waves, M tasks
-Wave 1: [description] -- N tasks
-Wave 2: [description] -- N tasks (if multi-wave)
-Dispatching Wave 1...
-```
-
-### Step 4: Dispatch
-
-Use the Agent tool with `subagent_type="general-purpose"` and `model="sonnet"`.
-
-Each agent prompt must include:
-
-- The specific task to accomplish
-- Relevant file paths and context
-- Instruction to use backslash paths for file operations on Windows
-
-### Step 5: Aggregate Results
-
-```
-DSP Results: [description]
-
-Tasks completed: X/Y
-Files modified: [list]
-Next steps: [if any]
-```
+---
+name: dsp
+description: Dispatch subagents in parallel for implementation tasks
+---
+
+# DSP -- Dispatch Subagents in Parallel
+
+Parallel agent dispatch for implementation tasks. Orchestrate, then delegate to subagents.
+
+**Usage:** `/dsp <instructions>`
+
+## Rules
+
+1. **Always dispatch, never self-execute** -- the purpose is to offload work to subagents
+2. **Parallel within waves** -- all agents in a wave dispatched in a SINGLE message
+3. **Orient first** -- read `.claude/rules/agent-start-here.md` before planning to understand project structure and task routing
+
+## Process
+
+### Step 1: Understand Context
+
+1. Read `.claude/rules/agent-start-here.md` for project structure, task-class routing, and boundary resolution
+2. Read relevant architecture/feature docs based on the task domain
+3. If the task touches code, explore the relevant `src/` directories
+
+### Step 2: Analyze Complexity
+
+**Single-Wave** -- all tasks independent, dispatch everything at once
+**Multi-Wave** -- tasks have dependencies, execute waves sequentially
+
+### Step 3: Plan
+
+For each unit of work, identify:
+
+- What files/areas are affected
+- What context the subagent needs
+- Whether it depends on another task's output
+
+Print the plan:
+
+```
+DSP Plan: N waves, M tasks
+Wave 1: [description] -- N tasks
+Wave 2: [description] -- N tasks (if multi-wave)
+Dispatching Wave 1...
+```
+
+### Step 4: Dispatch
+
+Use the Agent tool with `subagent_type="general-purpose"` and `model="sonnet"`.
+
+Each agent prompt must include:
+
+- The specific task to accomplish
+- Relevant file paths and context
+- Instruction to use backslash paths for file operations on Windows
+
+### Step 5: Aggregate Results
+
+```
+DSP Results: [description]
+
+Tasks completed: X/Y
+Files modified: [list]
+Next steps: [if any]
+```