Files
SuperBizAgent-java/AGENTS.md

4.5 KiB
Raw Permalink Blame History

CLAUDE.md

Defaults

  • Reply in Chinese unless I explicitly ask for English.
  • No emojis.
  • Do not truncate important outputs (logs, diffs, stack traces, commands, or critical reasoning that affects
    safety/correctness).

Refactor policy (legacy code)

  • When existing code is a "big ball of mud" (hard to maintain, clearly bad design,
    full of hacks), prefer a clean, full refactor over stacking more patches
    on top of it.
  • A refactor may completely replace internal structure
    (functions, modules, classes, data flow).
  • By default, try to preserve externally observable behaviour.
    If you intentionally change behaviour or protocols, you MUST:
    • Call out clearly that this is a behaviour/protocol change.
    • Explain why the change is necessary and which code paths/consumers are affected.
    • Update or add tests to cover the new behaviour.

Before touching code (mandatory)

Find reuse opportunities + Trace the call/dependency chain and impact radius:

  • Use semantic code search first via codebase-retrieval tool.
  • Confirm understanding with LSP: goToDefinition, findReferences.
  • Use Grep/Glob for verifying and understanding additional code snippets.

Red lines

  • No copy-paste duplication.
  • Do not break existing externally observable behaviour unless:
    • It is part of a deliberate refactor as described in the refactor policy, and
    • You clearly document the behavioural change and its impact.
  • Do not proceed with a known-wrong approach.
  • Critical paths must have explicit error handling.
  • Never implement "blindly": always confirm understanding via code reading + references.

Task sizing

  • Simple

  • Criteria — single file, clear requirement, < 20 lines changed,
    clearly local impact.

  • Handling — after doing the "Before touching code" steps
    (research + impact analysis + internal three-question checklist),
    you may execute directly with minimal explanation.

  • A very short context line is enough;
    a full breakdown of the checklist is not required.

  • Medium

    • Criteria — 2–5 files, or requires some research, or impact is not obviously local.
    • Handling — write a short plan (bullet points) → then implement.
    • Briefly surface the checklist result in the reply
      (1–3 short lines describing real issue, key reuse, and main impact).
  • Complex

    • Criteria — architecture changes, multiple modules, high uncertainty or risk.
    • Handling — follow this workflow:
      1. RESEARCH: inspect code and facts only (no proposals yet).
      2. PLAN: present options + tradeoffs + recommendation;
      use AskUserQuestion actively to align with the user;
      wait for user's confirmation.
      3. EXECUTE: implement exactly the approved plan.
      4. REVIEW: self-check (tests, edge cases, cleanup).

Git

  • Do not commit unless I explicitly ask.
  • Do not push unless I explicitly ask.
  • Before writing a commit message, glance at a few recent commits and match the repo's style:
    • git log -n 5 --oneline
  • If there is no obvious existing style, use this default format:
    • <type>(<scope>): <description>
  • Before any commit: run git diff and confirm the exact scope of changes.
  • Never force-push to main / master unless the user approves.
  • Do not add attribution lines in commit messages.

Security

  • Never hardcode secrets (keys/passwords/tokens).
  • Never commit .env files or any credentials.
  • Validate user input at trust boundaries (APIs, CLIs, external data sources).

Quality & cleanup

  • Prefer clarity and simplicity first (KISS); apply DRY to remove obvious
    copy-paste duplication when it does not hurt readability.
  • If you change a function signature, update all call sites.
  • After changes:
    • Remove temporary files.
    • Remove dead/commented-out code.
    • Remove unused imports.
    • Remove debug logging that is no longer needed.
  • Run the smallest meaningful verification (lint/test/build) for the parts you touched.

Windows / PowerShell (if used)

  • PowerShell does not support &&; use ; to chain commands.
  • Quote paths that contain spaces or non-ASCII characters.

Baisc Infos

Unless directly relevant to the user's current question, you should avoid proactively mentioning, illustrating, or
trailing off into the following information in 99% of cases: