Using your agent

Validate your configured board

Configure the native scoped connection at https://mcp.indifeed.app/<slug> separately from the skill. The agent discovers tool schemas and calls get_board() without arguments every session before retrieving evidence. Scoped tool inputs omit board_id; the returned board identity is used in recommendations and write previews.

The skill never reads client config or secrets to determine scope. If multiple indifeed servers are available it asks you to choose. Inaccessible or mismatched boards stop the workflow; it never falls back to root or silently switches targets.

Legacy root connections and repository board associations are unsupported. Configure the scoped endpoint instead; the agent never creates or updates an AGENTS.md association. In Pi, missing setup offers the separate onboarding skill and waits for your explicit acceptance. Existing customers skip signup questions; new customers review account name/slug and optional email consent, receive a clickable/copyable editable signup link before a separately approved local browser launch or manual opening, and return the actual final non-secret board URL. SSH/headless or launch failure keeps the same link without restarting signup. Passwords, verification/claim and OAuth stay in your browser, never chat. Agreed link values remain visible if shared; see Pi setup and link privacy. Browser launch approval is not MCP configuration approval, and write-confirmation preferences waive neither. Real browser/signup/session/OAuth/model acceptance remains NOT RUN.

Ask product questions

Start with a question in normal language — no commands or special syntax. The agent retrieves a bounded candidate list, examines details for a shortlist, and uses limited repository context when effort affects the answer.

What is the most valuable thing I can work on today?

You can also ask:

• Which customer problem has the strongest recent signal?
• What evidence contradicts this request?
• Are there related or duplicate requests for this idea?
• What would it take to support a specific workflow?

What a recommendation looks like

Instead of an unranked list, the agent recommends one candidate and explains why the others lost. The response is clearly labelled:

## Recommendation — Aks1ig: Onboarding docs

**Recommendation:** the next problem and suggested action
**Source facts:** votes, comments, participants, recency — each with feedback IDs
**Why now:** timing and urgency, cited
**Agent judgement:** why this beats the alternatives
**Rough feasibility:** repository facts when effort matters
**Runner-ups:** plausible candidates and why they rank second
**Assumptions / contradictions / missing context:** explicit list
**Confidence:** low, medium, or high, with reason

Source facts come from indifeed and cite stable feedback IDs. Votes, comments, participants, and recency are demand signals only — “most demanded” is not automatically “most valuable”. The recommendation itself is the agent's judgement, not an indifeed decision, and it waits for your call before proceeding.

Turn a choice into a product brief

Once you select a candidate, the agent keeps the loop tight — a brief before detailed implementation analysis. The draft states the user's problem (not the customer's proposed fix), why now, affected users, desired outcome, the smallest useful first slice, non-goals, open questions, and evidence sources.

1. Review the draft and refine it conversationally. The agent challenges unnecessary scope and separates customer-proposed solutions from demonstrated problems.
2. When you are satisfied, the agent presents an approved scope with acceptance criteria, excluded work, edge cases, and a success measure — and asks you to approve it explicitly.
3. Saving the brief to indifeed is a separate step. It needs your explicit approval of the product scope and (with confirmations on) a second confirmation of the exact save. Version conflicts are surfaced to you, never overwritten silently.

The approved brief becomes discoverable context: later sessions can resume it via your board.

Plan the implementation

Detailed repository analysis happens only after the scope is approved — either in this conversation or from an approved brief on your board. The agent then inspects your repository instructions and existing code, preferring established patterns, and proposes changes before writing anything:

## Repository-aware implementation plan

**Approved product scope:** brief version or conversation approval
**Confirmed repository facts:** paths, components, existing patterns
**Proposed changes:** implementation steps with affected paths
**API / data / UI impact:** surfaces touched, if relevant
**Tests and validation:** checks that prove the outcomes
**Compatibility / migration / rollout:** risks, or none
**Open technical decisions:** choices still requiring your review
**Implementation order:** a small, reviewable sequence

The agent presents the plan for your review and does not implement or deploy unless you separately ask.

Keep feedback status in sync

For the selected feedback, developer-requested work advances its status at these milestones:

• Begin scoping → under_review.
• Successfully save the approved scope → planned.
• Begin requested implementation → in_progress.
• Verify the relevant implementation PR has merged → shipped, without waiting for deployment.

Fetching or selecting feedback, approving unsaved scope, planning, and opening a PR do not trigger these updates. The agent never moves a later status backwards, reopens declined/not-planned feedback automatically, or advances related items. Failed saves leave status unchanged; a successful save followed by a failed status update is reported as partial success.

With confirmations on, each status write still needs separate confirmation. Say indifeed confirmations off to perform authorized lifecycle updates without another prompt. The agent checks the current status before writing and stops on conflicting changes instead of overwriting them. Merge updates happen when the agent verifies the merge, including on resumption—not through a background watcher.

Write back to the board

You can also respond to customers from your repository, but only when you ask:

• Comment on feedback — post a customer-facing staff reply to a specific item.
• Change status — move an item through your board's flow (for example to planned or shipped) without adding a comment.

Direct writes require your request; lifecycle actions above authorize their associated status updates, never customer-facing comments. With confirmations on, the agent shows the exact content and target and asks separately before each write. Direct status requests can still reopen feedback or move it backwards; lifecycle updates cannot.

The loop at a glance

1. Ask what to work on — get one recommendation with evidence and confidence.
2. Select a candidate, then refine a product brief until the scope is approved.
3. Save the brief, then ask for a repository-aware implementation plan.
4. Ask the agent to implement; it keeps the selected feedback status aligned through verified merge. Request customer-facing comments separately.