# Investigate Spike

> Investigate a spike task from an Epic's backlog using the Epic's dedicated repo clone, and save a findings report the team can decide from. Use when the user mentions a spike, スパイク調査, or wants a technical question from the backlog researched against the actual codebase.

- Skill: `atman-33/investigate-spike` (Agent Skill)
- Install (CLI): `npx skillmds@latest add atman-33/investigate-spike`
- Raw SKILL.md: https://api.skillmd.com/api/skills/atman-33/investigate-spike/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: atman-33 (https://skillmd.com/u/atman-33)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/atman-33/investigate-spike

---


# Investigate Spike

A spike is a time-boxed research task whose deliverable is knowledge, not
code. This skill runs the research against the Epic's dedicated clone and
leaves a report next to the Epic's other machine-managed data.

## Steps

1. **Identify the spike item.** If the user named one, use it. Otherwise list
   the Epic's items (`node "${CLAUDE_PLUGIN_ROOT}/scripts/monday/list-items.mjs"`)
   and look for spike markers — a name starting with `Spike` / `[Spike]` /
   `スパイク`, or a type/status column that marks spikes on this board. If
   nothing matches, show the candidates and ask; do not guess. When the board
   uses a different convention, note it for `setup-scrum-context` so it can
   be recorded.

2. **Load the question.** `get-item.mjs <itemId>` plus the item's saved
   updates (`.pm/backlog/updates/<itemId>.json`) and, if scaffolded,
   `pbi/<itemId>-*/acceptance.md` — the spike's question and its
   "done when we know X" criterion. If the question is ambiguous, confirm it
   with the user before spending investigation effort.

3. **Prepare the code.** Run
   `node "${CLAUDE_PLUGIN_ROOT}/scripts/repo/sync-repo.mjs" "<groupName>"` so
   the dedicated clone (`.pm/repo/repo-state.json` → `mirrorPath`) is current
   on the epic branch. The clone is the spike's dedicated workspace — never
   investigate in the user's own development checkout. Read-only: no edits,
   no branch switching beyond what `sync-repo.mjs` did.

4. **Investigate.** Answer the spike question with evidence: trace the
   relevant code paths in the mirror (`file:line` citations), consult library
   docs where the question involves external dependencies, and run read-only
   commands in the mirror if needed. Delegate broad sweeps to a read-only
   exploration agent (`code-explore`) and fold back conclusions. Time-box:
   when findings are sufficient to decide, stop — a spike ends at "enough to
   decide", not at exhaustive coverage.

5. **Write the report** to `.pm/reports/spikes/<itemId>-<slug>.html` — a
   self-contained HTML document (inline CSS, no external assets, same
   conventions as the progress report): the question, what was examined,
   findings with `file:line` evidence, options with trade-offs, and a
   recommendation. Slug: short kebab-case from the item title.

6. **Close the loop.** Report the recommendation + report path in chat. Offer
   (user approval required — monday writes are workspace-visible) to post the
   conclusion and report location as an update on the monday item via the
   `monday-api-mcp` server, and/or to set the item's status via
   `update-item-status.mjs`.

## Failure modes

- No `repo` configured for the Epic → the spike may still be researchable
  from docs alone; say the code view is unavailable and ask whether to
  proceed docs-only or configure the repo first.
- `MONDAY_TOKEN` missing → scripts exit 1; point to the plugin README.
- Spike question spans a repo other than the Epic's → ask for the repo URL
  and pass it as `sync-repo.mjs` `--repo-url`/`--epic-folder` overrides
  rather than silently investigating the wrong codebase.