원클릭으로 Manus에서 모든 스킬 실행

correction-propagation

스타2

포크1

업데이트2026년 7월 11일 19:27

When a published claim is corrected, retracted, downgraded, superseded, or reversed, sweep EVERY surface that restates it - sibling docs, other repos, mirrors, READMEs, indexes, memory files - and banner or supersede each in the SAME closeout before it's done. Activate on "I corrected/retracted/updated X", a metric downgraded, a status flipped, a conclusion reversed, a benchmark restated elsewhere, "did the correction propagate", closeout after a correction, or a claim in more than one repo/doc. Method: grep the claim's distinctive tokens (number, phrase) across ALL surfaces, top-of-file first.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

ralfyishere

ralfyishere/rules-with-receipts

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Correction Propagation

Purpose

The pack can MAKE claims (verification-discipline) and ATTACK them (adversarial-verify), but nothing owns RETRACTING one after it has spread. A claim rarely lives in one place: the same number, verdict, or headline gets restated in sibling docs, other repos, the public mirror, READMEs, indexes, issue trackers, and memory files. When that claim is corrected — downgraded, superseded, reversed, disproved — fixing the doc you happened to be looking at leaves every other copy asserting the old, now-wrong version. Readers land on the stale one and act on it.

This skill makes correction a sweep, not a spot-edit: name the claim's distinctive greppable tokens, enumerate every surface that could restate it, grep them all, banner or supersede each hit top-of-file first and dated, then re-grep to prove the sweep is clean. Only then is the correction done. It is the difference between "I fixed the README" and "the string '3/3' now appears in three repos, each bannered or deleted, re-grep returns only bannered hits."

When to use this skill

You just corrected, retracted, downgraded, or reversed a claim you had published.
A metric changed value, a status flipped (confirmed → disproved), or a conclusion reversed.
A benchmark, number, or verdict you're fixing is restated somewhere else too.
Someone asks "did the correction propagate?" or "is this still cited anywhere?"
Closeout of any session where a correction happened.
A claim that appears in more than one repo, doc, mirror, or memory file.

When NOT to use

The claim never left one file and nothing restates it — a single edit is the whole job.
You're making or grading a fresh claim, not changing one already out — that's verification-discipline / empirical-validation.
The change is additive (new claim) and contradicts nothing previously published.
Pure session-context staleness with no cross-artifact surfaces — that's memory-hygiene.

The procedure

Name the claim's distinctive, greppable tokens. The number, the exact phrase, the label — "3/3", "9/12", "replicated", "confirmed", the strategy name. Pick tokens specific enough to grep without drowning in false hits; too vague to grep = can't sweep it.
Enumerate EVERY surface that could restate it before grepping one: this doc, sibling docs in the same tree, other repos, the public mirror/clone, READMEs, overview/index files, issue trackers, changelogs, and memory files. Write the list — the miss is always a surface you didn't think to check, not a token that didn't match.
Grep all of them for the tokens. Every surface on the list, not just the file in hand. Include the public mirror path when the claim crossed the public boundary.
Banner, supersede, or delete each hit — top-of-file first, dated. A reader who lands mid-doc must see the correction, so the fix goes at the top (or wherever leads), not only at the buried line. State the old claim, the correction, and the date.
Verify the sweep. Re-grep the tokens across all surfaces; the only hits left are the ones you intentionally bannered or kept. An un-bannered hit = the sweep isn't done.
Only then is the correction done. "Fixed the one I was looking at" is not a corrected claim; a clean re-grep across all surfaces is.

Quality bar

No surface still asserts the old claim un-bannered — verified by a final re-grep, not by memory.
The correction is visible top-of-file (or wherever the doc leads), not buried below stale text.
The sweep covered other repos, the mirror, indexes, and memory files — not just the file in hand.
Each banner is dated and states what changed, so a later reader can trust it.

Common failure modes

