@notis_ai/cli 0.2.17 → 0.2.19

package/dist/base-skills/notis-cli/.notis-base-skill.json

@@ -0,0 +1 @@
+{"schema":1,"stamp":1792843001,"commit":"974cae565cf52fde4d5a93fb0502c52b83e2abf9"}

package/dist/base-skills/notis-cli/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: notis-cli
-description: Use when agents should work through the Notis CLI, especially to develop Notis apps locally or to access Notis, Composio, or MCP tools they do not currently have loaded directly.
-feature_flag: cli_access
+description: Use when agents should work through the Notis CLI, especially to develop Notis Spaces locally or to access Notis, Composio, or MCP tools they do not currently have loaded directly.
 mcp_resource: true
-mcp_tool_patterns: []
+mcp_tool_patterns: ["LOCAL_NOTIS_GET_INTELLIGENCE_POLICY"]
+mcp_references: ["references/app-delivery.md", "references/tool-examples.md", "references/native-databases.md", "references/troubleshooting.md", "references/intelligence.md"]
 ---
 
 # Notis CLI Skill
@@ -12,14 +12,13 @@ Use this skill when the user wants work done through the Notis CLI.
 
 This skill covers two main CLI workflows:
 
-1. Developing Notis apps locally.
+1. Developing Notis Spaces (views, their source and linked Skills) locally.
 2. Accessing Notis, Composio, and MCP tools through the CLI.
-
 ## When to use this skill
 
 Activate this skill when:
 
-- the user wants to init, develop, build, verify, link, pull, or deploy a Notis app through the CLI
+- the user wants to init, pull, build, verify, preview, deploy or promote a Notis Space through the CLI
 - the current agent does not have the tool it needs in its direct tool list
 - the user wants direct MCP access through Notis
 - the user wants to use an integration-backed capability through Notis rather than a first-class local tool
@@ -29,7 +28,7 @@ Use the registry-resolved published npm package everywhere:
 
 - `npx --package @notis_ai/cli@latest -- notis ...`
 
-Always use this NPX command form so the agent runs the current published CLI. In hosted shells, the CLI is pre-authenticated through `NOTIS_JWT`. On a local machine the CLI holds its own OAuth grant: `notis login` authorizes one in the browser, and signing in to the Notis desktop app authorizes one automatically for that account. Either way the grant belongs to the CLI, which refreshes it without the desktop app running.
+Always use this NPX command form so the agent runs the current published CLI, with one exception: on the Notis Cloud Computer (home folder `/vercel/sandbox`) the CLI is preinstalled and kept current, so run `notis ...` there with the same arguments, and use the NPX form only if `notis` is not found. Parallel NPX runs reinstall the package and can break each other. In hosted shells, the CLI is pre-authenticated through `NOTIS_JWT`. On a local machine the CLI holds its own OAuth grant: `notis login` authorizes one in the browser, and signing in to the Notis desktop app authorizes one automatically for that account. Either way the grant belongs to the CLI, which refreshes it without the desktop app running.
 
 `@latest` is correct for every account, including beta ones. Each deployment reports which published build belongs to it, `notis login` pins that on the profile, and a later run that finds itself on the wrong build hands the invocation to the right one before doing anything. Never substitute a channel by hand: pinning `@beta` on a production profile is how a machine ends up running a build its API does not expect. `notis doctor` reports the active channel, and `NOTIS_CLI_AUTO_CHANNEL=0` turns the hand-off off for a run.
 
@@ -39,11 +38,13 @@ The CLI bundles this `notis-cli` base skill and refreshes its canonical copy und
 
 A profile is one account paired with one API endpoint. Profiles live side by side; switching between them never signs any of them out.
 
