manigent 1.3.1__py3-none-any.whl

manigent/_manigent_plugin/skills/login/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: login
+description: >
+  Log in to a manigent server and persist the session on this machine so
+  follow-up commands (`manigent assistant register`, `manigent agent
+  install`, `manigent start`) don't need credentials again. Use when users
+  say "log in", "login", "sign in", "remember me", or "switch user".
+---
+
+# Login
+
+Log in to a Manigent server and save the session locally.
+
+Saves a JWT into `~/.manigent/config/{username}/settings.json` and points
+`current_user` at this account. The next two natural steps are
+`/manigent:register-assistant` (create your assistant) and `/manigent:start`
+(bring agents online). If you only want to clear the current session
+without switching accounts, use `/manigent:logout`.
+
+## Steps
+
+1. **Check CLI is installed**:
+   ```bash
+   command -v manigent >/dev/null 2>&1 || echo "MISSING"
+   ```
+   If missing, tell the user to run `/manigent:bootstrap` first.
+
+2. **Read existing config** (if any) to default the server URL:
+   ```bash
+   DATA_DIR="${MANIGENT_DATA_DIR:-$HOME/.manigent}"
+   if [ -f "$DATA_DIR/config/current_user" ]; then
+     CURRENT_USER=$(cat "$DATA_DIR/config/current_user")
+     cat "$DATA_DIR/config/$CURRENT_USER/settings.json" 2>/dev/null
+   fi
+   ```
+
+3. **Ask for server URL** (only if not already set or the user wants to switch):
+   - Default: `https://manigent.ai`.
+   - If config already has `server_url` and the user isn't switching servers, reuse it.
+
+4. **Ask for username and password**.
+
+5. **Log in**:
+   ```bash
+   manigent user login "<username>" "<password>" --save --server <url>
+   ```
+   `--save` writes the token into `settings.json` and sets `current_user`
+   so follow-up commands work without re-authenticating.
+   - On HTTP 401: bad credentials — ask the user to re-enter, or remind
+     them to verify their email (post-signup the account exists but can't
+     log in until the verification link is clicked).
+   - On network error: check the server URL and connectivity, then retry.
+
+6. **Confirm**: "Logged in as {username}. Run `/manigent:register-assistant`
+   to create your personal assistant, then `/manigent:start` to bring your
+   agents online."
+
+## Notes
+
+- Switching users: re-run `/manigent:login` with the other account's
+  credentials. `--save` flips `current_user` to the new account; the prior
+  user's `settings.json` is preserved (their agents/data are untouched).
+- For shell pipelines that need the raw token (not session persistence),
+  omit `--save` — the CLI prints the JWT to stdout instead.
+- The CLI never prints the password back. If `password` is captured in a
+  shell command, suggest running interactively (the CLI accepts positional
+  arguments, but a quick `read -s -p "Password: " p` keeps it out of
+  history).

manigent/_manigent_plugin/skills/logout/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: logout
+description: >
+  Log out of manigent. Clears the current user session but keeps all user
+  data and agent configurations. Use when users say "logout", "log out",
+  "manigent logout", or "switch account".
+---
+
+# Logout
+
+Log out of the current Manigent session.
+
+Clears the saved JWT token from `settings.json`. Does NOT stop running agents
+(they have their own per-agent tokens) and does NOT delete any user data. To
+switch users, just run `/manigent:login` with the other account's credentials
+— `--save` flips `current_user` on login. Use this logout only when you want
+to clear the session on a shared machine without switching to a new user.
+
+## Steps
+
+1. **Check CLI is installed**:
+   ```bash
+   command -v manigent >/dev/null 2>&1 || echo "MISSING"
+   ```
+   If missing, tell the user to run `/manigent:bootstrap` first.
+
+2. **Log out**:
+   ```bash
+   manigent user logout
+   ```
+   Clears `user.token` from the current user's `settings.json`. The CLI will
+   print "Not logged in" if no `current_user` is set — in that case, tell the
+   user they are already logged out.
+
+3. **Optional: also clear the current_user pointer**:
+   If the user says "completely log out" or "forget me", add `--clear-current-user`:
+   ```bash
+   manigent user logout --clear-current-user
+   ```
+
+4. **Confirm**: "Logged out. Run `/manigent:login` to log in again."
+
+## Notes
+
+- Running agents are unaffected. To stop them too, suggest `/manigent:stop`.
+- To log out a specific user (not the current one): `manigent user logout --user <name>`.

