zames_pro 2.75.6 → 2.76.0

package/CHANGELOG.md

@@ -7,6 +7,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [2.76.0] - 2026-10-16
+
+### Added
+
+- bake methodology skills in, localize skill hints, fix Ctrl+Del and scroll-to-bottom
+
 ## [2.75.6] - 2026-10-16
 
 ### Added

package/dist/context.js

@@ -57,6 +57,105 @@ const BUILTIN_SKILLS = [
             'couplings, and any WHY-comments that matter.\n' +
             '4. Do NOT change code. Answer in the operator language.',
     },
+    // Methodology skills, ported from superpowers (github.com/obra/superpowers)
+    // as plain prompt bodies — the zames equivalent of its SessionStart
+    // bootstrap, without a hook. The model is nudged to read the matching one
+    // before a non-trivial task by SKILLS_DISCIPLINE (src/system-prompt.ts).
+    // Baked in (not a file on disk) so a user who installed the npm package has
+    // them out of the box; a project skill of the same name overrides them.
+    {
+        name: 'brainstorming',
+        description: 'Use when the request is a GOAL, not a spec — "add X", "make it better", "integrate Y" — and it is unclear what "done" means.',
+        body: 'When a request is a goal ("make scrolling feel right"), building ' +
+            'immediately produces the wrong thing fast. First make the intent concrete.\n' +
+            'Pin down: (a) the REAL outcome — what should be TRUE after that is not ' +
+            'true now; (b) the acceptance check — how the operator will know it works; ' +
+            '(c) scope edges — what is explicitly NOT part of this; (d) the ' +
+            'alternatives considered and why you chose one.\n' +
+            'zames has NO conversational turn: the operator sees only your final ' +
+            'respond. So do the brainstorming YOURSELF and return a SHORT, concrete ' +
+            'proposal in ONE respond — the goal as you understood it, your ' +
+            'assumptions and defaults, what you will NOT do — then either proceed if ' +
+            'the request was clearly actionable, or stop and ask the ONE decision you ' +
+            'genuinely cannot make alone. For an already-precise request ("read X", ' +
+            '"rename Y") skip this entirely.',
+    },
+    {
+        name: 'writing-plans',
+        description: 'Use when a task needs more than one or two tool calls — a multi-file change, a new feature, a refactor. Breaks it into small ordered steps with exact paths and a verification for each.',
+        body: 'A plan is a sequence of steps a careful engineer with NO project ' +
+            'context could follow. Each step (2-5 minutes) names: the EXACT file ' +
+            'path(s); the concrete edit; how to verify it (command, test name, ' +
+            'expected output). Order matters: put the step that DE-RISKS the task ' +
+            'first (a spike, a failing test, a proof the API works) — do not build ' +
+            'three layers on an unverified assumption.\n' +
+            'Rules: one concern per step ("add the flag AND refactor the caller" is ' +
+            'two); prefer a step that FAILS LOUDLY over one that silently ' +
+            'half-works; every behavioural change gets a test step (see ' +
+            'test-driven-development); if a step turns out wrong, STOP and revise the ' +
+            'plan instead of improvising; a 30-step plan means the task should be ' +
+            'split. In zames the plan lives in your reasoning and, for a long task, ' +
+            'in a TodoWrite list — one entry per step. Do not narrate it between tool ' +
+            'calls; the todo list IS the visible plan.',
+    },
+    {
+        name: 'test-driven-development',
+        description: 'Use when writing or changing testable behaviour — a bug fix, a new function, a parser, a formatter. Write the failing test first, watch it fail, then make it pass.',
+        body: 'RED -> GREEN -> REFACTOR. The order is the point, not a formality.\n' +
+            '1. RED — write the smallest test that expresses the new behaviour and ' +
+            'RUN it. It must FAIL for the RIGHT reason ("not implemented", not a ' +
+            'typo). A test you never saw fail proves nothing.\n' +
+            '2. GREEN — write the MINIMUM code that makes it pass; do not add the ' +
+            'next feature "while you are there".\n' +
+            '3. REFACTOR — clean up with the test green, then re-run.\n' +
+            'A good test asserts BEHAVIOUR (input -> output), is deterministic (no ' +
+            'sleeps, no network, no wall-clock or test-order dependence) and fails ' +
+            'for ONE reason with a message that says what broke. In this project a ' +
+            'bug fix ALWAYS gets a regression test reproducing the original bug. ' +
+            'When a test needs fixing, ask whether the TEST or the CODE was wrong; ' +
+            'if the code was written before its test, rewrite it driven by the test.',
+    },
+    {
+        name: 'systematic-debugging',
+        description: 'Use when something is broken and the cause is not obvious — a failing test, a wrong result, a hang, a crash. Four phases: reproduce, isolate, hypothesize, fix.',
+        body: 'Do NOT start by editing code. Work the four phases in order; each ' +
+            'produces an artifact you can point at.\n' +
+            '1. REPRODUCE — get a command that FAILS the way the operator describes; ' +
+            'copy the exact error. If it passes you do not have the bug yet: narrow ' +
+            'the input until it fails.\n' +
+            '2. ISOLATE — shrink to the smallest failing unit (bisect, stub, ' +
+            'binary-search). Read the code the failing path ACTUALLY executes. Check ' +
+            'the obvious first: wrong file, stale build, cached state, different ' +
+            'config, an error swallowed by a catch.\n' +
+            '3. HYPOTHESIZE — state it in one sentence and predict what you should ' +
+            'see if it is right; test exactly that. One change at a time; prefer an ' +
+            'observation (log, test assertion) over an edit. If the prediction is ' +
+            'wrong, DISCARD the hypothesis.\n' +
+            '4. FIX AND VERIFY — fix the CAUSE, not the symptom; add a regression ' +
+            'test that fails WITHOUT the fix; re-run the phase-1 reproduction ' +
+            'verbatim; look for the same bug elsewhere.\n' +
+            'Anti-patterns: editing before reproducing; "it works now" without ' +
+            'knowing what changed; silencing an error you do not understand with a ' +
+            'try/catch; trusting a green test never seen red.',
+    },
+    {
+        name: 'verification-before-completion',
+        description: 'Use BEFORE declaring a task done — a feature, a bug fix, a generated file. Forces you to run the verification you promised instead of trusting the code looks right.',
+        body: '"It should work" is not done. Before reporting success, produce ' +
+            'EVIDENCE from the real artifact, not from your intent.\n' +
+            '1. Re-read the original request; tick every requirement (including the ' +
+            'ones in a parenthetical) against something you can show.\n' +
+            '2. Run the thing: build/typecheck/tests for code; run a script; for a ' +
+            'generated file, open/parse it and confirm it is COMPLETE, not ' +
+            'truncated; for a UI, the real screen, not the diff.\n' +
+            '3. Re-read your own diff as a reviewer: leftover debug output, dead ' +
+            'code, a wrong path, a test that asserts nothing.\n' +
+            '4. State the evidence in the final report — the exact command and its ' +
+            'result — so the operator can reproduce it. "Tests pass" without the ' +
+            'command is not evidence.\n' +
+            'If you cannot run the verification, SAY SO explicitly and describe what ' +
+            'you did instead; never report "done" implying a check you did not run.',
+    },
 ];
 // Per-file budgets. AGENTS.md/MEMORY.md are hand-maintained and grow over
 // time, so the caps are generous: an AGENTS.md of a real project (this repo's

