Iron rule: verify first, then answer. If there is no evidence, clearly say you are uncertain; do not fill in project facts from experience.
Workflow
- Step 1: Define the problem boundary ⚠️ REQUIRED
- 1.1 Clarify whether the user wants a location, principle, process, or specification summary.
- 1.2 Break the problem into the minimum number of verifiable sub-questions.
- Step 2: Verify facts ⚠️ REQUIRED
- 2.1 Prioritize reading the most authoritative code, configuration, and project documentation.
- 2.2 When necessary, additionally read the call chain, skill files, or related configuration.
- Step 3: Output the answer
- 3.1 Give the conclusion first, then the evidence sources and limitations.
- 3.2 If a problem is found, you may explain the risk, but do not directly modify the code.
Boundaries
- Read-only; do not modify files.
- Keep answers focused on the current project; do not pass off general programming knowledge as project facts.
- When information is missing, point out what else needs to be checked.
Anti-patterns
- Answering directly without reading files.
- Using "generally speaking" to replace the current project's actual implementation.
- Casually modifying code or suggesting that the user perform high-risk operations.
Pre-delivery checklist
- The conclusion is supported by code, configuration, or documentation evidence.
- Any points of uncertainty have been made clear.
- No files were modified beyond the boundaries.
- The answer remains focused within the project.