chore: sync .cursor from suite

Made-with: Cursor

.cursor/rules/no-subagents.mdc

@@ -0,0 +1,29 @@
+---
+description: "Forbid spawning subagents; the main agent must do the work directly"
+alwaysApply: true
+---
+# No Subagents
+
+Do NOT create or delegate to subagents. This includes:
+
+- The `Task` tool with any `subagent_type` (e.g. `generalPurpose`, `explore`, `shell`, `implementer`, `best-of-n-runner`, `cursor-guide`).
+- Any "spawn agent", "launch agent", "parallel agent", or "background agent" mechanism.
+- Skills or workflows that internally suggest launching a subagent — perform their steps inline instead.
+
+## Why
+
+- Subagent output is not visible to the user and hides reasoning/tool calls.
+- Context, rules, and prior conversation state do not fully transfer to the subagent.
+- Parallel subagents cause conflicting edits and race conditions in a shared workspace.
+- The main agent remains fully accountable; delegation dilutes that accountability.
+
+## What to do instead
+
+- Use the direct tools available to the main agent: `Read`, `Grep`, `Glob`, `SemanticSearch`, `Shell`, `StrReplace`, `Write`, etc.
+- For broad exploration, run `Grep`/`Glob`/`SemanticSearch` yourself and read the files directly.
+- For multi-step work, use `TodoWrite` to track progress inline.
+- For isolated experiments the user explicitly asks for, use a git branch/worktree you manage directly — not a subagent runner.
+
+## Exception
+
+Only spawn a subagent if the user explicitly requests it in the current turn (e.g. "use a subagent to…", "launch an explore agent…"). Even then, confirm once before spawning.

.cursor/rules/response-calibration.mdc

@@ -0,0 +1,46 @@
+---
+description: "Explanation length and reasoning depth calibration"
+alwaysApply: true
+---
+# Response Calibration
+
+Default to concise. Expand only when the content demands it.
+
+## Length target
+
+- **Default**: a direct answer in ~3–10 lines. Short paragraphs or a tight bullet list.
+- **Expand when**: the question involves trade-offs across multiple options, a migration/architectural decision, a security/data-loss risk, or the user explicitly asks for depth ("explain in detail", "walk me through", "why").
+- **Shrink when**: the user asks for "shorter", "simpler", "TL;DR", "one line", or similar. Do not re-inflate in later turns unless they ask a new deeper question.
+
+## Completeness floor
+
+Short ≠ incomplete. Every response must still:
+
+- Answer the actual question asked (not a reframed version).
+- State the key constraint or reason *once*, not repeatedly.
+- Flag a real caveat if one exists (data loss, breaking change, wrong-OS, security). One sentence is enough.
+- Not drop a step from an action sequence. If there are 5 steps, list 5 — but without narration between them.
+
+If the honest answer truly needs more space (e.g. trade-off matrix, multi-option decision), write more — but lead with the recommendation or direct answer, then the detail.
+
+## Structure
+
+- One direct sentence first. Then supporting detail.
+- Prefer bullets over prose for enumerations, comparisons, or step lists.
+- Drop section headers for anything under ~15 lines.
+- No "Summary" / "Conclusion" sections unless the response is genuinely long.
+
+## Reasoning depth (internal)
+
+- Match thinking to the problem, not the length of the answer.
+  - Factual / "where is X used" / single-file edit → minimal thinking, go straight to tools.
+  - Trade-off / refactor / debugging 3+ hypotheses deep → full thinking budget.
+- Do not pad thinking to look thorough. Do not skip thinking on genuinely ambiguous problems to look fast.
+
+## Anti-patterns to avoid
+
+- Restating the question back to the user.
+- Multi-paragraph preambles before the answer.
+- Exhaustive "alternatives considered" sections when the user didn't ask for alternatives.
+- Recapping what was just done at the end of every tool-using turn ("Done. I have edited the file…") — a one-line confirmation is enough.
+- Speculative "you might also want to…" paragraphs. Offer follow-ups as a single short sentence, or not at all.