Before implementing: - State your assumptions explicitly. If uncertain, ask. - If multiple interpretations exist, present them - don't pick silently. - If a simpler approach exists, say so. Push back when warranted. - If something is unclear, stop. Name what's confusing. Ask.
## 2. Simplicity First
**Minimum code that solves the problem. Nothing speculative.**
- No features beyond what was asked. - No abstractions for single-use code. - No "flexibility" or "configurability" that wasn't requested. - No error handling for impossible scenarios. - If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
## 3. Surgical Changes
**Touch only what you must. Clean up only your own mess.**
When editing existing code: - Don't "improve" adjacent code, comments, or formatting. - Don't refactor things that aren't broken. - Match existing style, even if you'd do it differently. - If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans: - Remove imports/variables/functions that YOUR changes made unused. - Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
## 4. Goal-Driven Execution
**Define success criteria. Loop until verified.**
Transform tasks into verifiable goals: - "Add validation" → "Write tests for invalid inputs, then make them pass" - "Fix the bug" → "Write a test that reproduces it, then make it pass" - "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan: ``` 1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check] ```
Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
## 5. My Personal Preferences
***Global instruction**: Your response needs to be in Chinese. (Keep this as the first rule.) ***Code line width**: Do not exceed 120 characters per line (use the editor’s margin as a visual guide). ***Function/method length**: Do not exceed 100 lines (excluding blank lines and comments). If it does, refactor into smaller, single‑responsibility functions. ***Commit & MR policy**: Each Merge Request (MR) must correspond to exactly **one** final commit, and one MR must equal exactly one requirement/feature (一个 MR = 一个需求). For long‑running tasks with multiple local saves, use `git commit --amend` to squash them into a single commit before pushing to the MR branch. **Concretely when using `superpowers` skills (brainstorming → writing‑plans → executing‑plans → test‑driven‑development, etc.): one spec = one commit.** Within a single spec, the intermediate checkpoints — spec written, plan written, each task finished, tests pass, prompt tuned, docs updated — are NOT commit boundaries. Keep accumulating with `git commit --amend`; do not run `git commit` again until the spec is fully done. Only when switching to a new spec / new requirement is a fresh `git commit` (and thus a new MR) allowed. Claude must not preset commit nodes inside a spec's lifecycle. ***Interaction mode**: When I choose to need a chat, you must wait for my reply before proceeding to the next option or action. Do not automatically jump to the next selection. ***Parallel subAgent execution**: If a task can be broken down into sub‑tasks that can be executed in parallel by subAgents, you must proactively ask the user whether they prefer parallel execution. Do not decide autonomously; the user may not care about token cost and may instead prioritize finishing the task as quickly as possible.
---
**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.