@amerged/ohmyhost-mcp 0.1.21 → 0.1.22

package/README.md

@@ -1,6 +1,6 @@
 # @amerged/ohmyhost-mcp
 
-ohmyho.st mcp client, version 0.1.21.
+ohmyho.st mcp client, version 0.1.22.
 
 ```sh
 npm install --global @amerged/ohmyhost-mcp

package/dist/{chunk-4WY7AAPR.js → chunk-NLBFEH6H.js}

@@ -8,7 +8,7 @@ var __export = (target, all) => {
 // apps/mcp/package.json
 var package_default = {
   name: "@ohmyhost/mcp",
-  version: "0.1.21",
+  version: "0.1.22",
   private: true,
   ohmyhost: {
     deployment: "production",
@@ -30651,9 +30651,9 @@ var GENERATED_SKILL_RESOURCES = Object.freeze([
     relativePath: "SKILL.md",
     uri: "skill://ohmyhost/ohmyhost-get-started/SKILL.md",
     title: "ohmyhost-get-started",
-    description: "Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through the browser sign-in, and select an organization before the first GitHub deployment. Also use it when one computer holds the logins of several ohmyho.st accounts, or a prompt names the user and organization to work as. Use for first-time installation or login; use the deployment Skill once access is ready.",
+    description: "Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through the browser sign-in, and select an organization before the first GitHub deployment. Also use it when one computer holds the logins of several ohmyho.st accounts, or a prompt names the user and organization to work as, and when the customer asks how to get support. Use for first-time installation or login; use the deployment Skill once access is ready.",
     mimeType: "text/markdown",
-    text: '---\nname: ohmyhost-get-started\ndescription: Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through the browser sign-in, and select an organization before the first GitHub deployment. Also use it when one computer holds the logins of several ohmyho.st accounts, or a prompt names the user and organization to work as. Use for first-time installation or login; use the deployment Skill once access is ready.\n---\n\n# Start with ohmyho.st\n\nConnect this agent to the customer\'s account, then continue with the selected GitHub app.\n\n## How to talk to the customer here\n\n- One action per message, in short plain sentences. Give the link, then what they will see.\n- Write in the language the customer writes in. Translate the message templates below; copy no\n  other sentence from this file into the chat.\n- Keep customer-facing messages focused on the action and why it is needed. Avoid narrating\n  routine internal steps; explain an actual limitation when it prevents the requested work.\n- Wait for required browser input before taking actions that depend on it. Independent repository\n  inspection can continue while the customer signs in; do not start another sign-in for the same\n  account or repeat the instruction without new information. Respect the customer\'s existing authorization and scope.\n- Never ask for a password, an email code or a token value. Never paste a credential into chat,\n  source or a command argument.\n- After they report back, verify with a command instead of trusting the report.\n\n## Step 1 \u2014 determine the state before doing anything\n\nRun these three checks first. They are cheap and decide everything that follows.\n\n```sh\nohmyhost --version\nohmyhost whoami --json\nohmyhost profile list --json\n```\n\nAlso list the MCP tools of the `ohmyho` server. A saved configuration alone is not a working connection.\nIf the customer\'s prompt names an account ("Use my ohmyho.st account user \u2026 in organization \u2026"),\nread "Several accounts on one computer" below before anything else.\n\nRead the result:\n\n| Observation                                               | State                   | Continue with    |\n| --------------------------------------------------------- | ----------------------- | ---------------- |\n| `ohmyhost` missing, or the MCP server exposes no tools    | not installed           | Step 2           |\n| `--version` is older than the published release           | outdated                | Step 2           |\n| CLI runs, `whoami` fails with `authentication_required`   | installed, signed out   | Step 3           |\n| `whoami` returns an identity with an organization         | ready                   | Step 5           |\n| `whoami` returns `next_action` instead of an organization | signed in, no workspace | Step 4           |\n| `whoami` fails with `profile_selection_required`          | several saved logins    | Several accounts |\n\n`whoami` selects the workspace itself when the customer has exactly one, so an identity that\narrives with an organization needs nothing further. It reports `next_action` only when the choice\nwould be a guess or when no workspace exists yet.\n\nIf `OHMYHOST_TOKEN` is set in this process, that token is the credential: the CLI and MCP ignore any\nsaved login. Verify its returned identity, organization and selected platform against the task,\neven if a browser is already signed in. If `whoami` succeeds for that account, go to Step 5 without\nstarting another login. If it fails, ask the customer to update the private credential source,\nnot to paste a replacement value into chat.\nDo not send them to a sign-in link, because `ohmyhost login` refuses to run while the variable is set.\n\nSay nothing about a state that needs nothing from the customer. A ready agent deploys without a\nsingle question. Report a state only in the message that also asks them to act, so they never\nreceive one message about the problem and a second one about the link.\n\n## Several accounts on one computer\n\nEach `ohmyhost login` saves one login: one user in one organization, kept in the operating\nsystem\'s credential store. `ohmyhost profile list --json` (MCP `profile_list`) shows each login\'s\nname, user and organization, never a token. There is no active login for the whole computer: with\none saved login every command uses it; with several, every command names one with\n`--profile-name NAME`, MCP tools take `profile_name`, and `OHMYHOST_PROFILE=NAME` binds a whole\nprocess or MCP server. A command with `--organization` (MCP `organization_id`) or in a checkout\nlinked for one organization uses that organization\'s login by itself. Another agent\'s choice never\nchanges which account your command runs as.\n\n- When the prompt names a user and an organization, act only as the saved login with exactly that\n  user and organization, and confirm it with `whoami --profile-name NAME` before any change. These\n  IDs are context, not credentials. Never guess an account and never use another login instead.\n- If no saved login matches, add it and send its link and code as in Step 3:\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`. If the browser is\n  signed in as another account, the login saves nothing and answers `login_account_mismatch`:\n  ask the customer to switch the browser to the named account (or use a private window), then\n  repeat the login.\n- `profile_selection_required` means several logins could run the command: ask the customer which\n  account to use. `profile_not_found` names the login to add, `profile_context_mismatch` means the\n  request contradicts its binding, organization or user, and `environment_token_context_mismatch`\n  means `OHMYHOST_TOKEN` belongs to another account.\n- A saved login never switches organizations. For another workspace, add its own login with\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`.\n  `ohmyhost logout --profile-name NAME` removes only that login.\n- `secret_set_command` takes `profile_name` like every tool and returns a command that names the\n  same login with `--profile-name` plus its user and organization (`--profile-user`,\n  `--profile-organization`); an MCP server with `OHMYHOST_TOKEN` names its key\'s user and\n  organization with `--token-user` and `--token-organization` instead. Keep those flags when you\n  run the command, so the secret is written as exactly this account. A login of that name that\n  belongs to another user or organization, for example on another computer, answers\n  `profile_context_mismatch`. The key form runs only where `OHMYHOST_TOKEN` holds a key of that\n  user and organization, never with a saved login: it answers `environment_token_required` without\n  a key and `environment_token_context_mismatch` with another account\'s key. None of these\n  refusals reads the value or sends anything.\n- Tokens stay in the operating system\'s credential store; the list of saved logins (names, users\n  and organizations, never a token) is kept in `~/.ohmyhost/profiles/`, so agents that sign in at\n  the same moment never lose each other\'s login. One environment keeps up to 64 saved logins;\n  beyond that `login` answers `profile_limit_reached` and saves nothing: ask the customer which\n  saved login to remove with `ohmyhost logout --profile-name NAME`.\n- One checkout can be linked for several organizations, one link each. With several links, name\n  the login with `--profile-name`; an older link without organization is used only after the API\n  confirms that the chosen login can see its project (`linked_project_organization_mismatch`\n  otherwise).\n- Errors that depend on the account name it in `acting_as`: `resource_not_found` with another\n  account\'s login means the wrong login, `github_connection_required` means that workspace has no\n  GitHub connection yet, and `repository_not_installed` means its GitHub App installation does not\n  cover the repository.\n\n## Step 2 \u2014 install what is missing\n\nRead <https://ohmyho.st/llms.txt> and the [CLI/MCP installation guide](https://docs.ohmyho.st/agents/mcp). Compare the installed CLI and MCP versions with the published one in <https://ohmyho.st/client-release.json> and install the published packages when they are missing or older, using the current archive URLs from that guide. An older client lacks commands the later steps use, and its failures look like platform faults.\n\nRead [harness setup](references/harness-setup.md) and register the local `ohmyhost-mcp` command with this harness\'s documented settings. Preserve other MCP servers, model choices and permission settings. Use `OHMYHOST_ENVIRONMENT=production` for CLI and MCP unless the customer explicitly selected the development platform.\n\nEvery CLI command and MCP tool is listed in [surfaces](references/surfaces.md); use it to find the exact name of a capability a customer asks for instead of guessing or assuming it is missing.\n\nReload the MCP connection after every install or upgrade, then verify `tools/list` and `resources/list`. A running server keeps the tool list it started with, so a freshly installed version is invisible until it restarts. Repeat Step 1 afterwards.\n\n## Step 3 \u2014 the customer signs in once\n\n```sh\nohmyhost login --json\n```\n\nWhen the prompt named a user and organization, add\n`--organization ORGANIZATION_ID --user USER_ID`, so nothing is saved unless the browser signs in\nas exactly that account. Each login is saved under a name derived from its organization;\n`--profile-name NAME` chooses another.\n\nWhile it waits, the command prints three things: a sign-in link, a confirmation code such as\n`ABCD-EFGH`, and how many minutes both stay valid. The sign-in page shows that same code and asks\nthe customer to confirm it. Send one message that states what you found and contains the full link,\nthe code and the validity. Then stop.\n\n> I found no valid ohmyho.st login for this account on this computer. Open this link to connect it:\n>\n> [full link exactly as printed]\n>\n> The page shows the code **[code]**. Continue only if it shows exactly this code.\n> Sign in there, or choose **Sign up** on that same page if you do not have an account yet.\n> Link and code are valid for [minutes] minutes; if the page rejects the code, say so and I will send a new one.\n> Tell me when you are done.\n\nRules for this step:\n\n- Always show the code. Every message that carries a sign-in link also carries its code, the first\n  time and after every repeated login. The customer checks it against the page; a code that\n  appears on the page but never in the chat gives them nothing to check.\n- Write the full link on its own line, exactly as the CLI printed it, so the customer sees the\n  address before opening it. Never hide it behind words like "this link" or "sign-in link" and\n  never shorten it; a bare address the chat makes clickable is fine. The customer types nothing.\n- State how long link and code are valid, taking the number from the CLI\'s own message rather than\n  inventing one.\n- Do not ask whether they have an account. The same page serves both, so naming both costs one\n  sentence and saves a round trip.\n- Sign-up is open. There is no invitation, no waitlist and no access code. Never send the customer\n  somewhere else to request access.\n- Wait for the customer. The command completes on its own once they finish; do not start a second\n  login while the first is still open.\n- A confirmation code lives only a few minutes. If it expired while they were signing up, run\n  `ohmyhost login --json` again and send the new link and the new code the same way. This is\n  expected, not a failure: do not report an error and do not suggest they did something wrong.\n\nWhen the command returns, verify and continue:\n\n```sh\nohmyhost whoami --json\n```\n\n## Step 4 \u2014 make sure a workspace is selected\n\n`login` and `whoami` select the workspace themselves when the customer has exactly one, and their\nresponse names the selected organization. They report `next_action` with several choices, and then\nthe customer decides; with no workspace at all, create the first one. `organization use` binds a\nlogin that has no organization yet; a login that already has one keeps it (use a separate login\nfor another workspace, see "Several accounts on one computer").\n\nAlways look before creating. The customer may already have a workspace from an earlier session:\n\n```sh\nohmyhost organization list --json\nohmyhost organization use --organization "$ORGANIZATION_ID" --json\n```\n\nCreate a workspace only when that list is empty, with a name the customer gave you:\n\n```sh\nohmyhost organization create --name "$ORGANIZATION_NAME" --source "$SIGNUP_SOURCE" --idempotency-key "$ORGANIZATION_REQUEST_KEY" --json\nohmyhost whoami --json\n```\n\n- `--source` is optional and is only where the customer came from. If the task mentioned a link like `https://ohmyho.st/?r=hostmebaby`, pass that single `r` value. Otherwise omit the flag. It grants nothing and is never a secret.\n- Reuse the same name, source and idempotency key after an interrupted response instead of creating a second organization.\n- Creating a workspace selects it immediately for a login that had none; `whoami` or `identity_get` confirms the selection before you create a project. A login already in another workspace keeps it, and the response names the `login` that adds one for the new workspace.\n- Over MCP, `organization_create`, `organization_list` and `organization_use` do the same and report the same `selected` workspace.\n- Creating, listing and selecting a workspace need the interactive login. An API token can do none of them, and says so.\n- Never create another workspace on your own when the customer already has one.\n- A session that selected none lists no projects: `projects_list` and `ohmyhost project list` answer `organization_required` instead of an empty page. Select a workspace, then read the list again.\n\n## Step 5 \u2014 keep access for later\n\nThe current CLI login is enough to continue; MCP uses it.\n\nFor an automation platform the customer can create a user token: `token_create`, or `ohmyhost token create`. The full value appears exactly once. Save it once to the private env file the customer chooses, mode `600`, and configure the process to load that file. Preserve existing credentials and never put the value in chat, source or a command argument.\n\n`OHMYHOST_TOKEN` overrides the saved logins in any process where it is set. A token alone runs every\ncommand in these Skills except these, which need the interactive login: `login`, `logout` (including\n`logout --revoke`), `organization create|list|use`, and `token create|list|revoke`. Run those in a\nprocess without the variable. Never delete a saved token file. A token belongs to one account and\norganization: a command that names another (`--profile-name`, `--organization`, or a checkout\nlinked for another organization) is refused with `environment_token_context_mismatch` before\nanything is sent.\n\n## Step 6 \u2014 continue with the app\n\nConfirm the selected directory and GitHub repository. Read `github_status` for the selected workspace. If it is not connected, an Owner or Admin uses `github_connect` (CLI below), opens its single `authorization_url`, then repeats the same request/key after the browser completes until the returned status is `connected`.\n\n```sh\nohmyhost github status --organization "$ORGANIZATION_ID" --json\nohmyhost github connect --organization "$ORGANIZATION_ID" --idempotency-key "$GITHUB_CONNECT_KEY" --json\n```\n\nThe one link handles the required installation/user authorization. Do not construct a second installation link, replay OAuth callbacks, or ask for an installation ID or provider token. Use the intended GitHub browser profile. A connected installation covers only its selected repositories; if one is missing, open `connection.settings_url` from status, add the repository and repeat its original source-link request/key.\n\nMCP/REST returns these objects directly. CLI JSON wraps the handoff in `authorization` and status in `github`: read `authorization.authorization_url` and `github.connection.settings_url`. For a failed or expired handoff, resolve `last_failure` and use a new connect key for the same workspace; do not poll a terminal failure forever.\n\nUse `projects_list` to reuse a project and `project_context_get` when resuming one. Preserve an existing project\'s region. For a new project, an explicit customer region wins; otherwise use a browser-location hint supplied in the customer\'s onboarding prompt and send that region explicitly. Without either, ask once for US or EU. Never infer customer location from the agent/server IP. The API default remains US; the selected region cannot change later.\n\nContinue with the **ohmyhost-deploy-github** Skill when a deployment is requested. Login, workspace creation, GitHub connection and project linking are distinct results; check each returned state rather than treating a completed browser page as deployment success.\n'
+    text: '---\nname: ohmyhost-get-started\ndescription: Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through the browser sign-in, and select an organization before the first GitHub deployment. Also use it when one computer holds the logins of several ohmyho.st accounts, or a prompt names the user and organization to work as, and when the customer asks how to get support. Use for first-time installation or login; use the deployment Skill once access is ready.\n---\n\n# Start with ohmyho.st\n\nConnect this agent to the customer\'s account, then continue with the selected GitHub app.\n\n## How to talk to the customer here\n\n- One action per message, in short plain sentences. Give the link, then what they will see.\n- Write in the language the customer writes in. Translate the message templates below; copy no\n  other sentence from this file into the chat.\n- Keep customer-facing messages focused on the action and why it is needed. Avoid narrating\n  routine internal steps; explain an actual limitation when it prevents the requested work.\n- Wait for required browser input before taking actions that depend on it. Independent repository\n  inspection can continue while the customer signs in; do not start another sign-in for the same\n  account or repeat the instruction without new information. Respect the customer\'s existing authorization and scope.\n- Never ask for a password, an email code or a token value. Never paste a credential into chat,\n  source or a command argument.\n- After they report back, verify with a command instead of trusting the report.\n\n## Step 1 \u2014 determine the state before doing anything\n\nRun these three checks first. They are cheap and decide everything that follows.\n\n```sh\nohmyhost --version\nohmyhost whoami --json\nohmyhost profile list --json\n```\n\nAlso list the MCP tools of the `ohmyho` server. A saved configuration alone is not a working connection.\nIf the customer\'s prompt names an account ("Use my ohmyho.st account user \u2026 in organization \u2026"),\nread "Several accounts on one computer" below before anything else.\n\nRead the result:\n\n| Observation                                               | State                   | Continue with    |\n| --------------------------------------------------------- | ----------------------- | ---------------- |\n| `ohmyhost` missing, or the MCP server exposes no tools    | not installed           | Step 2           |\n| `--version` is older than the published release           | outdated                | Step 2           |\n| CLI runs, `whoami` fails with `authentication_required`   | installed, signed out   | Step 3           |\n| `whoami` returns an identity with an organization         | ready                   | Step 5           |\n| `whoami` returns `next_action` instead of an organization | signed in, no workspace | Step 4           |\n| `whoami` fails with `profile_selection_required`          | several saved logins    | Several accounts |\n\n`whoami` selects the workspace itself when the customer has exactly one, so an identity that\narrives with an organization needs nothing further. It reports `next_action` only when the choice\nwould be a guess or when no workspace exists yet.\n\nIf `OHMYHOST_TOKEN` is set in this process, that token is the credential: the CLI and MCP ignore any\nsaved login. Verify its returned identity, organization and selected platform against the task,\neven if a browser is already signed in. If `whoami` succeeds for that account, go to Step 5 without\nstarting another login. If it fails, ask the customer to update the private credential source,\nnot to paste a replacement value into chat.\nDo not send them to a sign-in link, because `ohmyhost login` refuses to run while the variable is set.\n\nSay nothing about a state that needs nothing from the customer. A ready agent deploys without a\nsingle question. Report a state only in the message that also asks them to act, so they never\nreceive one message about the problem and a second one about the link.\n\n## Several accounts on one computer\n\nEach `ohmyhost login` saves one login: one user in one organization, kept in the operating\nsystem\'s credential store. `ohmyhost profile list --json` (MCP `profile_list`) shows each login\'s\nname, user and organization, never a token. There is no active login for the whole computer: with\none saved login every command uses it; with several, every command names one with\n`--profile-name NAME`, MCP tools take `profile_name`, and `OHMYHOST_PROFILE=NAME` binds a whole\nprocess or MCP server. A command with `--organization` (MCP `organization_id`) or in a checkout\nlinked for one organization uses that organization\'s login by itself. Another agent\'s choice never\nchanges which account your command runs as.\n\n- When the prompt names a user and an organization, act only as the saved login with exactly that\n  user and organization, and confirm it with `whoami --profile-name NAME` before any change. These\n  IDs are context, not credentials. Never guess an account and never use another login instead.\n- If no saved login matches, add it and send its link and code as in Step 3:\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`. If the browser is\n  signed in as another account, the login saves nothing and answers `login_account_mismatch`:\n  ask the customer to switch the browser to the named account (or use a private window), then\n  repeat the login.\n- `profile_selection_required` means several logins could run the command: ask the customer which\n  account to use. `profile_not_found` names the login to add, `profile_context_mismatch` means the\n  request contradicts its binding, organization or user, and `environment_token_context_mismatch`\n  means `OHMYHOST_TOKEN` belongs to another account.\n- A saved login never switches organizations. For another workspace, add its own login with\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`.\n  `ohmyhost logout --profile-name NAME` removes only that login.\n- `secret_set_command` takes `profile_name` like every tool and returns a command that names the\n  same login with `--profile-name` plus its user and organization (`--profile-user`,\n  `--profile-organization`); an MCP server with `OHMYHOST_TOKEN` names its key\'s user and\n  organization with `--token-user` and `--token-organization` instead. Keep those flags when you\n  run the command, so the secret is written as exactly this account. A login of that name that\n  belongs to another user or organization, for example on another computer, answers\n  `profile_context_mismatch`. The key form runs only where `OHMYHOST_TOKEN` holds a key of that\n  user and organization, never with a saved login: it answers `environment_token_required` without\n  a key and `environment_token_context_mismatch` with another account\'s key. None of these\n  refusals reads the value or sends anything.\n- Tokens stay in the operating system\'s credential store; the list of saved logins (names, users\n  and organizations, never a token) is kept in `~/.ohmyhost/profiles/`, so agents that sign in at\n  the same moment never lose each other\'s login. One environment keeps up to 64 saved logins;\n  beyond that `login` answers `profile_limit_reached` and saves nothing: ask the customer which\n  saved login to remove with `ohmyhost logout --profile-name NAME`.\n- One checkout can be linked for several organizations, one link each. With several links, name\n  the login with `--profile-name`; an older link without organization is used only after the API\n  confirms that the chosen login can see its project (`linked_project_organization_mismatch`\n  otherwise).\n- Errors that depend on the account name it in `acting_as`: `resource_not_found` with another\n  account\'s login means the wrong login, `github_connection_required` means that workspace has no\n  GitHub connection yet, and `repository_not_installed` means its GitHub App installation does not\n  cover the repository.\n\n## Step 2 \u2014 install what is missing\n\nRead <https://ohmyho.st/llms.txt> and the [CLI/MCP installation guide](https://docs.ohmyho.st/agents/mcp). Compare the installed CLI and MCP versions with the published one in <https://ohmyho.st/client-release.json> and install the published packages when they are missing or older, using the current archive URLs from that guide. An older client lacks commands the later steps use, and its failures look like platform faults.\n\nRead [harness setup](references/harness-setup.md) and register the local `ohmyhost-mcp` command with this harness\'s documented settings. Preserve other MCP servers, model choices and permission settings. Use `OHMYHOST_ENVIRONMENT=production` for CLI and MCP unless the customer explicitly selected the development platform.\n\nEvery CLI command and MCP tool is listed in [surfaces](references/surfaces.md); use it to find the exact name of a capability a customer asks for instead of guessing or assuming it is missing.\n\nReload the MCP connection after every install or upgrade, then verify `tools/list` and `resources/list`. A running server keeps the tool list it started with, so a freshly installed version is invisible until it restarts. Repeat Step 1 afterwards.\n\n## Step 3 \u2014 the customer signs in once\n\n```sh\nohmyhost login --json\n```\n\nWhen the prompt named a user and organization, add\n`--organization ORGANIZATION_ID --user USER_ID`, so nothing is saved unless the browser signs in\nas exactly that account. Each login is saved under a name derived from its organization;\n`--profile-name NAME` chooses another.\n\nWhile it waits, the command prints three things: a sign-in link, a confirmation code such as\n`ABCD-EFGH`, and how many minutes both stay valid. The sign-in page shows that same code and asks\nthe customer to confirm it. Send one message that states what you found and contains the full link,\nthe code and the validity. Then stop.\n\n> I found no valid ohmyho.st login for this account on this computer. Open this link to connect it:\n>\n> [full link exactly as printed]\n>\n> The page shows the code **[code]**. Continue only if it shows exactly this code.\n> Sign in there, or choose **Sign up** on that same page if you do not have an account yet.\n> Link and code are valid for [minutes] minutes; if the page rejects the code, say so and I will send a new one.\n> Tell me when you are done.\n\nRules for this step:\n\n- Always show the code. Every message that carries a sign-in link also carries its code, the first\n  time and after every repeated login. The customer checks it against the page; a code that\n  appears on the page but never in the chat gives them nothing to check.\n- Write the full link on its own line, exactly as the CLI printed it, so the customer sees the\n  address before opening it. Never hide it behind words like "this link" or "sign-in link" and\n  never shorten it; a bare address the chat makes clickable is fine. The customer types nothing.\n- State how long link and code are valid, taking the number from the CLI\'s own message rather than\n  inventing one.\n- Do not ask whether they have an account. The same page serves both, so naming both costs one\n  sentence and saves a round trip.\n- Sign-up is open. There is no invitation, no waitlist and no access code. Never send the customer\n  somewhere else to request access.\n- Wait for the customer. The command completes on its own once they finish; do not start a second\n  login while the first is still open.\n- A confirmation code lives only a few minutes. If it expired while they were signing up, run\n  `ohmyhost login --json` again and send the new link and the new code the same way. This is\n  expected, not a failure: do not report an error and do not suggest they did something wrong.\n\nWhen the command returns, verify and continue:\n\n```sh\nohmyhost whoami --json\n```\n\n## Step 4 \u2014 make sure a workspace is selected\n\n`login` and `whoami` select the workspace themselves when the customer has exactly one, and their\nresponse names the selected organization. They report `next_action` with several choices, and then\nthe customer decides; with no workspace at all, create the first one. `organization use` binds a\nlogin that has no organization yet; a login that already has one keeps it (use a separate login\nfor another workspace, see "Several accounts on one computer").\n\nAlways look before creating. The customer may already have a workspace from an earlier session:\n\n```sh\nohmyhost organization list --json\nohmyhost organization use --organization "$ORGANIZATION_ID" --json\n```\n\nCreate a workspace only when that list is empty, with a name the customer gave you:\n\n```sh\nohmyhost organization create --name "$ORGANIZATION_NAME" --source "$SIGNUP_SOURCE" --idempotency-key "$ORGANIZATION_REQUEST_KEY" --json\nohmyhost whoami --json\n```\n\n- `--source` is optional and is only where the customer came from. If the task mentioned a link like `https://ohmyho.st/?r=hostmebaby`, pass that single `r` value. Otherwise omit the flag. It grants nothing and is never a secret.\n- Reuse the same name, source and idempotency key after an interrupted response instead of creating a second organization.\n- Creating a workspace selects it immediately for a login that had none; `whoami` or `identity_get` confirms the selection before you create a project. A login already in another workspace keeps it, and the response names the `login` that adds one for the new workspace.\n- Over MCP, `organization_create`, `organization_list` and `organization_use` do the same and report the same `selected` workspace.\n- Creating, listing and selecting a workspace need the interactive login. An API token can do none of them, and says so.\n- Never create another workspace on your own when the customer already has one.\n- A session that selected none lists no projects: `projects_list` and `ohmyhost project list` answer `organization_required` instead of an empty page. Select a workspace, then read the list again.\n\n## Step 5 \u2014 keep access for later\n\nThe current CLI login is enough to continue; MCP uses it.\n\nFor an automation platform the customer can create a user token: `token_create`, or `ohmyhost token create`. The full value appears exactly once. Save it once to the private env file the customer chooses, mode `600`, and configure the process to load that file. Preserve existing credentials and never put the value in chat, source or a command argument.\n\n`OHMYHOST_TOKEN` overrides the saved logins in any process where it is set. A token alone runs every\ncommand in these Skills except these, which need the interactive login: `login`, `logout` (including\n`logout --revoke`), `organization create|list|use`, and `token create|list|revoke`. Run those in a\nprocess without the variable. Never delete a saved token file. A token belongs to one account and\norganization: a command that names another (`--profile-name`, `--organization`, or a checkout\nlinked for another organization) is refused with `environment_token_context_mismatch` before\nanything is sent.\n\n## Step 6 \u2014 continue with the app\n\nConfirm the selected directory and GitHub repository. Read `github_status` for the selected workspace. If it is not connected, an Owner or Admin uses `github_connect` (CLI below), opens its single `authorization_url`, then repeats the same request/key after the browser completes until the returned status is `connected`.\n\n```sh\nohmyhost github status --organization "$ORGANIZATION_ID" --json\nohmyhost github connect --organization "$ORGANIZATION_ID" --idempotency-key "$GITHUB_CONNECT_KEY" --json\n```\n\nThe one link handles the required installation/user authorization. Do not construct a second installation link, replay OAuth callbacks, or ask for an installation ID or provider token. Use the intended GitHub browser profile. A connected installation covers only its selected repositories; if one is missing, open `connection.settings_url` from status, add the repository and repeat its original source-link request/key.\n\nMCP/REST returns these objects directly. CLI JSON wraps the handoff in `authorization` and status in `github`: read `authorization.authorization_url` and `github.connection.settings_url`. For a failed or expired handoff, resolve `last_failure` and use a new connect key for the same workspace; do not poll a terminal failure forever.\n\nUse `projects_list` to reuse a project and `project_context_get` when resuming one. Preserve an existing project\'s region. For a new project, an explicit customer region wins; otherwise use a browser-location hint supplied in the customer\'s onboarding prompt and send that region explicitly. Without either, ask once for US or EU. Never infer customer location from the agent/server IP. The API default remains US; the selected region cannot change later.\n\nContinue with the **ohmyhost-deploy-github** Skill when a deployment is requested. Login, workspace creation, GitHub connection and project linking are distinct results; check each returned state rather than treating a completed browser page as deployment success.\n\nSupport runs through this agent. When the customer needs help, reports a bug or asks for a feature, submit a redacted report with `feedback_submit` (CLI `ohmyhost feedback submit`), give the customer the receipt ID and read replies later with `feedback_status`; the **ohmyhost-troubleshoot-deployment** Skill describes a good report. Point the customer to https://ohmyho.st/contact only when they cannot sign in, a billing issue names `contact_support`, or they ask about privacy or the DPA. The customer page is https://docs.ohmyho.st/support.\n'
   },
   {
     skillName: "ohmyhost-get-started",
@@ -30737,8 +30737,8 @@ function listOhmyhostSkillResources() {
 }
 
 // apps/mcp/dist/index.js
-function createOhmyhostMcpServer(name = "ohmyhost") {
-  const server = new McpServer({ name, version: package_default.version });
+function createOhmyhostMcpServer(name = "ohmyhost", instructions) {
+  const server = new McpServer({ name, version: package_default.version }, instructions === void 0 ? void 0 : { instructions });
   for (const resource of listOhmyhostSkillResources()) {
     server.registerResource(`${resource.skillName}:${resource.relativePath}`, resource.uri, {
       title: resource.title,

package/dist/index.js

@@ -2,7 +2,7 @@ import { createRequire as __ohmyhostCreateRequire } from "node:module"; const re
 import {
   createOhmyhostMcpServer,
   ohmyhostMcpHandler
-} from "./chunk-4WY7AAPR.js";
+} from "./chunk-NLBFEH6H.js";
 export {
   createOhmyhostMcpServer,
   ohmyhostMcpHandler

package/dist/stdio-main.js

@@ -26,7 +26,7 @@ import {
   serverIdentityOf,
   setNegotiatedProtocolVersion,
   validateEnvelopeMeta
-} from "./chunk-4WY7AAPR.js";
+} from "./chunk-NLBFEH6H.js";
 
 // node_modules/.pnpm/@modelcontextprotocol+server@2.0.0/node_modules/@modelcontextprotocol/server/dist/stdio.mjs
 var StdioServerTransport = class {
@@ -799,7 +799,7 @@ function exact2(v, keys) {
 // apps/product-cli/package.json
 var package_default = {
   name: "@ohmyhost/product-cli",
-  version: "0.1.21",
+  version: "0.1.22",
   private: true,
   ohmyhost: {
     deployment: "production",
@@ -6880,9 +6880,10 @@ var PLATFORM_SECRET_NAMES = /* @__PURE__ */ new Set([
   "OHMYHOST_MAIL_KEY",
   "OHMYHOST_MAIL_GATEWAY_URL"
 ]);
+var LOCAL_SERVER_INSTRUCTIONS = "Operate the user's ohmyho.st hosting account: projects, GitHub deployments, databases, domains, mail, usage and budgets. Start by reading the resource skill://ohmyhost/ohmyhost-get-started/SKILL.md and calling identity_get; read project_context_get before acting on a project. This server is also ohmyho.st support: report a bug, issue or feature request with feedback_submit, give the user the receipt ID and follow up with feedback_status (https://docs.ohmyho.st/support).";
 function createLocalOhmyhostMcpServer(dependencies) {
   const { commandPrefix } = resolveProductCliEnvironment(dependencies.environment);
-  const server = createOhmyhostMcpServer("ohmyhost-local");
+  const server = createOhmyhostMcpServer("ohmyhost-local", LOCAL_SERVER_INSTRUCTIONS);
   registerProductTool(server, dependencies, "database_compute_get", "Read current managed database size, memory, region and compute state without running SQL or waking the database. Shared Dev/Prod resolves to one physical database. A null database means no confirmed managed placement. suspend_timeout_seconds=0 uses the provider default; -1 disables scale to zero. A configured value is not proof that an in-progress resize finished. This read never resizes or changes billing.", external_exports.object({ project_id: identifier2, environment: external_exports.enum(["dev", "prod"]).default("dev") }), (client2, input) => client2.getDatabaseCompute({ projectId: input.project_id, environment: input.environment }));
   registerProductTool(server, dependencies, "database_compute_set", "Select standard or performance compute for an existing database: Free 0.25 CU/1 GB/60-second idle suspension, Paid 0.5 CU/2 GB/60-second idle suspension. First read database_compute_get and explain actual size, metered compute cost, possible brief connection interruption and that shared data changes both Dev and Prod. Require the user's decision before confirm=true. SQL data is preserved. Poll the returned operation every 60 seconds; never submit a second change while it runs. Performance requires active Paid access and selects 1 CU/4 GB/300-second idle suspension at 2.5x Paid-standard compute credits per equal active minute; the longer idle window also consumes more active time. This affects only database compute. Read organization_credits_get for the published rate and active meter first. A successful choice is remembered per physical database; automatic Free downgrades preserve it, and an explicit standard choice clears it. Mixed/uncertain transition hours waive the premium; never multiply raw CU usage again.", external_exports.object({
     project_id: identifier2,
@@ -7160,7 +7161,7 @@ function createLocalOhmyhostMcpServer(dependencies) {
     ...input.cursor === void 0 ? {} : { cursor: input.cursor },
     ...input.limit === void 0 ? {} : { limit: input.limit }
   }));
-  registerProductTool(server, dependencies, "feedback_submit", "Report a bug, suspected issue or feature request to ohmyho.st. Submit a redacted expected/actual description and minimal reproduction; never credentials, raw logs, environment dumps or personal records. Available at zero credits. Reuse the same key after uncertainty; only a returned receipt ID confirms submission, not triage or a fix.", external_exports.object({
+  registerProductTool(server, dependencies, "feedback_submit", "Report a bug, suspected issue or feature request to ohmyho.st. Submit a redacted expected/actual description and minimal reproduction; never credentials, raw logs, environment dumps or personal records. Available at zero credits. Reuse the same key after uncertainty; only a returned receipt ID confirms submission, not triage or a fix. This is ohmyho.st support for a signed-in agent: give the user the receipt ID and follow up with feedback_status (https://docs.ohmyho.st/support).", external_exports.object({
     organization_id: identifier2,
     project_id: identifier2.optional(),
     environment_id: identifier2.optional(),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@amerged/ohmyhost-mcp",
-  "version": "0.1.21",
+  "version": "0.1.22",
   "type": "module",
   "engines": {
     "node": ">=22"
@@ -24,6 +24,13 @@
   },
   "license": "Apache-2.0",
   "homepage": "https://docs.ohmyho.st/",
+  "bugs": {
+    "url": "https://docs.ohmyho.st/support"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/amerged-org/ohmyhost-mcp.git"
+  },
   "description": "ohmyho.st mcp client",
   "publishConfig": {
     "access": "public",

package/src/apps/mcp/index.ts

@@ -2,8 +2,11 @@ import mcpPackage from "../package.json" with { type: "json" };
 import { createMcpHandler, McpServer } from "@modelcontextprotocol/server";
 import { listOhmyhostSkillResources } from "@ohmyhost/agent-skills";
 
-export function createOhmyhostMcpServer(name = "ohmyhost") {
-  const server = new McpServer({ name, version: mcpPackage.version });
+export function createOhmyhostMcpServer(name = "ohmyhost", instructions?: string) {
+  const server = new McpServer(
+    { name, version: mcpPackage.version },
+    instructions === undefined ? undefined : { instructions },
+  );
   for (const resource of listOhmyhostSkillResources()) {
     server.registerResource(
       `${resource.skillName}:${resource.relativePath}`,

package/src/apps/mcp/local-server.ts

@@ -428,9 +428,14 @@ const PLATFORM_SECRET_NAMES = new Set([
   "OHMYHOST_MAIL_GATEWAY_URL",
 ]);
 
+const LOCAL_SERVER_INSTRUCTIONS =
+  "Operate the user's ohmyho.st hosting account: projects, GitHub deployments, databases, domains, mail, usage and budgets. " +
+  "Start by reading the resource skill://ohmyhost/ohmyhost-get-started/SKILL.md and calling identity_get; read project_context_get before acting on a project. " +
+  "This server is also ohmyho.st support: report a bug, issue or feature request with feedback_submit, give the user the receipt ID and follow up with feedback_status (https://docs.ohmyho.st/support).";
+
 export function createLocalOhmyhostMcpServer(dependencies: LocalOhmyhostMcpDependencies) {
   const { commandPrefix } = resolveProductCliEnvironment(dependencies.environment);
-  const server = createOhmyhostMcpServer("ohmyhost-local");
+  const server = createOhmyhostMcpServer("ohmyhost-local", LOCAL_SERVER_INSTRUCTIONS);
   registerProductTool(
     server,
     dependencies,
@@ -1078,7 +1083,7 @@ export function createLocalOhmyhostMcpServer(dependencies: LocalOhmyhostMcpDepen
     server,
     dependencies,
     "feedback_submit",
-    "Report a bug, suspected issue or feature request to ohmyho.st. Submit a redacted expected/actual description and minimal reproduction; never credentials, raw logs, environment dumps or personal records. Available at zero credits. Reuse the same key after uncertainty; only a returned receipt ID confirms submission, not triage or a fix.",
+    "Report a bug, suspected issue or feature request to ohmyho.st. Submit a redacted expected/actual description and minimal reproduction; never credentials, raw logs, environment dumps or personal records. Available at zero credits. Reuse the same key after uncertainty; only a returned receipt ID confirms submission, not triage or a fix. This is ohmyho.st support for a signed-in agent: give the user the receipt ID and follow up with feedback_status (https://docs.ohmyho.st/support).",
     z
       .object({
         organization_id: identifier,

package/src/packages/agent-skills/generated-skill-resources.ts

@@ -82,9 +82,9 @@ export const GENERATED_SKILL_RESOURCES = Object.freeze([
     uri: "skill://ohmyhost/ohmyhost-get-started/SKILL.md",
     title: "ohmyhost-get-started",
     description:
-      "Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through the browser sign-in, and select an organization before the first GitHub deployment. Also use it when one computer holds the logins of several ohmyho.st accounts, or a prompt names the user and organization to work as. Use for first-time installation or login; use the deployment Skill once access is ready.",
+      "Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through the browser sign-in, and select an organization before the first GitHub deployment. Also use it when one computer holds the logins of several ohmyho.st accounts, or a prompt names the user and organization to work as, and when the customer asks how to get support. Use for first-time installation or login; use the deployment Skill once access is ready.",
     mimeType: "text/markdown",
-    text: '---\nname: ohmyhost-get-started\ndescription: Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through the browser sign-in, and select an organization before the first GitHub deployment. Also use it when one computer holds the logins of several ohmyho.st accounts, or a prompt names the user and organization to work as. Use for first-time installation or login; use the deployment Skill once access is ready.\n---\n\n# Start with ohmyho.st\n\nConnect this agent to the customer\'s account, then continue with the selected GitHub app.\n\n## How to talk to the customer here\n\n- One action per message, in short plain sentences. Give the link, then what they will see.\n- Write in the language the customer writes in. Translate the message templates below; copy no\n  other sentence from this file into the chat.\n- Keep customer-facing messages focused on the action and why it is needed. Avoid narrating\n  routine internal steps; explain an actual limitation when it prevents the requested work.\n- Wait for required browser input before taking actions that depend on it. Independent repository\n  inspection can continue while the customer signs in; do not start another sign-in for the same\n  account or repeat the instruction without new information. Respect the customer\'s existing authorization and scope.\n- Never ask for a password, an email code or a token value. Never paste a credential into chat,\n  source or a command argument.\n- After they report back, verify with a command instead of trusting the report.\n\n## Step 1 — determine the state before doing anything\n\nRun these three checks first. They are cheap and decide everything that follows.\n\n```sh\nohmyhost --version\nohmyhost whoami --json\nohmyhost profile list --json\n```\n\nAlso list the MCP tools of the `ohmyho` server. A saved configuration alone is not a working connection.\nIf the customer\'s prompt names an account ("Use my ohmyho.st account user … in organization …"),\nread "Several accounts on one computer" below before anything else.\n\nRead the result:\n\n| Observation                                               | State                   | Continue with    |\n| --------------------------------------------------------- | ----------------------- | ---------------- |\n| `ohmyhost` missing, or the MCP server exposes no tools    | not installed           | Step 2           |\n| `--version` is older than the published release           | outdated                | Step 2           |\n| CLI runs, `whoami` fails with `authentication_required`   | installed, signed out   | Step 3           |\n| `whoami` returns an identity with an organization         | ready                   | Step 5           |\n| `whoami` returns `next_action` instead of an organization | signed in, no workspace | Step 4           |\n| `whoami` fails with `profile_selection_required`          | several saved logins    | Several accounts |\n\n`whoami` selects the workspace itself when the customer has exactly one, so an identity that\narrives with an organization needs nothing further. It reports `next_action` only when the choice\nwould be a guess or when no workspace exists yet.\n\nIf `OHMYHOST_TOKEN` is set in this process, that token is the credential: the CLI and MCP ignore any\nsaved login. Verify its returned identity, organization and selected platform against the task,\neven if a browser is already signed in. If `whoami` succeeds for that account, go to Step 5 without\nstarting another login. If it fails, ask the customer to update the private credential source,\nnot to paste a replacement value into chat.\nDo not send them to a sign-in link, because `ohmyhost login` refuses to run while the variable is set.\n\nSay nothing about a state that needs nothing from the customer. A ready agent deploys without a\nsingle question. Report a state only in the message that also asks them to act, so they never\nreceive one message about the problem and a second one about the link.\n\n## Several accounts on one computer\n\nEach `ohmyhost login` saves one login: one user in one organization, kept in the operating\nsystem\'s credential store. `ohmyhost profile list --json` (MCP `profile_list`) shows each login\'s\nname, user and organization, never a token. There is no active login for the whole computer: with\none saved login every command uses it; with several, every command names one with\n`--profile-name NAME`, MCP tools take `profile_name`, and `OHMYHOST_PROFILE=NAME` binds a whole\nprocess or MCP server. A command with `--organization` (MCP `organization_id`) or in a checkout\nlinked for one organization uses that organization\'s login by itself. Another agent\'s choice never\nchanges which account your command runs as.\n\n- When the prompt names a user and an organization, act only as the saved login with exactly that\n  user and organization, and confirm it with `whoami --profile-name NAME` before any change. These\n  IDs are context, not credentials. Never guess an account and never use another login instead.\n- If no saved login matches, add it and send its link and code as in Step 3:\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`. If the browser is\n  signed in as another account, the login saves nothing and answers `login_account_mismatch`:\n  ask the customer to switch the browser to the named account (or use a private window), then\n  repeat the login.\n- `profile_selection_required` means several logins could run the command: ask the customer which\n  account to use. `profile_not_found` names the login to add, `profile_context_mismatch` means the\n  request contradicts its binding, organization or user, and `environment_token_context_mismatch`\n  means `OHMYHOST_TOKEN` belongs to another account.\n- A saved login never switches organizations. For another workspace, add its own login with\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`.\n  `ohmyhost logout --profile-name NAME` removes only that login.\n- `secret_set_command` takes `profile_name` like every tool and returns a command that names the\n  same login with `--profile-name` plus its user and organization (`--profile-user`,\n  `--profile-organization`); an MCP server with `OHMYHOST_TOKEN` names its key\'s user and\n  organization with `--token-user` and `--token-organization` instead. Keep those flags when you\n  run the command, so the secret is written as exactly this account. A login of that name that\n  belongs to another user or organization, for example on another computer, answers\n  `profile_context_mismatch`. The key form runs only where `OHMYHOST_TOKEN` holds a key of that\n  user and organization, never with a saved login: it answers `environment_token_required` without\n  a key and `environment_token_context_mismatch` with another account\'s key. None of these\n  refusals reads the value or sends anything.\n- Tokens stay in the operating system\'s credential store; the list of saved logins (names, users\n  and organizations, never a token) is kept in `~/.ohmyhost/profiles/`, so agents that sign in at\n  the same moment never lose each other\'s login. One environment keeps up to 64 saved logins;\n  beyond that `login` answers `profile_limit_reached` and saves nothing: ask the customer which\n  saved login to remove with `ohmyhost logout --profile-name NAME`.\n- One checkout can be linked for several organizations, one link each. With several links, name\n  the login with `--profile-name`; an older link without organization is used only after the API\n  confirms that the chosen login can see its project (`linked_project_organization_mismatch`\n  otherwise).\n- Errors that depend on the account name it in `acting_as`: `resource_not_found` with another\n  account\'s login means the wrong login, `github_connection_required` means that workspace has no\n  GitHub connection yet, and `repository_not_installed` means its GitHub App installation does not\n  cover the repository.\n\n## Step 2 — install what is missing\n\nRead <https://ohmyho.st/llms.txt> and the [CLI/MCP installation guide](https://docs.ohmyho.st/agents/mcp). Compare the installed CLI and MCP versions with the published one in <https://ohmyho.st/client-release.json> and install the published packages when they are missing or older, using the current archive URLs from that guide. An older client lacks commands the later steps use, and its failures look like platform faults.\n\nRead [harness setup](references/harness-setup.md) and register the local `ohmyhost-mcp` command with this harness\'s documented settings. Preserve other MCP servers, model choices and permission settings. Use `OHMYHOST_ENVIRONMENT=production` for CLI and MCP unless the customer explicitly selected the development platform.\n\nEvery CLI command and MCP tool is listed in [surfaces](references/surfaces.md); use it to find the exact name of a capability a customer asks for instead of guessing or assuming it is missing.\n\nReload the MCP connection after every install or upgrade, then verify `tools/list` and `resources/list`. A running server keeps the tool list it started with, so a freshly installed version is invisible until it restarts. Repeat Step 1 afterwards.\n\n## Step 3 — the customer signs in once\n\n```sh\nohmyhost login --json\n```\n\nWhen the prompt named a user and organization, add\n`--organization ORGANIZATION_ID --user USER_ID`, so nothing is saved unless the browser signs in\nas exactly that account. Each login is saved under a name derived from its organization;\n`--profile-name NAME` chooses another.\n\nWhile it waits, the command prints three things: a sign-in link, a confirmation code such as\n`ABCD-EFGH`, and how many minutes both stay valid. The sign-in page shows that same code and asks\nthe customer to confirm it. Send one message that states what you found and contains the full link,\nthe code and the validity. Then stop.\n\n> I found no valid ohmyho.st login for this account on this computer. Open this link to connect it:\n>\n> [full link exactly as printed]\n>\n> The page shows the code **[code]**. Continue only if it shows exactly this code.\n> Sign in there, or choose **Sign up** on that same page if you do not have an account yet.\n> Link and code are valid for [minutes] minutes; if the page rejects the code, say so and I will send a new one.\n> Tell me when you are done.\n\nRules for this step:\n\n- Always show the code. Every message that carries a sign-in link also carries its code, the first\n  time and after every repeated login. The customer checks it against the page; a code that\n  appears on the page but never in the chat gives them nothing to check.\n- Write the full link on its own line, exactly as the CLI printed it, so the customer sees the\n  address before opening it. Never hide it behind words like "this link" or "sign-in link" and\n  never shorten it; a bare address the chat makes clickable is fine. The customer types nothing.\n- State how long link and code are valid, taking the number from the CLI\'s own message rather than\n  inventing one.\n- Do not ask whether they have an account. The same page serves both, so naming both costs one\n  sentence and saves a round trip.\n- Sign-up is open. There is no invitation, no waitlist and no access code. Never send the customer\n  somewhere else to request access.\n- Wait for the customer. The command completes on its own once they finish; do not start a second\n  login while the first is still open.\n- A confirmation code lives only a few minutes. If it expired while they were signing up, run\n  `ohmyhost login --json` again and send the new link and the new code the same way. This is\n  expected, not a failure: do not report an error and do not suggest they did something wrong.\n\nWhen the command returns, verify and continue:\n\n```sh\nohmyhost whoami --json\n```\n\n## Step 4 — make sure a workspace is selected\n\n`login` and `whoami` select the workspace themselves when the customer has exactly one, and their\nresponse names the selected organization. They report `next_action` with several choices, and then\nthe customer decides; with no workspace at all, create the first one. `organization use` binds a\nlogin that has no organization yet; a login that already has one keeps it (use a separate login\nfor another workspace, see "Several accounts on one computer").\n\nAlways look before creating. The customer may already have a workspace from an earlier session:\n\n```sh\nohmyhost organization list --json\nohmyhost organization use --organization "$ORGANIZATION_ID" --json\n```\n\nCreate a workspace only when that list is empty, with a name the customer gave you:\n\n```sh\nohmyhost organization create --name "$ORGANIZATION_NAME" --source "$SIGNUP_SOURCE" --idempotency-key "$ORGANIZATION_REQUEST_KEY" --json\nohmyhost whoami --json\n```\n\n- `--source` is optional and is only where the customer came from. If the task mentioned a link like `https://ohmyho.st/?r=hostmebaby`, pass that single `r` value. Otherwise omit the flag. It grants nothing and is never a secret.\n- Reuse the same name, source and idempotency key after an interrupted response instead of creating a second organization.\n- Creating a workspace selects it immediately for a login that had none; `whoami` or `identity_get` confirms the selection before you create a project. A login already in another workspace keeps it, and the response names the `login` that adds one for the new workspace.\n- Over MCP, `organization_create`, `organization_list` and `organization_use` do the same and report the same `selected` workspace.\n- Creating, listing and selecting a workspace need the interactive login. An API token can do none of them, and says so.\n- Never create another workspace on your own when the customer already has one.\n- A session that selected none lists no projects: `projects_list` and `ohmyhost project list` answer `organization_required` instead of an empty page. Select a workspace, then read the list again.\n\n## Step 5 — keep access for later\n\nThe current CLI login is enough to continue; MCP uses it.\n\nFor an automation platform the customer can create a user token: `token_create`, or `ohmyhost token create`. The full value appears exactly once. Save it once to the private env file the customer chooses, mode `600`, and configure the process to load that file. Preserve existing credentials and never put the value in chat, source or a command argument.\n\n`OHMYHOST_TOKEN` overrides the saved logins in any process where it is set. A token alone runs every\ncommand in these Skills except these, which need the interactive login: `login`, `logout` (including\n`logout --revoke`), `organization create|list|use`, and `token create|list|revoke`. Run those in a\nprocess without the variable. Never delete a saved token file. A token belongs to one account and\norganization: a command that names another (`--profile-name`, `--organization`, or a checkout\nlinked for another organization) is refused with `environment_token_context_mismatch` before\nanything is sent.\n\n## Step 6 — continue with the app\n\nConfirm the selected directory and GitHub repository. Read `github_status` for the selected workspace. If it is not connected, an Owner or Admin uses `github_connect` (CLI below), opens its single `authorization_url`, then repeats the same request/key after the browser completes until the returned status is `connected`.\n\n```sh\nohmyhost github status --organization "$ORGANIZATION_ID" --json\nohmyhost github connect --organization "$ORGANIZATION_ID" --idempotency-key "$GITHUB_CONNECT_KEY" --json\n```\n\nThe one link handles the required installation/user authorization. Do not construct a second installation link, replay OAuth callbacks, or ask for an installation ID or provider token. Use the intended GitHub browser profile. A connected installation covers only its selected repositories; if one is missing, open `connection.settings_url` from status, add the repository and repeat its original source-link request/key.\n\nMCP/REST returns these objects directly. CLI JSON wraps the handoff in `authorization` and status in `github`: read `authorization.authorization_url` and `github.connection.settings_url`. For a failed or expired handoff, resolve `last_failure` and use a new connect key for the same workspace; do not poll a terminal failure forever.\n\nUse `projects_list` to reuse a project and `project_context_get` when resuming one. Preserve an existing project\'s region. For a new project, an explicit customer region wins; otherwise use a browser-location hint supplied in the customer\'s onboarding prompt and send that region explicitly. Without either, ask once for US or EU. Never infer customer location from the agent/server IP. The API default remains US; the selected region cannot change later.\n\nContinue with the **ohmyhost-deploy-github** Skill when a deployment is requested. Login, workspace creation, GitHub connection and project linking are distinct results; check each returned state rather than treating a completed browser page as deployment success.\n',
+    text: '---\nname: ohmyhost-get-started\ndescription: Connect a customer agent to ohmyho.st. Determine what is already installed and signed in, guide the customer through the browser sign-in, and select an organization before the first GitHub deployment. Also use it when one computer holds the logins of several ohmyho.st accounts, or a prompt names the user and organization to work as, and when the customer asks how to get support. Use for first-time installation or login; use the deployment Skill once access is ready.\n---\n\n# Start with ohmyho.st\n\nConnect this agent to the customer\'s account, then continue with the selected GitHub app.\n\n## How to talk to the customer here\n\n- One action per message, in short plain sentences. Give the link, then what they will see.\n- Write in the language the customer writes in. Translate the message templates below; copy no\n  other sentence from this file into the chat.\n- Keep customer-facing messages focused on the action and why it is needed. Avoid narrating\n  routine internal steps; explain an actual limitation when it prevents the requested work.\n- Wait for required browser input before taking actions that depend on it. Independent repository\n  inspection can continue while the customer signs in; do not start another sign-in for the same\n  account or repeat the instruction without new information. Respect the customer\'s existing authorization and scope.\n- Never ask for a password, an email code or a token value. Never paste a credential into chat,\n  source or a command argument.\n- After they report back, verify with a command instead of trusting the report.\n\n## Step 1 — determine the state before doing anything\n\nRun these three checks first. They are cheap and decide everything that follows.\n\n```sh\nohmyhost --version\nohmyhost whoami --json\nohmyhost profile list --json\n```\n\nAlso list the MCP tools of the `ohmyho` server. A saved configuration alone is not a working connection.\nIf the customer\'s prompt names an account ("Use my ohmyho.st account user … in organization …"),\nread "Several accounts on one computer" below before anything else.\n\nRead the result:\n\n| Observation                                               | State                   | Continue with    |\n| --------------------------------------------------------- | ----------------------- | ---------------- |\n| `ohmyhost` missing, or the MCP server exposes no tools    | not installed           | Step 2           |\n| `--version` is older than the published release           | outdated                | Step 2           |\n| CLI runs, `whoami` fails with `authentication_required`   | installed, signed out   | Step 3           |\n| `whoami` returns an identity with an organization         | ready                   | Step 5           |\n| `whoami` returns `next_action` instead of an organization | signed in, no workspace | Step 4           |\n| `whoami` fails with `profile_selection_required`          | several saved logins    | Several accounts |\n\n`whoami` selects the workspace itself when the customer has exactly one, so an identity that\narrives with an organization needs nothing further. It reports `next_action` only when the choice\nwould be a guess or when no workspace exists yet.\n\nIf `OHMYHOST_TOKEN` is set in this process, that token is the credential: the CLI and MCP ignore any\nsaved login. Verify its returned identity, organization and selected platform against the task,\neven if a browser is already signed in. If `whoami` succeeds for that account, go to Step 5 without\nstarting another login. If it fails, ask the customer to update the private credential source,\nnot to paste a replacement value into chat.\nDo not send them to a sign-in link, because `ohmyhost login` refuses to run while the variable is set.\n\nSay nothing about a state that needs nothing from the customer. A ready agent deploys without a\nsingle question. Report a state only in the message that also asks them to act, so they never\nreceive one message about the problem and a second one about the link.\n\n## Several accounts on one computer\n\nEach `ohmyhost login` saves one login: one user in one organization, kept in the operating\nsystem\'s credential store. `ohmyhost profile list --json` (MCP `profile_list`) shows each login\'s\nname, user and organization, never a token. There is no active login for the whole computer: with\none saved login every command uses it; with several, every command names one with\n`--profile-name NAME`, MCP tools take `profile_name`, and `OHMYHOST_PROFILE=NAME` binds a whole\nprocess or MCP server. A command with `--organization` (MCP `organization_id`) or in a checkout\nlinked for one organization uses that organization\'s login by itself. Another agent\'s choice never\nchanges which account your command runs as.\n\n- When the prompt names a user and an organization, act only as the saved login with exactly that\n  user and organization, and confirm it with `whoami --profile-name NAME` before any change. These\n  IDs are context, not credentials. Never guess an account and never use another login instead.\n- If no saved login matches, add it and send its link and code as in Step 3:\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`. If the browser is\n  signed in as another account, the login saves nothing and answers `login_account_mismatch`:\n  ask the customer to switch the browser to the named account (or use a private window), then\n  repeat the login.\n- `profile_selection_required` means several logins could run the command: ask the customer which\n  account to use. `profile_not_found` names the login to add, `profile_context_mismatch` means the\n  request contradicts its binding, organization or user, and `environment_token_context_mismatch`\n  means `OHMYHOST_TOKEN` belongs to another account.\n- A saved login never switches organizations. For another workspace, add its own login with\n  `ohmyhost login --organization ORGANIZATION_ID --user USER_ID --json`.\n  `ohmyhost logout --profile-name NAME` removes only that login.\n- `secret_set_command` takes `profile_name` like every tool and returns a command that names the\n  same login with `--profile-name` plus its user and organization (`--profile-user`,\n  `--profile-organization`); an MCP server with `OHMYHOST_TOKEN` names its key\'s user and\n  organization with `--token-user` and `--token-organization` instead. Keep those flags when you\n  run the command, so the secret is written as exactly this account. A login of that name that\n  belongs to another user or organization, for example on another computer, answers\n  `profile_context_mismatch`. The key form runs only where `OHMYHOST_TOKEN` holds a key of that\n  user and organization, never with a saved login: it answers `environment_token_required` without\n  a key and `environment_token_context_mismatch` with another account\'s key. None of these\n  refusals reads the value or sends anything.\n- Tokens stay in the operating system\'s credential store; the list of saved logins (names, users\n  and organizations, never a token) is kept in `~/.ohmyhost/profiles/`, so agents that sign in at\n  the same moment never lose each other\'s login. One environment keeps up to 64 saved logins;\n  beyond that `login` answers `profile_limit_reached` and saves nothing: ask the customer which\n  saved login to remove with `ohmyhost logout --profile-name NAME`.\n- One checkout can be linked for several organizations, one link each. With several links, name\n  the login with `--profile-name`; an older link without organization is used only after the API\n  confirms that the chosen login can see its project (`linked_project_organization_mismatch`\n  otherwise).\n- Errors that depend on the account name it in `acting_as`: `resource_not_found` with another\n  account\'s login means the wrong login, `github_connection_required` means that workspace has no\n  GitHub connection yet, and `repository_not_installed` means its GitHub App installation does not\n  cover the repository.\n\n## Step 2 — install what is missing\n\nRead <https://ohmyho.st/llms.txt> and the [CLI/MCP installation guide](https://docs.ohmyho.st/agents/mcp). Compare the installed CLI and MCP versions with the published one in <https://ohmyho.st/client-release.json> and install the published packages when they are missing or older, using the current archive URLs from that guide. An older client lacks commands the later steps use, and its failures look like platform faults.\n\nRead [harness setup](references/harness-setup.md) and register the local `ohmyhost-mcp` command with this harness\'s documented settings. Preserve other MCP servers, model choices and permission settings. Use `OHMYHOST_ENVIRONMENT=production` for CLI and MCP unless the customer explicitly selected the development platform.\n\nEvery CLI command and MCP tool is listed in [surfaces](references/surfaces.md); use it to find the exact name of a capability a customer asks for instead of guessing or assuming it is missing.\n\nReload the MCP connection after every install or upgrade, then verify `tools/list` and `resources/list`. A running server keeps the tool list it started with, so a freshly installed version is invisible until it restarts. Repeat Step 1 afterwards.\n\n## Step 3 — the customer signs in once\n\n```sh\nohmyhost login --json\n```\n\nWhen the prompt named a user and organization, add\n`--organization ORGANIZATION_ID --user USER_ID`, so nothing is saved unless the browser signs in\nas exactly that account. Each login is saved under a name derived from its organization;\n`--profile-name NAME` chooses another.\n\nWhile it waits, the command prints three things: a sign-in link, a confirmation code such as\n`ABCD-EFGH`, and how many minutes both stay valid. The sign-in page shows that same code and asks\nthe customer to confirm it. Send one message that states what you found and contains the full link,\nthe code and the validity. Then stop.\n\n> I found no valid ohmyho.st login for this account on this computer. Open this link to connect it:\n>\n> [full link exactly as printed]\n>\n> The page shows the code **[code]**. Continue only if it shows exactly this code.\n> Sign in there, or choose **Sign up** on that same page if you do not have an account yet.\n> Link and code are valid for [minutes] minutes; if the page rejects the code, say so and I will send a new one.\n> Tell me when you are done.\n\nRules for this step:\n\n- Always show the code. Every message that carries a sign-in link also carries its code, the first\n  time and after every repeated login. The customer checks it against the page; a code that\n  appears on the page but never in the chat gives them nothing to check.\n- Write the full link on its own line, exactly as the CLI printed it, so the customer sees the\n  address before opening it. Never hide it behind words like "this link" or "sign-in link" and\n  never shorten it; a bare address the chat makes clickable is fine. The customer types nothing.\n- State how long link and code are valid, taking the number from the CLI\'s own message rather than\n  inventing one.\n- Do not ask whether they have an account. The same page serves both, so naming both costs one\n  sentence and saves a round trip.\n- Sign-up is open. There is no invitation, no waitlist and no access code. Never send the customer\n  somewhere else to request access.\n- Wait for the customer. The command completes on its own once they finish; do not start a second\n  login while the first is still open.\n- A confirmation code lives only a few minutes. If it expired while they were signing up, run\n  `ohmyhost login --json` again and send the new link and the new code the same way. This is\n  expected, not a failure: do not report an error and do not suggest they did something wrong.\n\nWhen the command returns, verify and continue:\n\n```sh\nohmyhost whoami --json\n```\n\n## Step 4 — make sure a workspace is selected\n\n`login` and `whoami` select the workspace themselves when the customer has exactly one, and their\nresponse names the selected organization. They report `next_action` with several choices, and then\nthe customer decides; with no workspace at all, create the first one. `organization use` binds a\nlogin that has no organization yet; a login that already has one keeps it (use a separate login\nfor another workspace, see "Several accounts on one computer").\n\nAlways look before creating. The customer may already have a workspace from an earlier session:\n\n```sh\nohmyhost organization list --json\nohmyhost organization use --organization "$ORGANIZATION_ID" --json\n```\n\nCreate a workspace only when that list is empty, with a name the customer gave you:\n\n```sh\nohmyhost organization create --name "$ORGANIZATION_NAME" --source "$SIGNUP_SOURCE" --idempotency-key "$ORGANIZATION_REQUEST_KEY" --json\nohmyhost whoami --json\n```\n\n- `--source` is optional and is only where the customer came from. If the task mentioned a link like `https://ohmyho.st/?r=hostmebaby`, pass that single `r` value. Otherwise omit the flag. It grants nothing and is never a secret.\n- Reuse the same name, source and idempotency key after an interrupted response instead of creating a second organization.\n- Creating a workspace selects it immediately for a login that had none; `whoami` or `identity_get` confirms the selection before you create a project. A login already in another workspace keeps it, and the response names the `login` that adds one for the new workspace.\n- Over MCP, `organization_create`, `organization_list` and `organization_use` do the same and report the same `selected` workspace.\n- Creating, listing and selecting a workspace need the interactive login. An API token can do none of them, and says so.\n- Never create another workspace on your own when the customer already has one.\n- A session that selected none lists no projects: `projects_list` and `ohmyhost project list` answer `organization_required` instead of an empty page. Select a workspace, then read the list again.\n\n## Step 5 — keep access for later\n\nThe current CLI login is enough to continue; MCP uses it.\n\nFor an automation platform the customer can create a user token: `token_create`, or `ohmyhost token create`. The full value appears exactly once. Save it once to the private env file the customer chooses, mode `600`, and configure the process to load that file. Preserve existing credentials and never put the value in chat, source or a command argument.\n\n`OHMYHOST_TOKEN` overrides the saved logins in any process where it is set. A token alone runs every\ncommand in these Skills except these, which need the interactive login: `login`, `logout` (including\n`logout --revoke`), `organization create|list|use`, and `token create|list|revoke`. Run those in a\nprocess without the variable. Never delete a saved token file. A token belongs to one account and\norganization: a command that names another (`--profile-name`, `--organization`, or a checkout\nlinked for another organization) is refused with `environment_token_context_mismatch` before\nanything is sent.\n\n## Step 6 — continue with the app\n\nConfirm the selected directory and GitHub repository. Read `github_status` for the selected workspace. If it is not connected, an Owner or Admin uses `github_connect` (CLI below), opens its single `authorization_url`, then repeats the same request/key after the browser completes until the returned status is `connected`.\n\n```sh\nohmyhost github status --organization "$ORGANIZATION_ID" --json\nohmyhost github connect --organization "$ORGANIZATION_ID" --idempotency-key "$GITHUB_CONNECT_KEY" --json\n```\n\nThe one link handles the required installation/user authorization. Do not construct a second installation link, replay OAuth callbacks, or ask for an installation ID or provider token. Use the intended GitHub browser profile. A connected installation covers only its selected repositories; if one is missing, open `connection.settings_url` from status, add the repository and repeat its original source-link request/key.\n\nMCP/REST returns these objects directly. CLI JSON wraps the handoff in `authorization` and status in `github`: read `authorization.authorization_url` and `github.connection.settings_url`. For a failed or expired handoff, resolve `last_failure` and use a new connect key for the same workspace; do not poll a terminal failure forever.\n\nUse `projects_list` to reuse a project and `project_context_get` when resuming one. Preserve an existing project\'s region. For a new project, an explicit customer region wins; otherwise use a browser-location hint supplied in the customer\'s onboarding prompt and send that region explicitly. Without either, ask once for US or EU. Never infer customer location from the agent/server IP. The API default remains US; the selected region cannot change later.\n\nContinue with the **ohmyhost-deploy-github** Skill when a deployment is requested. Login, workspace creation, GitHub connection and project linking are distinct results; check each returned state rather than treating a completed browser page as deployment success.\n\nSupport runs through this agent. When the customer needs help, reports a bug or asks for a feature, submit a redacted report with `feedback_submit` (CLI `ohmyhost feedback submit`), give the customer the receipt ID and read replies later with `feedback_status`; the **ohmyhost-troubleshoot-deployment** Skill describes a good report. Point the customer to https://ohmyho.st/contact only when they cannot sign in, a billing issue names `contact_support`, or they ask about privacy or the DPA. The customer page is https://docs.ohmyho.st/support.\n',
   },
   {
     skillName: "ohmyhost-get-started",