Skip to content
Back to skills

Spike Falsification

ASecurity

Use when validating a third-party dependency — an API, SDK, contract, or protocol — before designing on top of it, especially onchain/smart-contract dependencies. Triggers on "spike this integration", "validate this contract/SDK before we build on it", "is this really soulbound / non-transferable / read-only", "prove the API behaves like the docs say", "fork the network and test against the deployed contract", or any request to de-risk a dependency before committing to a design.

  • 4 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 22, 2026
ai-agentsrustgogitapi

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 22, 2026

npx -y skills add iamakbarsha1/whetstone --skill spike-falsification --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Spike Falsification?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Spike Falsification
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/iamakbarsha1-spike-falsification/badge)](https://www.skillsdirectory.com/skills/iamakbarsha1-spike-falsification)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: spike-falsification
description: >
  Use when validating a third-party dependency — an API, SDK, contract, or
  protocol — before designing on top of it, especially onchain/smart-contract
  dependencies. Triggers on "spike this integration", "validate this
  contract/SDK before we build on it", "is this really soulbound /
  non-transferable / read-only", "prove the API behaves like the docs say",
  "fork the network and test against the deployed contract", or any request to
  de-risk a dependency before committing to a design.
---

# Spike to Falsify, Not to Demo

**Type:** Open-source — client-agnostic methodology, no project-specific detail.

**Created by akbarsha — https://github.com/iamakbarsha1**

Distilled from an onchain spike where web research returned correct contract
signatures, but the behaviours that actually shaped the design were only caught
by executing against the deployed bytecode.

**Licence:** Released under CC BY 4.0 — share and adapt for any purpose with
credit. Full text: `LICENSE` at the repository root.

**Feedback & Support:** If a rule here proves wrong or needs sharpening, open an
issue on the repository or contact the author at the profile link above. If the
problem is the agent not following a rule below rather than the rule itself,
that's an execution failure — acknowledge and correct it.

## The core rule

Docs and research tell you the API *shape*; only executing against the
production artifact tells you its *behaviour*. A spike exists to try to
**falsify** your design assumptions — run the operation you believe is
impossible, forbidden, or already handled — not to demo the happy path. A spike
that only shows the thing working has tested nothing you were worried about.

## Checks

- **Execute against the real deployed artifact, not a mock or a local
  redeploy.** Run against the live network (fork it), the real API endpoint, or
  the actual published package version — a local reimplementation inherits your
  assumptions instead of exposing the vendor's. *(Web research returned correct
  contract signatures, but 1-based indexing and mandatory filter arguments only
  surfaced when calling the deployed bytecode on an anvil fork of the testnet.)*
- **Run at least one deliberate falsification.** Name the property your design
  depends on (immutable, soulbound, idempotent, read-only) and attempt the
  operation that would violate it; observe what actually happens rather than
  what the docs imply. *(A token assumed soulbound was in fact transferable —
  caught only by attempting the transfer, before a whole access model was built
  on the false assumption.)*
- **Keep an honest friction log.** Record every surprise, gotcha, and dead end
  in the findings doc, not just the path that worked — the friction is the
  reusable output of a spike. *(anvil's well-known default accounts carry
  contract code on public testnets, which silently breaks `_safeMint`'s
  onReceived callback; the fix — fund fresh EOAs with `anvil_setBalance` — is
  worthless to the next spike unless it's written down.)*

## Pre-flight check — before you trust a spike's conclusions

- [ ] The spike ran against the real deployed artifact (forked live network for
      onchain), not a mock, stub, or local redeploy.
- [ ] You attempted at least one operation your design assumes cannot happen,
      and recorded the actual result — not the documented one.
- [ ] The findings doc logs every surprise and gotcha hit, not only the
      happy-path result.
- [ ] Any check whose grounding case is domain-specific (e.g. anvil/EVM) was
      applied as an example of the pattern, not copied verbatim to an unrelated
      stack.

If any box is unchecked, you have a demo, not a spike — go try to break the
assumption you're about to build on.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.