agentsclimarketplace
Sign in

Negative results ledger

Skill huguryildiz/ALETHEIA/skills/extended/negative-results-ledger

Use when an idea, approach, or experiment fails, dead-ends, or gets abandoned — recording it in one line so it is never re-attempted from scratch and never silently buried. Also use when a negative or infeasibility result might itself be a finding, and when auditing a project for unrecorded dead ends. Trigger phrases: "that didn't work", "abandon this approach", "record the dead end", "why didn't we try X" , "we tried that before", "the result was negative".From its SKILL.md

Install
npx -y skills add huguryildiz/ALETHEIA --skill negative-results-ledger

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.1 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

negative-results-ledger

Dead ends are expensive knowledge — burying them buys the same failure twice. The contract: every abandoned approach leaves at least one line — what was tried, why it died, where the evidence is — in a place the next person (or the same person, six months later) will actually search. And a rigorous negative result is promoted, not just logged: infeasibility with evidence can be a primary finding.

When to use

  • An approach is being abandoned — algorithmic idea, modeling variant, tooling attempt, data source that didn't pan out.
  • A run produced a negative/null/infeasible outcome and someone is tempted to "just not mention it".
  • Before starting something that feels familiar: check the ledger first.
  • Pre-paper sweep: which dead ends belong in the text (limitations, "we also tried")?

When NOT to use

  • Bugs — a broken implementation is fixed or filed, not memorialized as a negative result. Only record it here if the approach itself was abandoned because of what the bug revealed.
  • Deferred-not-dead ideas — those are decision-log entries with status deferred.
  • Every failed exploratory cell in a notebook — the ledger records abandoned directions, not every red cell on the way.

The ledger

A single tracked file (recommended: docs/negative_results.md), newest first, one line per entry — with a link when evidence exists:

- YYYY-MM-DD — **<what was tried>**: <why it died — one clause>. Evidence: <link or "none, reasoning only">. See D<NN> if a decision was involved.

The bar for an entry is deliberately low (one line, ≤30 seconds); the bar for skipping one is high — "too minor to record" is how the same dead end gets re-explored quarterly.

Escalation ladder (one line is the floor, not the ceiling)

  1. One-liner (default) — the ledger line above.
  2. Rejected decision — the dead end settled a real design question → decision-log entry with status rejected; the ledger line points to it.
  3. Build-log entry — the failure came from a real campaign with numbers → the evidence and its interpretation get a build-log entry (write-once, citable), and the ledger line points to it.
  4. Primary finding — the negative result answers the research question (an infeasibility that proves a constraint is binding, a null that kills a hypothesized effect). Treat it as a first-class result: full evidence chain, statistical treatment, pre-registered branch honored (evidence-convention), and a place in the paper.

Rules

  1. Never soften, never bury. Recording a negative result verbatim is a norm the phase-gate enforces (a rigorous negative is a valid closure artifact); deleting a failed branch without a ledger line is the violation.
  2. "Didn't work" needs one clause of why. "Too slow at realistic sizes", "assumption X false in our data", "upstream data unusable" — the why is what prevents the re-attempt, and it distinguishes abandoned from abandoned prematurely.
  3. Date everything. A dead end from an old code era may deserve a revisit; the date is what makes that judgment possible.
  4. Check before you start. The ledger is read at idea-triage time (the idea lifecycle: probe → adopt → retire) — a hit does not forbid retrying, it demands engaging with why it died last time.
  5. Negative results are publishable material. The limitations section, the "approaches we ruled out" paragraph, and sometimes the headline finding come straight from this ledger — keep entries paper-quality honest.

Configuration

  • {{decision_log}}, {{build_log_dir}}, {{evidence_dir}} — escalation targets.

Provenance & maintenance

Authored from the research-hygiene canon (file-drawer effect countermeasures, tried-and- failed registries), grounded in working practice: a decision log with an explicit rejected status kept in place rather than deleted, infeasible cells recorded verbatim as data, and a pre-registered infeasibility branch that fired and was promoted to the project's primary finding rather than smoothed away. See the pack's examples/ directory for the worked exemplar mapping.

Re-verify in your project:

  • test -f docs/negative_results.md && head -5 docs/negative_results.md — the ledger exists and is current (adapt the path).
  • grep -c "rejected" {{decision_log}} — rejected decisions are recorded, not deleted.
  • Ask "what did we abandon this quarter?" — if the answer is from memory rather than the ledger, the discipline has lapsed.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most finance skills give in ~1.1k tokens

Counted across 469 of the 469 authors here whose files we hold, read 2026-08-07

  • Extract date vendor amount and descriptionin 15 of 469, across 3 files
  • Scan folder for invoice filesin 14 of 469, across 2 files
  • Rename files to standard formatin 14 of 469, across 2 files
  • Show organization plan before movingin 14 of 469, across 2 files
  • Generate summary CSVin 14 of 469, across 2 files
  • Organize files by categoryin 13 of 469, across 1 file
  • Preserve original filesin 13 of 469, across 1 file
  • Flag files missing critical infoin 13 of 469, across 1 file
  • Produce the requested output filein 9 of 469, across 4 files
  • Build best, base, and worst case scenariosin 9 of 469, across 5 files
  • Implement backoff if rate limit errors occurin 8 of 469, across 3 files
  • Determine the weighted average cost of capitalin 8 of 469, across 4 files

Said here and by no other author read

  • record every abandoned approach in one line
  • include what was tried, why it died, and evidence
  • state why an approach failed in one clause
  • date every ledger entry
  • check the ledger before starting a familiar approach
  • read the ledger at idea-triage time

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.