-- `npx --package @notis_ai/cli@latest -- notis profile list` — every profile on this machine, with its endpoint, user, and whether it is signed in. The active one is marked.
-- `npx --package @notis_ai/cli@latest -- notis profile use <name>` — change which account subsequent commands run as.
-- `npx --package @notis_ai/cli@latest -- notis --profile <name> <command>` — run a single command as another account without changing the active one.
-- `npx --package @notis_ai/cli@latest -- notis login --profile <name>` — add an account. The existing profiles keep their credentials.
-- `npx --package @notis_ai/cli@latest -- notis logout` — sign out of the active profile only; pass `--all-profiles` to clear every one.
+Notis Desktop signs the CLI in for every account saved in the app, one profile each. `default` keeps its name; each added account gets a profile named after its email with `@` turned into `-` (for example `flo-mindtheflo.com`), and Beta Desktop adds `-beta`. Switching accounts in Desktop never changes the active profile. Only the active profile's skills are linked into Claude Code, Codex and Cursor; every other account's skills sync into their own folder. Signing an account out of Desktop signs it out of the CLI on this computer and removes the profile and skills Desktop made for it. If that was the active profile, the CLI switches to the account Desktop opens next; with no other signed-in Desktop account it stays signed out. Profiles made with `notis login` are never removed or picked automatically.
+
+- `npx --package @notis_ai/cli@latest -- notis profile list`: every profile on this machine, with its endpoint, user, and whether it is signed in. The active one is marked.
+- `npx --package @notis_ai/cli@latest -- notis profile use <name>`: change which account subsequent commands run as, and link that account's skills into the agent folders straight away.
+- `npx --package @notis_ai/cli@latest -- notis --profile <name> <command>`: run a single command as another account without changing the active one.
+- `npx --package @notis_ai/cli@latest -- notis login --profile <name>`: add an account. The existing profiles keep their credentials.
+- `npx --package @notis_ai/cli@latest -- notis logout`: sign this computer out of the active profile only; the account stays signed in on other computers. Pass `--all-profiles` to clear every profile on this computer.
 
 Read the profile before acting on the user's data. `notis whoami` reports the account and endpoint a command will hit; if that is not the account the user meant, switch profiles rather than proceeding.
 
@@ -71,146 +72,15 @@ This is especially important when:
 
 Treat the Notis CLI the same way you would treat a Composio-style tool router flow: discover what is available first, then execute the right tool through the CLI.
 
