From 830b1cf2e149df4bcc876a3cf6ca74f3e312f591 Mon Sep 17 00:00:00 2001 From: rain Date: Mon, 22 Jun 2026 17:31:43 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E9=97=AE=E9=A2=98?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- AGENTS.md | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index d08bfb2..82682d7 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -4,7 +4,7 @@ Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-s Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment. 1. Think Before Coding -Don’t assume. Don’t hide confusion. Surface tradeoffs. +Don't assume. Don't hide confusion. Surface tradeoffs. Before implementing: @@ -12,30 +12,32 @@ State your assumptions explicitly. If uncertain, ask. If multiple interpretations exist, present them instead of picking silently. If a simpler approach exists, say so. Push back when warranted. If something is unclear, stop. Name what is 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 was not requested. +No "flexibility" or "configurability" that was not 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. +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: -Do not “improve” adjacent code, comments, or formatting. +Do not "improve" adjacent code, comments, or formatting. Do not refactor things that are not broken. Match existing style, even if you would do it differently. If you notice unrelated dead code, mention it instead of deleting it. + When your changes create orphans: Remove imports, variables, functions, files, docs, and references that YOUR changes made unused. Do not remove pre-existing dead code unless asked. -The test: Every changed line should trace directly to the user’s request. +The test: Every changed line should trace directly to the user's request. 4. Contract Discipline When a new contract lands, make it the only contract in the same change. @@ -49,11 +51,13 @@ Specify the single owner. Identify the one module, function, schema, document, or service that owns the contract. Do not leave the same rule duplicated across frontend, backend, scripts, prompts, docs, or tests. If multiple places need the value, they should consume it from the owner rather than redefine it. + Delete old fields and old entrypoints. Remove obsolete fields, fallback reads, compatibility branches, legacy routes, stale config keys, old scripts, and old docs. -Do not keep the old path “just in case” unless the user explicitly asks for a compatibility period. +Do not keep the old path "just in case" unless the user explicitly asks for a compatibility period. If compatibility is required, name it as temporary, define the removal condition, and keep it narrow. + Tighten validators and runtime together. Update schemas, validators, tests, fixtures, seed data, docs, and runtime code in the same change. @@ -66,16 +70,18 @@ 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.” -“Change a contract” → “Identify owner, remove old paths, tighten validators and runtime, then verify old inputs fail.” +"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." +"Change a contract" -> "Identify owner, remove old paths, tighten validators and runtime, then verify old inputs fail." + 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 like “make it work” require clarification. + +Strong success criteria let you loop independently. Weak criteria like "make it work" require clarification. 6. Verification Before Closure A change is not finished until the relevant behavior is checked. @@ -99,9 +105,11 @@ Say how it was verified. Mention any remaining risk or skipped verification. Do not bury important caveats in vague language. Do not over-explain routine edits. + Good final answer shape: Changed: [short summary] Verified: [command/check] Notes: [only if needed] -These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, fewer hidden compatibility paths, clearer ownership of contracts, and clarifying questions happen before implementation rather than after mistakes. \ No newline at end of file + +These guidelines are working if: fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, fewer hidden compatibility paths, clearer ownership of contracts, and clarifying questions happen before implementation rather than after mistakes.