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
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.
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.
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.
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.
Autonomy is not the goal. Quality is. A correct outcome with several clarification rounds beats a wrong outcome delivered without questions.
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.
1---2name: urd3description: 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 it4---56# Urd78## Overview910When 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.1112The user is available continuously. Use them.1314## Core Rules15161. **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.17182. **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.19203. **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.21224. **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.23245. **Autonomy is not the goal.** Quality is. A correct outcome with several clarification rounds beats a wrong outcome delivered without questions.25266. **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.2728## When to Ask vs Proceed2930| Situation | Action |31|-----------|--------|32| Spec covers the case directly | Proceed |33| Spec is silent on a case you've hit | Ask |34| Spec contradicts itself | Ask |35| You see a "cleaner" deviation from the spec | Ask before deviating |36| You're about to add an exception, fallback, or special case the spec doesn't mention | Ask |37| You're about to comment "TODO: handle X properly later" | Ask now |38| Tests need to be weakened or skipped to make code pass | Ask — likely a real problem |39| Type system or framework constraint forces a workaround | Ask — verify the workaround is acceptable |40| You feel "this is probably fine" without certainty | Ask |4142## Red Flags — Stop and Ask4344These thoughts indicate you should pause and ask the user:4546- "I'll just do X for now and revisit later."47- "The spec doesn't say but probably means..."48- "This edge case isn't in the plan, I'll handle it by..."49- "I'll suppress this warning / disable this check to move forward."50- "It would be cleaner if I also changed Y while I'm here." (scope creep)51- "I can work around this by..."52- "Close enough to what the spec says."5354Each of these is a question, not a decision.5556## How to Ask Well5758When you ask, give the user enough to decide quickly:5960- **Where you are** in the plan (which step / section)61- **What the spec says** verbatim, if relevant62- **What you found** that doesn't fit63- **The options** you see, with trade-offs64- **Your recommendation**, if you have one6566Don't ask open-ended "what should I do?" — propose, then ask for confirmation or redirection.6768## Common Mistakes6970- **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.71- **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.72- **Treating questions as failure.** A clarification is a normal part of accurate implementation. The user explicitly wants them.73- **Asking trivial questions.** If the spec or code answers it, read first. Asking is for genuine ambiguity, not for things you can verify yourself.74- **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."75- **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.7677## Boundary with Other Skills7879This 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.
krzysztofdudek