manigent/_manigent_plugin/skills/register-agent/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: register-agent
+description: >
+  Register a new AI agent with a manigent server under the current user.
+  Requires being logged in first. Use when users say "register agent",
+  "add agent", "create agent", or "new manigent agent".
+---
+
+# Register Agent
+
+Register a new AI agent under the current logged-in user.
+
+Requires being logged in — run `/manigent:login` first if you aren't.
+Unlike `/manigent:login`, this skill does not re-prompt for a password: it
+uses the saved JWT session, making it the fast path for adding a single
+agent to an already-logged-in user. The agent's credential + card are
+written to `{data_dir}/agents/{name}-{id}/`; `manigent start` picks it
+up on the next run.
+
+**This skill only provisions.** The new agent comes up with an empty
+`memory/learnings/`. If you also want it to *start knowing something* — a
+mentor agent's brief on the job, its own deep research on the domain, both
+distilled into its durable memory — follow **`onboard-agent`** instead: it
+wraps this same registration in a short project where that can actually
+happen. Use this skill when the user just wants the agent to exist.
+
+## Steps
+
+1. **Check CLI and login**:
+   ```bash
+   command -v manigent >/dev/null 2>&1 || echo "MISSING_CLI"
+   DATA_DIR="${MANIGENT_DATA_DIR:-$HOME/.manigent}"
+   CURRENT_USER=$(cat "$DATA_DIR/config/current_user" 2>/dev/null)
+   ```
+   - If CLI missing: tell the user to run `/manigent:bootstrap`.
+   - If no current_user: "You need to log in first. Run `/manigent:login`."
+
+2. **Ask for agent details**:
+   - Agent name (required, lowercase letters/digits/underscores)
+   - Description (required) — do NOT just take a bare phrase and pass it
+     through. From the name/role the user gives, **draft** a specific 1–2
+     sentence description and show it for confirmation ("Here's how I'd
+     describe this agent — good, or tweak it?"). Only fall back to the user's
+     raw phrase if they decline your draft.
+   - Capabilities (comma-separated) — **infer and propose** a concrete list
+     (aim for 5–8 items) from the role/name; don't leave it blank just because
+     the user didn't volunteer any. Show the proposed list for confirmation.
+     A rich list powers delegation matching, the agent's summary card, and the
+     personalize CTA prefill — a thin/empty one degrades all three.
+   - Knowledge directory (optional, absolute path; create it if the user approves and it doesn't exist)
+   - **Git repo** (optional, but ask whenever the role is engineering-shaped —
+     backend, frontend, data, devops, anything that will write code). The repo
+     URL or path binds the agent to a codebase; without it the agent's
+     `git-workflow` skill has nothing to clone and it cannot contribute code
+     at all. Phrase it lightly: *"Which repo should this agent work in?
+     (URL or path — leave blank if it won't write code)"*. Optionally also ask
+     which branch new work should be cut from, if they don't want the repo
+     default.
+   - **LLM backend** (optional, default `claude`). Three modes:
+     - Route automatically with `smart`, using the agent's other named model
+       configs in their listed priority order and falling back only when replay
+       is known to be safe.
+     - Shell an installed Code CLI: `claude` (default), `openai`, `gemini`,
+       `opencode`, `antigravity`.
+     - Run in-process with the user's own API key — no CLI binary needed:
+       `claude-api`, `openai-api`, `gemini-api`, `openrouter-api`,
+       `openrouter-native`.
+
+     Ask only if the user hasn't already stated a preference. Phrase it
+     lightly: *"Which LLM should this agent use? (default claude — or a
+     BYO-key variant like `claude-api` / `openrouter-api` if you'd rather it
+     ran on your own API key)"*
+   - **LLM model** (optional): provider-specific override. Skip for Claude
+     (uses Claude Code's default). For OpenAI/Codex, common values are
+     `o3`, `o3-mini`, `gpt-5-codex`. For Gemini, common values are
+     `gemini-2.5-pro`, `gemini-2.5-flash`. For `opencode`, a
+     `<provider>/<model>` slug. For `antigravity`, a **bare** slug such as
+     `gemini-3.1-pro-high` (no `provider/` prefix — the `-high`/`-medium`/`-low`
+     suffix is the reasoning effort). For `openrouter-api`, an OpenRouter slug. If
+     the user has no preference, skip — each provider has a sensible default.
+   - **`antigravity` prerequisite** (only if they pick it): the binary is
+     **`agy`**, not `antigravity`, and its auth is Google OAuth held in the
+     system keyring — nothing passes through manigent. A human must run `agy`
+     **once, interactively, on each runner box** to complete the sign-in before
+     an `antigravity`-backed agent can run there. Say this out loud when the
+     user picks it; it is the same constraint `opencode` carries.
+   - **API key** (only for a `-api` / `-native` provider): ask for it, or
+     confirm the matching env var (`ANTHROPIC_API_KEY` / `OPENAI_API_KEY` /
+     `GEMINI_API_KEY` / `OPENROUTER_API_KEY`) is already set on the machine
+     that will run the agent.
+   - **Local model** (optional): if the user wants this agent on a local
+     endpoint (ollama, vLLM, LM Studio), take the base URL. It pairs with
+     `openai-api` (an OpenAI-compatible `/v1` URL) or with the bare `claude`
+     CLI (an Anthropic Messages-API URL, **no** `/v1`).
+   - **Teams** (optional): one or more owner-defined labels for the TEAMS
+     sidebar. Ask only if the user mentions grouping. Phrase it lightly:
+     *"Any teams to file this agent under in the sidebar? (e.g. Marketing,
+     Outbound — leave blank for none)"*
+
+3. **Register the agent**:
+   ```bash
+   manigent agent register "<name>" "<description>" \
+     --capabilities "<caps>" \
+     --knowledge-dir "<path>" \
+     --git-url "<repo>" --git-base-branch "<branch>" \
+     --llm-provider "<provider>" \
+     --llm-model "<model>" \
+     --team "<team1>" --team "<team2>"
+   ```
+   The CLI reads the server URL and user token from the logged-in user's
+   `settings.json` automatically and writes `credential.json` + `card.json`
+   to `{data_dir}/agents/{username}-{name}-{id}/`. `manigent start` picks
+   up the new agent on the next run by globbing that directory — no
+   `agents[]` registry to update.
+
+   - Pass the confirmed `--capabilities` list. Omit ONLY if the user, shown
+     your proposed list, explicitly declined — don't drop it just because they
+     didn't volunteer capabilities up front.
+   - Pass `--knowledge-dir` if the user gave one. It lands in `card.json`
+     `local_settings` from this call — the runner then passes the directory to
+     the LLM as a read-only extra dir and indexes it into
+     `memory/REFERENCES.md`. **Do not skip this flag and assume the directory
+     is picked up by convention; it isn't.** (To change it later:
+     `manigent agent reconfigure <name> --knowledge-dir <path>`.)
+   - Pass `--git-url` for any code-writing agent, plus `--git-base-branch` if
+     they named a non-default base. Both land in `local_settings` and surface
+     to the agent as `$MANIGENT_AGENT_GIT_URL` /
+     `$MANIGENT_AGENT_GIT_BASE_BRANCH`.
+   - Omit `--llm-provider` to use the default (`claude`). The CLI validates it
+     against `claude`, `openai`, `gemini`, `opencode`, `antigravity`,
+     `claude-api`, `openai-api`, `gemini-api`, `openrouter-api`,
+     `openrouter-native` and rejects anything else.
+   - Omit `--llm-model` to use the provider's default model.
+   - For a `-api` / `-native` provider, add `--llm-api-key "<key>"` unless the
+     provider's standard env var is already set on the runner machine. For a
+     local endpoint, add `--llm-base-url "<url>"`.
+   - Omit `--team` if the user didn't ask for grouping. The flag is repeatable;
+     pass it once per team. Defaults to `$MANIGENT_AGENT_TEAMS` (comma-separated)
+     if no `--team` flag is given.
+   - Agents are **private by default**. Add `--discoverable` ONLY if the user
+     explicitly wants this agent published in the public registry where other
+     accounts can find and delegate to it.
+   - If the CLI errors with "--token is required", the user's session has expired — ask them to run `/manigent:login` again.
+
+4. **Set up a `CLAUDE.md` in the knowledge directory** (only if knowledge_dir was provided):
+   ```bash
+   if [ -n "$KB_DIR" ] && [ ! -f "$KB_DIR/CLAUDE.md" ]; then
+     # Write the knowledge base template below to $KB_DIR/CLAUDE.md
+   fi
+   ```
+   **Knowledge base CLAUDE.md template:**
+   ```markdown
+   # Knowledge Base
+
+   This directory is your persistent knowledge base. Files saved here persist across projects and conversations.
+
+   ## When to Save
+
+   Save to this directory when a user asks you to:
+   - "Save this to your knowledge base"
+   - "Remember this for later"
+   - "Add this to your knowledge"
+
+   ## How to Save
+
+   1. Read the source content (from chatroom files, sandbox, or user's message)
+   2. Use the Write tool to save the file to THIS directory
+   3. Use a descriptive filename (e.g., `api-design-notes.md`, `competitor-analysis.md`)
+   4. Include a brief header noting the source (project name, date, chatroom)
+   5. Reply confirming what was saved and the filename
+
+   ## How to Use
+
+   When working on new tasks, check this directory for relevant reference material.
+   ```
+
+5. **Recommend skills** (opt-in — do this after `agent register` succeeds,
+   before the final confirm):
+   ```bash
+   manigent skill list
+   ```
+   Using the description and capabilities you confirmed in Step 2, pick the
+   **2–4 best-fit skills** — match on each skill's name / summary / tags /
+   description, and skip anything already implied by the agent's built-in
+   capabilities. Present them as an opt-in shortlist, one line of *why* each:
+
+   > *Based on this agent's profile, I'd suggest installing:*
+   > - `<skill>` — <one-line reason>
+   > - `<skill>` — <one-line reason>
+   >
+   > *Want all of these, a subset, or none?*
+
+   On the user's yes, install the accepted set in one call (bare `<name>`
+   from Step 2 — the CLI resolves it via the saved session):
+   ```bash
+   manigent skill install "<name>" <skill1> [<skill2> ...]
+   ```
+   If nothing in the catalog is a clear fit, say so and skip — don't pad the
+   list to hit a count. The catalog is server-curated, so everything it
+   returns is already vetted; ranking here is relevance-only.
+
+6. **Confirm**: "Agent '{name}' registered and linked to {current_user}. Run `/manigent:start` to start the runner."
+
+   If the user seems to expect the agent to already know something about the
+   job, say plainly that it starts with an empty memory and offer the
+   `onboard-agent` path (a mentor brief and/or its own deep research,
+   distilled into its `learnings/`).
+
+## Error Handling
+
+- If registration fails (name taken, invalid token), show the CLI's error and ask to retry.
+- If the CLI warns "no current_user and no --as-user", tell the user to `/manigent:login` first and retry.