package/dist/i18n/help.js

@@ -574,4 +574,50 @@ export const helpMessages = {
         ru: 'Индикаторы в статус-строке: 🧠 — глубокое размышление, 🌐 — поиск в интернете (видны, когда включены).',
         en: 'Status-line icons: 🧠 — Deep thinking, 🌐 — web search (shown when enabled).',
     },
+    // Localized descriptions for the WELL-KNOWN skills (built-in + bundled
+    // methodology). A skill's SKILL.md frontmatter is agent-facing English, so
+    // showing it verbatim in the «/» hints would leave an English line in a
+    // Russian UI. Keyed by skill NAME, applied regardless of source, so a local
+    // `.zames/skills/` copy of a bundled skill still shows the translated text.
+    // An unknown (user-authored) skill has no key and keeps its own description.
+    'skill.desc.commit': {
+        ru: 'подготовить аккуратный git-коммит из текущих изменений',
+        en: 'prepare a clean git commit from the current changes',
+    },
+    'skill.desc.review': {
+        ru: 'ревью текущего диффа на баги и риски (без правок)',
+        en: 'review the current diff for bugs and risks (no changes)',
+    },
+    'skill.desc.test': {
+        ru: 'прогнать тесты проекта и чинить падения до зелёного',
+        en: 'run the project tests and fix failures until green',
+    },
+    'skill.desc.debug': {
+        ru: 'системно диагностировать и починить баг',
+        en: 'systematically diagnose and fix a bug',
+    },
+    'skill.desc.explain': {
+        ru: 'объяснить, как работает файл/модуль/фича',
+        en: 'explain how a file/module/feature works',
+    },
+    'skill.desc.brainstorming': {
+        ru: 'когда запрос — это цель, а не спека: сначала прояснить замысел',
+        en: 'when the request is a goal, not a spec: pin down the intent first',
+    },
+    'skill.desc.writing-plans': {
+        ru: 'разбить многошаговую задачу на маленькие шаги с проверкой каждого',
+        en: 'break a multi-step task into small steps, each with a check',
+    },
+    'skill.desc.test-driven-development': {
+        ru: 'сначала падающий тест, потом код (RED → GREEN → REFACTOR)',
+        en: 'write the failing test first, then the code (RED → GREEN → REFACTOR)',
+    },
+    'skill.desc.systematic-debugging': {
+        ru: 'четыре фазы отладки: воспроизвести, изолировать, гипотеза, фикс',
+        en: 'four debugging phases: reproduce, isolate, hypothesize, fix',
+    },
+    'skill.desc.verification-before-completion': {
+        ru: 'прогнать проверку ПЕРЕД тем, как объявить задачу готовой',
+        en: 'run the verification BEFORE declaring the task done',
+    },
 };

