[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXTXP1JBPPVB515JQ2P9KF":3,"skill-same:01M6DXTXP1JBPPVB515JQ2P9KF":124},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6DXTXP1JBPPVB515JQ2P9KF","conduct-spike",null,"Interactively conduct a time-boxed spike — collaboratively reduce uncertainty through discussion mixed with agent-driven research (and small throwaway prototypes where a question is empirical), then record the outcome on the spike's work item. Use when a work item or brief poses open questions that must be resolved before planning or implementation can proceed with confidence.","atomicinnovation\u002Faccelerator","atomicinnovation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F65866524?v=4","01M6DXP513JV585FN2QPNR6079","Atomic","01M6DXP55MPK99YVZ2HGMEN991",34,"MIT","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fresearch\u002Fconduct-spike\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"conduct","conduct spike","spike","implementation","work item","when","throwaway","proceed","frontmatter","reduce","path","number","driven","time","record","use","outcome","question","work","Bash","open","brief","metadata","planning","config","validate","research","2026-11-10 10:12:30",false,"---\nname: conduct-spike\ndescription: Interactively conduct a time-boxed spike — collaboratively reduce\n  uncertainty through discussion mixed with agent-driven research (and small\n  throwaway prototypes where a question is empirical), then record the outcome\n  on the spike's work item. Use when a work item or brief poses open questions\n  that must be resolved before planning or implementation can proceed with\n  confidence.\nargument-hint: \"[path to spike work item or brief, or work item number]\"\nallowed-tools:\n  - Bash(accelerator config *)\n  - Bash(accelerator corpus metadata derive)\n  - Bash(accelerator corpus frontmatter validate *)\n---\n\n# Conduct Spike\n\n!`accelerator config context --skill conduct-spike --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:web-search-researcher, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser.\n\n**Work items directory**: !`accelerator config path work --fail-safe`\n\nYou are tasked with conducting a **spike**: a time-boxed, uncertainty-reducing\ninvestigation. The spike is mostly conceptual, but a question is often best\nanswered by building a small throwaway prototype or test case. Your job is to\ntake an open, ambiguous brief and **iteratively reduce its uncertainty through\ncollaborative discussion** — backed by agent-driven research and, where needed,\nsmall experiments — until the team can proceed with confidence, then record the\noutcome.\n\nThis is **not** an interview and **not** a report you generate alone. It is a\n**collaborative discussion**: you surface evidence, propose interpretations, and\nthe human steers — together you converge on answers. Lean on the research agents\nto do the legwork so the conversation stays high-level.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **If a brief reference was provided**, resolve it in this order:\n\n   - A **path** (e.g. `meta\u002Fwork\u002F0003-skill-evaluation-framework-selection.md`,\n     or any arbitrary brief document) — read it.\n   - A bare **work item number** (e.g. `0003` or `3`) — resolve against the\n     work items directory shown above.\n   - Otherwise, treat the provided text as an **inline brief** for the spike.\n   - If a path or number was given but no file exists there, report\n     \"No spike brief at \u003Cpath>\" and stop — do not guess.\n\n   Then read it FULLY (no limit\u002Foffset). If it is a work item with a non-empty\n   `parent`, read the parent too. Proceed to the process below.\n\n2. **If no reference was provided**, respond with:\n\n   ```\n   I'll run a spike with you — an interactive, time-boxed investigation to\n   reduce the uncertainty until we can proceed with confidence.\n\n   Point me at the spike: a path to the work item or brief, or a work item\n   number. You can also paste the brief directly.\n\n   Example: `\u002Fconduct-spike meta\u002Fwork\u002F0003-skill-evaluation-framework-selection.md`\n   Or by number: `\u002Fconduct-spike 3`\n   ```\n\n   Then wait.\n\n## Principles\n\nHold these throughout — they define the character of a spike:\n\n- **Reduce uncertainty, don't just gather information.** Every move should\n  shrink a specific unknown that is currently blocking a decision. Track what is\n  still uncertain explicitly and watch it converge.\n- **Cover all bases before concluding.** A spike ends with confidence, which\n  means actively hunting for the blind spot — the option not considered, the\n  assumption not verified, the question not yet asked — not just answering the\n  questions already written down.\n- **Discussion over interrogation.** Bring evidence and a proposed reading of\n  it; invite the human to push back, reframe, or redirect. Resolve one thread to\n  its conclusion before opening the next.\n- **Self-answer through research; reserve the human for judgment.** If a\n  question can be answered by an agent (the web, the codebase, our own\n  documents) or by a quick experiment, answer it that way. Spend the human's\n  attention on intent, priorities, trade-offs, and risk appetite.\n- **Evidence is cited.** Findings carry their source — a URL, a `file:line`, a\n  prototype result. Unsupported assertions are flagged as assumptions, not\n  facts.\n- **Respect the time-box.** Spikes are bounded (the brief usually states the\n  box, e.g. \"2 days\"). Prioritise the highest-leverage unknowns; if the box\n  forces unresolved questions, that is itself a finding to record.\n\n## The Spike Process\n\n### Step 1: Read the brief and absorb the frame\n\nRead the brief (and parent) fully, then extract — for your own grounding, not as\na wall of text to the user:\n\n- **The core questions \u002F decision(s)** the spike must resolve.\n- **The acceptance criteria** — what must be true for the spike to be \"done\".\n- **The time-box** and any constraints.\n- **Where the outcome should go.** Default is to append it to this work item\n  (see Step 6). If the brief names a different or additional destination — an\n  ADR to feed, a doc to write, a downstream work item to update — note that and\n  honour it.\n\nAlso scan our own prior thinking early: spawn the **{documents locator agent}**\nto find related research, notes, plans, or decisions in the meta directories, so\nthe spike builds on what we already know instead of rediscovering it.\n\n### Step 2: Frame the uncertainty (collaborative checkpoint)\n\nDistil the brief into an explicit **uncertainty register** — the set of open\nquestions the spike must close. For each, capture:\n\n- **The question \u002F unknown**, in plain language.\n- **Why it matters** — which decision or acceptance criterion it gates.\n- **Current confidence** — what we believe today and how firmly.\n- **How we'd reduce it** — web research, codebase investigation, prior-art in\n  meta, a small prototype\u002Ftest, or a judgment call by the human.\n\nPresent this register to the user as the opening move and **collaborate to\nsharpen it**: Have we framed the right questions? Is anything missing? What's\nthe riskiest unknown? Agree the starting order (highest leverage first) before\ndiving in. This first exchange is where you confirm you're solving the right\nproblem.\n\n### Step 3: Reduce uncertainty iteratively (the core loop)\n\nWork the register down, one thread at a time:\n\n1. **Pick** the highest-leverage open question.\n2. **Choose the instrument** that best reduces it (see \"Choosing how to reduce a\n   question\" below) — often more than one in parallel.\n3. **Investigate.** Spawn agents (concurrently when they're independent) and\u002For\n   build a small prototype or test case. Give each agent a specific, focused,\n   read-only brief — the agents know how to search; tell them *what* you need,\n   not *how* to look.\n4. **Bring the evidence into the discussion.** Summarise what was learned, cite\n   sources, and propose what it implies. Surface tensions and surprises. Let the\n   user react, decide, or redirect — this is the collaborative heart of the\n   spike, not a status report.\n5. **Update the register.** Mark questions resolved, adjust confidences, and\n   **add any new unknowns** the findings surfaced (they often do). A spike that\n   only ever shrinks its question list and never grows it probably isn't probing\n   deeply enough.\n6. **Repeat** until the register's open, decision-gating questions are closed or\n   consciously deferred.\n\nRun this as a genuine back-and-forth: short loops, visible evidence, the human\nin the loop on every interpretation that affects the decision.\n\n### Step 4: Cover all bases (blind-spot sweep)\n\nBefore converging, deliberately look for what you might have missed — this is\nwhat turns \"we answered the questions\" into \"we can proceed with confidence\":\n\n- **Unconsidered options.** Did we evaluate the real alternatives, or anchor on\n  the first? Consider a fresh **{web search researcher agent}** pass framed to\n  find approaches we haven't named.\n- **Unverified assumptions.** Walk the brief's stated and implied assumptions —\n  verify each against the codebase, the docs, or a quick test rather than\n  trusting it.\n- **Unused research modality.** Did we lean on one source and skip another that\n  would see different failure modes (web vs. our own codebase vs. our own\n  documents vs. an experiment)?\n- **Untested empirical claims.** Anything asserted as \"X works \u002F behaves like Y\"\n  that we haven't actually run — prototype it.\n- **Acceptance-criteria coverage.** Walk each criterion in the brief and confirm\n  the spike now answers it.\n\nSurface what the sweep turns up and feed anything material back into Step 3.\n\n### Step 5: Converge on a decision\n\nWhen uncertainty is acceptably low, synthesise with the user:\n\n- The **recommendation \u002F decision** (a choice, or a small set with a clear\n  default), in the brief's own terms.\n- The **rationale**, grounded in the evidence gathered (with links \u002F `file:line`\n  \u002F prototype results).\n- **What was surveyed \u002F explored** — the options and angles considered, so the\n  decision is auditable, not just asserted.\n- **Residual risks and open questions** — what remains uncertain, and why it's\n  acceptable to proceed anyway (or what would trigger revisiting).\n- **Implications** — what this unblocks and any follow-on work it implies.\n\nUse the `AskUserQuestion` tool to confirm the synthesis with the user before\nrecording it, with two options:\n\n1. **Yes, record this synthesis** — write the outcome to the spike document\n2. **No, revise first** — adjust the synthesis before recording\n\n### Step 6: Record the outcome\n\n**Default: append the outcome to the work item** (the brief overrides this only\nif it explicitly names another destination — honour additions like feeding an\nADR or updating a downstream item *as well*).\n\n- Use `accelerator corpus metadata derive` to obtain\n  the `Current Date\u002FTime (UTC):` value and the resolved author.\n- With the Edit tool, add (or update) outcome sections in the work item body.\n  Match the section name the brief asks for — e.g. if the acceptance criteria\n  call for a **Recommendation** section, write exactly that. A typical shape:\n\n  - `## Spike Outcome` — date, time spent vs. box, and a one-line verdict.\n  - `## Recommendation` (or `## Findings` + `## Recommendation`) — the decision\n    and rationale, the options surveyed, and the evidence\u002Flinks.\n  - `## Residual Risks & Open Questions` — what remains, and the trigger to\n    revisit.\n\n- Update **only** the frontmatter fields `last_updated` (to the UTC value above)\n  and `last_updated_by` (to the resolved author). **Do not change `status`,\n  `priority`, or other lifecycle frontmatter** — those transitions belong to\n  `\u002Fupdate-work-item`. Likewise leave the body `**Status**:` \u002F `**Priority**:`\n  labels alone.\n- If an Edit target can't be matched (the file differs from what you read),\n  abort that specific edit with a clear diagnostic and continue with the rest.\n\nIf the spike worked from an **inline brief** with no work item, write the\noutcome to a research document in the configured research directory instead, and\ntell the user where it went.\n\n**Validate the frontmatter**: after writing, run `corpus frontmatter\nvalidate` over the work item you just updated:\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cpath>\n```\n\nIf it exits non-zero, the work item violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n### Step 7: Present and hand off\n\n- Confirm where the outcome was recorded.\n- Give a concise summary: the decision, the key evidence, and the residual\n  risks.\n- Note the natural next step (e.g. \"this work item is ready to move to `ready`\n  via `\u002Fupdate-work-item`\", or \"this feeds ADR …\"), but don't take lifecycle\n  actions yourself.\n\n## Choosing how to reduce a question\n\nMatch the instrument to the unknown — and run independent investigations in\nparallel:\n\n- **External \u002F conceptual unknowns** (how does this technology work, what are\n  the options, what's current best practice, what are the trade-offs) → the\n  **{web search researcher agent}**. This is the workhorse of a conceptual\n  spike. Instruct it to return **links** with its findings, and carry those\n  links into the outcome.\n- **\"Where does X live \u002F does our code already do Y?\"** → the **{codebase\n  locator agent}** to find it, then the **{codebase analyser agent}** to\n  understand how it actually works.\n- **\"Is there an existing pattern we'd follow?\"** → the **{codebase pattern\n  finder agent}** for concrete examples.\n- **\"Have we already thought about this?\"** → the **{documents locator agent}**\n  to discover relevant meta documents, then the **{documents analyser agent}**\n  to extract the substance from the most relevant ones.\n- **Empirical \u002F \"does it actually behave this way?\" unknowns** → build a small\n  prototype or test case (see below). Don't speculate when you can measure.\n- **Intent \u002F priority \u002F trade-off \u002F risk-appetite questions** → ask the human.\n  These are the questions agents can't answer.\n\n## Building prototypes and test cases\n\nWhen a question is empirical — does this API behave as documented, does this\napproach compile, what's the rough performance, does this integration actually\nwork — get ground truth instead of reasoning in the abstract:\n\n- Keep it **minimal and throwaway**: the smallest thing that answers the\n  question. Build it in the scratchpad directory (or a clearly-marked spike\n  scratch location), not in the production tree, unless the brief says the\n  prototype is a deliverable.\n- **Capture the result** — the command run, the output, the measurement — as\n  evidence for the outcome.\n- **Discard the code, keep the learning.** The artifact of a spike is the\n  resolved uncertainty and the recorded decision, not the prototype.\n- If a prototype reveals the real cost or risk is different from what the brief\n  assumed, that's a primary finding — bring it back into the discussion.\n\n## Important notes\n\n- **The conversation is the deliverable's source — the record is its\n  destination.** Don't silently research and dump a conclusion; reduce\n  uncertainty *with* the user, then record what you concluded together.\n- **Never conclude with placeholder values** in the recorded outcome, and never\n  skip the recording step — an unrecorded spike is an unfinished spike.\n- **Parallelise** independent agent investigations to keep the loop tight and\n  the main context lean; keep yourself focused on synthesis, not deep file\n  reading.\n- **Prefer live evidence over our own historical documents** when they\n  disagree; treat prior meta documents as context, not ground truth.\n- **Read fully**: always read the brief and any directly referenced files with\n  no limit\u002Foffset before spawning agents.\n- **Edit conservatively** when recording: add the outcome and touch only\n  `last_updated` \u002F `last_updated_by`; leave every other field to its owning\n  skill.\n- **A deferred question is a finding.** If the time-box closes with unknowns\n  open, record them explicitly with their risk — don't let them vanish.\n\n!`accelerator config instructions conduct-spike --fail-safe`\n","# Conduct Spike\n\n!`accelerator config context --skill conduct-spike --fail-safe`\n!`accelerator config agents --fail-safe`\n\nIf no \"Agent Names\" section appears above, use these defaults:\naccelerator:web-search-researcher, accelerator:codebase-locator,\naccelerator:codebase-analyser, accelerator:codebase-pattern-finder,\naccelerator:documents-locator, accelerator:documents-analyser.\n\n**Work items directory**: !`accelerator config path work --fail-safe`\n\nYou are tasked with conducting a **spike**: a time-boxed, uncertainty-reducing\ninvestigation. The spike is mostly conceptual, but a question is often best\nanswered by building a small throwaway prototype or test case. Your job is to\ntake an open, ambiguous brief and **iteratively reduce its uncertainty through\ncollaborative discussion** — backed by agent-driven research and, where needed,\nsmall experiments — until the team can proceed with confidence, then record the\noutcome.\n\nThis is **not** an interview and **not** a report you generate alone. It is a\n**collaborative discussion**: you surface evidence, propose interpretations, and\nthe human steers — together you converge on answers. Lean on the research agents\nto do the legwork so the conversation stays high-level.\n\n## Initial Response\n\nWhen this command is invoked:\n\n1. **If a brief reference was provided**, resolve it in this order:\n\n   - A **path** (e.g. `meta\u002Fwork\u002F0003-skill-evaluation-framework-selection.md`,\n     or any arbitrary brief document) — read it.\n   - A bare **work item number** (e.g. `0003` or `3`) — resolve against the\n     work items directory shown above.\n   - Otherwise, treat the provided text as an **inline brief** for the spike.\n   - If a path or number was given but no file exists there, report\n     \"No spike brief at \u003Cpath>\" and stop — do not guess.\n\n   Then read it FULLY (no limit\u002Foffset). If it is a work item with a non-empty\n   `parent`, read the parent too. Proceed to the process below.\n\n2. **If no reference was provided**, respond with:\n\n   ```\n   I'll run a spike with you — an interactive, time-boxed investigation to\n   reduce the uncertainty until we can proceed with confidence.\n\n   Point me at the spike: a path to the work item or brief, or a work item\n   number. You can also paste the brief directly.\n\n   Example: `\u002Fconduct-spike meta\u002Fwork\u002F0003-skill-evaluation-framework-selection.md`\n   Or by number: `\u002Fconduct-spike 3`\n   ```\n\n   Then wait.\n\n## Principles\n\nHold these throughout — they define the character of a spike:\n\n- **Reduce uncertainty, don't just gather information.** Every move should\n  shrink a specific unknown that is currently blocking a decision. Track what is\n  still uncertain explicitly and watch it converge.\n- **Cover all bases before concluding.** A spike ends with confidence, which\n  means actively hunting for the blind spot — the option not considered, the\n  assumption not verified, the question not yet asked — not just answering the\n  questions already written down.\n- **Discussion over interrogation.** Bring evidence and a proposed reading of\n  it; invite the human to push back, reframe, or redirect. Resolve one thread to\n  its conclusion before opening the next.\n- **Self-answer through research; reserve the human for judgment.** If a\n  question can be answered by an agent (the web, the codebase, our own\n  documents) or by a quick experiment, answer it that way. Spend the human's\n  attention on intent, priorities, trade-offs, and risk appetite.\n- **Evidence is cited.** Findings carry their source — a URL, a `file:line`, a\n  prototype result. Unsupported assertions are flagged as assumptions, not\n  facts.\n- **Respect the time-box.** Spikes are bounded (the brief usually states the\n  box, e.g. \"2 days\"). Prioritise the highest-leverage unknowns; if the box\n  forces unresolved questions, that is itself a finding to record.\n\n## The Spike Process\n\n### Step 1: Read the brief and absorb the frame\n\nRead the brief (and parent) fully, then extract — for your own grounding, not as\na wall of text to the user:\n\n- **The core questions \u002F decision(s)** the spike must resolve.\n- **The acceptance criteria** — what must be true for the spike to be \"done\".\n- **The time-box** and any constraints.\n- **Where the outcome should go.** Default is to append it to this work item\n  (see Step 6). If the brief names a different or additional destination — an\n  ADR to feed, a doc to write, a downstream work item to update — note that and\n  honour it.\n\nAlso scan our own prior thinking early: spawn the **{documents locator agent}**\nto find related research, notes, plans, or decisions in the meta directories, so\nthe spike builds on what we already know instead of rediscovering it.\n\n### Step 2: Frame the uncertainty (collaborative checkpoint)\n\nDistil the brief into an explicit **uncertainty register** — the set of open\nquestions the spike must close. For each, capture:\n\n- **The question \u002F unknown**, in plain language.\n- **Why it matters** — which decision or acceptance criterion it gates.\n- **Current confidence** — what we believe today and how firmly.\n- **How we'd reduce it** — web research, codebase investigation, prior-art in\n  meta, a small prototype\u002Ftest, or a judgment call by the human.\n\nPresent this register to the user as the opening move and **collaborate to\nsharpen it**: Have we framed the right questions? Is anything missing? What's\nthe riskiest unknown? Agree the starting order (highest leverage first) before\ndiving in. This first exchange is where you confirm you're solving the right\nproblem.\n\n### Step 3: Reduce uncertainty iteratively (the core loop)\n\nWork the register down, one thread at a time:\n\n1. **Pick** the highest-leverage open question.\n2. **Choose the instrument** that best reduces it (see \"Choosing how to reduce a\n   question\" below) — often more than one in parallel.\n3. **Investigate.** Spawn agents (concurrently when they're independent) and\u002For\n   build a small prototype or test case. Give each agent a specific, focused,\n   read-only brief — the agents know how to search; tell them *what* you need,\n   not *how* to look.\n4. **Bring the evidence into the discussion.** Summarise what was learned, cite\n   sources, and propose what it implies. Surface tensions and surprises. Let the\n   user react, decide, or redirect — this is the collaborative heart of the\n   spike, not a status report.\n5. **Update the register.** Mark questions resolved, adjust confidences, and\n   **add any new unknowns** the findings surfaced (they often do). A spike that\n   only ever shrinks its question list and never grows it probably isn't probing\n   deeply enough.\n6. **Repeat** until the register's open, decision-gating questions are closed or\n   consciously deferred.\n\nRun this as a genuine back-and-forth: short loops, visible evidence, the human\nin the loop on every interpretation that affects the decision.\n\n### Step 4: Cover all bases (blind-spot sweep)\n\nBefore converging, deliberately look for what you might have missed — this is\nwhat turns \"we answered the questions\" into \"we can proceed with confidence\":\n\n- **Unconsidered options.** Did we evaluate the real alternatives, or anchor on\n  the first? Consider a fresh **{web search researcher agent}** pass framed to\n  find approaches we haven't named.\n- **Unverified assumptions.** Walk the brief's stated and implied assumptions —\n  verify each against the codebase, the docs, or a quick test rather than\n  trusting it.\n- **Unused research modality.** Did we lean on one source and skip another that\n  would see different failure modes (web vs. our own codebase vs. our own\n  documents vs. an experiment)?\n- **Untested empirical claims.** Anything asserted as \"X works \u002F behaves like Y\"\n  that we haven't actually run — prototype it.\n- **Acceptance-criteria coverage.** Walk each criterion in the brief and confirm\n  the spike now answers it.\n\nSurface what the sweep turns up and feed anything material back into Step 3.\n\n### Step 5: Converge on a decision\n\nWhen uncertainty is acceptably low, synthesise with the user:\n\n- The **recommendation \u002F decision** (a choice, or a small set with a clear\n  default), in the brief's own terms.\n- The **rationale**, grounded in the evidence gathered (with links \u002F `file:line`\n  \u002F prototype results).\n- **What was surveyed \u002F explored** — the options and angles considered, so the\n  decision is auditable, not just asserted.\n- **Residual risks and open questions** — what remains uncertain, and why it's\n  acceptable to proceed anyway (or what would trigger revisiting).\n- **Implications** — what this unblocks and any follow-on work it implies.\n\nUse the `AskUserQuestion` tool to confirm the synthesis with the user before\nrecording it, with two options:\n\n1. **Yes, record this synthesis** — write the outcome to the spike document\n2. **No, revise first** — adjust the synthesis before recording\n\n### Step 6: Record the outcome\n\n**Default: append the outcome to the work item** (the brief overrides this only\nif it explicitly names another destination — honour additions like feeding an\nADR or updating a downstream item *as well*).\n\n- Use `accelerator corpus metadata derive` to obtain\n  the `Current Date\u002FTime (UTC):` value and the resolved author.\n- With the Edit tool, add (or update) outcome sections in the work item body.\n  Match the section name the brief asks for — e.g. if the acceptance criteria\n  call for a **Recommendation** section, write exactly that. A typical shape:\n\n  - `## Spike Outcome` — date, time spent vs. box, and a one-line verdict.\n  - `## Recommendation` (or `## Findings` + `## Recommendation`) — the decision\n    and rationale, the options surveyed, and the evidence\u002Flinks.\n  - `## Residual Risks & Open Questions` — what remains, and the trigger to\n    revisit.\n\n- Update **only** the frontmatter fields `last_updated` (to the UTC value above)\n  and `last_updated_by` (to the resolved author). **Do not change `status`,\n  `priority`, or other lifecycle frontmatter** — those transitions belong to\n  `\u002Fupdate-work-item`. Likewise leave the body `**Status**:` \u002F `**Priority**:`\n  labels alone.\n- If an Edit target can't be matched (the file differs from what you read),\n  abort that specific edit with a clear diagnostic and continue with the rest.\n\nIf the spike worked from an **inline brief** with no work item, write the\noutcome to a research document in the configured research directory instead, and\ntell the user where it went.\n\n**Validate the frontmatter**: after writing, run `corpus frontmatter\nvalidate` over the work item you just updated:\n\n```bash\naccelerator corpus frontmatter validate --file \u003Cpath>\n```\n\nIf it exits non-zero, the work item violates the canonical frontmatter\nstandard; report the emitted violation and fix the frontmatter before\ncompleting.\n\n### Step 7: Present and hand off\n\n- Confirm where the outcome was recorded.\n- Give a concise summary: the decision, the key evidence, and the residual\n  risks.\n- Note the natural next step (e.g. \"this work item is ready to move to `ready`\n  via `\u002Fupdate-work-item`\", or \"this feeds ADR …\"), but don't take lifecycle\n  actions yourself.\n\n## Choosing how to reduce a question\n\nMatch the instrument to the unknown — and run independent investigations in\nparallel:\n\n- **External \u002F conceptual unknowns** (how does this technology work, what are\n  the options, what's current best practice, what are the trade-offs) → the\n  **{web search researcher agent}**. This is the workhorse of a conceptual\n  spike. Instruct it to return **links** with its findings, and carry those\n  links into the outcome.\n- **\"Where does X live \u002F does our code already do Y?\"** → the **{codebase\n  locator agent}** to find it, then the **{codebase analyser agent}** to\n  understand how it actually works.\n- **\"Is there an existing pattern we'd follow?\"** → the **{codebase pattern\n  finder agent}** for concrete examples.\n- **\"Have we already thought about this?\"** → the **{documents locator agent}**\n  to discover relevant meta documents, then the **{documents analyser agent}**\n  to extract the substance from the most relevant ones.\n- **Empirical \u002F \"does it actually behave this way?\" unknowns** → build a small\n  prototype or test case (see below). Don't speculate when you can measure.\n- **Intent \u002F priority \u002F trade-off \u002F risk-appetite questions** → ask the human.\n  These are the questions agents can't answer.\n\n## Building prototypes and test cases\n\nWhen a question is empirical — does this API behave as documented, does this\napproach compile, what's the rough performance, does this integration actually\nwork — get ground truth instead of reasoning in the abstract:\n\n- Keep it **minimal and throwaway**: the smallest thing that answers the\n  question. Build it in the scratchpad directory (or a clearly-marked spike\n  scratch location), not in the production tree, unless the brief says the\n  prototype is a deliverable.\n- **Capture the result** — the command run, the output, the measurement — as\n  evidence for the outcome.\n- **Discard the code, keep the learning.** The artifact of a spike is the\n  resolved uncertainty and the recorded decision, not the prototype.\n- If a prototype reveals the real cost or risk is different from what the brief\n  assumed, that's a primary finding — bring it back into the discussion.\n\n## Important notes\n\n- **The conversation is the deliverable's source — the record is its\n  destination.** Don't silently research and dump a conclusion; reduce\n  uncertainty *with* the user, then record what you concluded together.\n- **Never conclude with placeholder values** in the recorded outcome, and never\n  skip the recording step — an unrecorded spike is an unfinished spike.\n- **Parallelise** independent agent investigations to keep the loop tight and\n  the main context lean; keep yourself focused on synthesis, not deep file\n  reading.\n- **Prefer live evidence over our own historical documents** when they\n  disagree; treat prior meta documents as context, not ground truth.\n- **Read fully**: always read the brief and any directly referenced files with\n  no limit\u002Foffset before spawning agents.\n- **Edit conservatively** when recording: add the outcome and touch only\n  `last_updated` \u002F `last_updated_by`; leave every other field to its owning\n  skill.\n- **A deferred question is a finding.** If the time-box closes with unknowns\n  open, record them explicitly with their risk — don't let them vanish.\n\n!`accelerator config instructions conduct-spike --fail-safe`\n",{"name":5,"description":7,"allowed-tools":51,"argument-hint":55},[52,53,54],"Bash(accelerator config *)","Bash(accelerator corpus metadata derive)","Bash(accelerator corpus frontmatter validate *)","[path to spike work item or brief, or work item number]","main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Fresearch\u002Fconduct-spike",2,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-10 21:05:37",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add atomicinnovation\u002Faccelerator --skill conduct-spike",{"tool":70,"command":71},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill conduct-spike",{"tool":73,"command":74},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill conduct-spike","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fresearch\u002Fconduct-spike\u002FSKILL.md",true,[78,84,88,92,96,102,106,110,114,118],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"assets\u002Fbaposter_template.tex","ASSET","资产文件",7432,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Fassets\u002Fbaposter_template.tex",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"assets\u002Fbeamerposter_template.tex",7652,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Fassets\u002Fbeamerposter_template.tex",{"path":89,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":90,"sourceHtmlUrl":91},"assets\u002Fposter_quality_checklist.md",11172,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Fassets\u002Fposter_quality_checklist.md",{"path":93,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":94,"sourceHtmlUrl":95},"assets\u002Ftikzposter_template.tex",7887,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Fassets\u002Ftikzposter_template.tex",{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Flatex_poster_packages.md","REFERENCE","参考文档",17836,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Freferences\u002Flatex_poster_packages.md",{"path":103,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fposter_content_guide.md",20361,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Freferences\u002Fposter_content_guide.md",{"path":107,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fposter_design_principles.md",22916,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Freferences\u002Fposter_design_principles.md",{"path":111,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fposter_layout_design.md",22327,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Freferences\u002Fposter_layout_design.md",{"path":115,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":116,"sourceHtmlUrl":117},"references\u002FREADME.md",11654,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Freferences\u002FREADME.md",{"path":119,"resourceType":120,"resourceTypeDesc":121,"sizeBytes":122,"sourceHtmlUrl":123},"scripts\u002Freview_poster.sh","SCRIPT","脚本",7939,"https:\u002F\u002Fgithub.com\u002Ffranklee16\u002Facademic-research-skills\u002Fblob\u002Fmaster\u002Fpresentations\u002Flatex-posters\u002Fscripts\u002Freview_poster.sh",[125,159,178,200,218,242],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":141,"publishedAt":46},"01M70S7PFGVATJREBFEGPJB718","explore-pr","Build an interactive, design-first and picture-first exploration page for a pull request — its architecture, abstractions and design decisions drawn as diagrams, a guided tour in reading order with code as the evidence, an attention map of where the risk sits, a ledger of its riskiest operations, prior review findings re-checked against the code, and simulations specific to the PR — with the reviewer's verdicts and notes saved. Use when the user wants to explore, understand or review a large pull request or its design, asks for a review page, walkthrough or visual explanation of a PR, or is struggling to review a big change.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fexplore-pr\u002FSKILL.md",[131,136],{"categoryNo":132,"categoryName":133,"taxonomyType":134,"taxonomyTypeDesc":135},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[142,143,144,145,146,147,148,149,150,151,24,30,152,38,153,154,155,156,157,158],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","design","map","URL","code","architecture","reviewer","review","notes","change",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":46},"01M6DY04WBTMFV96JMBP5ZXVFX","update-work-item","Update fields (status, priority, tags, parent, etc.) of an existing work item. Use to transition status, change priority, manage tags, or edit any frontmatter field. No transition enforcement — arbitrary changes are allowed.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fupdate-work-item\u002FSKILL.md",[],[37,166,167,23,168,169,34,38,158,43,170,44,171,172,27,173,174,175,176,177],"update","update work item","enforcement","manage","edit","status","transition","Existing","tags","changes","fields","op",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":46},"01M6DY0106CF15CYEJHZM14GBZ","sync-work-items","Reconcile local work items in meta\u002Fwork\u002F with the active remote tracker named by work.integration. Use when the user wants to sync, push, or pull work items to or from Jira or Linear, preview what a sync would change, or reconcile divergent local and remote state.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items\u002FSKILL.md",[],[37,185,186,187,188,189,190,38,191,158,192,193,194,195,196,197,198,43,199,27,24],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":46},"01M6HNF86984S4XK21Q26VZA21","sync-work-items-recovery","Recovery procedures for work sync failures that need a person — terminal rows, refused pending pushes and refused orders. Read by sync-work-items — not invoked directly.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items-recovery\u002FSKILL.md",[],[207,37,208,185,186,209,210,211,212,213,214,215,216,217],"sync work items recovery","recovery","work-items","for","terminal","read","person","true","false","orders","pending",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":227,"publishedAt":46},"01M6DXZWH7PR72VCEXSSD4XNK4","stress-test-work-item","Interactively stress-test a work item by grilling the user on scope, assumptions, acceptance criteria, edge cases, and dependencies to surface issues, gaps, and flawed assumptions before implementation is planned.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002FSKILL.md",[224],{"categoryNo":225,"categoryName":226,"taxonomyType":134,"taxonomyTypeDesc":135},"01JBSEEDCAT000000000000008","测试与质量",[228,229,37,230,23,231,232,233,234,235,236,38,237,238,43,44,22,239,240,30,241,27],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","grilling","user","gaps",{"skillNo":243,"name":244,"nameZh":6,"description":245,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":246,"categories":247,"keywords":248,"publishedAt":46},"01M6DXZRQWHTWV1G9PTTHCGGYA","review-work-item","Review a work item through multiple quality lenses and collaboratively iterate based on findings. Use when the user wants to evaluate a work item before implementation or escalation.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002FSKILL.md",[],[156,37,249,23,250,251,34,38,252,253,43,44,22,240,41,24,254,255,27,29],"review work item","review work","escalation","file","quality","iterate","evaluate"]