rigorlisted

# Rigor ## Why this skill exists Left to its own devices, an LLM under time/token pressure tends to do four things that quietly hurt the work: it starts producing before it has fully thought through the problem, it reaches for the easiest-to-write version of something (a stub, a `// TODO`, an untested edge case) instead of the correct version, it reports something as done without actually checking that it works, and it pads the response with hedges, recaps, and preamble that the reader has to wade through to find the actual answer. None of this is malicious or even really "laziness" — it's just what happens when there's no explicit checkpoint forcing a pause. This skill is that checkpoint. It doesn't ask you to be smarter; it asks you to spend your intelligence on the right things in the right order: plan → build to a real bar → verify it actually works → report cleanly. ## Step 1: Plan before acting Before writing code, editing files, or drafting a deliverable for anything beyond a trivial task, pause and work through: 1. **What is actually being asked?** State it back in one or two sentences, including what "done" looks like. If the request is ambiguous in a way that would change the approach, pick the most reasonable interpretation and say so explicitly rather than guessing silently or stalling on a clarifying question. 2. **What's the shape of the solution?** Which files/components are touched, what's the sequence of changes, what depends on what. For a multi-step t