spikes-feedback

MCP server: spikes

{
  "command": "npx",
  "args": [
    "-y",
    "spikes-mcp"
  ]
}

Read targeted user feedback collected by Spikes (spikes.sh) and act on it. Use when the user mentions Spikes, asks "what did reviewers say", points at `.spikes/`, or after shipping a UI change to a page that has the Spikes widget injected.

# Spikes feedback loop

Spikes captures click-targeted feedback on web pages: each item has a CSS selector, bounding box, page URL, rating (yes/no/meh), reviewer, and comment. The point of this skill is to make that feedback actionable inside an editing session instead of leaving it in a dashboard.

## When this skill applies

- The repo contains a `.spikes/` directory or a `spikes` config.
- The user asks about reviewer feedback, or says something like "address the feedback", "what's broken on the mockup", "any new spikes".
- You just changed a page that has the Spikes widget — proactively check whether existing feedback is now resolved or stale.

## Reading feedback

If the Spikes MCP server is wired up (this plugin ships `.mcp.json` for it), prefer the MCP tools — they return structured JSON without shelling out.

Fallback CLI:

```bash
spikes list --json                  # everything
spikes list --json --unresolved     # open items only
spikes list --json --rating no      # things reviewers flagged as broken
spikes list --json --page /pricing  # one page
```

Each item includes `selector`, `bbox`, `page`, `rating`, `comment`, `reviewer`, `resolved`. The selector is the actionable part — grep the codebase for the matching element rather than guessing from the comment alone.

## Working a feedback item

1. Read the item: selector + comment + rating.
2. Locate the element in the codebase by selector (or by visible text from the bounding-box screenshot if present).
3. Make the change.
4. Mark the item resolved — `resolve_spike` MCP tool, or `spikes resolve <id>` — **only after** you've verified the fix in `spikes serve` or the user's dev server. Don't pre-resolve.
5. If the comment is ambiguous, surface it to the user verbatim and ask before guessing.

## What not to do

- Don't bulk-resolve items without addressing them.
- Don't treat `meh` ratings as "ignore" — they're often the most useful signal.
- Don't edit `.spikes/feedback.jsonl` by hand; go through the CLI/MCP so provenance stays intact.

Nudge agents to check Spikes feedback after touching pages with the widget injected.

# Spikes feedback loop

If this repo has a `.spikes/` directory, treat reviewer feedback as a first-class input.

- After a UI change, run `spikes list --json --unresolved` (or the equivalent MCP tool) and check whether any open item was about the element you just touched.
- When a user says "fix the feedback" without specifics, list open items first and confirm scope before editing.
- Resolve items only after verifying the fix renders correctly. Don't pre-resolve.
- Selectors are the source of truth for "which element" — prefer them over paraphrased comments.