inherited-claims

Re-verify conclusions inherited from prior sessions against primary sources before publishing.

4.7k|238|Updated Jan 25, 2016
One-click install
npx skills add https://github.com/werf/werf --skill inherited-claims
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: inherited-claims
Source: https://github.com/werf/werf/tree/main/.agents/skills/inherited-claims
Command: npx skills add https://github.com/werf/werf --skill inherited-claims

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Handover notes, prepared comments, verdict files, and previous session summaries contain claims that may no longer match the current codebase, and publishing them unverified puts stale or invented statements in the user's name.

Core Features & Use Cases

  • Claim Re-derivation: Requires every inherited conclusion to be re-derived from primary sources such as code, APIs, configs, and actual command output before it reaches a tracker comment, PR description, or message.
  • Reason Verification: Distinguishes correct verdicts from invented explanations, ensuring the stated reason for an action is checked, not just the action itself.
  • Batch Review Guard: Treats piles of pre-written items as unverified claims rather than completed work, preventing bulk approval of stale content.
  • Use Case: When resuming a task from a previous agent's summary claiming a feature was removed in a release, check the call site at the released tag with git show before repeating that claim in an issue comment.

Quick Start

Load this skill whenever a task starts from handover notes or a previous session's conclusions, then verify each inherited claim against the current code before publishing anything.

Frequently Asked Questions about inherited-claims

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify claims from a previous session's handover notes?

Re-derive each claim from the primary source: the code, API, config, or actual command output. For version claims, check the call site at the released ref with git show <tag>:<path> before repeating the conclusion anywhere a human will read it.

What counts as an inherited claim in a coding task?

Handover notes, prepared comment texts, verdict files, plans, issue bodies, previous agent summaries, and even merged PR titles, changelog entries, and migration guides. All describe intent or a past state, not necessarily the current code.

Can I trust a merged PR description about removed behavior?

No. A PR can land its description's headline only in part, and guides written from it may document behavior the code never had. Check the actual call site at the released tag before ruling a behavior in or out.

What should I do when an inherited claim cannot be verified cheaply?

Drop it from the text rather than softening it, since a hedge still reads as an assertion. Only publish claims you can back with a file and line reference, a flag default, or a response body.

Why is batch approving pre-written comments risky?

A pile of pre-written items feels like finished work but is actually a pile of unverified claims. Approving them as a batch publishes them as a batch, including any stale or invented statements they contain.