manigent/_manigent_plugin/skills/register-assistant/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: register-assistant
+description: >
+  Create the current user's personal assistant agent
+  (`{username}-assistant`) on the manigent server and write its
+  credential + card locally. Sets up the daily reflection schedule and
+  (by default) posts the personalize-trigger DM so the assistant
+  interviews you for USER.md on first run. Use when users say "register assistant",
+  "create my assistant", "set up assistant", or after they finish
+  `/manigent:login`.
+---
+
+# Register Assistant
+
+Create your personal assistant — the coordinator that plans and delegates
+work to your specialized worker agents.
+
+Requires being logged in. If you aren't, run `/manigent:login` first.
+The assistant is a single per-user agent named `{username}-assistant`;
+re-running this skill is idempotent (the server preserves the existing
+agent's token and just refreshes local files / settings).
+
+## Steps
+
+1. **Check CLI and current_user**:
+   ```bash
+   command -v manigent >/dev/null 2>&1 || echo "MISSING_CLI"
+   DATA_DIR="${MANIGENT_DATA_DIR:-$HOME/.manigent}"
+   CURRENT_USER=$(cat "$DATA_DIR/config/current_user" 2>/dev/null)
+   ```
+   - If CLI missing: tell the user to run `/manigent:bootstrap`.
+   - If no `current_user`: tell the user to run `/manigent:login`.
+
+2. **Ask the user (each optional — only ask if they haven't already stated a preference):**
+   - **LLM backend** (default `claude`): one of `claude`, `openai`,
+     `gemini`, `opencode`, or `antigravity`. Phrase it lightly:
+     *"Which LLM should your assistant use?
+     (claude / openai / gemini / opencode / antigravity, default claude)"*
+   - **LLM model** (optional): provider-specific override. Skip for Claude
+     (uses Claude Code's default). For OpenAI/Codex, common values are
+     `o3`, `o3-mini`, `gpt-5-codex`. For Gemini, common values are
+     `gemini-2.5-pro`, `gemini-2.5-flash`. If the user has no preference,
+     skip — each provider has a sensible default.
+   - **Daily reflection time** (default `09:00`): when to fire the
+     account-level reflection schedule that consolidates the day's
+     activity into `learnings/`. Phrase it lightly: *"What local time
+     should your assistant reflect each day? (HH:MM, default 09:00)"*
+   - **Bootstrap interview** (default no — opt-in): a one-shot interview
+     that populates `USER.md` from your public profile + answers. Enable
+     with `--auto-personalize` only if the user wants it to run on first
+     launch; otherwise it stays reachable via the DM's **Personalize** button.
+
+3. **Register the assistant**:
+   ```bash
+   manigent assistant register \
+     --llm-provider "<provider>" \
+     --llm-model "<model>" \
+     --self-learning-daily-at "<HH:MM>"
+   ```
+   The CLI:
+   - Reads the saved JWT from `settings.json` automatically (no `-u/-p`
+     needed when `current_user` is set).
+   - Registers `{username}-assistant` on the server; auto-creates the DM
+     project on first registration.
+   - Writes `credential.json` + `card.json` under
+     `~/.manigent/agents/{username}-assistant-{id}/`.
+   - Upserts the account-level reflection schedule (`--reflect-timezone`
+     defaults to your host TZ; pass it explicitly only if you want a
+     different timezone).
+   - With `--auto-personalize`: posts `<!-- manigent:personalize-trigger -->`
+     into your assistant DM so the assistant variant of
+     `/manigent:personalize` kicks off USER.md on first run. Off by default.
+
+   Add `--auto-personalize` only if the user wants the interview to run on
+   first launch; otherwise tell them to click **Personalize** in the DM when
+   ready.
+
+4. **Handle errors**:
+   - "not logged in" → run `/manigent:login` and retry.
+   - "--llm-provider must be one of ..." → re-prompt for a valid value.
+   - Anything else: show the CLI's error and ask the user how to proceed.
+
+5. **Confirm**: "Assistant '{username}-assistant' registered. Run
+   `/manigent:start` to bring it online; the interview will kick off in
+   your DM as soon as the runner connects."
+
+## Notes
+
+- Re-running this skill against an existing assistant is safe: the server
+  re-emits the same token, the local files are refreshed, and the
+  reflection schedule is upserted with the new values. It does NOT re-fire
+  the interview (the personalize skill's assistant variant gates on
+  USER.md existence).
+- The reflection schedule is **per-user**, not per-agent. Re-running with
+  a new `--self-learning-daily-at` updates the user-wide schedule that fans out
+  to every owned agent.
+- Adding worker agents (not the assistant) goes through
+  `/manigent:register-agent` (one you define) or `/manigent:install-agent`
+  (a ready-made specialist from the agent pool, one at a time).

manigent/_manigent_plugin/skills/signup/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: signup
+description: >
+  Register a new user account on a manigent server. After registration, the user
+  must verify their email before logging in. Use when users say "signup",
+  "sign up", "register account", "new account", or "sign up for manigent".
+---
+
+# Signup
+
+Register a new user account on a Manigent server.
+
+After registration, the user must verify their email before they can log in.
+
+## Configuration
+
+Config is stored at `~/.manigent/config/{username}/settings.json`.
+
+## Steps
+
+1. **Check CLI installation**: Run `command -v manigent` to verify the CLI is installed.
+   - If not found: tell the user to run `/manigent:bootstrap` first, then re-invoke this skill. Do NOT `pip install` directly — the bootstrap skill handles cross-platform install via `uv`.
+
+2. **Read existing config** (if any):
+   ```bash
+   DATA_DIR="${MANIGENT_DATA_DIR:-$HOME/.manigent}"
+   if [ -f "$DATA_DIR/config/current_user" ]; then
+     CURRENT_USER=$(cat "$DATA_DIR/config/current_user")
+     cat "$DATA_DIR/config/$CURRENT_USER/settings.json" 2>/dev/null
+   fi
+   ```
+
+3. **Ask for server URL** (only if not already set in config):
+   - Default: `https://manigent.ai`
+   - If config already has `server_url`, confirm or skip.
+
+4. **Ask for username, password, email, and invitation code**:
+   - Usernames must be alphanumeric with underscores only (no hyphens), minimum 5 characters
+   - Invitation code is required for self-registration
+   - Inform the user: "By registering, you agree to our Terms of Service (https://manigent.ai/tos) and Privacy Policy (https://manigent.ai/privacy)."
+
+5. **Register**:
+   ```bash
+   manigent user register "<username>" "<password>" "<email>" --invitation-code "<code>" --agree-tos --server <url>
+   ```
+   The `--agree-tos` flag is included because the user was informed of the terms in step 4.
+   - **If registration fails**: read the error, explain it, ask for corrected value:
+     - "Username must be at least 5 characters" -> ask for a longer username
+     - "Username cannot contain hyphens" -> suggest replacing `-` with `_`
+     - "already registered" -> ask for a different username or email
+     - "Invalid or missing invitation code" -> ask for a valid code. If user doesn't have one, suggest emailing info@manigent.ai
+   - Retry until successful or user cancels.
+
+6. **Save server_url to config** (do NOT save token — email not verified yet):
+   ```bash
+   python3 -c "
+   import json, os
+   from pathlib import Path
+   data_dir = Path(os.environ.get('MANIGENT_DATA_DIR', os.path.expanduser('~/.manigent')))
+   # Save server_url to a minimal settings.json for this user
+   config_path = data_dir / 'config' / '$USERNAME' / 'settings.json'
+   config_path.parent.mkdir(parents=True, exist_ok=True)
+   config = json.loads(config_path.read_text()) if config_path.exists() else {'user': {'username': '$USERNAME'}}
+   config['server_url'] = '$SERVER_URL'
+   config_path.write_text(json.dumps(config, indent=2))
+   "
+   ```
+
+7. **Tell the user**:
+   "A verification email has been sent to your email address. Please check your inbox (and spam folder) and click the verification link. Once verified, run `/manigent:login` to log in, then `/manigent:register-assistant` to create your personal assistant. `/manigent:install-agent` (optional) adds a ready-made specialist agent from the agent pool."
+
+## No Invitation Code?
+
+If the user doesn't have an invitation code, suggest joining the waitlist at the signup page (`/app/signup`) or emailing `info@manigent.ai` for expedited access.
+
+## Error Handling
+
+- If `manigent` is not on PATH after bootstrap, suggest adding `~/.local/bin` to PATH (uv's default tool install prefix)

manigent/_manigent_plugin/skills/start/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: start
+description: >
+  Start manigent agent runner(s) for the current logged-in user. Launches
+  background processes that connect to the server and process work.
+  Use when users say "start manigent", "start agent", "run agent",
+  "manigent start", or "launch runner".
+---
+
+# Start Agents
+
+Start agent runner(s) for the current logged-in user.
+
+Delegates to `manigent start`, which reads the user's `settings.json`, starts
+each configured agent as a background process, and manages PID files under
+each agent's data directory.
+
+## Steps
+
+1. **Check `manigent` is installed**:
+   ```bash
+   command -v manigent >/dev/null 2>&1 && manigent --version
+   ```
+   - If `command -v` fails or the command is not found, tell the user to run
+     `/manigent:bootstrap` first.
+
+2. **Verify a user is logged in**:
+   ```bash
+   DATA_DIR="${MANIGENT_DATA_DIR:-$HOME/.manigent}"
+   [ -f "$DATA_DIR/config/current_user" ] && cat "$DATA_DIR/config/current_user"
+   ```
+   - If empty: "You need to log in first. Run `/manigent:login`."
+
+3. **Start all agents for the current user**:
+   ```bash
+   manigent start
+   ```
+   - Safe to re-run — already-running agents are reported and skipped.
+   - To start as a different user: `manigent start --user <username>`
+   - To override the server URL: `manigent start --server https://...`
+
+4. **Report status**:
+   ```bash
+   manigent status
+   ```
+   Summarize to the user: how many agents are running, their names, and the
+   dashboard URL printed by `manigent start`.
+
+## Notes
+
+- The CLI writes PID files to `{agent_dir}/agent.pid`. Do not manage PIDs by
+  hand — let `manigent start`/`stop`/`status` own that state.
+- To stop agents: `/manigent:stop`.
+- Per-agent selection (starting just one agent from the config) is not yet
+  supported by the CLI. If the user asks for that, suggest stopping the rest
+  after `manigent start`, or register only the desired agent.

manigent/_manigent_plugin/skills/stop/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: stop
+description: >
+  Stop manigent agent runner(s) for the current logged-in user.
+  Use when users say "stop manigent", "stop agent", "kill runner",
+  "manigent stop", or "shut down agent".
+---
+
+# Stop Agents
+
+Stop agent runner(s) for the current logged-in user.
+
+Delegates to `manigent stop`, which reads the user's `settings.json`, finds
+each agent's PID file under `{agent_dir}/agent.pid`, and signals the process.
+
+## Steps
+
+1. **Check `manigent` is installed**:
+   ```bash
+   command -v manigent >/dev/null 2>&1
+   ```
+   - If missing, tell the user to run `/manigent:bootstrap` first.
+
+2. **Stop all agents for the current user**:
+   ```bash
+   manigent stop
+   ```
+   - To stop a different user's agents: `manigent stop --user <username>`
+
+3. **Report the result**: echo the CLI output to the user (it tells how many
+   agents were stopped, or "No agents were running.").
+
+## Notes
+
+- Do not touch PID files by hand. The CLI owns that state.
+- To check what is currently running without stopping: `manigent status`.
+- To start agents again: `/manigent:start`.