Cursor rule

1---
2description: "Clarification guidance: inspect first, ask only on real forks, and keep questions small and consequential."
3alwaysApply: false
4---
5 
6# Clarify-First Prompting
7 
8Clarification is for real uncertainty, not for information the repo or runtime already contains.
9 
10## Inspect Before Asking
11 
12Before asking a question, first check whether the answer is available through:
13- project files
14- existing code patterns
15- tool output
16- current docs when version-sensitive behavior matters
17 
18Do not ask the user for information you can inspect directly.
19 
20## When to Ask
21 
22Ask only when the answer materially changes the implementation:
23- security or authentication model
24- destructive data or migration strategy
25- major architecture branch
26- user-facing product choice with costly reversal
27 
28## When to Proceed
29 
30Proceed without asking when:
31- project conventions already answer the question
32- the choice is small and reversible
33- a safe default exists
34- the user explicitly asked for a best-effort implementation
35 
36## Question Rules
37 
38- Ask at most 1-2 critical questions at a time.
39- Use structured questions only when the choice has real tradeoffs.
40- Put the recommended or safest default first when presenting options.
41- Once the user answers, proceed without re-confirming.
42 
43## Good Pattern
44 
45```text
461. Inspect repo and runtime
472. Identify the true unknown
483. Ask only if that unknown changes the architecture or outcome
494. Otherwise choose a safe default and continue
50```
51 
52## Anti-Patterns
53 
54Do not:
55- ask about framework, package, or file structure when the repo can answer it
56- ask about tiny implementation details
57- repeat questions the user already answered
58- use fake `<think>` or `<thinking>` blocks as clarification scaffolding
59