Global Agent Rules

Language

Response Style

Prioritize debugging, prohibit silent degradation

• Do not introduce new boundary rules, guardrails, blocking logic or upper limits (such as max-turns), degradation behaviors or silent failures just to make the code "run".
• Do not add mock/fake success paths (such as returning

  (mock) ok

  , template outputs that bypass real execution, swallowing errors).
• Do not write defensive or fallback code; this does not solve the root problem, it only increases debugging costs.
• Prioritize full exposure: let failures emerge clearly (clear errors, exceptions, logs, failed tests), so that bugs are visible and can be fixed from the root cause.
• If boundary rules or fallback logic are really necessary (for security/privacy, or explicitly requested by the user), they must meet:
  • Explicit (never silent),
  • Documented,
  • Easy to disable,
  • And approved by the user in advance.

Engineering Quality Baseline

• Follow SOLID, DRY, separation of concerns and YAGNI principles.
• Use clear naming and pragmatic abstractions; add concise comments only for key or non-obvious logic.
• Delete dead code and outdated compatibility paths when modifying behavior, unless the user explicitly requires compatibility retention.
• Consider time/space complexity in relevant scenarios, optimize heavy IO or memory usage.
• Explicitly handle edge cases; do not hide failures.

Code Metrics (Mandatory Limits)

• Function length: 50 lines (excluding blank lines). If exceeded, extract helper functions immediately.
• File size: 300 lines. If exceeded, split by responsibility.
• Nesting depth: 3 levels. Use early return/guard clauses to flatten.
• Number of parameters: 3 positional parameters. If more, use configuration/option objects.
• Cyclomatic complexity: No more than 10 per function. If exceeded, decompose branch logic.
• Magic numbers are prohibited: Extract as named constants (

  MAX_RETRIES = 3

  instead of bare number

  3

  ).

Decoupling and Immutability

• Dependency injection: Business logic does not directly

  new

  or hard import specific implementations; inject via parameters or interfaces.
• Immutability first: Prioritize use of

  readonly

  ,

  frozen=True

  ,

  const

  , immutable data structures. Do not modify function parameters or global state; return new values.

Security Baseline

• Do not hardcode secrets, API Key or credentials in source code; use environment variables or secret managers.
• All database access uses parameterized queries; do not splice user input into SQL/commands.
• Verify and clean all external inputs at system boundaries (user input, API responses, file content).
• Secrets in conversations are not equal to code leaks: It is a normal workflow for users to share API Key in conversations (such as configuring providers, debugging connections), do not issue a "secret leak" warning. Alert only when secrets are written to source code files.

Testing and Verification

• Keep code testable, verify through automated checks as much as possible.
• When running backend unit tests, enforce a 60-second hard timeout to avoid task stuck.
• Prioritize static checks, formatting and reproducible verification over temporary manual confirmation.

Skills Routing Table

researcher

explore

taskmaster