@elevasis/sdk 0.5.15 → 0.5.16

package/dist/cli.cjs

@@ -43851,7 +43851,7 @@ async function apiDelete(endpoint, apiUrl = resolveApiUrl()) {
 // package.json
 var package_default = {
   name: "@elevasis/sdk",
-  version: "0.5.15",
+  version: "0.5.16",
   description: "SDK for building Elevasis organization resources",
   type: "module",
   bin: {
@@ -44753,6 +44753,7 @@ function registerCheckCommand(program3) {
 }
 
 // src/cli/commands/exec.ts
+var import_node_fs = require("node:fs");
 var POLL_INTERVAL_MS = 3e3;
 async function pollForCompletion(resourceId, executionId, apiUrl) {
   const pollSpinner = ora("Waiting for completion...").start();
@@ -44771,10 +44772,7 @@ async function pollForCompletion(resourceId, executionId, apiUrl) {
     const elapsed = Math.round((Date.now() - startTime) / 1e3);
     pollSpinner.text = `Waiting for completion... (${elapsed}s)`;
     try {
-      const detail = await apiGet(
-        `/api/external/executions/${resourceId}/${executionId}`,
-        apiUrl
-      );
+      const detail = await apiGet(`/api/external/executions/${resourceId}/${executionId}`, apiUrl);
       if (detail.status === "completed" || detail.status === "failed") {
         process.removeListener("SIGINT", cleanup);
         if (detail.status === "completed") {
@@ -44807,70 +44805,71 @@ async function pollForCompletion(resourceId, executionId, apiUrl) {
 }
 function registerExecCommand(program3) {
   program3.command("exec <resourceId>").description(`Execute a deployed resource
-  Example: elevasis-sdk exec my-workflow -i '{"key":"value"}'`).option("-i, --input <json>", "Input data as JSON string").option("--async", "Execute asynchronously with polling").option("--api-url <url>", "API URL").action(wrapAction("exec", async (resourceId, options2) => {
-    const input = options2.input ? JSON.parse(options2.input) : {};
-    const apiUrl = resolveApiUrl(options2.apiUrl);
-    if (options2.async) {
-      const asyncSpinner = ora(`Starting async execution of ${resourceId}...`).start();
-      const asyncResult = await apiPost(
-        "/api/external/execute-async",
-        { resourceId, input },
-        apiUrl
-      );
-      asyncSpinner.succeed(source_default.green("Execution started"));
-      console.log(source_default.gray("  Execution ID:"), source_default.cyan(asyncResult.executionId));
-      console.log("");
-      await pollForCompletion(resourceId, asyncResult.executionId, apiUrl);
-      return;
-    }
-    const spinner = ora(`Executing ${resourceId}...`).start();
-    try {
-      const result = await apiPost(
-        "/api/external/execute",
-        { resourceId, input },
-        apiUrl
-      );
-      if (result.success) {
-        spinner.succeed(source_default.green("Execution complete"));
-        console.log(source_default.gray("  Execution ID:"), source_default.cyan(result.executionId));
-        console.log("");
-        console.log(source_default.green("  Output:"));
-        console.log(JSON.stringify(result.data, null, 2));
-      } else {
-        spinner.fail(source_default.red("Execution failed"));
-        console.log(source_default.gray("  Execution ID:"), source_default.cyan(result.executionId));
-      }
-    } catch (error46) {
-      const message = error46 instanceof Error ? error46.message : String(error46);
-      const isConnectionFailure = message.includes("fetch failed") || message.includes("ECONNRESET") || message.includes("socket hang up") || message.includes("network");
-      if (isConnectionFailure) {
-        spinner.warn("Connection lost -- execution may still be running");
-        console.log();
-        try {
-          const recoverSpinner = ora("Recovering execution...").start();
-          const listResult = await apiGet(
-            `/api/external/executions/${resourceId}?limit=1`,
+  Example: elevasis-sdk exec my-workflow -i '{"key":"value"}'`).option("-i, --input <json>", "Input data as JSON string").option("-f, --input-file <path>", "Read input from a JSON file (avoids shell escaping issues)").option("--async", "Execute asynchronously with polling").option("--api-url <url>", "API URL").action(
+    wrapAction(
+      "exec",
+      async (resourceId, options2) => {
+        const input = options2.inputFile ? JSON.parse((0, import_node_fs.readFileSync)(options2.inputFile, "utf8")) : options2.input ? JSON.parse(options2.input) : {};
+        const apiUrl = resolveApiUrl(options2.apiUrl);
+        if (options2.async) {
+          const asyncSpinner = ora(`Starting async execution of ${resourceId}...`).start();
+          const asyncResult = await apiPost(
+            "/api/external/execute-async",
+            { resourceId, input },
             apiUrl
           );
-          const running = listResult.executions.find((e) => e.status === "running");
-          if (running) {
-            recoverSpinner.succeed(`Found running execution: ${running.id}`);
-            console.log();
-            await pollForCompletion(resourceId, running.id, apiUrl);
+          asyncSpinner.succeed(source_default.green("Execution started"));
+          console.log(source_default.gray("  Execution ID:"), source_default.cyan(asyncResult.executionId));
+          console.log("");
+          await pollForCompletion(resourceId, asyncResult.executionId, apiUrl);
+          return;
+        }
+        const spinner = ora(`Executing ${resourceId}...`).start();
+        try {
+          const result = await apiPost("/api/external/execute", { resourceId, input }, apiUrl);
+          if (result.success) {
+            spinner.succeed(source_default.green("Execution complete"));
+            console.log(source_default.gray("  Execution ID:"), source_default.cyan(result.executionId));
+            console.log("");
+            console.log(source_default.green("  Output:"));
+            console.log(JSON.stringify(result.data, null, 2));
           } else {
-            recoverSpinner.info("No running execution found -- it may have already completed");
-            console.log(source_default.dim("  Check status manually or re-run with --async"));
+            spinner.fail(source_default.red("Execution failed"));
+            console.log(source_default.gray("  Execution ID:"), source_default.cyan(result.executionId));
           }
-        } catch {
-          console.log(source_default.yellow("Could not recover. The execution may still be running on the server."));
-          console.log(source_default.dim("  Check status manually or re-run with --async"));
+        } catch (error46) {
+          const message = error46 instanceof Error ? error46.message : String(error46);
+          const isConnectionFailure = message.includes("fetch failed") || message.includes("ECONNRESET") || message.includes("socket hang up") || message.includes("network");
+          if (isConnectionFailure) {
+            spinner.warn("Connection lost -- execution may still be running");
+            console.log();
+            try {
+              const recoverSpinner = ora("Recovering execution...").start();
+              const listResult = await apiGet(
+                `/api/external/executions/${resourceId}?limit=1`,
+                apiUrl
+              );
+              const running = listResult.executions.find((e) => e.status === "running");
+              if (running) {
+                recoverSpinner.succeed(`Found running execution: ${running.id}`);
+                console.log();
+                await pollForCompletion(resourceId, running.id, apiUrl);
+              } else {
+                recoverSpinner.info("No running execution found -- it may have already completed");
+                console.log(source_default.dim("  Check status manually or re-run with --async"));
+              }
+            } catch {
+              console.log(source_default.yellow("Could not recover. The execution may still be running on the server."));
+              console.log(source_default.dim("  Check status manually or re-run with --async"));
+            }
+            process.exit(0);
+          }
+          spinner.fail(source_default.red("Execution failed"));
+          throw error46;
         }
-        process.exit(0);
       }
-      spinner.fail(source_default.red("Execution failed"));
-      throw error46;
-    }
-  }));
+    )
+  );
 }
 
 // src/cli/commands/resources.ts
@@ -45180,7 +45179,7 @@ var import_path3 = require("path");
 var import_promises2 = require("fs/promises");
 
 // src/cli/commands/templates/core/workspace.ts
-var TEMPLATE_VERSION = 28;
+var TEMPLATE_VERSION = 29;
 function configTemplate() {
   return `import type { ElevasConfig } from '@elevasis/sdk'
 
@@ -45410,8 +45409,8 @@ process.stdin.on('end', () => {
 function claudeSdkBoundaryHookTemplate() {
   return String.raw`#!/usr/bin/env node
 // enforce-sdk-boundary.mjs
-// Blocks gh CLI, destructive git operations, and file writes outside the project root.
-// Allows git add, commit, push, pull, fetch -- used by /meta deploy.
+// Blocks file modifications (Write, Edit, MultiEdit, destructive Bash) outside the project root.
+// Git, gh, and other CLI tools are NOT blocked -- the agent can use them freely.
 
 import { resolve, normalize } from "node:path";
 import { appendFileSync, mkdirSync } from "node:fs";
@@ -45456,44 +45455,6 @@ try {
   if (input.tool_name === "Bash") {
     const cmd = input.tool_input?.command ?? "";
 
-    // GitHub CLI -- blocked (affects shared remote state, user-initiated only)
-    if (/\bgh\b/.test(cmd)) {
-      deny(
-        "BLOCKED: GitHub CLI (gh) command detected.\n" +
-        "WHY: GitHub CLI operations affect shared remote state (PRs, issues, releases). These must be user-initiated.\n" +
-        "INSTEAD: Ask the user to run this gh command manually."
-      );
-      process.exit(0);
-    }
-
-    // Destructive git -- blocked
-    if (/(?<!-)\bgit\s+reset\b/.test(cmd) && /--hard/.test(cmd)) {
-      deny(
-        "BLOCKED: git reset --hard detected.\n" +
-        "WHY: Hard resets destroy uncommitted work and cannot be undone. This must be user-initiated.\n" +
-        "INSTEAD: Ask the user to run this git command manually."
-      );
-      process.exit(0);
-    }
-
-    if (/(?<!-)\bgit\s+clean\b/.test(cmd) && /-[a-zA-Z]*f/.test(cmd)) {
-      deny(
-        "BLOCKED: git clean -f detected.\n" +
-        "WHY: Force-cleaning the working tree permanently removes untracked files. This must be user-initiated.\n" +
-        "INSTEAD: Ask the user to run this git command manually."
-      );
-      process.exit(0);
-    }
-
-    if (/(?<!-)\bgit\s+(rebase|merge)\b/.test(cmd)) {
-      deny(
-        "BLOCKED: git rebase/merge detected.\n" +
-        "WHY: Rebase and merge rewrite history or combine branches in ways that require user judgment.\n" +
-        "INSTEAD: Ask the user to run this git command manually."
-      );
-      process.exit(0);
-    }
-
     // Path-scoped blocks -- destructive commands or redirects outside project root
     const winPaths = cmd.match(/(?<![A-Za-z])[A-Za-z]:[/\\][^\s"'|;&)]+/g) || [];
     const unixPaths = cmd.match(/(?<=\s|^|"|')\/[^\s"'|;&)]+/g) || [];
@@ -45676,7 +45637,7 @@ For detailed per-dimension adaptation rules, read
 | --- | --- |
 | \`/meta\` | Project lifecycle: init, status, fix, deploy, health |
 | \`/docs\` | Browse, create, and verify permanent documentation |
-| \`/work\` | Task tracking: create, save, resume, complete |
+| \`/work\` | Task tracking: auto-detects intent (create, save, resume); suggests complete |
 | \`/tutorial\` | Progressive learning path (21 items across 4 sections) |
 
 ## Skills
@@ -45908,43 +45869,46 @@ Observation focus: full lifecycle coverage, pipeline internals.
 **Item 4: /work and /docs**
 
 When automation is none:
-"You can ask the assistant to track work across conversations. When you start something
-complex, use /work create to save your place. Next session, /work resume picks up where
-you left off." Walk through the concept without deep command details. Then introduce /docs:
-"When a task is finished, /work complete moves it to docs/ permanently. After that, /docs
-helps you find and read what's there -- like a notebook for your project." Run /docs (no
-args) to show the docs/ overview together.
-Verify: Create a task with \`/work create "practice task"\`, then run /work to see it listed.
+"You can ask the assistant to track work across conversations. Just say /work and tell it
+what you're working on -- it figures out the rest. It'll save your progress automatically,
+and next session you just say /work to pick up where you left off." Walk through the
+concept without deep command details. Then introduce /docs:
+"When a task is done, the assistant will ask if you want to finalize it -- that moves it
+to docs/ permanently. /docs helps you find and read what's there -- like a notebook for
+your project." Run /docs (no args) to show the docs/ overview together.
+Verify: Run \`/work\` and describe "practice task", see it created automatically.
 Then run /docs to see the docs/ structure.
 Observation focus: persistence concept, cross-session continuity, docs as permanent notes.
 
 When automation is low-code:
-Show /work operations: create (task doc with frontmatter + sections), save (updates
-Progress + Resume Context), resume (loads context for next session), complete (moves
-to permanent docs/).
+Show /work as intent-driven: the agent detects whether to create, resume, or save based
+on context. Create happens when you describe new work, resume when you pick an existing
+task, save happens automatically when progress is made. Complete is the only action that
+asks permission first.
 Then introduce /docs: "/docs is for permanent knowledge -- things that don't expire. Use
 /docs create to document a workflow or integration. Use /docs verify to check if your
 docs match the current code." Explain the boundary: /work manages in-progress/, /docs
 manages permanent docs/.
-Verify: Create a task with \`/work create "practice task"\`, run /work save, inspect the
-file. Then run /docs to browse docs/.
-Observation focus: task tracking workflow, /work vs /docs separation.
+Verify: Run \`/work\` and describe "practice task", see auto-create. Make some changes,
+then notice auto-save. Then run /docs to browse docs/.
+Observation focus: intent-driven task tracking, /work vs /docs separation.
 
 When automation is custom:
 Read \`.claude/commands/work.md\`. Full /work coverage:
-/work create (kebab-case filename, frontmatter with status, Objective/Plan/Progress/
-Resume Context sections), /work save (Progress + Resume Context update), /work resume
-(multiple-task disambiguation), /work complete (moves to final location).
+Intent detection table (list, create, resume, save auto-invoked; complete always suggests).
+Task doc anatomy: kebab-case filename, frontmatter with status, Objective/Plan/Progress/
+Resume Context sections. Auto-save behavior: triggers on heavy context, wrap-up signals,
+2+ steps completed. Resolution order for resume: number, keyword match, single in-progress.
 Then read \`.claude/commands/docs.md\`. Cover /docs operations:
 /docs (default): browse permanent docs/, categorized with read-only auto-generated files
 separate; /docs create: interview-driven, resource-aware doc creation from src/ code
 analysis; /docs verify: cross-references resource IDs, schema fields, platform tools in
 docs against src/ -- standalone analog of /meta fix step 5.
-Explain the relationship: /work owns docs/in-progress/ (task lifecycle), /work complete
+Explain the relationship: /work owns docs/in-progress/ (task lifecycle), completing a task
 moves docs to permanent location, /docs browses and verifies what's there.
-Verify: Create a task doc, save progress, run /work complete to move it. Then run /docs
-to see it in the permanent docs/ listing.
-Observation focus: task doc anatomy, /work-to-/docs handoff, docs verification as standalone tool.
+Verify: Create a task via /work, make progress, observe auto-save, then run /work complete
+to move it. Run /docs to see it in the permanent docs/ listing.
+Observation focus: intent detection, auto-save behavior, /work-to-/docs handoff, docs verification.
 
 **Item 5: Your First Custom Workflow**
 
@@ -46478,6 +46442,8 @@ function claudeWorkCommandTemplate() {
 
 You are a task tracking assistant for this Elevasis workspace. \`/work\` is the primary command for managing all work and projects.
 
+Your job is to **intelligently manage tasks without requiring the user to know subcommands**. Detect what the user needs from context and act accordingly.
+
 ## Context
 
 Read \`docs/priorities.mdx\` if it exists for current priorities.
@@ -46497,9 +46463,25 @@ When scanning, treat \`index.mdx\` as the primary task doc for a directory.
 
 Enforce exactly three values in frontmatter: \`planned\`, \`in-progress\`, \`complete\`.
 
-## Operations
+## Intent Detection
+
+When \`/work\` is invoked (with or without arguments), detect intent from context:
+
+| Signal | Action |
+|--------|--------|
+| No arguments, no active conversation context | **List** tasks, then let user pick |
+| User picks a number or names a task | **Resume** that task automatically |
+| User describes new work (not matching existing tasks) | **Create** a task doc automatically |
+| \`/work\` with a description that matches no existing task | **Create** automatically |
+| \`/work\` with a keyword/name matching an existing task | **Resume** automatically |
+| Conversation is getting heavy, user wrapping up, or 2+ steps completed | **Save** automatically |
+| All plan steps are COMPLETE | **Suggest** \`/work complete\` (never auto-invoke) |
 
-### No arguments (default) -- List and Pick
+**Key principle:** Create, save, and resume are auto-invoked. Complete always asks permission first.
+
+## Behaviors
+
+### List and Pick (default when no context)
 
 1. Scan \`docs/in-progress/\` recursively for \`.mdx\` files with \`status\` frontmatter
 2. For directories, read \`index.mdx\` as the primary task doc
@@ -46518,30 +46500,25 @@ Active Tasks
 3. [complete] CRM Integration
    Completed: 2026-03-03
 
-Pick a task by number or name to resume, or say:
-- "create" to start new work
-- "complete <name>" to finish a task
+Pick a task by number or name, or describe new work to start.
 \`\`\`
 
 4. Cross-reference with \`docs/priorities.mdx\` if it exists
-5. When the user picks a number or describes a task in natural language, auto-invoke the **resume** flow on that task
-6. If no tasks found, suggest \`/work create\`
+5. When the user picks a number or describes a task, auto-invoke the appropriate flow (resume or create)
+6. If no tasks found, ask: "What are you trying to accomplish?"
 
-### \`create [description]\`
+### Create (auto-invoked when new work detected)
 
-Guided task creation with interview:
-
-1. If no description given, ask: "What are you trying to accomplish?"
-2. Ask 2-3 focused questions:
+1. If the user's intent is clear, skip the interview and create directly
+2. If ambiguous, ask 1-2 focused questions:
    - "What does success look like?" (acceptance criteria)
-   - "Is this related to any existing work?" (scan \`docs/in-progress/\` and \`docs/\` for related topics)
-   - "Do we need to investigate anything first, or is the path clear?" (suggest investigation if needed)
-3. Determine directory placement:
-   - Scan \`docs/in-progress/\` for existing directories related to the topic
+   - "Do we need to investigate anything first, or is the path clear?"
+3. Scan \`docs/in-progress/\` for existing directories related to the topic
+4. Determine directory placement:
    - If related to existing directory, create as a file within it
    - If new concept that may grow, create \`docs/in-progress/<slug>/index.mdx\`
    - If small/standalone, create \`docs/in-progress/<slug>.mdx\`
-4. Create the doc with \`status: planned\` and structured sections:
+5. Create the doc with \`status: planned\` and structured sections:
 
 \`\`\`yaml
 ---
@@ -46553,15 +46530,20 @@ status: planned
 
 Sections: Objective (what and why), Plan (numbered steps), Progress (per-step tracking with PENDING markers), Resume Context (current state, key docs, "To continue" prompt).
 
-5. Update \`docs/priorities.mdx\` if it exists
-6. Report what was created with location and step count
+6. Update \`docs/priorities.mdx\` if it exists
+7. Report what was created with location and step count
 
-### \`save\`
+### Save (auto-invoked when progress detected)
 
-Update the current task doc's Progress and Resume Context:
+Auto-save triggers (do NOT ask, just save):
+- The conversation context is getting heavy (many tool calls, large file reads)
+- The user appears to be wrapping up (thanks, goodbye, switching topics)
+- Significant progress has been made (2+ steps completed without saving)
+- Before a context reset
 
-1. Identify the current task from conversation context (which in-progress doc was loaded/discussed)
-2. If not working on a tracked task, list available docs and ask which to save to, or offer to create a new one
+Save flow:
+1. Identify the current task from conversation context
+2. If not working on a tracked task, offer to create a new one
 3. Update Progress section:
    - Mark completed steps as \`COMPLETE\` with: what was done, key decisions, files changed
    - Mark current step as \`IN PROGRESS\` with current state
@@ -46571,15 +46553,13 @@ Update the current task doc's Progress and Resume Context:
    - Files Modified: table of file paths and descriptions of changes
    - Key docs to read on resume: file paths with why they matter
    - To continue: copy-pasteable prompt for the next session
-5. Set \`status\` appropriately (\`in-progress\` if ongoing, \`complete\` if all steps done)
-6. Report: task title, status, completed steps count, last step, and the resume command
+5. Set \`status\` appropriately (\`in-progress\` if ongoing)
+6. Briefly confirm: "Progress saved to {path}."
 
-### \`resume [name-or-number]\`
-
-Resume in-progress work. Designed for non-technical users who may not know file paths.
+### Resume (auto-invoked when existing task detected)
 
 **Resolution order:**
-1. If a number is given (e.g., \`/work resume 2\`), map to the numbered list from the default list operation
+1. If a number is given, map to the numbered list from the task list
 2. If a name/keyword is given, substring match against task titles and filenames in \`docs/in-progress/\`
 3. If no argument, scan for \`status: in-progress\` docs -- if one found, use it; if multiple, list and ask
 4. If multiple matches, list them and ask which to resume
@@ -46605,35 +46585,32 @@ Key context loaded:
 Ready to continue. {Copy of "To continue" prompt}
 \`\`\`
 
-### \`complete [name]\`
+### Complete (NEVER auto-invoked -- always suggest)
+
+When all plan steps are COMPLETE, suggest: "All steps for '{task}' look done. Want me to finalize it?"
 
-Mark task complete, clean up, and move to permanent docs:
+Only proceed after explicit user confirmation. Then:
 
-1. Resolve target (same as resume: number, name, or scan for \`status: complete\`)
-2. **Validate readiness:** Check that all plan steps are marked COMPLETE. If not, warn and ask for confirmation.
-3. **Clean up the doc:**
+1. **Validate readiness:** Check that all plan steps are marked COMPLETE. If not, warn and ask for confirmation.
+2. **Clean up the doc:**
    - Strip \`## Resume Context\` section entirely (header through next \`##\` or EOF)
    - Strip progress markers: \`COMPLETE\`, \`IN PROGRESS\`, \`PENDING\` from step headings
    - Remove steps still marked PENDING entirely (header + body) -- they were never done
    - Remove \`status\` from frontmatter (keep \`title\` and \`description\`)
    - Target 200-400 lines; flag if result exceeds 500 lines
-4. **Determine destination:**
+3. **Determine destination:**
    - Scan \`docs/\` (excluding \`docs/in-progress/\`) for existing directories related to this work
    - If a related directory exists, propose merging into it
    - If no related directory, propose \`docs/<slug>/\` or \`docs/<slug>.mdx\`
    - Present the proposed destination and ask user to confirm
-5. **Move the doc(s):**
+4. **Move the doc(s):**
    - Single file: move from \`docs/in-progress/\` to destination
    - Directory: move entire directory
-6. **Verify and report:**
+5. **Verify and report:**
    - Confirm destination exists, source removed
    - Check no leftover \`status:\` or \`## Resume Context\` in moved files
    - Update \`docs/priorities.mdx\` if it exists
    - Report: task title, cleanup stats (lines before/after), destination path
-
-## Completion Suggestions
-
-When the agent observes that all plan steps for a task are marked COMPLETE and the user seems to be moving on, proactively suggest: "All steps for '{task}' are complete. Run \`/work complete\` to finalize it."
 `;
 }
 function claudeDocsCommandTemplate() {
@@ -46699,7 +46676,7 @@ Steps:
 
 ### \`create [description]\` -- Reference Doc Creation
 
-Interview-driven creation for permanent documentation. Task docs go through \`/work create\`.
+Interview-driven creation for permanent documentation. Task docs go through \`/work\`.
 
 1. If no description given, ask: "What do you want to document?"
 2. Determine doc type (infer or ask):
@@ -47069,17 +47046,19 @@ Exactly three values for frontmatter \`status\`: \`planned\`, \`in-progress\`, \
   - IN PROGRESS -> COMPLETE (finishing a step)
 - Do NOT update on every action -- only on step transitions
 
-## Save Suggestions
+## Auto-Save Behavior
 
-Proactively suggest \`/work save\` when:
+The agent auto-saves progress (no user action needed) when:
 - The conversation context is getting heavy (many tool calls, large file reads)
 - The user appears to be wrapping up (thanks, goodbye, switching topics)
 - Significant progress has been made (2+ steps completed without saving)
-- Before a \`/clear\` or context reset
+- Before a context reset
+
+Auto-save updates the task doc's Progress and Resume Context sections silently, then briefly confirms.
 
 ## Completion Suggestions
 
-When all plan steps are marked COMPLETE, suggest \`/work complete\` to finalize the task.
+When all plan steps are marked COMPLETE, **suggest** completing the task -- never auto-invoke. Ask: "All steps for '{task}' look done. Want me to finalize it?"
 
 ## Directory Conventions
 
@@ -47204,7 +47183,7 @@ const RECOVERY_TABLE = [
     test: r => /boundary hook/i.test(r) && /block|denied/i.test(r),
     advice: 'Command blocked by SDK boundary hook.',
     fix: 'Ask the user to run this command manually.',
-    why: 'The boundary hook blocks gh CLI, destructive git operations, and file writes outside the project.',
+    why: 'The boundary hook blocks file modifications (Write, Edit, destructive Bash) outside the project boundary.',
     see: 'CLAUDE.md',
   },
   {

package/dist/templates.js

@@ -1,7 +1,7 @@
 // package.json
 
 // src/cli/commands/templates/core/workspace.ts
-var TEMPLATE_VERSION = 28;
+var TEMPLATE_VERSION = 29;
 function configTemplate() {
   return `import type { ElevasConfig } from '@elevasis/sdk'
 
@@ -104,8 +104,8 @@ process.stdin.on('end', () => {
 function claudeSdkBoundaryHookTemplate() {
   return String.raw`#!/usr/bin/env node
 // enforce-sdk-boundary.mjs
-// Blocks gh CLI, destructive git operations, and file writes outside the project root.
-// Allows git add, commit, push, pull, fetch -- used by /meta deploy.
+// Blocks file modifications (Write, Edit, MultiEdit, destructive Bash) outside the project root.
+// Git, gh, and other CLI tools are NOT blocked -- the agent can use them freely.
 
 import { resolve, normalize } from "node:path";
 import { appendFileSync, mkdirSync } from "node:fs";
@@ -150,44 +150,6 @@ try {
   if (input.tool_name === "Bash") {
     const cmd = input.tool_input?.command ?? "";
 
-    // GitHub CLI -- blocked (affects shared remote state, user-initiated only)
-    if (/\bgh\b/.test(cmd)) {
-      deny(
-        "BLOCKED: GitHub CLI (gh) command detected.\n" +
-        "WHY: GitHub CLI operations affect shared remote state (PRs, issues, releases). These must be user-initiated.\n" +
-        "INSTEAD: Ask the user to run this gh command manually."
-      );
-      process.exit(0);
-    }
-
-    // Destructive git -- blocked
-    if (/(?<!-)\bgit\s+reset\b/.test(cmd) && /--hard/.test(cmd)) {
-      deny(
-        "BLOCKED: git reset --hard detected.\n" +
-        "WHY: Hard resets destroy uncommitted work and cannot be undone. This must be user-initiated.\n" +
-        "INSTEAD: Ask the user to run this git command manually."
-      );
-      process.exit(0);
-    }
-
-    if (/(?<!-)\bgit\s+clean\b/.test(cmd) && /-[a-zA-Z]*f/.test(cmd)) {
-      deny(
-        "BLOCKED: git clean -f detected.\n" +
-        "WHY: Force-cleaning the working tree permanently removes untracked files. This must be user-initiated.\n" +
-        "INSTEAD: Ask the user to run this git command manually."
-      );
-      process.exit(0);
-    }
-
-    if (/(?<!-)\bgit\s+(rebase|merge)\b/.test(cmd)) {
-      deny(
-        "BLOCKED: git rebase/merge detected.\n" +
-        "WHY: Rebase and merge rewrite history or combine branches in ways that require user judgment.\n" +
-        "INSTEAD: Ask the user to run this git command manually."
-      );
-      process.exit(0);
-    }
-
     // Path-scoped blocks -- destructive commands or redirects outside project root
     const winPaths = cmd.match(/(?<![A-Za-z])[A-Za-z]:[/\\][^\s"'|;&)]+/g) || [];
     const unixPaths = cmd.match(/(?<=\s|^|"|')\/[^\s"'|;&)]+/g) || [];
@@ -370,7 +332,7 @@ For detailed per-dimension adaptation rules, read
 | --- | --- |
 | \`/meta\` | Project lifecycle: init, status, fix, deploy, health |
 | \`/docs\` | Browse, create, and verify permanent documentation |
-| \`/work\` | Task tracking: create, save, resume, complete |
+| \`/work\` | Task tracking: auto-detects intent (create, save, resume); suggests complete |
 | \`/tutorial\` | Progressive learning path (21 items across 4 sections) |
 
 ## Skills
@@ -602,43 +564,46 @@ Observation focus: full lifecycle coverage, pipeline internals.
 **Item 4: /work and /docs**
 
 When automation is none:
-"You can ask the assistant to track work across conversations. When you start something
-complex, use /work create to save your place. Next session, /work resume picks up where
-you left off." Walk through the concept without deep command details. Then introduce /docs:
-"When a task is finished, /work complete moves it to docs/ permanently. After that, /docs
-helps you find and read what's there -- like a notebook for your project." Run /docs (no
-args) to show the docs/ overview together.
-Verify: Create a task with \`/work create "practice task"\`, then run /work to see it listed.
+"You can ask the assistant to track work across conversations. Just say /work and tell it
+what you're working on -- it figures out the rest. It'll save your progress automatically,
+and next session you just say /work to pick up where you left off." Walk through the
+concept without deep command details. Then introduce /docs:
+"When a task is done, the assistant will ask if you want to finalize it -- that moves it
+to docs/ permanently. /docs helps you find and read what's there -- like a notebook for
+your project." Run /docs (no args) to show the docs/ overview together.
+Verify: Run \`/work\` and describe "practice task", see it created automatically.
 Then run /docs to see the docs/ structure.
 Observation focus: persistence concept, cross-session continuity, docs as permanent notes.
 
 When automation is low-code:
-Show /work operations: create (task doc with frontmatter + sections), save (updates
-Progress + Resume Context), resume (loads context for next session), complete (moves
-to permanent docs/).
+Show /work as intent-driven: the agent detects whether to create, resume, or save based
+on context. Create happens when you describe new work, resume when you pick an existing
+task, save happens automatically when progress is made. Complete is the only action that
+asks permission first.
 Then introduce /docs: "/docs is for permanent knowledge -- things that don't expire. Use
 /docs create to document a workflow or integration. Use /docs verify to check if your
 docs match the current code." Explain the boundary: /work manages in-progress/, /docs
 manages permanent docs/.
-Verify: Create a task with \`/work create "practice task"\`, run /work save, inspect the
-file. Then run /docs to browse docs/.
-Observation focus: task tracking workflow, /work vs /docs separation.
+Verify: Run \`/work\` and describe "practice task", see auto-create. Make some changes,
+then notice auto-save. Then run /docs to browse docs/.
+Observation focus: intent-driven task tracking, /work vs /docs separation.
 
 When automation is custom:
 Read \`.claude/commands/work.md\`. Full /work coverage:
-/work create (kebab-case filename, frontmatter with status, Objective/Plan/Progress/
-Resume Context sections), /work save (Progress + Resume Context update), /work resume
-(multiple-task disambiguation), /work complete (moves to final location).
+Intent detection table (list, create, resume, save auto-invoked; complete always suggests).
+Task doc anatomy: kebab-case filename, frontmatter with status, Objective/Plan/Progress/
+Resume Context sections. Auto-save behavior: triggers on heavy context, wrap-up signals,
+2+ steps completed. Resolution order for resume: number, keyword match, single in-progress.
 Then read \`.claude/commands/docs.md\`. Cover /docs operations:
 /docs (default): browse permanent docs/, categorized with read-only auto-generated files
 separate; /docs create: interview-driven, resource-aware doc creation from src/ code
 analysis; /docs verify: cross-references resource IDs, schema fields, platform tools in
 docs against src/ -- standalone analog of /meta fix step 5.
-Explain the relationship: /work owns docs/in-progress/ (task lifecycle), /work complete
+Explain the relationship: /work owns docs/in-progress/ (task lifecycle), completing a task
 moves docs to permanent location, /docs browses and verifies what's there.
-Verify: Create a task doc, save progress, run /work complete to move it. Then run /docs
-to see it in the permanent docs/ listing.
-Observation focus: task doc anatomy, /work-to-/docs handoff, docs verification as standalone tool.
+Verify: Create a task via /work, make progress, observe auto-save, then run /work complete
+to move it. Run /docs to see it in the permanent docs/ listing.
+Observation focus: intent detection, auto-save behavior, /work-to-/docs handoff, docs verification.
 
 **Item 5: Your First Custom Workflow**
 
@@ -1172,6 +1137,8 @@ function claudeWorkCommandTemplate() {
 
 You are a task tracking assistant for this Elevasis workspace. \`/work\` is the primary command for managing all work and projects.
 
+Your job is to **intelligently manage tasks without requiring the user to know subcommands**. Detect what the user needs from context and act accordingly.
+
 ## Context
 
 Read \`docs/priorities.mdx\` if it exists for current priorities.
@@ -1191,9 +1158,25 @@ When scanning, treat \`index.mdx\` as the primary task doc for a directory.
 
 Enforce exactly three values in frontmatter: \`planned\`, \`in-progress\`, \`complete\`.
 
-## Operations
+## Intent Detection
+
+When \`/work\` is invoked (with or without arguments), detect intent from context:
+
+| Signal | Action |
+|--------|--------|
+| No arguments, no active conversation context | **List** tasks, then let user pick |
+| User picks a number or names a task | **Resume** that task automatically |
+| User describes new work (not matching existing tasks) | **Create** a task doc automatically |
+| \`/work\` with a description that matches no existing task | **Create** automatically |
+| \`/work\` with a keyword/name matching an existing task | **Resume** automatically |
+| Conversation is getting heavy, user wrapping up, or 2+ steps completed | **Save** automatically |
+| All plan steps are COMPLETE | **Suggest** \`/work complete\` (never auto-invoke) |
 
-### No arguments (default) -- List and Pick
+**Key principle:** Create, save, and resume are auto-invoked. Complete always asks permission first.
+
+## Behaviors
+
+### List and Pick (default when no context)
 
 1. Scan \`docs/in-progress/\` recursively for \`.mdx\` files with \`status\` frontmatter
 2. For directories, read \`index.mdx\` as the primary task doc
@@ -1212,30 +1195,25 @@ Active Tasks
 3. [complete] CRM Integration
    Completed: 2026-03-03
 
-Pick a task by number or name to resume, or say:
-- "create" to start new work
-- "complete <name>" to finish a task
+Pick a task by number or name, or describe new work to start.
 \`\`\`
 
 4. Cross-reference with \`docs/priorities.mdx\` if it exists
-5. When the user picks a number or describes a task in natural language, auto-invoke the **resume** flow on that task
-6. If no tasks found, suggest \`/work create\`
+5. When the user picks a number or describes a task, auto-invoke the appropriate flow (resume or create)
+6. If no tasks found, ask: "What are you trying to accomplish?"
 
-### \`create [description]\`
+### Create (auto-invoked when new work detected)
 
-Guided task creation with interview:
-
-1. If no description given, ask: "What are you trying to accomplish?"
-2. Ask 2-3 focused questions:
+1. If the user's intent is clear, skip the interview and create directly
+2. If ambiguous, ask 1-2 focused questions:
    - "What does success look like?" (acceptance criteria)
-   - "Is this related to any existing work?" (scan \`docs/in-progress/\` and \`docs/\` for related topics)
-   - "Do we need to investigate anything first, or is the path clear?" (suggest investigation if needed)
-3. Determine directory placement:
-   - Scan \`docs/in-progress/\` for existing directories related to the topic
+   - "Do we need to investigate anything first, or is the path clear?"
+3. Scan \`docs/in-progress/\` for existing directories related to the topic
+4. Determine directory placement:
    - If related to existing directory, create as a file within it
    - If new concept that may grow, create \`docs/in-progress/<slug>/index.mdx\`
    - If small/standalone, create \`docs/in-progress/<slug>.mdx\`
-4. Create the doc with \`status: planned\` and structured sections:
+5. Create the doc with \`status: planned\` and structured sections:
 
 \`\`\`yaml
 ---
@@ -1247,15 +1225,20 @@ status: planned
 
 Sections: Objective (what and why), Plan (numbered steps), Progress (per-step tracking with PENDING markers), Resume Context (current state, key docs, "To continue" prompt).
 
-5. Update \`docs/priorities.mdx\` if it exists
-6. Report what was created with location and step count
+6. Update \`docs/priorities.mdx\` if it exists
+7. Report what was created with location and step count
 
-### \`save\`
+### Save (auto-invoked when progress detected)
 
-Update the current task doc's Progress and Resume Context:
+Auto-save triggers (do NOT ask, just save):
+- The conversation context is getting heavy (many tool calls, large file reads)
+- The user appears to be wrapping up (thanks, goodbye, switching topics)
+- Significant progress has been made (2+ steps completed without saving)
+- Before a context reset
 
-1. Identify the current task from conversation context (which in-progress doc was loaded/discussed)
-2. If not working on a tracked task, list available docs and ask which to save to, or offer to create a new one
+Save flow:
+1. Identify the current task from conversation context
+2. If not working on a tracked task, offer to create a new one
 3. Update Progress section:
    - Mark completed steps as \`COMPLETE\` with: what was done, key decisions, files changed
    - Mark current step as \`IN PROGRESS\` with current state
@@ -1265,15 +1248,13 @@ Update the current task doc's Progress and Resume Context:
    - Files Modified: table of file paths and descriptions of changes
    - Key docs to read on resume: file paths with why they matter
    - To continue: copy-pasteable prompt for the next session
-5. Set \`status\` appropriately (\`in-progress\` if ongoing, \`complete\` if all steps done)
-6. Report: task title, status, completed steps count, last step, and the resume command
+5. Set \`status\` appropriately (\`in-progress\` if ongoing)
+6. Briefly confirm: "Progress saved to {path}."
 
-### \`resume [name-or-number]\`
-
-Resume in-progress work. Designed for non-technical users who may not know file paths.
+### Resume (auto-invoked when existing task detected)
 
 **Resolution order:**
-1. If a number is given (e.g., \`/work resume 2\`), map to the numbered list from the default list operation
+1. If a number is given, map to the numbered list from the task list
 2. If a name/keyword is given, substring match against task titles and filenames in \`docs/in-progress/\`
 3. If no argument, scan for \`status: in-progress\` docs -- if one found, use it; if multiple, list and ask
 4. If multiple matches, list them and ask which to resume
@@ -1299,35 +1280,32 @@ Key context loaded:
 Ready to continue. {Copy of "To continue" prompt}
 \`\`\`
 
-### \`complete [name]\`
+### Complete (NEVER auto-invoked -- always suggest)
+
+When all plan steps are COMPLETE, suggest: "All steps for '{task}' look done. Want me to finalize it?"
 
-Mark task complete, clean up, and move to permanent docs:
+Only proceed after explicit user confirmation. Then:
 
-1. Resolve target (same as resume: number, name, or scan for \`status: complete\`)
-2. **Validate readiness:** Check that all plan steps are marked COMPLETE. If not, warn and ask for confirmation.
-3. **Clean up the doc:**
+1. **Validate readiness:** Check that all plan steps are marked COMPLETE. If not, warn and ask for confirmation.
+2. **Clean up the doc:**
    - Strip \`## Resume Context\` section entirely (header through next \`##\` or EOF)
    - Strip progress markers: \`COMPLETE\`, \`IN PROGRESS\`, \`PENDING\` from step headings
    - Remove steps still marked PENDING entirely (header + body) -- they were never done
    - Remove \`status\` from frontmatter (keep \`title\` and \`description\`)
    - Target 200-400 lines; flag if result exceeds 500 lines
-4. **Determine destination:**
+3. **Determine destination:**
    - Scan \`docs/\` (excluding \`docs/in-progress/\`) for existing directories related to this work
    - If a related directory exists, propose merging into it
    - If no related directory, propose \`docs/<slug>/\` or \`docs/<slug>.mdx\`
    - Present the proposed destination and ask user to confirm
-5. **Move the doc(s):**
+4. **Move the doc(s):**
    - Single file: move from \`docs/in-progress/\` to destination
    - Directory: move entire directory
-6. **Verify and report:**
+5. **Verify and report:**
    - Confirm destination exists, source removed
    - Check no leftover \`status:\` or \`## Resume Context\` in moved files
    - Update \`docs/priorities.mdx\` if it exists
    - Report: task title, cleanup stats (lines before/after), destination path
-
-## Completion Suggestions
-
-When the agent observes that all plan steps for a task are marked COMPLETE and the user seems to be moving on, proactively suggest: "All steps for '{task}' are complete. Run \`/work complete\` to finalize it."
 `;
 }
 function claudeDocsCommandTemplate() {
@@ -1393,7 +1371,7 @@ Steps:
 
 ### \`create [description]\` -- Reference Doc Creation
 
-Interview-driven creation for permanent documentation. Task docs go through \`/work create\`.
+Interview-driven creation for permanent documentation. Task docs go through \`/work\`.
 
 1. If no description given, ask: "What do you want to document?"
 2. Determine doc type (infer or ask):
@@ -1727,17 +1705,19 @@ Exactly three values for frontmatter \`status\`: \`planned\`, \`in-progress\`, \
   - IN PROGRESS -> COMPLETE (finishing a step)
 - Do NOT update on every action -- only on step transitions
 
-## Save Suggestions
+## Auto-Save Behavior
 
-Proactively suggest \`/work save\` when:
+The agent auto-saves progress (no user action needed) when:
 - The conversation context is getting heavy (many tool calls, large file reads)
 - The user appears to be wrapping up (thanks, goodbye, switching topics)
 - Significant progress has been made (2+ steps completed without saving)
-- Before a \`/clear\` or context reset
+- Before a context reset
+
+Auto-save updates the task doc's Progress and Resume Context sections silently, then briefly confirms.
 
 ## Completion Suggestions
 
-When all plan steps are marked COMPLETE, suggest \`/work complete\` to finalize the task.
+When all plan steps are marked COMPLETE, **suggest** completing the task -- never auto-invoke. Ask: "All steps for '{task}' look done. Want me to finalize it?"
 
 ## Directory Conventions
 
@@ -1862,7 +1842,7 @@ const RECOVERY_TABLE = [
     test: r => /boundary hook/i.test(r) && /block|denied/i.test(r),
     advice: 'Command blocked by SDK boundary hook.',
     fix: 'Ask the user to run this command manually.',
-    why: 'The boundary hook blocks gh CLI, destructive git operations, and file writes outside the project.',
+    why: 'The boundary hook blocks file modifications (Write, Edit, destructive Bash) outside the project boundary.',
     see: 'CLAUDE.md',
   },
   {

package/dist/worker/index.js

@@ -4908,7 +4908,10 @@ var scheduler = createAdapter("scheduler", [
 
 // src/worker/adapters/llm.ts
 var llm = {
-  generate: (params) => platform.call({ tool: "llm", method: "generate", params })
+  generate: async (params) => {
+    const result = await platform.call({ tool: "llm", method: "generate", params });
+    return { output: result };
+  }
 };
 
 // src/worker/adapters/storage.ts

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@elevasis/sdk",
-  "version": "0.5.15",
+  "version": "0.5.16",
   "description": "SDK for building Elevasis organization resources",
   "type": "module",
   "bin": {

package/reference/framework/agent.mdx

@@ -73,15 +73,15 @@ The `/docs` command manages the permanent `docs/` tree -- everything except `doc
 
 ### `/work` Command
 
-The `/work` command manages in-progress task tracking across sessions. It uses `docs/in-progress/` for task documents with standardized frontmatter (`status: planned | in-progress | complete`). Operations:
+The `/work` command manages in-progress task tracking across sessions. It uses `docs/in-progress/` for task documents with standardized frontmatter (`status: planned | in-progress | complete`).
 
-- **`/work`** (no arguments) -- Numbered list sorted by status (`in-progress` first) with last-saved date and current step. Pick by number to auto-resume.
-- **`/work create`** -- Guided interview (5 questions) covering objective, acceptance criteria, relation to existing work, investigation needed, and placement. New docs start with `status: planned`. Placement is determined intelligently: related directory, new directory for multi-file tasks, flat file for small tasks.
-- **`/work save`** -- Comprehensive snapshot: progress markers, files modified table, key docs to read on resume, and a copy-pasteable "To continue" prompt. Proactively suggested before context pressure builds.
-- **`/work resume [<name>]`** -- Load a task by number, keyword, or auto-detect. Loads key docs in parallel and verifies referenced files exist. No file paths required.
-- **`/work complete`** -- Seven-step pipeline: resolve target, validate readiness, clean doc (strip resume context, remove progress markers, target 200-400 lines), determine destination in `docs/`, confirm with user, move, verify.
+`/work` is intent-driven -- the agent detects what to do from context rather than requiring explicit subcommands:
 
-When all plan steps for a task are marked COMPLETE and the user appears to be moving on, the agent proactively suggests running `/work complete`.
+- **`/work`** (no arguments) -- Lists tasks sorted by status (`in-progress` first) with last-saved date and current step. Pick by number or name to auto-resume, or describe new work to auto-create a task.
+- **Auto-create** -- When the user describes work that doesn't match an existing task, the agent creates a task doc automatically. If intent is clear, it skips the interview; if ambiguous, it asks 1-2 focused questions.
+- **Auto-save** -- The agent saves progress silently when the conversation context is getting heavy, the user is wrapping up, or 2+ steps have been completed without saving. Updates progress markers, files modified, and resume context.
+- **Auto-resume** -- When the user picks an existing task (by number, name, or keyword), the agent loads context and resumes automatically.
+- **Suggest complete** -- When all plan steps are marked COMPLETE, the agent suggests finalizing: "All steps for '{task}' look done. Want me to finalize it?" It never auto-invokes completion. The complete flow validates readiness, cleans the doc (strips resume context, removes progress markers, targets 200-400 lines), determines destination in `docs/`, confirms with user, moves, and verifies.
 
 **Directory conventions for `docs/in-progress/`:**
 

package/reference/framework/index.mdx

@@ -21,7 +21,7 @@ Running `elevasis-sdk init my-project` produces the following agent infrastructu
 │   ├── tutorial.md             # Progressive learning path (3 tracks)
 │   └── work.md                 # Task tracking
 ├── hooks/
-│   └── enforce-sdk-boundary.mjs  # Blocks destructive git, gh CLI, external writes
+│   └── enforce-sdk-boundary.mjs  # Blocks file modifications outside project boundary
 ├── skills/
 │   └── creds/SKILL.md          # Credential management (auto-triggers)
 └── rules/
@@ -167,15 +167,15 @@ Section templates by doc type:
 
 **Command Routing Reference:**
 
-| Scenario                                | Command        |
-| --------------------------------------- | -------------- |
-| Starting new work                       | `/work create` |
-| Resuming yesterday's work               | `/work resume` |
-| Browsing what docs exist                | `/docs`        |
-| Creating a reference doc (not a task)   | `/docs create` |
-| Checking if docs match current code     | `/docs verify` |
-| Full maintenance pipeline (8 steps)     | `/meta fix`    |
-| Deploying code and auto-generating maps | `/meta deploy` |
+| Scenario                                | Command                                               |
+| --------------------------------------- | ----------------------------------------------------- |
+| Starting new work                       | `/work` (auto-detects new work from your description) |
+| Resuming yesterday's work               | `/work` (auto-resumes if one task is in-progress)     |
+| Browsing what docs exist                | `/docs`                                               |
+| Creating a reference doc (not a task)   | `/docs create`                                        |
+| Checking if docs match current code     | `/docs verify`                                        |
+| Full maintenance pipeline (8 steps)     | `/meta fix`                                           |
+| Deploying code and auto-generating maps | `/meta deploy`                                        |
 
 ---
 

package/reference/framework/project-structure.mdx

@@ -96,7 +96,7 @@ This file is NOT scaffolded by default. The agent creates it the first time you
 
 ### `docs/in-progress/`
 
-Work-in-progress task documents created by `/work create`. Each file represents an active work item with objective, plan, progress markers, and resume context. `/work complete` moves finished items to their permanent location in `docs/`.
+Work-in-progress task documents managed by `/work`. Each file represents an active work item with objective, plan, progress markers, and resume context. When all steps are complete, the agent suggests finalizing the task, which moves finished items to their permanent location in `docs/`.
 
 This directory is NOT deployed -- it is filtered out during the doc scan in `elevasis-sdk deploy`.
 
@@ -112,7 +112,7 @@ Only `src/` and `docs/` are scaffolded by `elevasis-sdk init`. The following dir
 | `src/example/`         | `elevasis-sdk init` (default)    | Always -- echo starter workflow lives here (replace with your own) |
 | `src/shared/`          | `elevasis-sdk init` (default)    | Always -- cross-domain shared utilities (starts empty)             |
 | `docs/`                | `elevasis-sdk init` (default)    | Always                                                             |
-| `docs/in-progress/`    | Agent (on first `/work create`)  | When you create a task doc for in-progress work                    |
+| `docs/in-progress/`    | Agent (on first `/work`)         | When you create a task doc for in-progress work                    |
 | `docs/project-map.mdx` | `elevasis-sdk deploy`            | Auto-generated on every deploy                                     |
 | `docs/priorities.mdx`  | Agent (on first goal discussion) | When you discuss project goals or priorities                       |
 | `data/`                | Agent (on demand)                | When you connect a database                                        |
@@ -224,7 +224,7 @@ The `.claude/commands/` directory contains four commands covering the core devel
 
 - **`/meta`** -- Project lifecycle: init, status, fix, deploy, health
 - **`/docs`** -- Browse, create, and verify permanent documentation
-- **`/work`** -- Task tracking across sessions: list, create, save, resume, complete
+- **`/work`** -- Task tracking across sessions: auto-detects intent (create, save, resume); suggests complete
 - **`/tutorial`** -- Progressive learning path adapted to your skill profile
 
 For detailed command documentation, see [Agent System](agent).

package/reference/getting-started.mdx

@@ -31,7 +31,7 @@ my-project/
 │   │   ├── tutorial.md             # Progressive learning
 │   │   └── work.md                 # Task tracking
 │   ├── hooks/
-│   │   └── enforce-sdk-boundary.mjs # Blocks destructive commands (auto-loaded)
+│   │   └── enforce-sdk-boundary.mjs # Blocks file modifications outside project (auto-loaded)
 │   ├── scripts/
 │   │   └── statusline-command.js   # Dynamic status line script
 │   ├── skills/