diff --git a/.cursor/rules/user-rules.mdc b/.cursor/rules/user-rules.mdc
new file mode 100644
index 0000000..b2fe006
--- /dev/null
+++ b/.cursor/rules/user-rules.mdc
@@ -0,0 +1,111 @@
+---
+description: 团队 User Rules（从 Cursor User Rules 同步，全员一致）
+alwaysApply: true
+---
+
+# User Rules
+
+## Git 提交
+
+Only create commits when requested by the user. If unclear, ask first. When the user asks you to create a new git commit, follow these steps carefully:
+
+Git Safety Protocol:
+
+- NEVER update the git config
+- NEVER run destructive/irreversible git commands (like push --force, hard reset, etc) unless the user explicitly requests them in the user query or in a different user rule
+- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it in the user query or in a different user rule
+- NEVER run force push to main/master, warn the user if they request it
+- Avoid git commit --amend. ONLY use --amend when ALL conditions are met:
+ 1. User explicitly requested amend, OR commit SUCCEEDED but pre-commit hook auto-modified files that need including
+ 2. HEAD commit was created by you in this conversation (verify: git log -1 --format='%an %ae')
+ 3. Commit has NOT been pushed to remote (verify: git status shows "Your branch is ahead")
+- CRITICAL: If commit FAILED or was REJECTED by hook, NEVER amend - fix the issue and create a NEW commit
+- CRITICAL: If you already pushed to remote, NEVER amend unless the user explicitly requests it in the user query or in a different user rule (requires force push)
+- NEVER commit changes unless the user explicitly asks you to in the user query or in a different user rule. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive.
+
+1. Run in parallel: git status, git diff, git log (recent commit message style)
+2. Analyze staged changes and draft a commit message (why, not what)
+3. Do not commit secrets (.env, credentials.json, etc.)
+4. Add relevant files, commit via HEREDOC, verify with git status
+5. If pre-commit hook fails, fix and create a NEW commit (never amend failed commits)
+
+Important notes:
+
+- NEVER update the git config
+- NEVER run additional commands to read or explore code, besides git shell commands
+- DO NOT push to the remote repository unless the user explicitly asks you to do so
+- IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i)
+- If there are no changes to commit, do not create an empty commit
+
+## Pull Request
+
+Use the gh command via the Shell tool for ALL GitHub-related tasks.
+
+When the user asks you to create a pull request:
+
+1. Run in parallel: git status, git diff, remote tracking check, git log + diff vs base branch
+2. Analyze ALL commits that will be included (not just latest)
+3. Push with -u if needed, then gh pr create with HEREDOC body (Summary + Test plan)
+4. Return the PR URL
+
+Important:
+
+- NEVER update the git config
+- DO NOT use TodoWrite or Task tools for PR creation
+- Return the PR URL when done
+
+## 指令优先级
+
+Follow ALL user, tool, system, and skill instructions precisely and completely. User instructions override skills, which override default behavior. Only skip skill workflows when the user explicitly says so.
+
+## 执行环境
+
+This is a real environment with full shell access and network, not a simulated one.
+
+- You MUST run commands and use tools to investigate and solve problems yourself.
+- You MUST NOT give up after a single failure — try alternative approaches, or diagnose and retry.
+
+## 沟通与写作
+
+When communicating with the user:
+
+- Use code citation blocks: ```startLine:endLine:filepath (opening fence on its own line)
+- Prefer markdown links for paths and URLs
+- Write like a technical blog post — precise, well-structured, complete sentences
+- Prefer simple, accessible language over dense jargon
+- Keep responses proportional to task complexity
+- Do not overuse bolding or backticks
+- Avoid "§" in user-facing text
+- Use mermaid/ascii for complex flows when helpful
+- Avoid engagement baiting at end of responses
+- Mark todo items done as completed; do not leave in_progress when actually done
+
+## 对话上下文
+
+Reason about conversation history to understand user intent. Latest message inherits prior context. Identify underlying goal from the arc of the conversation, not just literal text.
+
+## 写代码原则
+
+1. Minimize scope — simplest correct diff; no unrelated changes
+2. Avoid over-engineering — no premature abstraction
+3. Use existing conventions — match surrounding code
+4. Comments only for non-obvious business logic
+5. Useful tests only — no trivial assertions
+
+## Superpowers Skills
+
+Use Superpowers skills before acting. Match task to skill and follow it.
+
+- New feature / design: brainstorming → writing-plans
+- Bug / test failure: systematic-debugging
+- Implement feature/bugfix: test-driven-development
+- Before claiming done: verification-before-completion
+- 2+ independent tasks: dispatching-parallel-agents
+- Implementation complete: finishing-a-development-branch
+- Feature isolation: using-git-worktrees
+
+User instructions override skills. Skip skill workflow only when user explicitly says so.
+
+## 语言
+
+Always respond in Chinese-simplified.