package/dist/index.js

@@ -530,9 +530,18 @@ async function refreshDynamicCommands(workdir) {
         for (const s of skills) {
             if (!s.userInvokable)
                 continue;
+            // A well-known skill (built-in or bundled methodology) has a localized
+            // description keyed by NAME — its SKILL.md frontmatter is agent-facing
+            // English, which must not leak into a Russian UI. `t` returns the key
+            // itself when it is missing, so an unknown (user-authored) skill falls
+            // back to its own description.
+            const descKey = 'skill.desc.' + s.name;
+            const localized = t(descKey);
             out.push({
                 name: '/' + s.name,
-                description: s.description || t('help.cmd.skill'),
+                description: localized !== descKey
+                    ? localized
+                    : s.description || t('help.cmd.skill'),
             });
         }
         const cmds = await loadCommands(workdir);

package/dist/tui/TuiEditor.js

@@ -254,6 +254,10 @@ export class TuiEditor {
         this.printAbove(theme.userBar('▌ ') +
             theme.user(wrapToWidth(display, contentWidth() - 2)));
         this.store.set({ pastes: [] });
+        // Sending a message pins the log back to the newest content: the operator
+        // expects their message (and the answer) at the BOTTOM, so a viewport left
+        // scrolled-up (PgUp / wheel) must snap to scroll=0 on submit.
+        this.store.set({ scroll: 0 });
         this.onSubmit?.(text, atts);
         if (this.busy)
             this.thinking();

package/dist/tui/edit.js

@@ -82,35 +82,26 @@ export function deleteWordLeft(s) {
     return { ...s, buf: chars.join(''), cursor: i };
 }
 /**
- * Delete the word on the RIGHT of the cursor (Ctrl+Delete / Alt+Delete).
- *
- * FALLBACK: at the END of the line there is no word to the right, so the key
- * did NOTHING and the operator (whose terminal sends the standard xterm
- * Ctrl+Delete) read it as "Ctrl+Delete does not delete the word before the
- * cursor". Deleting the word on the LEFT there matches what other terminal
- * editors do and what the operator expects, while keeping the standard
- * right-delete when the cursor is mid-line.
+ * Delete the word on the RIGHT of the cursor (Ctrl+Delete / Alt+Delete):
+ * skip the whitespace after the cursor, then delete up to the end of the next
+ * word — the mirror of deleteWordLeft(). At the end of the line there is
+ * nothing to the right, so the buffer is left UNCHANGED (never a surprise
+ * leftward delete), matching the legacy LineEditor's _deleteWordRight().
  */
 export function deleteWordRight(s) {
     const chars = charsOf(s);
-    // Nothing to the right (end of buffer or only whitespace to the newline):
-    // delete the word on the LEFT instead of doing nothing.
-    let probe = s.cursor;
-    while (probe < chars.length &&
-        chars[probe] !== NL &&
-        /\s/.test(chars[probe])) {
-        probe++;
-    }
-    if (probe >= chars.length || chars[probe] === NL) {
-        return deleteWordLeft(s);
-    }
+    // Stop at a NEWLINE: it is whitespace for /\s/ but must never be swallowed
+    // by a word delete (the old code guarded this; without the guard the key
+    // ate the line break).
     let i = s.cursor;
-    while (i < chars.length && /\s/.test(chars[i]))
+    while (i < chars.length && chars[i] !== NL && /\s/.test(chars[i]))
         i++;
-    while (i < chars.length && !/\s/.test(chars[i]))
+    while (i < chars.length && chars[i] !== NL && !/\s/.test(chars[i]))
         i++;
+    if (i === s.cursor)
+        return s;
     chars.splice(s.cursor, i - s.cursor);
-    return { ...s, buf: chars.join('') };
+    return { ...s, buf: chars.join(''), cursor: s.cursor };
 }
 /** Delete from the cursor to the end of the current LOGICAL line (Ctrl+K). */
 export function killToLineEnd(s) {

package/dist/tui/keys.js

@@ -35,8 +35,8 @@ export function parseCsiU(raw) {
     if (cp === 13 && (ctrl || alt))
         return { type: 'newline' };
     if (cp === 3) {
-        // Ctrl/Alt+Delete deletes the word on the LEFT (see dispatchKey).
-        return ctrl || alt ? { type: 'deleteWordLeft' } : { type: 'delete' };
+        // Ctrl/Alt+Delete deletes the word on the RIGHT (standard editor binding).
+        return ctrl || alt ? { type: 'deleteWordRight' } : { type: 'delete' };
     }
     if (cp === 127) {
         return ctrl || alt ? { type: 'deleteWordLeft' } : { type: 'backspace' };
@@ -85,11 +85,11 @@ export function dispatchKey(input, key, ctx, isVisualEdge) {
             return { type: 'wordLeft' };
         if (key.rightArrow)
             return { type: 'wordRight' };
-        // Ctrl+Delete deletes the word BEFORE the cursor (the operator's binding:
-        // "Ctrl+Del must delete the word before the cursor"). Ctrl+Backspace does
-        // the same. Plain Delete still deletes one char to the RIGHT.
+        // Ctrl+Delete deletes the word AFTER the cursor (the standard editor
+        // binding, same as the legacy LineEditor). Ctrl+Backspace deletes the word
+        // BEFORE it. Plain Delete still deletes one char to the right.
         if (key.delete)
-            return { type: 'deleteWordLeft' };
+            return { type: 'deleteWordRight' };
         if (key.backspace)
             return { type: 'deleteWordLeft' };
         if (key.home)
@@ -143,16 +143,16 @@ export function dispatchKey(input, key, ctx, isVisualEdge) {
         if (input === 'f')
             return { type: 'wordRight' };
         // VSCode sends Ctrl+Delete as `ESC d` (which Ink reports as Alt+d).
-        // The operator expects it to delete the word BEFORE the cursor.
+        // Standard editor binding: delete the word AFTER the cursor.
         if (input === 'd')
-            return { type: 'deleteWordLeft' };
+            return { type: 'deleteWordRight' };
         if (key.backspace)
             return { type: 'deleteWordLeft' };
-        // Alt/Ctrl+Delete also deletes the word BEFORE the cursor (the operator's
-        // binding, consistent with ESC d): some terminals encode Ctrl+Delete as
-        // meta+Delete rather than ESC d.
+        // Alt/Ctrl+Delete also deletes the word AFTER the cursor (consistent with
+        // ESC d): some terminals encode Ctrl+Delete as meta+Delete rather than
+        // ESC d.
         if (key.delete)
-            return { type: 'deleteWordLeft' };
+            return { type: 'deleteWordRight' };
         return null;
     }
     // ---- LF as a bare newline (Ctrl+J) ----

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zames_pro",
-  "version": "2.75.6",
+  "version": "2.76.0",
   "description": "Terminal coding agent that drives a real browser to chat with DeepSeek, Qwen and other web LLMs — no API key required. Reads and edits files, runs commands, commits to git, like Claude Code / Codex CLI.",
   "type": "module",
   "bin": {