Setting up your agent

Install the skill and configure your board

The indifeed package installs product-manager and client metadata, plus a separate onboarding skill for Pi only, not an MCP server connection. Configure https://mcp.indifeed.app/<slug> separately, replacing <slug> with your board's slug. No local MCP server, proxy, or token paste is required.

The board-scoped URL is required and always enabled; client/auth acceptance is still pending. The account-wide root endpoint is unsupported.

Install Pi from the public @indifeed/pi npm package or its Git alternative, and other clients from the published agent plugin repository; no source checkout or local package path is required. Pi’s root manifest selects only its two skills under clients/pi/skills. Claude/Codex marketplaces and Hermes’s Git subdirectory installer select their own isolated roots. Live client installation/OAuth acceptance remains pending.

Claude Code

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

Merge into project .mcp.json, approve the project server, restart, and authenticate with /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 trusted project .codex/config.toml, then run codex mcp login indifeed from that project:

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

Codex loads project configuration only after project trust. Check the intended server before authenticating.

Pi

The product-management skill is named indifeed: invoke /skill:indifeed in Pi. When updating from the previous indifeed-product-manager skill, update explicit invocations and custom skill-name/path filters; no old-name alias is shipped. The separate indifeed-onboarding skill is unchanged.

pi install npm:@indifeed/pi

Alternatively: pi install https://git.bit-monkey.io/indifeed/agents.git. Choose only one Pi package source to avoid duplicate skills. If initial npm publication is still pending, use the Git alternative. Both contain the same two skills and use the agent package version, independently of the application version.

Start Pi in your project, reload if needed, then say Set up indifeed for this project or invoke /skill:indifeed-onboarding. Existing customers choose their board by URL/slug without signup questions. New customers are asked for account name and desired board address/slug plus optional email (you can enter it only in the browser). Review the agreed defaults and explicitly consent before email is included in a prefilled signup link. Pi always displays the clickable/copyable link before offering Open browser or I'll open manually; launching needs separate approval on your local desktop. Edit any defaults in the browser, complete signup/verification there, and return only the actual final non-secret board URL, not necessarily the suggested slug. The trial supports first interaction; setup does not require a purchase.

The prefill uses https://indifeed.dev/signup#accountName=Example+Team&appSlug=example-team with optional encoded email in the fragment, never passwords/auth artifacts. The fragment is not in the initial HTTP request and signup strips it before router/analytics/error telemetry. Agreed values still appear in chat/copied links and may remain in browser history; sharing the link shares those values. An optional public slug check is advisory; failed/unavailable checks keep the usable editable signup link and browser signup remains authoritative.

Approved browser launch uses native macOS open or Linux xdg-open with a display, not shell/custom BROWSER commands. SSH/headless/remote/Windows/unsupported environments stay link-only. Launch failure preserves the same link: no restart, repeated account questions, or duplicate signup is needed. Opener success does not mean signup completed. Password/bot challenge, verification/claim and OAuth remain user-browser-only; no auth forms are automated. Browser-launch and MCP config approvals are separate and neither is waived by write-confirmation preferences. Real browser/signup/session/OAuth/model acceptance remains NOT RUN.

Onboarding previews the exact project path, .pi/mcp.json destination, server name, and safe board endpoint, and asks for separate approval before a native project-local add. It reuses identical connections and stops for intentional manual conflict/legacy/adapter repair; it never silently shadows a different user-level target. Its Node metadata inspector reads only redacted metadata for the selected name after explicit intent and board selection, honoring PI_CODING_AGENT_DIR. Never share raw config, passwords, verification codes/links, OAuth artifacts, callback URLs, or payment details in chat.

Review project sources before granting trust, then use /reload or restart after external changes. Authenticate yourself in native /mcp Sign in or /mcp login indifeed. An adapter owning /mcp replaces native session support: review pi config, intentionally disable/remove the adapter separately, enable built-in MCP, and restart. Shell commands alone do not prove a live session is connected.

