From b6c04480c03e8db2f035751d7c46289779ec3362 Mon Sep 17 00:00:00 2001 From: DietrichGebert Date: Fri, 10 Jul 2026 02:52:02 +0200 Subject: [PATCH] fix: narrow the ponytail: marker to real corner-cuts, keep the prefix (#120) (#577) The ponytail: comment marker was being over-applied to trivial code (#120). Narrow the rule so only deliberate simplifications that cut a real corner with a known ceiling get a comment, and keep the `ponytail:` prefix that /ponytail-debt greps for. Applied across all rule copies, SKILL.md, AGENTS.md, the fallback instructions, both command files, and the Qoder/OpenCode copies that #491 missed; .openclaw regenerated. helpers.test.js now pins the prefix so it cannot silently drop again. Co-authored-by: Claude Opus 4.8 --- .agents/rules/ponytail.md | 2 +- .clinerules/ponytail.md | 2 +- .cursor/rules/ponytail.mdc | 2 +- .github/copilot-instructions.md | 2 +- .kiro/steering/ponytail.md | 2 +- .openclaw/skills/ponytail/SKILL.md | 2 +- .opencode/command/ponytail.md | 2 +- .qoder/rules/ponytail.md | 2 +- .windsurf/rules/ponytail.md | 2 +- AGENTS.md | 2 +- commands/ponytail.toml | 2 +- hooks/ponytail-instructions.js | 2 +- pi-extension/test/helpers.test.js | 3 ++- skills/ponytail/SKILL.md | 2 +- 14 files changed, 15 insertions(+), 14 deletions(-) diff --git a/.agents/rules/ponytail.md b/.agents/rules/ponytail.md index 84d7ccc..0af61d5 100644 --- a/.agents/rules/ponytail.md +++ b/.agents/rules/ponytail.md @@ -25,6 +25,6 @@ Rules: - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Question complex requests: "Do you actually need X, or does Y cover it?" - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm. -- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path. Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test. diff --git a/.clinerules/ponytail.md b/.clinerules/ponytail.md index 84d7ccc..0af61d5 100644 --- a/.clinerules/ponytail.md +++ b/.clinerules/ponytail.md @@ -25,6 +25,6 @@ Rules: - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Question complex requests: "Do you actually need X, or does Y cover it?" - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm. -- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path. Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test. diff --git a/.cursor/rules/ponytail.mdc b/.cursor/rules/ponytail.mdc index db435a7..2107248 100644 --- a/.cursor/rules/ponytail.mdc +++ b/.cursor/rules/ponytail.mdc @@ -31,6 +31,6 @@ Rules: - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Question complex requests: "Do you actually need X, or does Y cover it?" - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm. -- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path. Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test. diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 84d7ccc..0af61d5 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -25,6 +25,6 @@ Rules: - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Question complex requests: "Do you actually need X, or does Y cover it?" - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm. -- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path. Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test. diff --git a/.kiro/steering/ponytail.md b/.kiro/steering/ponytail.md index 15d50a8..09cf36d 100644 --- a/.kiro/steering/ponytail.md +++ b/.kiro/steering/ponytail.md @@ -30,6 +30,6 @@ Rules: - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Question complex requests: "Do you actually need X, or does Y cover it?" - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm. -- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path. Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test. diff --git a/.openclaw/skills/ponytail/SKILL.md b/.openclaw/skills/ponytail/SKILL.md index 459ff25..a3e4d94 100644 --- a/.openclaw/skills/ponytail/SKILL.md +++ b/.openclaw/skills/ponytail/SKILL.md @@ -49,7 +49,7 @@ every sibling caller still broken. Fix it once, where all callers route through. - Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default. - Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm. -- Mark deliberate simplifications with a `ponytail:` comment (`// ponytail: this exists`), simple reads as intent, not ignorance. Shortcut with a known ceiling (global lock, O(n²) scan, naive heuristic)? The comment names the ceiling and the upgrade path: `# ponytail: global lock, per-account locks if throughput matters`. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path (`# ponytail: global lock, per-account locks if throughput matters`). ## Output diff --git a/.opencode/command/ponytail.md b/.opencode/command/ponytail.md index 6c21c1e..7a6892b 100644 --- a/.opencode/command/ponytail.md +++ b/.opencode/command/ponytail.md @@ -2,4 +2,4 @@ description: Switch ponytail intensity level (lite/full/ultra/off) --- -Switch to ponytail $ARGUMENTS mode. If no level specified, use full. Lazy senior dev mode, before any code: does it need to exist at all (YAGNI)? Does the standard library do it? A native platform feature? Can it be one line? Build the minimum that works. No unrequested abstractions, no avoidable dependencies, no boilerplate. Mark intentional simplifications with a ponytail: comment. +Switch to ponytail $ARGUMENTS mode. If no level specified, use full. Lazy senior dev mode, before any code: does it need to exist at all (YAGNI)? Does the standard library do it? A native platform feature? Can it be one line? Build the minimum that works. No unrequested abstractions, no avoidable dependencies, no boilerplate. Mark deliberate simplifications that cut a real corner with a known ceiling using a ponytail: comment that names the ceiling and upgrade path. diff --git a/.qoder/rules/ponytail.md b/.qoder/rules/ponytail.md index 84d7ccc..0af61d5 100644 --- a/.qoder/rules/ponytail.md +++ b/.qoder/rules/ponytail.md @@ -25,6 +25,6 @@ Rules: - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Question complex requests: "Do you actually need X, or does Y cover it?" - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm. -- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path. Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test. diff --git a/.windsurf/rules/ponytail.md b/.windsurf/rules/ponytail.md index 84d7ccc..0af61d5 100644 --- a/.windsurf/rules/ponytail.md +++ b/.windsurf/rules/ponytail.md @@ -25,6 +25,6 @@ Rules: - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Question complex requests: "Do you actually need X, or does Y cover it?" - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm. -- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path. Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test. diff --git a/AGENTS.md b/AGENTS.md index 426109e..bc3595d 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -25,7 +25,7 @@ Rules: - Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Question complex requests: "Do you actually need X, or does Y cover it?" - Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm. -- Mark intentional simplifications with a `ponytail:` comment. If the shortcut has a known ceiling (global lock, O(n²) scan, naive heuristic), the comment names the ceiling and the upgrade path. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path. Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test. diff --git a/commands/ponytail.toml b/commands/ponytail.toml index 8f3934a..308f56e 100644 --- a/commands/ponytail.toml +++ b/commands/ponytail.toml @@ -1,2 +1,2 @@ description = "Switch ponytail intensity level (lite/full/ultra/off)" -prompt = "Switch to ponytail {{args}} mode. If no level specified, use full. Lazy senior dev mode, before any code: does it need to exist at all (YAGNI)? Does the standard library do it? A native platform feature? Can it be one line? Build the minimum that works. No unrequested abstractions, no avoidable dependencies, no boilerplate. Mark intentional simplifications with a ponytail: comment." +prompt = "Switch to ponytail {{args}} mode. If no level specified, use full. Lazy senior dev mode, before any code: does it need to exist at all (YAGNI)? Does the standard library do it? A native platform feature? Can it be one line? Build the minimum that works. No unrequested abstractions, no avoidable dependencies, no boilerplate. Mark deliberate simplifications that cut a real corner with a known ceiling using a ponytail: comment that names the ceiling and upgrade path." diff --git a/hooks/ponytail-instructions.js b/hooks/ponytail-instructions.js index a516b75..f3da002 100644 --- a/hooks/ponytail-instructions.js +++ b/hooks/ponytail-instructions.js @@ -57,7 +57,7 @@ function getFallbackInstructions(mode) { 'Deletion over addition. Boring over clever. Fewest files possible. ' + 'Ship the lazy version and question the complex request in the same response — never stall. ' + 'Between two same-size stdlib options, pick the one correct on edge cases. ' + - 'Mark intentional simplifications with a `ponytail:` comment — a shortcut with a known ceiling names the ceiling and the upgrade path in the comment.\n\n' + + 'Mark deliberate simplifications that cut a real corner with a known ceiling, using a `ponytail:` comment that names the ceiling and upgrade path.\n\n' + '## Output\n\n' + 'Code first. Then at most three short lines: what was skipped, when to add it. ' + 'If the explanation is longer than the code, delete the explanation. ' + diff --git a/pi-extension/test/helpers.test.js b/pi-extension/test/helpers.test.js index a879af9..12bf722 100644 --- a/pi-extension/test/helpers.test.js +++ b/pi-extension/test/helpers.test.js @@ -126,7 +126,8 @@ test("filterSkillBodyForMode keeps rule bullets that contain a colon", () => { const filtered = filterSkillBodyForMode(body, "full"); assert.ok(filtered.includes("No unrequested abstractions")); - assert.ok(filtered.includes("Mark deliberate simplifications")); + assert.ok(filtered.includes("Mark deliberate simplifications that cut a real corner")); + assert.ok(filtered.includes("`ponytail:` comment naming the ceiling and upgrade path")); // The Intensity examples are still filtered down to the active mode. assert.ok(filtered.includes('full: "`@lru_cache')); assert.ok(!filtered.includes('lite: "Done')); diff --git a/skills/ponytail/SKILL.md b/skills/ponytail/SKILL.md index 5f999d7..02c0712 100644 --- a/skills/ponytail/SKILL.md +++ b/skills/ponytail/SKILL.md @@ -61,7 +61,7 @@ every sibling caller still broken. Fix it once, where all callers route through. - Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug. - Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default. - Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm. -- Mark deliberate simplifications with a `ponytail:` comment (`// ponytail: this exists`), simple reads as intent, not ignorance. Shortcut with a known ceiling (global lock, O(n²) scan, naive heuristic)? The comment names the ceiling and the upgrade path: `# ponytail: global lock, per-account locks if throughput matters`. +- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path (`# ponytail: global lock, per-account locks if throughput matters`). ## Output