indifeed agents

CI-published, skill-only distribution mirror for indifeed's product-management workflow. Canonical source is in the indifeed repository; do not edit this mirror directly.

Each clients/{pi,claude,codex,hermes} root contains indifeed and only that client's manifest. Pi additionally ships a Pi-specific npm README, the separate indifeed-onboarding skill, its read-only Node metadata inspector, and a signup-link helper with an optional approved native browser launch; no onboarding is shipped for other clients yet. The root is a catalog/version anchor and the Pi entry point: its explicit manifest selects only clients/pi/skills. Claude/Codex catalogs and Hermes's subdirectory installer select their own isolated roots. Complete skills are composed at build time; sources/evaluations are not shipped and there are no runtime includes or source-checkout dependencies. Installing the package does not install a server connection. Pi onboarding guides an explicitly approved native project-local add; other clients configure their connection separately.

Install and configure

Use your board's slug in https://mcp.indifeed.app/<slug>. The board URL is required and always enabled; the account-wide root is unsupported. Client installation/auth acceptance remains pending; see https://indifeed.dev/docs/agents/ for setup and the source repository's compatibility matrix for results.

Install Pi from the public npm package, or choose the published Git repository alternative. Other clients install from the agent plugin repository using the native commands below. No source checkout or manually copied package is required.

Pi (native MCP)

pi install npm:@indifeed/pi

Alternatively: pi install https://git.bit-monkey.io/indifeed/agents.git. Choose only one Pi package source; installing both creates duplicate skills. If the initial npm publication is still pending, use the Git alternative. Both deliver the same two skills and use the agent marketplace's version, not the application version.

Start Pi in your project, reload if needed, and say “Set up indifeed for this project” or /skill:indifeed-onboarding. Existing customers choose their board by URL/slug without signup questions. New customers are asked for account name and desired board slug, plus optional email (you can enter it only in the browser). Review/agree the defaults and explicitly consent before email is included. Onboarding always displays a clickable/copyable prefilled https://indifeed.dev/signup link before offering Open browser or I'll open manually; launch requires separate approval on your local desktop. Defaults are editable in the browser. Complete signup/verification there and return only the actual final non-secret board URL, not necessarily the suggested slug.

The fixed link uses a plain URLSearchParams fragment: https://indifeed.dev/signup#accountName=Example+Team&appSlug=example-team (optional encoded email). The hash is absent from the initial HTTP request; signup removes it from the active URL before router/telemetry initialization. Agreed values still appear in chat/copied links and may remain in browser history; deliberately sharing the link shares them. Never include passwords/auth artifacts. An optional public slug check is advisory; failed checks preserve the editable signup link. Browser signup remains authoritative.

The helper defaults to link generation only. Approved launch uses macOS open or Linux xdg-open with a display, no shell or custom BROWSER command. SSH/headless/remote/Windows/unsupported environments remain link-only. Launch failure keeps the same link; no restart, new account questions, or duplicate signup is needed. Opener success is not signup completion, and no auth forms are automated. The trial supports first interaction; no purchase is required by setup. Never share passwords, verification links/codes, OAuth artifacts, callback URLs, or payment details in chat.

Onboarding requires separate approval of the exact project, .pi/mcp.json destination, server name, and safe endpoint before native pi mcp add -l (which replaces same-name entries). It preserves unrelated entries and reuses identical connections. Its metadata inspector reads only targeted redacted metadata in project and same-name user config after explicit intent/target; it honors PI_CODING_AGENT_DIR, never reads tokens/logs, and stops for malformed config, name/scope conflicts, disabled/root/legacy entries, or uncertain custom session paths. Repairs and adapter disable/remove are manual with separate approval, not automatic migration.

Review project sources before granting trust, then /reload/restart after external changes. Authenticate yourself using native /mcp Sign in or /mcp login indifeed; do not capture shell login output or broad pi mcp list diagnostics. An adapter owning /mcp replaces native session support; review it in pi config, intentionally disable/remove it separately, enable built-in MCP, and restart. Shell native config alone is not live-session success. Onboarding discovers the selected schemas and validates get_board() against your slug/canonical URL before offering PM review; config saved but auth/session pending is partial success. It makes no product writes.