Setup validates the selected server's schemas and get_board() against your slug/canonical URL before offering product-manager review. Saved config with auth/session pending is partial success. Product-manager offers onboarding and waits when setup is missing; auth-only recovery does not force reconfiguration. No automatic feedback, status, or brief writes occur during setup. Skills and project trust are not a sandbox. Real session/OAuth and model behavior acceptance remain NOT RUN.

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 Agent Plugins v1 package supplies only the skill. Use skills_list to find its namespaced name. Merge this connection into ~/.hermes/config.yaml or your explicitly selected profile configuration:

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

Authenticate through Hermes when prompted. Select the intended user/profile explicitly; repository-local automatic selection is not verified.

Update Pi with pi update npm:@indifeed/pi or pi update https://git.bit-monkey.io/indifeed/agents.git, matching your installed source. Use pi list to identify and remove the old package declaration before switching sources, including previous local-path installations. Remove or move manually copied Hermes plugins before repository installation, then review the disabled package before enabling it. Refresh Claude/Codex catalogs and reinstall the unchanged indifeed@indifeed ID when their package roots change. Avoid duplicate standalone skill copies.

Upgrading from the bundled-connection package is a breaking transition: remove or disable the old bundled/root server, configure the scoped URL explicitly, and authenticate again. Old root credentials are rejected and are not converted into scoped credentials; revoke any you no longer need in indifeed first.

Configuration must not contain a client secret, token, token command, or custom Authorization header.

Your coding agent stores and refreshes OAuth credentials outside the conversation and repository. Never print, copy, or commit them.

Connect your indifeed account

1. Start authentication from your coding agent's MCP UI or login command.
2. The client opens indifeed's secure browser authorization flow using S256 PKCE.
3. Sign in as staff on the selected board's tenant.
4. Review the client name, callback host, account, selected board restriction, and read-write access before approving. All connections can read and write; there is no permission selector.
5. Approve or deny. indifeed returns directly to the coding agent; never copy an authorization code or token into chat.

A loopback callback is normal for a CLI client, but approve it only when you initiated the connection. Grants cover only the selected board; legacy root grants are rejected. Every call checks current staff membership, account state, board ownership, entitlement, and the board restriction.

Product-manager discovers scope from tool schemas, not client config or secrets (only Pi onboarding may inspect targeted redacted setup metadata after intent and target selection), and validates get_board() every scoped session. If multiple servers are available it asks you to choose. A mismatch or failed validation stops the workflow without switching boards or broadening access.

To change scope later, revoke the connection and authenticate again. See Manage or revoke access.

Customize write confirmations

All connections support discovery, recommendations, and explicitly requested writes:

• Submit feedback with an explicit staff_only visibility value.
• Save an approved, source-linked product brief.
• Post a customer-facing staff comment.
• Update a feedback item's status without posting a comment.

Separate confirmation is on by default. Tell the agent either command to change it globally:

indifeed confirmations off
indifeed confirmations on

The setting applies immediately and across future conversations and repositories using the same home directory. With confirmations on, the agent shows the exact pending write and asks before performing it. With confirmations off, your explicit request to save, post, or update is sufficient without a second yes/no prompt.

Turning confirmations off does not authorize agent-initiated writes. Comment and status changes must still be requested separately, product scope must still be approved before saving a brief, and version conflicts are never overwritten silently.

Manage or revoke access

Open Agent connections in indifeed admin to see and revoke approved agents. Revoking there ends server-side access. Removing the local MCP entry alone does not revoke the connection.

To remove local credentials, revoke in indifeed first, then clear indifeed authentication in your coding agent's MCP UI or logout command.

Existing board-scoped connections also have read-write access without reauthentication. Old account-wide connections require a board URL and fresh authentication.

Troubleshooting

• No indifeed tools: verify the package and MCP integration are installed, then restart the agent.
• OAuth does not start: update to a client that supports remote HTTP MCP, authorization-code + PKCE, and dynamic client registration.
• The callback fails: use the client's documented headless callback relay; never paste credentials into chat.
• A board is missing: check your staff membership and the board's current entitlement.
• Writes are unavailable: check current staff access, board entitlement, and board state. All connections have read-write access; separate confirmation follows your global confirmations setting.
• The selected board is inaccessible or wrong: correct the chosen client connection and reauthenticate if needed. The skill never switches boards, falls back to root, or writes an AGENTS.md association.