Corrected the one I was looking at: the classic — fix the doc in focus, leave every sibling copy stale. The trigger for this skill is precisely "there is more than one copy."
Buried correction: the fix lands at line 31 but line 7 still leads with the wrong claim. A mid-doc reader never scrolls to the retraction. Fix top-of-file first.
Cross-repo blindness: repo A is fixed, repo B still cites the retracted number. The public mirror is the most common blind spot — it's a separate surface.
Token too vague to grep: the claim can't be searched, so the sweep silently misses copies. If the tokens don't isolate the claim, that's the first thing to fix.

Works with sibling skills

verification-discipline labels a claim's evidence level WHEN it's made; this skill propagates a CHANGE to a claim already published — one owns the birth, the other owns the retraction. memory-hygiene handles session-context-vs-observation staleness; this handles cross-artifact, cross-repo surfaces that outlive the session. session-orientation's closeout owns updating the map; this is a closeout duty whenever a correction happened. publish-hygiene guards leaks and metadata across the public boundary; this guards claim consistency across that same boundary.

Provenance and maintenance

Added 2026-07-09 after a cross-repo audit found a disproven benchmark claim — "only the always-on rules flagged it 3/3" — corrected in one public repo (rules-with-receipts) but still asserted in a sibling public repo (agent-failure-modes, AFM-3), and an internal AB-SNIPPET doc whose title still read "confirmed" after the result was disproved; separately, an analysis's published verdict was never amended after its own successor commit reversed it. In each case the correction was made in one place and never propagated. Re-verify by grepping a corrected claim's distinctive tokens across all repos after any correction — a hit that isn't bannered is this skill's trigger having failed.

이 저장소의 다른 Skills

같은 저장소

foresight

ralfyishere/rules-with-receipts

Project the trajectory before committing - pre-register dated, credenced predictions about what breaks, what becomes necessary, and what pays off 5/10/20 steps ahead, then resolve them when the future arrives and score your calibration. Activate when starting any build, plan, or strategy; making architecture, roadmap, scaling, or investment bets; choosing between directions; or shipping something whose problems will surface later. Trigger signals: "will this scale", "what will we regret", "where does this break at 10x", "what will we need by then", a plan whose risk section only covers the present, or a direction justified only by today's constraints.

2026-07-112

deep-decomposition

ralfyishere/rules-with-receipts

Break hard tasks into smaller solvable units with explicit dependencies and unknowns. Activate when a task feels too big to plan in one pass — large features, migrations, research questions with many sub-questions, multi-part documents, business analyses, gnarly debugging with several possible fault lines, or anything where the honest answer to "what's step 4?" is "no idea yet". Trigger signals: the user asks for something "end to end", "the whole thing", a system rather than a change, or you notice your plan has steps like "figure out the rest".

2026-07-112

discovery-loop

ralfyishere/rules-with-receipts

Keep generating and testing NEW hypotheses against a live domain instead of stopping at a closed verdict - observe what is actually succeeding, log a belief-state with credence, attack every confirmation streak. Activate in any standing investigation (an edge, a root cause, a market, a growth lever, a performance hunt) when a verdict doc or kill-list exists and might be read as final; when all recent evidence came from your own priors rather than observation; or when someone else is visibly succeeding at what your verdict said was impossible. Trigger signals: "we already proved that doesn't work", a rival/competitor result contradicting your conclusion, "keep looking", resuming an investigation after a closure.

2026-07-112

intent-clarity

ralfyishere/rules-with-receipts

Decode what the user actually needs before optimizing the wrong thing. Use when a request has vague referents ("fix it", "make it better", "clean this up", "improve this"), looks like a symptom-fix ("increase the timeout", "make this function faster"), is oddly specific with missing context, or would be strange taken literally. Use when a user corrects or rephrases - the delta between versions is the intent. ALWAYS use before asking any clarifying question, to check the question isn't lazy (inferable, decision-offloading, or covered by a reasonable default).

2026-07-112