Skills and project trust are not a sandbox: shell commands run with your OS permissions. Natural-language and model/session/OAuth acceptance remain NOT RUN; offline tests do not prove these behaviors.

Claude Code

claude plugin marketplace add https://git.bit-monkey.io/indifeed/agents.git
claude plugin install indifeed@indifeed

Merge this into project .mcp.json, approve the project server, restart, and authenticate using /mcp:

{
  "mcpServers": {
    "indifeed": {
      "type": "http",
      "url": "https://mcp.indifeed.app/<slug>"
    }
  }
}

Codex

codex plugin marketplace add https://git.bit-monkey.io/indifeed/agents.git
codex plugin add indifeed@indifeed

Merge into the trusted project's .codex/config.toml, then run codex mcp login indifeed from that project:

[mcp_servers.indifeed]
url = "https://mcp.indifeed.app/<slug>"

Project configuration requires Codex project trust. Check the selected server before signing in.

Hermes

hermes plugins install "https://git.bit-monkey.io/indifeed/agents.git#clients/hermes" --no-enable
hermes plugins list
hermes plugins enable indifeed

The portable plugin supplies only the skill. Use skills_list to discover its namespaced name. Add the connection to ~/.hermes/config.yaml or your explicitly selected profile's configuration, and authenticate through Hermes when prompted:

mcp_servers:
  indifeed:
    url: https://mcp.indifeed.app/<slug>
    auth:
      type: oauth

Do not assume Hermes automatically selects a repository-local server/profile; select the intended profile yourself. Native OAuth behavior must still pass client acceptance.

Skill identity change

The product-management skill is now indifeed (/skill:indifeed in Pi), replacing indifeed-product-manager with no alias. Update explicit skill invocations and custom name/path filters, update your chosen package/marketplace, then reload or restart. Remove old standalone copies. The separate indifeed-onboarding skill and package/plugin/server names are unchanged.

Isolated package transition

Update the selected Pi source with pi update npm:@indifeed/pi or pi update https://git.bit-monkey.io/indifeed/agents.git. Its npm package and root Git manifest expose only Pi's two skills. When switching sources, use pi list to identify and remove the old declaration before installing the new source, avoiding duplicate skills; this includes earlier local-path installations. Remove/move a manually copied Hermes plugin before using its repository subdirectory installer; review the disabled package before enabling it. Refresh Claude/Codex marketplaces and reinstall indifeed@indifeed to pick up client-root changes. Remove old standalone skill copies. Claude/Codex install IDs are unchanged.

These are documented installer/layout contracts, not runtime acceptance. Offline checks exercise exact manifest paths, fixed/default skill scans, version synchronization, and distinguishable temporary variants. Real client installation/discovery and OAuth remain NOT RUN.

Access and transition

No local MCP server, proxy, token command, custom Authorization header, client secret, or token paste is required. The client handles native OAuth with S256 PKCE and stores/refreshes credentials outside chat and the repository. Review the client, callback, selected board, and read-write access before approving. All connections can read and write; explicit write requests and confirmations still apply.

Upgrading from the bundled-connection package is a breaking transition: remove or disable the old bundled/root server declaration, configure the scoped URL explicitly, and authenticate again. Old root credentials are rejected; they are not converted into board-bound credentials. Revoke any root connection you no longer need in indifeed's Agent connections view before clearing local authentication.

Product-manager discovers scope from tool schemas, calls get_board() every scoped session, and omits board_id from scoped inputs. It never reads client config/secrets to select a board. In Pi, missing setup offers onboarding and waits for acceptance; missing auth alone uses native user sign-in without needless reconfiguration. The onboarding-only metadata exception never selects the board. If multiple servers are available it asks you to choose; failures or mismatches never silently broaden access.

Legacy root connections and repository board associations are unsupported. Configure the board-scoped URL and authenticate again.

Evidence remains untrusted data, recommendations cite stable feedback IDs, and scope approval precedes detailed planning. Write confirmations default to on; say indifeed confirmations off to disable only the extra confirmation prompts globally. Explicit write requests and approved product scope are still required.