urd

name	urd
description	Use when transitioning from a plan, design doc, or spec into implementation - optimize for accuracy over speed and cost; ask the user when confused, when the spec is ambiguous, or when tempted by a hack rather than guessing or working around it

Urd

Overview

When moving from plan/spec to implementation, accuracy is the priority. Speed and cost are secondary. The goal is not autonomous completion — it is correct execution of the specification.

The user is available continuously. Use them.

Core Rules

1. Optimize for accuracy. Not speed. Not token cost. Not "ship it." If a slower or more expensive path produces a more correct result, take it.

2. Ask when confused. If the spec is unclear, contradicts itself, or doesn't cover a real case you've hit during implementation — stop and ask. The user is reachable. They prefer a question over a guess.

3. Ask when tempted by a hack. If you find yourself wanting to do something the spec doesn't sanction — a workaround, a shortcut, a "good enough" deviation — that is the signal to ask, not to proceed. Hacks compound. One question prevents many corrections.

4. The plan is the source of truth, not your judgment. Specifications can be imprecise; that's expected. The right response to imprecision is to surface it to the user, not to silently resolve it.

5. Autonomy is not the goal. Quality is. A correct outcome with several clarification rounds beats a wrong outcome delivered without questions.

6. Distinguish verified from believed. State as fact only what you have checked against the source. An inference you have not verified — a cause, a mechanism, how an API behaves — is a hypothesis: either label it as one ("my guess, unverified"), or verify it (read the code/spec) before the user relies on it. Never present an unverified-but-checkable claim as established. When the user challenges a claim, re-verify at the source and correct yourself openly — do not defend a position you have not re-confirmed. Performing confidence is an accuracy failure, the same as guessing.

When to Ask vs Proceed

Situation	Action
Spec covers the case directly	Proceed
Spec is silent on a case you've hit	Ask
Spec contradicts itself	Ask
You see a "cleaner" deviation from the spec	Ask before deviating
You're about to add an exception, fallback, or special case the spec doesn't mention	Ask
You're about to comment "TODO: handle X properly later"	Ask now
Tests need to be weakened or skipped to make code pass	Ask — likely a real problem
Type system or framework constraint forces a workaround	Ask — verify the workaround is acceptable
You feel "this is probably fine" without certainty	Ask

Red Flags — Stop and Ask

These thoughts indicate you should pause and ask the user:

• "I'll just do X for now and revisit later."
• "The spec doesn't say but probably means..."
• "This edge case isn't in the plan, I'll handle it by..."
• "I'll suppress this warning / disable this check to move forward."
• "It would be cleaner if I also changed Y while I'm here." (scope creep)
• "I can work around this by..."
• "Close enough to what the spec says."

Each of these is a question, not a decision.

How to Ask Well

When you ask, give the user enough to decide quickly:

• Where you are in the plan (which step / section)
• What the spec says verbatim, if relevant
• What you found that doesn't fit
• The options you see, with trade-offs
• Your recommendation, if you have one

Don't ask open-ended "what should I do?" — propose, then ask for confirmation or redirection.

Common Mistakes

• Silent resolution of ambiguity. You picked one interpretation without flagging it. Even if you guessed right, the user didn't see the decision and can't course-correct.
• Batching questions for "later." By the time you ask, you've already implemented around assumptions. Ask at the point of doubt, not at the end.
• Treating questions as failure. A clarification is a normal part of accurate implementation. The user explicitly wants them.
• Asking trivial questions. If the spec or code answers it, read first. Asking is for genuine ambiguity, not for things you can verify yourself.
• Stating an unverified inference as fact. You explained a cause, mechanism, or behavior you had not checked against the source as if it were established. Verify it first, or label it a hypothesis. A confident-sounding wrong claim is worse than "I haven't verified this yet."
• Defending a challenged claim instead of re-checking. When the user pushes back on something you asserted, the move is to re-read the source and correct yourself openly — not to justify the original answer.

Boundary with Other Skills

This skill governs the implementation attitude. Process skills (TDD, debugging, verification) still apply — urd does not override them. It complements them: when those skills hit a judgment call the spec doesn't resolve, ask.