# Inherited Claims > How to treat conclusions inherited from an earlier session — handover notes, prepared comments, verdict files, plans. Use whenever a task starts from context you did not derive yourself, or resumes work described by a previous session. - Skill: `werf/inherited-claims` (Agent Skill) - Install (CLI): `npx skillmds@latest add werf/inherited-claims` - Raw SKILL.md: https://api.skillmd.com/api/skills/werf/inherited-claims/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: werf (https://skillmd.com/u/werf) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/werf/inherited-claims --- # Inherited Claims A conclusion carried in from somewhere else is a claim, not a finding — no matter how confident its wording or how detailed its citations. Handover notes, prepared comment texts, verdict files, plans, an issue's own body, a previous agent's summary: all of them were true about a codebase that may no longer exist. The repo itself carries claims too: a merged PR's title and body, a changelog entry, a migration guide, a release note. Those describe what someone intended to do, not necessarily what shipped. ## Rules - Re-derive every inherited claim from the primary source — the code, the API, the config, the actual command output — before it reaches anywhere a human will read it: a tracker comment, a PR description, a card, a message to the user. - "X was removed/changed in version N" is a claim even when a merged PR title and the shipped documentation both say it. Check the call site at the released ref — `git show : | grep ` — before ruling a behavior out or in. Removing the flag that *disables* a check is not removing the check; a PR can land its own description's headline only in part, and the guide written from that description then documents behavior the code never had (paid in full: a check documented as removed in a migration guide, still executing in the released binary, blamed for nothing until its cost showed up as a 3.6-hour rebuild). - Re-derive the *reason*, not just the verdict. "Close this as obsolete" may be right while the sentence explaining why is invented; publishing the invented sentence is the damage. - When an inherited note states a convention and a skill covers the same ground, the skill wins. Load the skill and follow it; do not act on the remembered version. - Quote what you verified with a `file:line`, a flag default, a response body. If a claim cannot be checked cheaply, drop it from the text rather than softening it — a hedge still reads as an assertion. - Batching is where this fails. A pile of pre-written items feels like work already done; it is a pile of unverified claims, and approving them as a batch means publishing them as a batch. ## Why this matters more than it looks Being wrong in public, in the user's name, costs more than having nothing to say. A stale claim in a tracker is read as the maintainer's position, gets quoted back, and outlives the session that produced it.