This is an automated email from the ASF dual-hosted git repository.

terrymanu pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git


The following commit(s) were added to refs/heads/master by this push:
     new 69d96afd27d Refactor agents.md (#38716)
69d96afd27d is described below

commit 69d96afd27d237b301bd5879c43ab62a1cb69477
Author: Liang Zhang <[email protected]>
AuthorDate: Mon May 25 17:24:01 2026 +0800

    Refactor agents.md (#38716)
    
    * Refactor agents.md
    
    * Refactor agents.md
---
 AGENTS.md | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/AGENTS.md b/AGENTS.md
index 4a70c7c2330..77a31843edc 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -90,10 +90,25 @@ This guide is written **for AI coding agents only**. Follow 
it literally; improv
 
 Dangerous operation detected! Operation type: [specific action] Scope of 
impact: [affected area] Risk assessment: [potential consequence] Please confirm 
whether to continue. [Requires explicit “yes”, “confirm”, or “proceed”]
 
+## Coding Execution Principles
+- **Think before coding**: inspect existing code, contracts, tests, and 
relevant standards before editing; do not guess, hide uncertainty, or invent 
unsupported facts.
+- **Simple first**: solve the verified goal with the smallest clear 
implementation that preserves existing behavior.
+- **Precise modification**: change only the files and code paths required by 
the task; avoid drive-by refactors and unrelated cleanup.
+- **Goal-driven execution**: convert the request into verifiable outcomes 
before implementation, then validate those outcomes with scoped checks.
+
+## Coding Skill Guidance
+- When the named third-party skills are available in the current environment, 
use them for the matching work:
+  `source-driven-development` for official-source checks, 
`api-and-interface-design` for public contracts,
+  `doubt-driven-development` for non-trivial decisions, `code-simplification` 
after implementation, and `code-review-and-quality` before handoff.
+- If a named third-party skill is unavailable, do not install it automatically 
or block the task.
+  Apply an equivalent manual checklist for the same intent, record the 
fallback in the plan or final response, and continue.
+
 ## Workflow
 - Use Sequential Thinking when tasks need decomposition: 6-10 steps (fallback 
3-5), one sentence each, actionable.
-- Intake: choose the strategy for the task, confirm tool 
availability/fallbacks, and capture constraints (forbidden APIs, output format, 
coverage/test expectations).
-- Plan: inspect existing code with tools before edits, finish the plan before 
coding, and set the quality/verification bar.
+- Intake: choose the strategy for the task, confirm tool 
availability/fallbacks, capture constraints (forbidden APIs, output format, 
coverage/test expectations),
+  and use `source-driven-development` when available, or equivalent 
source-checking, to verify facts that depend on authoritative sources.
+- Plan: inspect existing code with tools before edits, finish the plan before 
coding, use `doubt-driven-development` when available for non-trivial decisions,
+  and set the quality/verification bar.
 - Implement: keep scope minimal, follow quality standards, record decisions, 
and handle edge cases; honor instruction precedence from Core Principle #7.
 - Validate: run the narrowest meaningful checks (see Verification & Commands) 
and prefer scoped runs; note any sandbox or limit blocks and alternatives.
 - Report & self-check: share intent, edits, verification results, and next 
steps; ensure all required instructions, coverage, and mocking rules are 
satisfied, with remaining risks called out.
@@ -107,6 +122,18 @@ Dangerous operation detected! Operation type: [specific 
action] Scope of impact:
 - **Post-task self-check (before replying):** confirm all instructions were 
honored; verify no placeholders/unused code; ensure Checkstyle/Spotless gates 
for touched modules are satisfied or explain why not run and what to run; list 
commands with exit codes; call out risks and follow-ups; complete all 
applicable checks before replying and do not rely on users to find missed rule 
violations.
 - **Final response template:** include intent/why, changed files with paths, 
rationale per file/section, commands run (with exit codes), verification 
status, and remaining risks/next actions (if tests skipped, state reason and 
the exact command to run); include a concise self-check result statement 
confirming final clean status after fixes.
 
+## Final Self-Iteration Gate
+- Apply this gate only to implementation tasks where the user has requested or 
authorized code or documentation edits.
+  For review-only, analysis-only, triage-only, or plan-only tasks, report 
findings and suggested follow-ups without modifying the reviewed target.
+- Before finishing an authorized implementation task, ask whether this task 
created in-scope legacy or dead code that can be safely removed,
+  whether the changed implementation can be simpler without changing behavior,
+  whether existing public behavior and contracts are preserved, and whether 
`code-review-and-quality` or equivalent review still has in-scope required 
findings.
+- Use `doubt-driven-development` when available, or equivalent adversarial 
self-review, to keep raising and resolving valuable in-scope questions until 
the stop condition is met.
+  Stop when no actionable findings remain, the same findings repeat, 3 doubt 
cycles complete, or the user explicitly overrides.
+- If any answer reveals an in-scope, behavior-preserving, low-risk required 
fix, make the fix and rerun relevant checks.
+- Repeat the review-fix-verify loop until no in-scope required findings remain.
+- Do not continue iterating for optional polish, broad cleanup, risky 
refactors, or unrelated code. Record those as follow-up suggestions instead of 
expanding the task.
+
 ## Coverage & Branch Checklist
 - When coverage targets are declared (including 100%), list every branch/path 
with its planned test before coding.
 - Map each branch to exactly one test; add cases until all declared branches 
are covered or explicitly waived.

Reply via email to