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.