verify-before-deciding

Validates pending task records against current source code before deciding to act.

9|Updated Mar 4, 2026
One-click install
npx skills add https://github.com/timcsy/semorphe --skill verify-before-deciding-timcsy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: verify-before-deciding
Source: https://github.com/timcsy/semorphe/tree/main/knowledge/skills/verify-before-deciding
Command: npx skills add https://github.com/timcsy/semorphe --skill verify-before-deciding-timcsy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Backlogs, roadmaps, and acceptance checklists silently drift out of sync with the codebase: items get completed without being recorded, prerequisites get resolved, and claims that were true when written become false. Acting on stale records wastes effort or re-does finished work. ## Core Features & Use Cases - Claim Verification: Copies each pending item's claim verbatim, then checks it against the code with grep and real measurements instead of trusting memory or comments. - Four Ordered Questions: Checks whether the referenced thing still exists, whether stated numbers still hold, whether the claimed blocker actually blocks, and whether someone already made an opposite decision. - Classification and Disposition: Sorts each verified item into outcomes (never existed, already done, partially true, prerequisite resolved, still blocked, guess-based) with a distinct action for each, including tombstone notes for overturned claims. - Use Case: Before starting a backlog item that says "blocked on FSA verification," run this Skill to discover the item actually uses <a download> and was never blocked at all. ## Quick Start Ask the AI to verify a specific unchecked backlog item or acceptance criterion against the current codebase before deciding whether to work on it.

Frequently Asked Questions about verify-before-deciding

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

FAQPage Schema
How do I check if a backlog item is still valid before working on it?

Copy the item's claim verbatim, then grep the referenced file, function, or field to confirm it still exists. Re-run any measurement rather than trusting numbers in comments, and verify the claimed blocker actually blocks the path described.

Why do task lists and roadmaps drift out of sync with code?

Records decay silently: items get completed without status updates, prerequisites get resolved by unrelated changes, and claims true when written become false. Nothing notifies you when a written record stops matching reality.

What should I do when a backlog item turns out to be already done?

Reclaim it: move it into the history or milestone log and add the missing transition record. Do not just delete it, because the record of completion matters for future decisions.

Should I verify multiple similar backlog items together?

No. Verify one item at a time, because adjacent items on a list may have been written months apart. Assuming a batch shares the same situation is the most expensive verification mistake.

When should verification results be recorded?

Record corrections in the persistent documentation, not just the current conversation. Leave a tombstone note for overturned claims explaining why they originally looked correct, so the same wrong idea is not rediscovered.