agentleFS
huguryildizhuguryildiz/ALETHEIA/skills/extended/external-positioning/SKILL.md

external-positioning

Skill0 starsChanged 4 months agoMITView on GitHub

Use when a claim is about to face the outside world — classifying what is novel versus known, scoping claims to what the evidence supports, holding the figure-regeneration bar (every kept figure rebuilds from one command), and holding the reproducibility bar before anything enters a draft. Trigger phrases: "is this novel", "position against the literature", "are we over-claiming", "regenerate the figure", "can we rebuild all figures", "ready for submission", "what's our contribution". (Citation verification lives in `lit-anchor`.)

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep a claims ledger (a section in the paper-planning doc or a standalone file): each paper-bound claim classified and anchored —

    line 31
  2. Distinctive:

    One command per figure: Every kept figure regenerates via a single recorded command (a plotting script or notebook cell path + arguments) …

    line 53
  3. Very specific:

    Map figure → generator → data: Keep the mapping discoverable: a figure registry in the docs, or a naming convention (fig3_<topic> generated …

    line 56
  4. Very specific:

    Regenerate on upstream change: When the evidence data or plotting code changes, the figure is stale until re-run — treat committed stale …

    line 61
  5. Distinctive:

    Fix the source, then the story: When positioning review finds an unsupported claim, the evidence gets strengthened or the claim gets …

    line 94

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

external-positioning

The project's claims will be read by skeptical strangers. This skill keeps the external story honest before it ships: novelty is bookkept rather than felt, citations are verified rather than pattern-matched, claim strength is scoped to evidence strength, and nothing enters a draft that a reviewer could not reproduce from the record.

When to use

  • Writing or reviewing contribution statements, abstracts, related-work sections.
  • Adding any citation to the project record.
  • A claim is about to travel — paper draft, talk, README, funding text.
  • Pre-submission: the full positioning + citation + reproducibility sweep.

When NOT to use

  • Internal decisions and their rationale — decision-log.
  • The statistical form of a result — statistical-reporting.
  • Verifying and formatting citations — lit-anchor (the sole citation authority).

Novelty bookkeeping

Keep a claims ledger (a section in the paper-planning doc or a standalone file): each paper-bound claim classified and anchored —

  • novel — no prior work found doing this; the search that failed to find it is recorded (venues/queries/date), because "we found nothing" is an auditable statement;
  • known, applied — exists elsewhere, new in this setting; cite the origin;
  • confirmation / negative — replicates or refutes something; cite what it tests.

A novelty claim without a recorded search is a feeling with formatting. Re-run the search near submission — the literature moved while you worked.

Citations

Citations: see lit-anchor (the sole citation authority) — individual DOI resolution, distrust of bulk-generated bibliographies, the abstract-only-cannot-carry-a-load-bearing-claim rule, and tracked citation debt all live there.

Figure regeneration

A figure that cannot be regenerated from one command does not go in the paper. No exceptions at submission time; the time to enforce is at creation time.

  1. One command per figure. Every kept figure regenerates via a single recorded command (a plotting script or notebook cell path + arguments) reading tracked code and evidence data — no manual pipeline of clicks.
  2. Map figure → generator → data. Keep the mapping discoverable: a figure registry in the docs, or a naming convention (fig3_<topic> generated by a function/script of the same name), plus the evidence directory it reads.
  3. No hand-edited figures. Annotations, croppings, and style fixes go into the plotting code; a figure edited in an image editor is unregenerable by construction.
  4. Regenerate on upstream change. When the evidence data or plotting code changes, the figure is stale until re-run — treat committed stale figures as drift (layer-sync).
  5. Pre-submission sweep: rebuild every paper figure from scratch and diff against the committed versions; investigate any mismatch.

Claim scoping (honesty labels)

Scope every claim to its evidence tier, in the text itself:

  • calibrated measurement → claim the number;
  • physics/theory-grounded model without calibration → claim shape and ranking, label the absolute values "to be calibrated";
  • design operating point → say so ("chosen design point", not "optimal");
  • single-setting evidence → claim the setting, not the universe ("in our configuration").

Over-claiming is the cheapest thing a reviewer can catch and the most expensive to walk back; the label costs one clause.

The reproducibility bar (before any claim travels)

A claim may enter a draft only when its chain is complete: evidence directory with meta (evidence-convention), environment + input + seed provenance (run-provenance), statistical treatment (statistical-reporting), regenerable figures (above), and verified citations (lit-anchor). The pre-submission sweep re-checks the chain end-to-end for every headline claim.

Rules

  1. The contribution list is written against the ledger, not from memory — every "we are the first to X" traces to a recorded search.
  2. Negative and boundary results go in the story — a mapped dead end or a binding constraint (negative-results-ledger) positioned honestly reads as rigor, not weakness.
  3. Every number in the abstract exists in a table with N and uncertainty behind it.
  4. Fix the source, then the story. When positioning review finds an unsupported claim, the evidence gets strengthened or the claim gets weakened — the wording never bridges the gap alone.

Configuration

  • {{evidence_dir}}, {{decision_log}} — where claim chains and their decisions live.

Provenance & maintenance

Authored from the scholarly-integrity canon (novelty auditing, citation verification, calibrated claim language), grounded in working practice: a one-at-a-time identifier verification protocol adopted after machine-generated references were caught fabricating entries; an explicit full-text-before-submission obligation for abstract-only sources; and shipped claims scoped as physics-grounded shape/ranking with absolute calibration labeled future work. See the pack's examples/ directory for the worked exemplar mapping.

Re-verify in your project:

  • Pick two random bibliography entries; resolve their identifiers and check they support their citing sentences.
  • grep -rn "TODO.*cite\|abstract-only\|UNVERIFIED" docs/ | head — citation debt is marked, and shrinking.
  • For one headline claim, walk the chain: draft sentence → table → evidence dir → meta → seeds. Any missing link fails the bar.

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.