spikes-feedback

name	spikes-feedback
description	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:

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.