-## Section 1: Developing Notis Apps
-
-Use this section when the goal is to create or update a Notis app from a local
-workspace or a hosted sandbox.
-
-Notis apps are Vite + React projects using `@notis/sdk`. After init or pull and editing, choose one terminal branch: local Desktop uses `dev → build → verify → user approval → deploy`; hosted sandbox uses `build → verify → identity/schema reconciliation → deploy`; Store submission is a later, separately confirmed action.
-
-Important: `deploy` only updates the installed app artifact for the current user or team. Store submission is a separate, user-gated step. After the user explicitly confirms that the current App Details page and Store listing are ready, `apps publish --confirm-ready` submits the matching deployed version through the backend review flow.
-
-Choose the execution path before changing the app:
-
-- **Hosted sandbox**: a sandbox instruction or `/vercel/sandbox` working tree
-  proves that Desktop cannot mount the source. Do not run `apps dev`. A create
-  or edit request authorizes `apps deploy` after `apps build` and automated
-  `apps verify` pass unless the user explicitly requests preview-only,
-  read-only, or no deployment; inspection, review, and diagnosis stay
-  read-only. `apps pull <app-id>` links an existing app. Test before any remote
-  mutation. If an opt-out applies, stop there without create/link, database
-  mutation, deploy, or post-deploy checks. Otherwise, for a new unlinked app,
-  compare profile state and `apps list --json` with the canonical
-  `notis.config.ts` `name` and intended personal/team scope: link one exact
-  editable non-development match after a metadata-only (`include_documents:
-  false`) detail read proves scope, fail on any ambiguity/development
-  collision/scope mismatch, or create only on zero exact matches. Default new
-  apps to personal scope unless the user explicitly asks for team scope. Prove
-  canonicalizing the config title yields its name. For personal creation, run
-  `apps create "<canonical-config-title>" . --json` exactly once. For explicit
-  team scope, discover/describe and dry-run `LOCAL_NOTIS_CREATE_APP`, execute it
-  exactly once with team visibility and verified current team scope, verify the
-  returned identity/scope, and link that exact id. In a fresh sandbox, install Agent Browser with `npm exec --yes --package
-  agent-browser@latest -- agent-browser install` and run verification through
-  `npx --yes --package @notis_ai/cli@latest --package agent-browser@latest --
-  notis apps verify`. Read back the exact app id/version and Portal URL with `apps list --json`, run
-  the same combined command with `apps verify --mode live`, and return the exact
-  Portal URL. Stop before deployment on test failure and before retry on an
-  outcome-unknown create or deploy.
-- **Local computer**: run `apps dev`, let the user test the DEV-badged app, and
-  deploy that development identity directly only after the user explicitly
-  asks; never run `apps create` after `apps dev`.
-
-### App development workflow
-
-1. Scaffold a new app (every published Store app is a scaffold; `notis apps scaffolds list [--search <term>]` lists them from the public registry, and `--from <slug>` downloads that app's source):
-   - `npx --package @notis_ai/cli@latest -- notis apps init ["My App"] [--from <slug>]`
-2. Or pull an existing app's source to edit it (the project is linked automatically):
-   - `npx --package @notis_ai/cli@latest -- notis apps pull <app-id>`
-   - then run `npm install`, increment `notisAppVersion`, and edit
-3. **Local Desktop branch:** run `apps dev` for live testing, confirm the DEV
-   app and root/mount acceptance checks, then run `apps build` and `apps verify`.
-   Let the user test the DEV app and stop for explicit user approval. When
-   approved, run exactly one `apps deploy` to promote the existing `dev_app_id`
-   (or update the already linked app), then read it back. Never run `apps create`
-   after `apps dev`.
-4. **Hosted sandbox branch:** bootstrap Agent Browser as described above, then
-   run `apps build` followed by the automated hosted `apps verify`. If automatic
-   deployment is opted out, stop after those tests with no app create/link,
-   database mutation, deploy, or post-deploy check. Otherwise, for a new hosted
-   app, reconcile `.notis/state.json` and `apps list --json` against
-   the canonical config `name` and intended scope (personal by default; team
-   only when explicitly requested). Include
-   development rows as collision checks. Link one exact editable non-dev match
-   only after a metadata-only (`include_documents: false`) exact app detail
-   proves scope; fail on multiple/scope mismatch, or create only on zero. Prove
-   canonicalize(config title) equals config name. For personal creation, run
-   `apps create "<canonical-config-title>" . --json` exactly once and verify id,
-   slug, edit permission, and personal scope. For explicit team scope, discover
-   and describe `LOCAL_NOTIS_CREATE_APP`, dry-run it, then execute it exactly once
-   with the canonical title, team visibility, and verified current team scope;
-   verify id/slug/team scope/edit permission and `apps link` that exact id. Then
-   compare declared databases, mutate only
-   missing/changed backward-compatible schemas with ownership proof, run exactly
-   one `apps deploy`, and read back id/version/Portal URL before live verify.
-5. Check project health:
-   - `npx --package @notis_ai/cli@latest -- notis apps doctor`
-6. Only after the user explicitly approves the current Store preview, submit the deployed version:
-   - `npx --package @notis_ai/cli@latest -- notis apps publish --confirm-ready`
-
-### App development rules
-
-- Always `build` before `deploy`; run `verify` before deploy when validating an app change.
-- Never run `apps dev` in a hosted sandbox. Deploy every successfully verified
-  sandbox app create or edit unless explicitly told preview-only, read-only, or
-  no-deploy, then prove the remote id/version and live runtime. Other app tasks
-  do not authorize mutation.
-- Deploy does not create databases. Compare first; materialize only missing or
-  changed hosted-app schemas, and verify exact ownership before an update.
-- Build and verify before hosted app creation or database mutation. Only
-  backward-compatible schema expansion may happen before deployment.
-- In hosted sandboxes, bootstrap `agent-browser` and include its package on the
-  verification command's `PATH`; `--no-browser` is not a passing automated gate.
-- Never deploy a local Desktop edit until the user tests the DEV app and asks.
-- Prefer `npx --package @notis_ai/cli@latest -- notis apps deploy` for the first deploy of a project already run with `apps dev`; it promotes the development app in place.
-- Link before `deploy`, or pass `--app-id <id>` when intentionally deploying without writing local link state.
-- Use `npx --package @notis_ai/cli@latest -- notis apps doctor` to diagnose configuration or dependency issues.
-- Use `npx --package @notis_ai/cli@latest -- notis apps list --json` to discover exact slugs, permissions, versions, and Portal links before linking and after deployment; use a metadata-only (`include_documents: false`) exact app-detail read to prove personal/team scope without materializing databases.
-- Never treat deploy approval as Store approval. Set visibility to Team or Public first, then run `apps publish --confirm-ready` only after the user explicitly confirms the current App Details page and Store listing.
-- `apps publish --confirm-ready` submits the deployed snapshot through the same backend review flow as App Details. It must reject missing confirmation, incomplete listing media, a local/deployed version mismatch, private visibility, or an existing pending review.
-
-### App development command reference
-
-- `npx --package @notis_ai/cli@latest -- notis apps list` -- list accessible apps
-- `npx --package @notis_ai/cli@latest -- notis apps init` -- scaffold a new Vite + React + `@notis/sdk` project
-- `npx --package @notis_ai/cli@latest -- notis apps pull <app-id> [dir] [--force] [--source-version <n>]` -- download the persisted source snapshot for an installed app and link the local directory to that app/version; legacy apps must be redeployed once with the current CLI before they can be pulled
-- `npx --package @notis_ai/cli@latest -- notis apps dev` -- discover local apps, register desktop-local dev sessions, and load them as DEV-badged Workspace rows in the Electron Portal
-- `npx --package @notis_ai/cli@latest -- notis apps build` -- compile the production artifact
-- `npx --package @notis_ai/cli@latest -- notis apps verify` -- headless render-smoke packaged routes before deploy
-- `npx --package @notis_ai/cli@latest -- notis apps create` -- create a fresh remote app and optionally link the local project
-- `npx --package @notis_ai/cli@latest -- notis apps link` -- associate the project with a remote app
-- `npx --package @notis_ai/cli@latest -- notis apps deploy` -- upload the artifact and editable source snapshot to the linked installed app in Notis
-- `npx --package @notis_ai/cli@latest -- notis apps deploy --direct` -- deploy directly to Supabase storage, bypassing the backend server (auto-fallback when server is down)
-- `npx --package @notis_ai/cli@latest -- notis apps publish --confirm-ready` -- submit the matching deployed version for Team or Public Store review after explicit user confirmation
-- `npx --package @notis_ai/cli@latest -- notis apps doctor` -- run project diagnostics
-
-App Details remains the visual review surface and offers the same Publish/Update action. The CLI command is for agents completing an already approved submission; it does not weaken the separate confirmation gate.
-
-If the task is specifically about app structure, runtime behavior, or database/view packaging, pair this skill with the `notis-apps` skill. Use `notis-cli` for the command workflow and `notis-apps` for the product/runtime contract.
-
-## IMPORTANT: When NOT to use tool access for app development
-
-When building or deploying a Notis app, do NOT use `npx --package @notis_ai/cli@latest -- notis tools exec` for app file operations:
-
-- Loading or saving app files -- use `npx --package @notis_ai/cli@latest -- notis apps build` and `npx --package @notis_ai/cli@latest -- notis apps deploy`
-- Linting app files -- use `npx --package @notis_ai/cli@latest -- notis apps build` which validates automatically
-- Managing app routes -- write standard Vite + React pages in `app/`, not raw JS files
-
-Database schemas are the exception: declaring a slug in `notis.config.ts` does
-not create it. Use the discovery-first native database tool workflow to
-create/update and read back each app-owned schema before deployment. Tool calls
-are also valid for testing runtime behavior after deployment.
-
-## Section 2: Accessing Tools Through the Notis CLI
-
-Use this section when the current agent does not already have the right tool and needs to reach tools through Notis.
-
-This is the main escape hatch for:
-
-- direct MCP access
-- Composio-backed integrations
-- native Notis tools that are available through the generic CLI tool bridge
-- any task where you need to discover the canonical tool name and schema before execution
+## User and repository policy takes precedence
+
+Default delivery below applies only when no more restrictive user or repository
+instruction exists. Explicit preview-only/no-deploy requests and standing requirements
+for explicit deployment consent override the default. Preserve that authority across
+local and cloud runs. For local-only work, build and run stub verification; do not
+create remote resources or deploy a Space. Use the CLI's documented
+build/verification harness. Store publication remains
+separately authorized.
 
 ### Tool access workflow
 
@@ -240,6 +110,9 @@ use `--timeout-ms 90000` for `tools toolkits`, `tools search`, `tools describe`,
 and schema-only discovery calls. If a discovery call returns `network_timeout`,
 retry that same command once with `--timeout-ms 90000`; do not start a new
 query, invent a tool name, or loop on the default 30-second command.
+The CLI itself retries dropped connections and gateway errors when repeating a
+call is safe, within that same budget, so never wrap a CLI call in your own
+retry loop ([details](references/troubleshooting.md)).
 
 Discovery is idempotent but should be bounded: run the toolkit listing once per
 task, run one natural-language search per distinct capability, and cache the
@@ -258,131 +131,29 @@ discovery request before every connected-service action.
 - Use `--reconnect` to replace an existing connection. If multiple accounts exist, select one with `--connection-id <id>`.
 - For API keys, basic auth, or other credential JSON, prefer `--credentials -` and pipe or redirect stdin. Avoid inline secrets because they can enter shell history and process listings.
 
-### Toolkit mental model
-
-Typical toolkit namespaces include:
-
-- `notis` for native Notis tools
-- `composio-*` for Composio-backed integrations
-- `mcp-*` for MCP-backed tools
-
-The pattern is:
-
-1. discover toolkits
-2. search tools
-3. inspect schema if needed
-4. execute the canonical tool
-
-### Tool access examples
-
-Find a tool:
-
-```bash
-npx --package @notis_ai/cli@latest -- notis tools toolkits
-npx --package @notis_ai/cli@latest -- notis tools search "list today's calendar events"
-```
-
-Inspect a tool before execution:
-
-```bash
-npx --package @notis_ai/cli@latest -- notis tools describe composio-googlecalendar-list_events
-npx --package @notis_ai/cli@latest -- notis tools exec composio-googlecalendar-list_events --get-schema
-```
-
-Dry-run a tool call:
-
-```bash
-npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_GET_DATABASE --dry-run --arguments '{"database_slug":"tasks"}'
-npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_QUERY --dry-run --arguments '{"database_id":"tasks-db-id","query":{"page_size":10}}'
-```
-
-Execute a tool call:
-
-```bash
-npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_GET_DATABASE --arguments '{"database_slug":"tasks"}'
-npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_QUERY --arguments '{"database_id":"tasks-db-id","query":{"page_size":10}}'
-```
-
-Connect a missing toolkit:
-
-```bash
-npx --package @notis_ai/cli@latest -- notis tools link github
-```
-
-Reconnect a credential-based toolkit without putting the secret in shell history:
-
-```bash
-npx --package @notis_ai/cli@latest -- notis tools link dataforseo --reconnect --credentials - < credentials.json
-```
-
-## Native database access
-
-Native Notis databases are accessed through the generic tool workflow, not a first-class database command group. Use these canonical tool names:
-
-- `LOCAL_NOTIS_DATABASE_LIST_DATABASES` -- list databases accessible to the current profile
-- `LOCAL_NOTIS_DATABASE_GET_DATABASE` -- inspect read-only metadata and schema detail
-- `LOCAL_NOTIS_DATABASE_QUERY` -- query documents from a database
-- `LOCAL_NOTIS_DATABASE_UPSERT_DATABASE` -- create or update a database schema. Every database belongs to a Notis app: creation requires the owning app's slug or id in the `app` argument (create the app first with `LOCAL_NOTIS_CREATE_APP` if needed)
-
-Example workflow before building an app:
-
-```bash
-npx --package @notis_ai/cli@latest -- notis tools search "list Notis databases"
-npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_LIST_DATABASES --arguments '{}'
-npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_GET_DATABASE --get-schema
-npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_GET_DATABASE --arguments '{"database_slug":"social_media_calendar"}'
-npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_QUERY --arguments '{"database_id":"social-media-calendar-db-id","query":{"page_size":1}}'
-```
-
-When `LOCAL_NOTIS_DATABASE_LIST_DATABASES` or `LOCAL_NOTIS_DATABASE_GET_DATABASE` returns a database ID, prefer `database_id` for `LOCAL_NOTIS_DATABASE_QUERY`; `database_slug` remains supported as a fallback.
-
-## Supporting commands
-
-- `npx --package @notis_ai/cli@latest -- notis whoami` — confirm which account and endpoint a command will target
-- `npx --package @notis_ai/cli@latest -- notis doctor` — verify CLI config, auth, routing, and API reachability before relying on the CLI
-- `npx --package @notis_ai/cli@latest -- notis describe <command...>` — get the exact command contract for first-class CLI commands
-
-## Summary
-
-Use `notis-cli` for two things:
-
-1. local app development through `npx --package @notis_ai/cli@latest -- notis apps ...`
-2. tool discovery and execution through `npx --package @notis_ai/cli@latest -- notis tools ...`
-
-Most importantly: if you do not currently have the tool you need, especially for direct MCP or integration work, use the Notis CLI instead of treating the task as blocked.
-
-## Troubleshooting
-
-### CLI returns `auth_expired` or `auth_missing`
-
-The profile's browser authorization has lapsed or was never granted. Run
-`notis login` (add `--profile <name>` when the failing profile is not the
-active one) and have the user approve the browser prompt. In JSON/agent mode
-the first hint is the exact command to run. Do not copy refresh tokens into
-commands or try to mint a credential yourself.
-
-If the profile is a `dev-*` one, the fix is to restart `./dev.sh` in the
-workspace it belongs to, or to switch to a real account profile.
-
-### Deploy fails with "network_error" or "fetch failed"
-
-The CLI defaults to the live Notis API (`https://api.notis.ai`, or
-`https://api-beta.notis.ai` when the signed-in user is on beta). Solutions:
-
-1. Run `npx --package @notis_ai/cli@latest -- notis doctor` and confirm `api_base` is a live Notis host
-2. Use `--direct` for app deploys when you only need Supabase storage upload: `npx --package @notis_ai/cli@latest -- notis apps deploy --direct`
-3. If auth looks stale, run `npx --package @notis_ai/cli@latest -- notis login` and retry
-
-Localhost backends are a Notis-developer test lane only. Do not retarget the CLI at loopback from this skill — that path is owned by `./dev.sh`, which exposes its own lease-backed `dev-*` profile.
-
-### `npx --package @notis_ai/cli@latest -- notis doctor` shows health/tool_roundtrip errors
-
-The CLI health check pings the configured live API. App development commands that are `backend_call: local` (`init`, `build`, `verify`, `link`, `doctor`) work offline. `dev`, `pull`, `create`, `list`, and normal `deploy` need the live API; `deploy --direct` can bypass it when Supabase credentials are available.
-
-### Stale bundle in the portal after deploy
-
-The portal caches app bundles by version. If you re-deploy to the same version, the portal may serve the cached old bundle. Solutions:
-
-1. Hard refresh the portal page (Cmd+Shift+R)
-2. Open browser DevTools > Application > Storage > Clear site data
-3. The bundle cache key includes version number -- incrementing the version forces a fresh load
+## Task guides
+
+Read only the guide needed for this task. Relative links resolve in the skill bundle.
+For hosted MCP, fetch the matching `notis://docs/notis-cli/references/<file>.md` URI
+with resources/read or the available Notis resource-fetch tool; the root resource
+also rewrites these links to their published URIs.
+
+- [Space delivery](references/app-delivery.md)
+- [Toolkit mental model](references/tool-examples.md)
+- [Native database access](references/native-databases.md)
+- [Supporting commands](references/troubleshooting.md)
+
+## Intelligence for skills and delegated work
+
+Skills request `low`, `medium`, or `high`, never a fixed model name. Discover the
+read-only `LOCAL_NOTIS_GET_INTELLIGENCE_POLICY` tool to obtain the shared `contract`
+and current mapping
+for `notis`, `codex`, or `claude_code` and the requested `level`. Resolve model and
+reasoning effort together at the start of each job; validate the selected options
+with the executing harness. Explicit invocation overrides win. A fixed-model
+harness may inherit and disclose that the level was not applied; an automated
+launcher needing an exact selection stops before side effects if policy is unavailable.
+Repository and installed skills consume that same response; neither needs a
+checkout-relative document. Record actual execution receipts, not the level name, as model provenance. Media
+engines remain separate capabilities selected by their tools. See
+[the intelligence contract](references/intelligence.md) for cross-environment details.

package/dist/base-skills/notis-cli/references/app-delivery.md

@@ -0,0 +1,17 @@
+# Space delivery
+
+Use the canonical `notis-spaces` skill's entrypoint and [release guide](../../notis-spaces/references/release.md).
+For hosted MCP fetch `notis://docs/notis-spaces` and `notis://docs/notis-spaces/references/release.md`.
+User/repository no-deploy and explicit-consent policies take precedence over default delivery.
+
+## IMPORTANT: When NOT to use tool access for Space development
+
+When building or deploying a Space, do NOT use `npx --package @notis_ai/cli@latest -- notis tools exec` for source operations:
+
+- Loading, building or publishing source -- use `notis spaces pull`, `spaces build`, `spaces verify`, `spaces preview`, `spaces deploy` and `spaces promote` as the release guide orders them
+- Validating views -- `spaces build` and `spaces verify` check declarations, fixtures and renders
+- Writing pages -- write standard Vite + React views with `@notis/sdk`, not raw JS files
+
+Database schemas have two routes: the native database tool (create with `links.add`
+and `main_view`), or a `create` declaration in Space source that the deploy applies
+atomically. Tool calls are also valid for testing runtime behavior after deployment.

package/dist/base-skills/notis-cli/references/intelligence.md

@@ -0,0 +1,94 @@
+# Agent intelligence levels
+
+This is one shared contract for repository skills and account-installed skills.
+Read it from the `contract` field returned by `LOCAL_NOTIS_GET_INTELLIGENCE_POLICY`,
+directly as a native tool or through the authenticated Notis CLI. The same response
+contains current harness mappings and a `contract_revision` fingerprint. No local
+repository document is a runtime prerequisite. This bundled guide is the source
+served by that lookup, not a separate environment-specific contract.
+
+Skills request **low**, **medium**, or **high**. They never maintain model names,
+version pins, family aliases, effort tables, or price scorecards. The current
+Notis runtime policy is the source of truth, on every operating system and host.
+
+## Choosing a level
+
+| Level | Work |
+| --- | --- |
+| **low** | Bounded extraction, classification against a supplied rubric, formatting, and repetitive generation from complete inputs. |
+| **medium** | Synthesis, writing and reviewing prose from supplied evidence, and moderately complex bounded work. |
+| **high** | The skill default when unspecified: complex reasoning, investigation, coding, code review, and orchestration. |
+
+These are skill defaults, not changes to account or product defaults. The user's
+explicit instruction for this invocation wins: level, exact model, effort,
+harness, or inheritance from the current session. Preserve the scope of that
+override; never save a lasting preference unless asked. Maximum-depth requests
+are invocation overrides, not a fourth Notis level.
+
+## Resolve at execution time
+
+Discover **get current Notis intelligence policy for each harness** through the
+Notis tool catalogue. The read-only tool is `LOCAL_NOTIS_GET_INTELLIGENCE_POLICY`:
+
+```bash
+npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_GET_INTELLIGENCE_POLICY \
+  --arguments '{"harness":"codex","level":"low"}'
+```
+
+Omit arguments to read all levels. Harness keys are `notis`, `codex`, and
+`claude_code`. A local Mac, Windows host, cloud sandbox, or CI runner uses the
+same contract. Cursor or another host must identify its actual execution engine;
+it must not pretend to be a supported harness based on installed binaries.
+
+The projection is generated from the backend native intelligence configuration and external-harness policy. It contains no
+second mapping. Weekly policy changes therefore require no skill edits.
+
+- Resolve **both model and reasoning effort**. Level names are not effort names.
+- Resolve once per delegated job; keep its `policy_revision` and selection stable
+  through claim, generation, retry and completion. A new job gets a fresh policy.
+- Explicit user choices override the selection; validate them with the executing
+  harness. Never substitute another model, buy API capacity, or change accounts
+  because a selection is unavailable.
+- Validate the request against advertised harness capabilities. Policy is not
+  evidence of entitlement, quota, installed support or successful execution.
+- Use native `intelligence_mode` when the Notis delegation interface supports it.
+  External launchers translate the returned selection into their supported options.
+- Do not downgrade or restart the main session to enforce a skill default.
+- A single-model harness can inherit its current configuration and disclose that
+  the requested level was not applied. Unknown or unavailable mappings are not
+  permission to guess a model. Automated launchers that require an exact selection
+  stop before claiming jobs or producing side effects and explain the missing policy.
+- Before this lookup is deployed, use a current runtime-injected policy if present;
+  otherwise use the transparent inheritance behavior above. Do not copy a temporary
+  model table into skills as a rollout workaround.
+
+## Modalities, product assertions and provenance
+
+Image, speech, video, embedding and provider-research engines are capabilities,
+not interchangeable text-reasoning levels. Skills discover the current native
+capability and let its backend select the engine. External scripts requiring an
+exact provider-specific identifier must resolve current supported configuration
+or take an explicit invocation override; they must not pass `low` as an engine ID.
+
+Test specs assert behavior against the current backend configuration, rather than
+freezing last month's model names. Preserve exact comparisons: derive the expected
+identifier from the owning policy or tool configuration, then compare the receipt.
+Do not weaken a routing test to merely check that some model name exists.
+
+Persist **the actual model that ran**, not an intelligence level. Resolve before
+claiming jobs when the identifier participates in a prompt hash or lease contract.
+Verify execution readback before certifying provenance; aliases and requested
+settings are not actual-model receipts. Preserve historical evidence and existing
+records. Do not rewrite an old receipt as today's policy.
+
+## Subscription execution
+
+A level chooses intelligence, not payment authority. Use the current harness's
+sub-agents or the user's subscription CLI. The existing direct-provider approval
+boundary remains in the workspace/account provider-approval policy.
+
+For subscription CLI subprocesses, remove provider API-key/base-URL variables
+from the child environment. Preserve native subscription credentials; never log
+out or rewrite account authentication to enforce a level. Check the harness's
+execution/authentication readback. Resolve only once per job, batch bounded items
+where appropriate, and keep existing concurrency and usage limits.

package/dist/base-skills/notis-cli/references/native-databases.md

@@ -0,0 +1,21 @@
+## Native database access
+
+Native Notis databases are accessed through the generic tool workflow, not a first-class database command group. Use these canonical tool names:
+
+- `LOCAL_NOTIS_DATABASE_LIST_DATABASES` -- list databases accessible to the current profile
+- `LOCAL_NOTIS_DATABASE_GET_DATABASE` -- inspect read-only metadata and schema detail
+- `LOCAL_NOTIS_DATABASE_QUERY` -- query documents from a database
+- `LOCAL_NOTIS_DATABASE_UPSERT_DATABASE` -- create or update a database schema. A new database is linked to a Space in the same call (`links.add`) and names its main view; change a database used in Spaces through protocol 1 with its exact Space binding target
+- `LOCAL_NOTIS_DATABASE_DELETE_DATABASE` -- permanently delete a database and all its rows by `database_id`. It is refused for every database a Space links (`database_linked_to_space`: move it instead; a database used only in one Space is deleted with that Space from the bin), for a legacy App database its App declares, and while another database relates to it or an automation is triggered by it; the error says what to remove first
+
+Example workflow before building a Space view:
+
+```bash
+npx --package @notis_ai/cli@latest -- notis tools search "list Notis databases"
+npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_LIST_DATABASES --arguments '{}'
+npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_GET_DATABASE --get-schema
+npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_GET_DATABASE --arguments '{"database_id":"<id from LIST_DATABASES>"}'
+npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_QUERY --arguments '{"protocol":1,"target":{"space_id":"<space id>","binding":"<binding id>"},"input":{"mode":"rows","page_size":1}}'
+```
+
+Most databases are used in Spaces. Such a database is read only through one of its links: `GET_DATABASE` with a bare `database_id` returns `resolved_target` (the main view's `{space_id, binding}`), and a bare-id `QUERY` answers `database_in_spaces` with every link. Reuse that exact target with `protocol: 1`. Every database lives in a Space; a `database_slug` resolves among every database you can reach, and a slug several of them share answers `database_slug_ambiguous` with each `database_id` and its Spaces.

package/dist/base-skills/notis-cli/references/tool-examples.md

@@ -0,0 +1,56 @@
+### Toolkit mental model
+
+Typical toolkit namespaces include:
+
+- `notis` for native Notis tools
+- `composio-*` for Composio-backed integrations
+- `mcp-*` for MCP-backed tools
+
+The pattern is:
+
+1. discover toolkits
+2. search tools
+3. inspect schema if needed
+4. execute the canonical tool
+
+### Tool access examples
+
+Find a tool:
+
+```bash
+npx --package @notis_ai/cli@latest -- notis tools toolkits
+npx --package @notis_ai/cli@latest -- notis tools search "list today's calendar events"
+```
+
+Inspect a tool before execution:
+
+```bash
+npx --package @notis_ai/cli@latest -- notis tools describe composio-googlecalendar-list_events
+npx --package @notis_ai/cli@latest -- notis tools exec composio-googlecalendar-list_events --get-schema
+```
+
+Dry-run a tool call:
+
+```bash
+npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_GET_DATABASE --dry-run --arguments '{"database_id":"<tasks database id>"}'
+npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_QUERY --dry-run --arguments '{"protocol":1,"target":{"space_id":"<space id>","binding":"<binding id>"},"input":{"mode":"rows","page_size":10}}'
+```
+
+Execute a tool call:
+
+```bash
+npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_GET_DATABASE --arguments '{"database_id":"<tasks database id>"}'
+npx --package @notis_ai/cli@latest -- notis tools exec LOCAL_NOTIS_DATABASE_QUERY --arguments '{"protocol":1,"target":{"space_id":"<space id>","binding":"<binding id>"},"input":{"mode":"rows","page_size":10}}'
+```
+
+Connect a missing toolkit:
+
+```bash
+npx --package @notis_ai/cli@latest -- notis tools link github
+```
+
+Reconnect a credential-based toolkit without putting the secret in shell history:
+
+```bash
+npx --package @notis_ai/cli@latest -- notis tools link dataforseo --reconnect --credentials - < credentials.json
+```