@elevasis/sdk 0.5.3 → 0.5.5

package/dist/cli.cjs

@@ -43695,13 +43695,15 @@ var esbuild = __toESM(require("esbuild"), 1);
 // src/cli/config.ts
 var DEV_API_URL = "http://localhost:5170";
 var PROD_API_URL = "https://api.elevasis.io";
-function resolveApiUrl(cliOverride) {
+function resolveApiUrl(cliOverride, prod) {
   if (cliOverride) return cliOverride;
+  if (prod) return PROD_API_URL;
   if (process.env.ELEVASIS_API_URL) return process.env.ELEVASIS_API_URL;
   if (process.env.NODE_ENV === "development") return DEV_API_URL;
   return PROD_API_URL;
 }
-function resolveEnvironment() {
+function resolveEnvironment(prod) {
+  if (prod) return "production";
   return process.env.NODE_ENV === "development" ? "development" : "production";
 }
 
@@ -43785,7 +43787,7 @@ async function apiDelete(endpoint, apiUrl = resolveApiUrl()) {
 // package.json
 var package_default = {
   name: "@elevasis/sdk",
-  version: "0.5.3",
+  version: "0.5.5",
   description: "SDK for building Elevasis organization resources",
   "comment:bin": "IMPORTANT: This package shares the 'elevasis' binary name with @repo/cli. They never conflict because @elevasis/sdk must NEVER be added as a dependency of any workspace package (apps/*, packages/*, organizations/*). Workspace projects use @repo/cli for the 'elevasis' binary. External developers (outside the workspace) get this SDK's binary via npm install.",
   type: "module",
@@ -44304,10 +44306,10 @@ async function generateProjectMap(org) {
   await (0, import_promises.writeFile)((0, import_path.resolve)("docs/project-map.mdx"), lines.join("\n"), "utf-8");
 }
 function registerDeployCommand(program3) {
-  program3.command("deploy").description("Validate, bundle, upload, and deploy project resources\n  Example: elevasis deploy --api-url http://localhost:5170").option("--api-url <url>", "API URL").option("--entry <path>", "Path to entry file (default: ./src/index.ts)").action(wrapAction("deploy", async (options2) => {
+  program3.command("deploy").description("Validate, bundle, upload, and deploy project resources\n  Example: elevasis deploy --api-url http://localhost:5170").option("--api-url <url>", "API URL").option("--entry <path>", "Path to entry file (default: ./src/index.ts)").option("--prod", "Deploy to production (overrides NODE_ENV=development)").action(wrapAction("deploy", async (options2) => {
     const startTime = Date.now();
-    const apiUrl = resolveApiUrl(options2.apiUrl);
-    const env2 = resolveEnvironment();
+    const apiUrl = resolveApiUrl(options2.apiUrl, options2.prod);
+    const env2 = resolveEnvironment(options2.prod);
     const entryPath = options2.entry ?? "./src/index.ts";
     const authSpinner = ora("Authenticating...").start();
     let orgName;
@@ -45074,7 +45076,7 @@ var import_path3 = require("path");
 var import_promises2 = require("fs/promises");
 
 // src/cli/commands/templates/core/workspace.ts
-var TEMPLATE_VERSION = 21;
+var TEMPLATE_VERSION = 22;
 function configTemplate() {
   return `import type { ElevasConfig } from '@elevasis/sdk'
 
@@ -45492,6 +45494,7 @@ For detailed per-dimension adaptation rules, read
 | Command | Purpose |
 | --- | --- |
 | \`/meta\` | Project lifecycle: init, status, fix, deploy, health |
+| \`/docs\` | Browse, create, and verify permanent documentation |
 | \`/work\` | Task tracking: create, save, resume, complete |
 | \`/tutorial\` | Progressive learning path (7 core lessons + 9 modules) |
 
@@ -45575,67 +45578,57 @@ Read \`.claude/memory/tutorial-progress.md\` to check current lesson progress.
 When \`/tutorial\` is invoked:
 
 1. Read \`.claude/memory/tutorial-progress.md\` (if it exists)
-2. Display the appropriate menu:
-
-**No progress (first time):**
-
-\`\`\`
-Welcome to the Elevasis Tutorial!
-==================================
-
-What would you like to learn?
-
-1. Orchestration Concepts (Core Path)
-   Build workflows step-by-step: data schemas, platform tools,
-   multi-step flows, decision points, and production deployment.
-   7 lessons -- estimated 2-3 hours total.
+2. Display the full menu table. Fill in progress indicators from the progress file.
+3. User picks a number -> start or resume that item directly. No track gating.
 
-2. Examples & Advanced Modules
-   Hands-on deep-dives: human-in-the-loop, scheduling,
-   notifications, integrations, LLM, agents, and more.
-   9 standalone modules -- pick any order.
+Progress indicators: \`[ ]\` not started, \`[>]\` in progress, \`[x] YYYY-MM-DD\` complete.
 
-3. Meta-Framework
-   Learn the Claude Code context system: /meta, /work,
-   rules, memory, and how to customize your workspace.
-   5 lessons -- estimated 1-2 hours total.
+Example (first time, no progress):
 
-Pick a number to start, or say "status" to see your progress.
 \`\`\`
-
-**With existing progress:**
-
-Show active tracks at the top, then offer resume options alongside new choices. Example:
-
-\`\`\`
-Progress: Core Path (Lesson 4/7) | Meta-Framework (MF2/5)
-
-1. Resume Orchestration Concepts (Lesson 4)
-2. Orchestration Concepts (Core Path -- start over)
-3. Examples & Advanced Modules
-4. Resume Meta-Framework (MF2)
-5. Meta-Framework (start over)
-6. Show full status
-
-Pick a number, or describe what you'd like to learn.
+Elevasis Tutorial
+==================
+
+ORCHESTRATION CONCEPTS                              0/7
+  1  Welcome & Orientation                          [ ]
+  2  Your First Custom Workflow                     [ ]
+  3  Understanding Data (Schemas)                   [ ]
+  4  Using Platform Tools                           [ ]
+  5  Multi-Step Workflows                           [ ]
+  6  Decision Points                                [ ]
+  7  Going to Production                            [ ]
+
+EXAMPLES & ADVANCED MODULES                        0/9
+  8  Human-in-the-Loop                              [ ]
+  9  Task Scheduling                                [ ]
+ 10  Notification System                            [ ]
+ 11  Real-World Integrations                        [ ]
+ 12  Error Handling Mastery                         [ ]
+ 13  Advanced Workflows                             [ ]
+ 14  Resource Composition                           [ ]
+ 15  LLM Integration                               [ ]
+ 16  AI Agents                                     [ ]
+
+META-FRAMEWORK                                     0/5
+ 17  The Agent Framework                            [ ]
+ 18  The /meta Command                              [ ]
+ 19  /work and /docs                                [ ]
+ 20  Rules, Memory, and Customization               [ ]
+ 21  Template Lifecycle                             [ ]
+
+Pick a number to start.
 \`\`\`
 
-After user picks:
-- Orchestration Concepts: Resume or start core lesson flow
-- Examples & Advanced Modules: Show module menu (see ## Module Menu)
-- Meta-Framework: Resume or start MF1 (see ## Meta-Framework Track)
-- "status": Display Phase, current position, completion counts
+Always show this full table when \`/tutorial\` is invoked. Populate progress
+indicators from completed/current state. \`"status"\` -> show the same table.
 
 ## Progress Logic
 
 1. Read \`.claude/memory/tutorial-progress.md\`
-2. Show the menu (## Menu section) with progress summary if progress exists
-3. After user picks a track:
-   - **Orchestration Concepts**: If Completed Lessons < 7 -> start/resume at Current Lesson; if 7 complete -> note completion, offer module menu or repeat
-   - **Examples & Advanced Modules**: Show module menu (## Module Menu section)
-   - **Meta-Framework**: If Current MF Lesson is set -> resume at that lesson; otherwise start MF1
-4. Track completion: mark the track done in progress file when all lessons/modules complete
-5. If all three tracks complete -> set Phase to \`complete\`, congratulate, suggest exploring docs/ or /work
+2. Show the full menu table (## Menu) with progress filled in
+3. User picks a number -> start or resume that lesson or module directly
+4. After completion: mark done in progress file, show updated menu table
+5. All 21 items complete -> congratulate, suggest exploring docs/ or /work
 
 ## Lesson Flow
 
@@ -45643,7 +45636,7 @@ Each lesson follows this flow:
 1. Announce lesson title and what they'll learn (1-2 sentences)
 2. Explain the concept (read docs per skill level, adapt to user)
 3. Guide user to build or modify something (agent writes all code for automation: none)
-4. Verify it works (Execution Runner is primary for none; CLI + UI are equal for others)
+4. Verify it works (CLI primary for all levels; Command Center for visual review -- Command View, Execution Logs)
 5. Celebrate success, record observations in \`.claude/memory/tutorial-progress.md\`
 6. Ask: "Ready for the next lesson, or want to practice more?"
 
@@ -45657,7 +45650,7 @@ from \`reference/developer/interaction-guidance.mdx\` (recipe, assembly line, ki
 appliance). Explain deployment plainly: "You write the recipe here, then deploy it so
 it's live." Deploy the starter echo workflow (\`elevasis check\` + \`elevasis deploy\`),
 THEN tour the Command Center so the user sees populated pages, not empty ones. Tour:
-Command View (echo node), Execution Runner (run echo from form), Execution Logs (result).
+Command View (echo node), Execution Logs (result).
 Observation focus: automation value understanding, Command Center comfort.
 
 When automation is low-code or custom:
@@ -45665,7 +45658,7 @@ Tour project files: src/index.ts (registry), src/example/echo.ts (starter
 workflow), src/operations/platform-status.ts (platform API example),
 elevasis.config.ts, .env, docs/. Explain the execution model.
 Verify: run \`elevasis resources\`. Then open the Command Center and tour the
-main pages: Command View (resource graph), Execution Runner, Execution Logs.
+main pages: Command View (resource graph), Execution Logs.
 Point out the echo workflow node in Command View.
 Observation focus: cloud deployment model, UI navigation comfort.
 
@@ -45674,9 +45667,9 @@ Observation focus: cloud deployment model, UI navigation comfort.
 When automation is none:
 Frame the workflow as "a recipe." Use plain language: "settings" not "config",
 "what data it needs" not "contract", "instructions" not "steps", "where it starts"
-not "entryPoint." Agent writes all code changes. Execution Runner form is PRIMARY
-verification -- show user how to fill the form and run it. CLI is secondary:
-"here's the power user way." Observation focus: recipe-to-result connection, form comfort.
+not "entryPoint." Agent writes all code changes. Agent runs \`elevasis exec\` to verify
+and narrates the result in plain terms.
+Observation focus: recipe-to-result connection.
 
 When automation is low-code or custom:
 Modify the echo workflow. Walk through each part: config, contract, steps,
@@ -45689,25 +45682,25 @@ Observation focus: deployment-to-execution loop, TypeScript syntax comfort.
 **Lesson 3: Understanding Data (Schemas)**
 
 When automation is none:
-Frame as "What information does your automation need?" Each piece becomes a form
-field. Describe types in plain English: text, number, yes/no, a choice from a list.
-NO Zod, no z.string(), no z.infer(), no code shown. Agent reads identity.md goals
-and writes the workflow schema. User fills the form in Execution Runner to verify.
-Observation focus: data-to-form connection, required vs optional understanding.
+Frame as "What information does your automation need?" Describe types in plain English:
+text, number, yes/no, a choice from a list. NO Zod, no z.string(), no z.infer(), no
+code shown. Agent reads identity.md goals and writes the workflow schema. Agent runs
+\`elevasis exec\` with sample input and narrates the result.
+Observation focus: data-to-input connection, required vs optional understanding.
 
 When automation is low-code:
 "Field mapping like Zapier, but with validation." Show Zod types briefly. Demonstrate
-how \`.describe()\` sets the form field label. Build schema based on identity.md goals.
-After deploy, open Execution Runner and point out each field.
-Observation focus: schema-to-form connection, optional fields, types.
+how \`.describe()\` documents each field. Build schema based on identity.md goals.
+After deploy, run with \`elevasis exec --input '{...}'\` to verify each field.
+Observation focus: schema-to-input mapping, optional fields, types.
 
 When automation is custom:
 Explain schemas in plain English (concepts page). Show common Zod types.
 Explain \`z.infer\`. Build a new workflow with real-world input schema based
 on the user's goals (read .claude/memory/profile/identity.md). After deploy,
-open the Execution Runner and show how each Zod field becomes a form control.
-Point out how \`.describe()\` sets the field label.
-Observation focus: schema-to-form connection, optional fields, types.
+run with \`elevasis exec --input '{...}'\` to verify the schema and inspect
+the execution output.
+Observation focus: schema-to-input mapping, optional fields, types.
 
 **Lesson 4: Using Platform Tools**
 
@@ -45736,8 +45729,8 @@ Observation focus: credential setup (CLI + UI), async/await.
 When automation is none:
 Frame as "Step 1 passes its result to Step 2, like a relay race." Command View is
 PRIMARY teaching tool -- show the visual graph before explaining code. Agent builds
-the 2-step workflow. User verifies in Command View (see the two nodes + arrow) and
-Execution Runner (see output flow). Code is secondary.
+the 2-step workflow. Agent runs \`elevasis exec\` to verify and shows output flow.
+User opens Command View to see the two nodes + arrow. Code is secondary.
 Observation focus: relay-race concept, visual graph comprehension.
 
 When automation is low-code or custom:
@@ -45752,7 +45745,7 @@ Observation focus: data flow reasoning, relationship visualization.
 When automation is none:
 Frame as "If the customer is VIP, do this -- otherwise, do that." No StepType.CONDITIONAL
 jargon -- focus on the concept, not the implementation. Agent adds the condition.
-User tests both paths via Execution Runner, then opens Execution Logs to see which
+Agent runs \`elevasis exec\` for both paths. Open Execution Logs to see which
 path ran. Guide log navigation step-by-step.
 Observation focus: branching concept understanding, log navigation.
 
@@ -45782,18 +45775,10 @@ Observation focus: readiness for independent operation (CLI + UI).
 
 ## Module Menu
 
-Fixed module order: hitl, schedules, notifications, integrations, workflows,
-composition, llm, agents, error-handling.
-
-Show the next 2-3 uncompleted modules from the list. Format:
-
-"Core path complete! Here are your next modules:"
-1. <Title> -- <one-line description>
-2. <Title> -- <one-line description>
-3. <Title> -- <one-line description>
-"Pick a number to start, or say 'show more' to see additional modules."
+Module order (items 8-16 in the main menu): hitl, schedules, notifications,
+integrations, error-handling, workflows, composition, llm, agents.
 
-If all 9 modules are complete -> set Phase to \`complete\`, congratulate.
+After completing a module, show the updated full menu table (## Menu).
 
 ## Module Flow
 
@@ -45803,7 +45788,7 @@ Each module follows this flow:
 3. Guide user to build a resource exercising the module's concepts
 4. Verify it works (CLI + Command Center where applicable)
 5. Record observations in \`.claude/memory/tutorial-progress.md\`
-6. Return to module menu (show next uncompleted modules)
+6. Show updated full menu table (## Menu)
 
 ## Modules
 
@@ -45836,6 +45821,15 @@ Key concepts: adapter pattern, credential scoping, error handling for external c
 Verify: Run workflow with real credential, confirm external service call, test error
 handling with invalid credential.
 
+**Module: error-handling -- Error Handling Mastery**
+Read: \`reference/resources/patterns.mdx\` (error handling),
+\`reference/troubleshooting/common-errors.mdx\`.
+Build: Create a workflow demonstrating all three error types. Add try/catch,
+\`context.logger\`, and error recovery.
+Key concepts: ExecutionError, PlatformToolError, ToolingError, recovery patterns.
+Verify: Trigger each error type, confirm messages in Execution Logs with correct
+categorization.
+
 **Module: workflows -- Advanced Workflows**
 Read: \`reference/resources/patterns.mdx\` (execution store, logging, organizing).
 Build: Refactor an existing workflow to use \`context.store\` for cross-step data,
@@ -45866,15 +45860,6 @@ Compare agent vs workflow for a task.
 Key concepts: agent definition, tool registration, LLM tool calling, execution trace.
 Verify: Run agent with \`elevasis exec\`, review tool call trace in Execution Logs.
 
-**Module: error-handling -- Error Handling Mastery**
-Read: \`reference/resources/patterns.mdx\` (error handling),
-\`reference/troubleshooting/common-errors.mdx\`.
-Build: Create a workflow demonstrating all three error types. Add try/catch,
-\`context.logger\`, and error recovery.
-Key concepts: ExecutionError, PlatformToolError, ToolingError, recovery patterns.
-Verify: Trigger each error type, confirm messages in Execution Logs with correct
-categorization.
-
 ## Meta-Framework Track
 
 The Meta-Framework track teaches you how the Claude Code workspace works -- the commands,
@@ -45941,32 +45926,46 @@ CLAUDE.md and commands. Note the template access model: templates read from
 Verify: Run /meta to see project status. Identify what a version mismatch looks like.
 Observation focus: full lifecycle coverage, pipeline internals.
 
-**MF3: /work -- Task Lifecycle**
+**MF3: /work and /docs -- Task and Documentation Lifecycle**
 
 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. Show docs/ -- explain
-it's where project notes live.
+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.
-Observation focus: persistence concept, cross-session continuity.
+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).
-Explain how task docs persist: they're workspace files, not memory -- they survive
-session compaction.
-Verify: Create a task with \`/work create "practice task"\`, run /work save, inspect the file.
-Observation focus: task tracking workflow, doc creation pattern.
+Progress + Resume Context), resume (loads context for next session), complete (moves
+to permanent docs/).
+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.
 
 When automation is custom:
-Read \`.claude/commands/work.md\`. Full coverage:
+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).
-Explain how Resume Context serves as the session handoff artifact.
-Verify: Create a task doc, save progress, inspect the generated file structure.
-Observation focus: task doc anatomy, resume context as handoff pattern.
+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
+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.
 
 **MF4: Rules, Memory, and Customization**
 
@@ -46036,13 +46035,13 @@ Observation focus: full template lifecycle, conflict resolution pattern.
 
 **automation: none**
 Use the non-technical variant for each lesson. Agent writes all code -- user
-never types code. User verifies visually (Execution Runner, Command View, Logs).
-Avoid all jargon; use analogies. Execution Runner is the primary verification tool.
+never types code. Agent runs \`elevasis exec\` for verification and narrates results.
+Avoid all jargon; use analogies. CLI is the primary verification tool.
 Always deploy before directing the user to the Command Center.
 
 **automation: low-code**
 Map concepts to Zapier/Make equivalents. Show code with plain-English explanations.
-Execution Runner and CLI are equal verification tools. Show Zod types with labels.
+CLI is the primary verification tool. Show Zod types with labels.
 
 **automation: custom**
 Full technical content. Code-first. CLI and UI are equal. Condense explanations
@@ -46052,26 +46051,22 @@ for intermediate/advanced users.
 - If user is fast, acknowledge and offer to skip ahead within a lesson
 - After each lesson, update \`.claude/memory/tutorial-progress.md\`
 - If user demonstrates a level change, promote to skills.md Growth Log
-- After completing a module, return to the module menu
+- After completing a module, show the updated full menu table
 - Adapt module depth to skill level as with lessons
 
 ## Progress Format
 
 Store in \`.claude/memory/tutorial-progress.md\`:
-- Phase (core | modules | meta-framework | complete)
-- Current Lesson number (during core phase)
-- Current Module (module id during modules phase)
-- Current MF Lesson (MF1-MF5, during meta-framework phase)
+- Current (free-form, e.g. "L4: Using Platform Tools" or "M:integrations" or "MF2")
 - Started and Last Session dates
 - Completed Lessons table (lesson, title, completed, duration)
 - Completed Modules table (module, title, completed, duration)
 - Completed MF Lessons table (lesson, title, completed, notes)
-- Capability Observations table (lesson/module, observation) -- prefix L# for lessons, M:<id> for modules, MF# for meta-framework lessons
+- Capability Observations table (source, observation) -- prefix L# for lessons, M:<id> for modules, MF# for MF lessons
 - Assessment Notes (bullet points)
 
-Backward-compatible: missing Phase is inferred from lesson count;
-missing Completed Modules is treated as empty;
-missing Completed MF Lessons is treated as empty.
+Backward-compatible: missing Completed Modules treated as empty;
+missing Completed MF Lessons treated as empty.
 `;
 }
 function claudeMetaCommandTemplate() {
@@ -46192,6 +46187,7 @@ Detect and repair all drift. Optionally upgrades the SDK first.
    c. Flag mismatches between documented schemas and actual resource definitions
    d. Check for undocumented resources (resources in src/ without docs coverage)
    e. Report discrepancies with suggested fixes
+   Note: \`/docs verify\` is available for standalone interactive verification outside this pipeline.
 6. **Settings consistency:** Verify expected fields
 7. **Rules health:** Scan \`memory/errors/\` -- flag any entry that has recurred
    3+ times and is not yet in \`.claude/rules/workspace-patterns.md\`.
@@ -46406,6 +46402,173 @@ Mark task complete, clean up, and move to permanent docs:
 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() {
+  return `# /docs command
+
+You are a documentation assistant for this Elevasis workspace. \`/docs\` manages the
+permanent \`docs/\` tree -- browsing, creating reference content, and verifying accuracy
+against code.
+
+**Scope:** Everything in \`docs/\` EXCEPT:
+- \`docs/in-progress/\` -- \`/work\`'s territory
+- \`docs/project-map.mdx\` and \`docs/resource-map.mdx\` -- auto-generated, read-only
+
+## Context
+
+Read \`.claude/memory/profile/skills.md\` first. The \`automation\` skill level controls
+how results are presented.
+
+## Operations
+
+### \`/docs\` (no arguments) -- Browse
+
+Scan \`docs/\` recursively. Display:
+
+\`\`\`
+Your Docs
+=========
+
+Auto-generated (read-only):
+  project-map.mdx      Updated 2026-03-03
+  resource-map.mdx     Updated 2026-03-03
+
+Reference (3):
+  1. index.mdx              Workspace overview
+  2. priorities.mdx         Current priorities
+  3. crm-integration/       CRM integration guide (2 files)
+
+Pick a number to read and discuss, or say:
+  "create" to write a new doc
+  "verify" to check docs against current code
+\`\`\`
+
+Steps:
+1. Scan \`docs/\` recursively for \`.mdx\` files, excluding \`in-progress/\`
+2. Separate auto-generated files (\`project-map.mdx\`, \`resource-map.mdx\`) into a
+   read-only group -- show modification date, no number
+3. Number all user-maintained docs. For directories, show \`index.mdx\` as primary
+   with file count
+4. Sort: \`index.mdx\` first, \`priorities.mdx\` second, then alphabetical
+5. When user picks a number: read the file and present a summary. Ask what they
+   want -- discuss, update, or go back
+6. If only auto-generated files and \`index.mdx\` exist, suggest: "Your docs/ is
+   mostly empty. Run \`/docs create\` to add reference documentation."
+
+**automation: none** -- Frame as "your project's knowledge base." Plain language:
+"These are your project's permanent notes. Pick one to read or discuss."
+
+**automation: low-code** -- Standard presentation. Map to "like a wiki for your automations."
+
+**automation: custom** -- Compact. Show file sizes and last-modified dates.
+
+---
+
+### \`create [description]\` -- Reference Doc Creation
+
+Interview-driven creation for permanent documentation. Task docs go through \`/work create\`.
+
+1. If no description given, ask: "What do you want to document?"
+2. Determine doc type (infer or ask):
+   - **Resource guide** -- documents a specific workflow or agent
+   - **Integration guide** -- how a specific external tool is used
+   - **Architecture notes** -- design decisions, system diagrams
+   - **Process doc** -- operational procedures, runbooks
+   - **General reference** -- glossaries, onboarding, anything else
+3. If the doc is about a specific resource: scan \`src/\` for matching resource IDs.
+   If found, pre-populate with resource config, schemas, step names, and platform
+   tools used. The user does not need to describe what the resource does.
+4. Determine placement:
+   - Scan \`docs/\` for existing directories related to the topic
+   - If related to an existing directory, propose adding to it
+   - If the topic may grow into multiple files, create \`docs/<slug>/index.mdx\`
+   - If small and standalone, create \`docs/<slug>.mdx\`
+5. Create with proper frontmatter:
+   \`\`\`yaml
+   ---
+   title: Guide Title
+   description: What this covers
+   ---
+   \`\`\`
+   Sections by doc type:
+   - **Resource guide:** Overview, Input/Output, How It Works, Platform Tools Used, Configuration
+   - **Integration guide:** Overview, Setup (credentials), Data Model, Usage Patterns, Troubleshooting
+   - **Architecture notes:** Context, Decision, Consequences, Alternatives Considered
+   - **Process doc:** Purpose, Prerequisites, Steps, Recovery
+   - **General reference:** determined by content
+6. Report what was created and suggest next steps.
+
+**automation: none** -- Agent writes the full doc from code analysis. User reviews and
+approves. "I've written a guide for your CRM integration based on the code. Take a look
+and tell me if anything is missing."
+
+**automation: low-code** -- Agent drafts, highlights sections the user should customize.
+Shows what was auto-detected vs what needs human input.
+
+**automation: custom** -- Agent scaffolds structure and fills in code-derived content.
+Leaves technical prose to the user. Concise.
+
+---
+
+### \`verify [file?]\` -- Interactive Documentation Verification
+
+Standalone interactive version of \`/meta fix\` step 5. Checks docs against current code.
+
+**Without argument -- verify all:**
+
+1. Scan \`docs/\` for user-maintained \`.mdx\` files (skip \`in-progress/\`,
+   \`project-map.mdx\`, \`resource-map.mdx\`)
+2. For each file: cross-reference resource IDs, schema fields, and platform tools
+   mentioned against \`src/\`
+3. Check for undocumented resources: resources in \`src/\` without docs coverage
+4. Present results interactively:
+
+\`\`\`
+Docs Verification
+=================
+
+crm-integration/index.mdx:
+  - Line 23: references resourceId "attio-sync" but src/ has "attio-sync-v2"
+  - Line 45: schema field "companyName" no longer exists in input schema
+
+onboarding-guide.mdx:
+  - No issues found
+
+Undocumented resources (2):
+  - email-sender (src/communications/email-sender.ts)
+  - lead-scorer (src/scoring/lead-scorer.ts)
+
+Fix crm-integration issues now? (yes/no/skip)
+\`\`\`
+
+5. When user says yes: read source code, apply fixes to doc, show the diff
+6. For undocumented resources: offer to create a doc for each one (invokes \`create\` flow)
+
+**With argument -- verify one file:**
+
+Same but scoped to a single file. Resolves by substring match against \`docs/\` file names.
+
+\`\`\`
+/docs verify crm-integration
+\`\`\`
+
+**automation: none** -- Plain language: "Your CRM guide mentions a field called
+'companyName' but that field was renamed to 'company'. Want me to fix it?"
+
+**automation: low-code** -- Standard presentation with suggested fixes.
+
+**automation: custom** -- Compact diff-style. Auto-fix obvious issues, ask only for
+ambiguous ones.
+
+---
+
+## What /docs Does NOT Do
+
+- Touch \`docs/in-progress/\` -- \`/work\`'s territory
+- Handle task lifecycle (planned / in-progress / complete)
+- Edit \`project-map.mdx\` or \`resource-map.mdx\` -- auto-generated, read-only
+- Replace \`/meta fix\` step 5 -- it supplements it with interactivity
+`;
+}
 function claudeCredsSkillTemplate() {
   return `---
 name: creds
@@ -46871,6 +47034,7 @@ function getManagedTemplates(ctx = {}) {
     ".claude/commands/tutorial.md": claudeTutorialCommandTemplate,
     ".claude/commands/meta.md": claudeMetaCommandTemplate,
     ".claude/commands/work.md": claudeWorkCommandTemplate,
+    ".claude/commands/docs.md": claudeDocsCommandTemplate,
     ".claude/skills/creds/SKILL.md": claudeCredsSkillTemplate,
     ".claude/rules/sdk-patterns.md": claudeSdkPatternsRuleTemplate,
     ".claude/rules/docs-authoring.md": claudeDocsAuthoringRuleTemplate,
@@ -47077,6 +47241,7 @@ var MANAGED_FILES = [
   ".claude/commands/tutorial.md",
   ".claude/commands/meta.md",
   ".claude/commands/work.md",
+  ".claude/commands/docs.md",
   ".claude/skills/creds/SKILL.md",
   ".claude/rules/sdk-patterns.md",
   ".claude/rules/docs-authoring.md",
@@ -47142,6 +47307,7 @@ function registerInitCommand(program3) {
       ".claude/commands/tutorial.md": claudeTutorialCommandTemplate(),
       ".claude/commands/meta.md": claudeMetaCommandTemplate(),
       ".claude/commands/work.md": claudeWorkCommandTemplate(),
+      ".claude/commands/docs.md": claudeDocsCommandTemplate(),
       ".claude/skills/creds/SKILL.md": claudeCredsSkillTemplate(),
       ".claude/rules/sdk-patterns.md": claudeSdkPatternsRuleTemplate(),
       ".claude/rules/workspace-patterns.md": claudeWorkspaceRulesTemplate(),

package/dist/index.d.ts

@@ -3426,6 +3426,7 @@ interface UpdateContactParams {
 }
 type UpsertContactParams = CreateContactParams;
 interface ContactFilters {
+    listId?: string;
     qualification?: 'qualified' | 'disqualified' | 'pending';
     openingLineIsNull?: boolean;
 }