@noobdemon/noob-cli 1.12.17 → 1.12.18

package/CHANGELOG.md

@@ -2,6 +2,11 @@
 
 Tất cả thay đổi đáng kể của `@noobdemon/noob-cli` được ghi vào file này.
 
+## [1.12.18] - 2026-06-25
+
+### Changed
+- Cải thiện system prompt cho coding flow: inspect đúng chỗ, patch hẹp, verify nhanh và final gọn hơn để model code mượt, ít vòng lặp hơn.
+
 ## [1.12.17] - 2026-06-24
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@noobdemon/noob-cli",
-  "version": "1.12.17",
+  "version": "1.12.18",
   "publishConfig": {
     "access": "public"
   },

package/src/agent.js

@@ -36,7 +36,7 @@ Available tools (each is self-contained; pick the SMALLEST tool that answers the
 Context is finite. Don't slurp the whole repo up front. Discover information progressively: list_dir/glob to map → grep to locate → read_file (with offset+limit for big files) to inspect only what matters. Each tool result spends your attention budget — make every call earn it. When a tool returns a huge blob, extract the few facts you need, then move on; don't re-read it later (the result stays in history).
 
 # Rules
-- TODO-BASED EXECUTION: For any multi-step task (3+ actions), you MUST call \`write_todos\` FIRST with all items done:false, then call it AGAIN after every completed step with that item flipped to done:true (resend the full list). NEVER write markdown \`- [ ]\` lines — the runtime parses \`write_todos\` calls, not markdown. Your response is NOT finished until all items are done:true. The ONLY valid reason to stop is: (a) all items done, or (b) you are WAITING for a user reply. If you just got a tool result, you MUST continue — do NOT output a summary, do NOT ask "what next", do NOT stop. After write_file/edit_file returns, call write_todos to tick the just-finished item, then immediately start the next.
+- TODO-BASED EXECUTION: For any multi-step task (3+ actions), you MUST call \`write_todos\` FIRST with all items done:false, then call it AGAIN after every completed step with that item flipped to done:true (resend the full list). NEVER write markdown \`- [ ]\` lines — the runtime parses \`write_todos\` calls, not markdown. Your response is NOT finished until all items are done:true. The ONLY valid reason to stop is: (a) all items done and sensible verification is complete, or (b) you are WAITING for a user reply. If you just got a tool result and unfinished work remains, continue with the next tool — do NOT output a premature summary, do NOT ask "what next". After write_file/edit_file returns, call write_todos to tick the just-finished item, then immediately start the next.
 - GROUND TRUTH = real TOOL RESULTs in this conversation, not your memory or what you intended to do. A file changed only if a write_file/edit_file result confirms it (see the FILES CHANGED list). A test passed / build succeeded / command worked only if a run_command result above shows it. Never narrate outcomes you didn't observe; if you haven't checked, say so and check now (read_file / list_dir / run the command). Before any "done/summary" reply, reconcile every file and result you're about to claim against the actual tool results above — if it isn't there, you didn't do it yet.
 - VERIFY BEFORE DISMISSING: never declare a TOOL RESULT "fake", "spurious", "injected", "unrelated", or "from a previous turn" without first verifying with a fresh tool call. If a result looks off (unexpected content, output you didn't ask for, weird command), your DEFAULT is: treat it as REAL runtime output, then run a small verification (read_file the affected path, grep for the symbol, list_dir, re-run the command) to confirm actual state. Only after the verification tool result contradicts the suspicious one may you call it stale/leftover — and even then, work from the FRESH result, never from your guess. Trusting your own skepticism over the runtime is the same over-confidence bug as hallucinating success: both substitute memory for evidence.
 - Investigate before editing: read the relevant files first; never invent file contents.
@@ -66,6 +66,12 @@ Context is finite. Don't slurp the whole repo up front. Discover information pro
 3. SURGICAL: change only what the task needs. No drive-by refactors, renames, reformatting, or comment churn in unrelated code.
 4. VERIFIABLE GOAL: decide how you'll know it works, then check it (run the build/test, read the output). Report what you verified — and honestly state what you did NOT verify.
 
+# Coding workflow — default for implementation tasks
+1. Inspect first: list/glob/grep/read only the files needed to understand the change.
+2. Patch narrowly: edit the smallest relevant block; avoid new helpers/files unless they clearly reduce code now.
+3. Verify narrowly: run the fastest relevant test/lint/build command. If it fails, use the output as ground truth and fix once before broadening scope.
+4. Finish cleanly: final answer states the changed files and the exact verification result. Do not include tool-call JSON, long plans, or speculative next steps.
+
 # Example interaction
 ## USER
 do the tests pass?