leverage-first

ralfyishere/rules-with-receipts

Before committing real effort to a chosen approach, spend a cheap cycle to find the higher-leverage path - an existing solution/tool/dataset, a more efficient method, or a smarter composition - instead of grinding the first workable idea on one track. Activate when about to build a tool, collect data the slow way, or write a lot of code; on "is there a better way", "what else could we try", "how should we do this"; or when you catch yourself about to hand-roll something, poll/scrape in a loop, or test one pet hypothesis. Signals: the obvious grind; about to reinvent something.

2026-07-112

open-mandate

ralfyishere/rules-with-receipts

Handle explicitly delegated judgment - "do whatever you think is needed", "you decide what's next", "keep going", standing autonomous sessions. Activate when the user hands you the prioritization itself rather than a task: no deliverable is named, and choosing what to work on IS the work. Trigger signals: "do what you think", "whatever's next", "take it from here", "surprise me", or resuming an autonomous session with no fresh instruction. NOT for ambiguous requests (that's intent-clarity - there IS a task, it's just underspecified).

2026-07-112

name

Correction Propagation

description

Correction Propagation

Purpose

When to use this skill

You just corrected, retracted, downgraded, or reversed a claim you had published.
A metric changed value, a status flipped (confirmed → disproved), or a conclusion reversed.
A benchmark, number, or verdict you're fixing is restated somewhere else too.
Someone asks "did the correction propagate?" or "is this still cited anywhere?"
Closeout of any session where a correction happened.
A claim that appears in more than one repo, doc, mirror, or memory file.

When NOT to use

The claim never left one file and nothing restates it — a single edit is the whole job.
You're making or grading a fresh claim, not changing one already out — that's verification-discipline / empirical-validation.
The change is additive (new claim) and contradicts nothing previously published.
Pure session-context staleness with no cross-artifact surfaces — that's memory-hygiene.

The procedure

Name the claim's distinctive, greppable tokens. The number, the exact phrase, the label — "3/3", "9/12", "replicated", "confirmed", the strategy name. Pick tokens specific enough to grep without drowning in false hits; too vague to grep = can't sweep it.
Enumerate EVERY surface that could restate it before grepping one: this doc, sibling docs in the same tree, other repos, the public mirror/clone, READMEs, overview/index files, issue trackers, changelogs, and memory files. Write the list — the miss is always a surface you didn't think to check, not a token that didn't match.
Grep all of them for the tokens. Every surface on the list, not just the file in hand. Include the public mirror path when the claim crossed the public boundary.
Banner, supersede, or delete each hit — top-of-file first, dated. A reader who lands mid-doc must see the correction, so the fix goes at the top (or wherever leads), not only at the buried line. State the old claim, the correction, and the date.
Verify the sweep. Re-grep the tokens across all surfaces; the only hits left are the ones you intentionally bannered or kept. An un-bannered hit = the sweep isn't done.
Only then is the correction done. "Fixed the one I was looking at" is not a corrected claim; a clean re-grep across all surfaces is.

Quality bar

No surface still asserts the old claim un-bannered — verified by a final re-grep, not by memory.
The correction is visible top-of-file (or wherever the doc leads), not buried below stale text.
The sweep covered other repos, the mirror, indexes, and memory files — not just the file in hand.
Each banner is dated and states what changed, so a later reader can trust it.

Common failure modes

Corrected the one I was looking at: the classic — fix the doc in focus, leave every sibling copy stale. The trigger for this skill is precisely "there is more than one copy."
Buried correction: the fix lands at line 31 but line 7 still leads with the wrong claim. A mid-doc reader never scrolls to the retraction. Fix top-of-file first.
Cross-repo blindness: repo A is fixed, repo B still cites the retracted number. The public mirror is the most common blind spot — it's a separate surface.
Token too vague to grep: the claim can't be searched, so the sweep silently misses copies. If the tokens don't isolate the claim, that's the first thing to fix.