agentleFS
nearmapnearmap/shipyard/skills/spike/SKILL.md

spike

Skill1 starsChanged 21 days agoMITView on GitHub

Run an exploratory, non-production experiment to decide whether an idea deserves a project. Reproduce current behaviour as a validated baseline, design a falsifiable experiment, measure gain and regression, produce inspectable evidence, and record a directional verdict plus a /sy:plan-ready brief when warranted.

54 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use competitor-news-monitor, blocked-page-recovery and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • aivrarSkill

    competitor-news-monitor

    Watch named companies for material news; cited digests.

    Also in 6 projects that use this

  • aivrarSkill

    blocked-page-recovery

    Recover blocked/paywalled/WAF'd pages via fallbacks.

    Also in 6 projects that use this

  • john-data-chenSkill

    teams-meeting-pipeline

    Operate the Teams meeting summary pipeline via Hermes CLI — summarize meetings, inspect pipeline status, replay jobs, manage Microsoft Graph subscriptions.

    Also in 8 projects that use this

  • john-data-chenSkill

    touchdesigner-mcp

    Control a running TouchDesigner instance via twozero MCP — create operators, set parameters, wire connections, execute Python, build real-time visuals. 36 native tools.

    Also in 5 projects that use this

  • Tommy-ywSkill

    songwriting-and-ai-music

    Songwriting craft, AI music generation prompts (Suno focus), parody/adaptation techniques, phonetic tricks, and lessons learned. These are tools and ideas, not rules. Break any of them when the art calls for it.

    Also in 8 projects that use this

  • mae616Skill

    p5js

    p5.js(クリエイティブコーディング)のProcessing由来「コードでスケッチ」思想を軸に、setup/drawループ・座標系・インタラクション・パフォーマンス最適化を整理する。p5.js、Processing、クリエイティブコーディング、ジェネラティブアート、インタラクティブ表現、ビジュアルプログラミング、Canvas描画、パーティクル、フラクタル、ノイズ表現に関する相談で必ず使うこと。ユーザーが「コードでアート」「動くビジュアル」「インタラクティブな描画」と言った場合にも適用する。

    Also in 8 projects that use this

  • +4 more from aivrar

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 3 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 50 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before anything else, run the tracker preflight (${CLAUDE_PLUGIN_ROOT}/skills/shared/references/preflight.md).

    line 17
  2. Distinctive:

    If the problem still does not reproduce, report that plainly.

    line 45
  3. Distinctive:

    Every material empirical or spatial claim must be directly inspectable through a figure, table, or compact numeric evidence.

    line 64
  4. Distinctive:

    Create one standalone, reproducible artifact folder with:

    line 72
  5. Very specific:

    Before posting it, pressure-test the directional conclusion with sy:debate — unconditionally, not only when the result looks contested: …

    line 87
  6. Very specific:

    If the idea clears the bar, write a /sy:plan brief that states the opportunity, evidence, success bar, constraints, failure modes, and the …

    line 101
  7. Very specific:

    Every subagent dispatch resolves its model and effort from config and passes them as the Agent invocation's actual model and effort …

    line 105

“Common” is measured: kept by at least 6 in 10 of the 50 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Answer: is this idea worth a proper project? Produce a reproducible exploratory artifact and directional verdict, not production code.

$ARGUMENTS

Before anything else, run the tracker preflight (${CLAUDE_PLUGIN_ROOT}/skills/shared/references/preflight.md); a failure stops here with its single ## Action needed block, before any baseline work starts.

Create/load the spike Task via the tracker skill: discover candidate hackday Epics in the configured project (owned by the tracker skill), let the user choose the parent via AskUserQuestion (${CLAUDE_PLUGIN_ROOT}/skills/shared/references/user-interaction.md), create the Task, set it in-progress, and self-assign. Keep tracker command mechanics in the tracker skill (/sy:tracker), not here.

Routing

  • small cohesive evidence ⇒ read directly;
  • broad archaeology ⇒ sy:sweep;
  • one load-bearing production/data path ⇒ sy:trace, at most the resolved limits.max_depth_agents cap in flight — resolve per ${CLAUDE_PLUGIN_ROOT}/skills/shared/references/config-values.md.

Returned briefs are leads. Verify decisive spans and own the experimental conclusions. Seed every agent prompt with known anchors — paths, symbols, data locations — and name ground already covered.

1. Establish the baseline

Locate the real production behaviour and enough representative data to reproduce it offline. Treat production as a baseline/reference implementation, not an oracle: the experiment may exist because production is wrong.

Validate baseline fidelity against known examples before comparing alternatives. Record any irreducible mismatch.

2. Validate reproduction

A failed reproduction is not yet a negative result. First verify:

  • premise;
  • data selection;
  • baseline fidelity;
  • ordering/configuration assumptions;
  • sampling bias.

If the problem still does not reproduce, report that plainly. Do not manufacture a positive result.

3. Design the experiment

Define:

  • falsifiable success bar;
  • comparison baseline;
  • primary metric(s);
  • regression metric(s) in the opposite direction;
  • representative and adversarial slices;
  • controls for leakage/confounding where relevant.

Surface to the user via AskUserQuestion only when a load-bearing choice changes the experiment or verdict interpretation.

4. Measure gain and regression

Measure both directions: improvement and what gets worse. Use representative shapes and report uncertainty/sampling limits. Prefer direct metrics over proxy storytelling.

Every material empirical or spatial claim must be directly inspectable through a figure, table, or compact numeric evidence. Do not force a chart where a table or scalar is clearer.

5. Stress-test sampling

Probe boundary cases, failure clusters, and slices where the proposed approach should plausibly lose. Look specifically for evidence against the preferred hypothesis.

6. Produce the artifact

Create one standalone, reproducible artifact folder with:

  • README/run instructions;
  • data anchors or retrieval instructions;
  • baseline reproduction;
  • alternative implementation;
  • metrics in both directions;
  • figures/tables/numeric evidence;
  • limitations and unresolved questions;
  • exact environment/commands needed to rerun.

Repository-specific plotting/style defaults belong to repository standards, not this generic skill.

7. Record the verdict

Before posting it, pressure-test the directional conclusion with sy:debate — unconditionally, not only when the result looks contested: even a clear-looking gain/regression measurement can hide a confound, a sampling bias, or a stronger alternative explanation that only an adversary surfaces. See ${CLAUDE_PLUGIN_ROOT}/skills/shared/references/debate.md.

Post a tracker verdict comment. Its human part is the call being made:

  • TL;DR verdict;
  • strongest failure cases;
  • recommendation: stop, iterate another spike, or start /sy:plan.

Its agent_detail part is what a later session reruns or cites from:

  • headline gain and regression numbers;
  • baseline-fidelity confidence;
  • artifact path/link.

If the idea clears the bar, write a /sy:plan brief that states the opportunity, evidence, success bar, constraints, failure modes, and the next unanswered project-level questions. Link it from the verdict.

Set the spike Task's status to done via the tracker skill only after the verdict is durable. End with the Task key/link, artifact path, verdict, and /sy:plan <brief> kickoff when applicable.

Every subagent dispatch resolves its model and effort from config and passes them as the Agent invocation's actual model and effort parameters, per ${CLAUDE_PLUGIN_ROOT}/skills/shared/references/model-dispatch.md; a nested dispatch inherits nothing and must resolve again.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.