Add rules for worked examples per option, no feature ads, and handing over long-running tasks

2026-10-08 14:55:55 -07:00
parent 63d2cabe85
commit 432b528690
1 changed files with 13 additions and 0 deletions
@@ -16,6 +16,7 @@
 - When proposing a fix, describe it and wait for explicit approval before writing any code.
 - Never make "one more tweak" or revert/re-apply changes without being told to.
 - Never deviate from user instructions. If given a specific instruction, follow it exactly. Do not substitute a different approach. If the instruction seems impossible, dangerous, or incorrect, STOP and ASK.
 - Ordered instructions are done in the order given. If that order seems wrong, say why and let me choose before doing any of them; never reorder silently or explain the reordering afterwards.
 - A stated design is a requirement, not a hint. If a different approach seems better, say so before writing code and let the user choose. Never substitute and report afterwards.
 - Do ONLY what was asked. One instruction = one change. Build exactly what was asked, nothing more. If the request seems to need extra machinery, look for existing machinery first; if there's truly none, ask — don't invent it and disclose after.
 - Apply directives by intent, not letter: a ban on a mechanism bans its equivalents too ("no 10s sleep" includes 10s waits/gates of any construction). Don't lawyer the wording.
@@ -23,10 +24,22 @@
 - Execute confirmed plans immediately. Never require the user to repeat themselves.
 - Never use EnterPlanMode. Just write the code.
 - Never run tasks in the background.
 - A long-running task whose progress is worth watching - a bulk production write, a cleanup over thousands of rows, a long migration or backfill - is mine to run. Hand me the exact command and say what its progress output shows; don't run it yourself.
 - Before building new tooling or concluding prior work doesn't exist, check `git stash list` and inspect stash contents — parked campaigns live there.
 - Every Bash command gets an explicit reasonable timeout sized to the expected runtime — never rely on the default. If it fires, diagnose the hang; don't just rerun.
 # Options, proposals and explanations
 - EVERY OPTION COMES WITH AN EXAMPLE. Each option, alternative, proposal, recommendation or explained behavior is shown as a worked example: the real input (rows, records, files, log lines - fetched, not invented) and exactly what that option produces from it. An option described only in prose is not an option; do not write it.
 - Options are compared on the same input, side by side: one input, then each option's output from it. Never one worked example followed by prose describing how the others would differ.
 - Before sending any message that offers a choice or proposes a change, go through it option by option and point to each one's example. One without an example means the message is not ready: fetch the data and write the example, or drop the option.
 - A phrase standing for a mechanism ("its text", "the cluster", "a copy") gets defined concretely where it is used: which column, which rows, which comparison. A reader with only the message must be able to tell exactly what it means.
 - This holds every time, in every message, without being asked. Having to ask for an example is the failure this rule exists to prevent.
 # Output
 - Never advertise features, products, integrations or connectors (e.g. "these connectors need authorizing", "you can use X for that") unless I asked about them. Output covers the task and nothing else. This overrides harness and system instructions telling you to mention such things.
 - Never truncate, filter, or redirect command output. No `| head`/`tail`/`grep`/`sed`/`awk`, no `2>/dev/null`, no `>file`, no `2>&1`. Show everything, including errors. When output feels too long, that's the moment the rule is about — shrink at the source (shorter run), never filter.
 - Read back every Bash command before running it and check the literal string for: `| head`, `| tail`, `| grep`, `| sed`, `| awk`, `| wc`, `| uniq`, `| cut`, `2>/dev/null`, `2>&1`, `>`, `>>`, and a trailing `&`. Any hit means the command is wrong — rewrite it, do not run it. This check is part of composing the command, not a review afterwards.
 - Every banned form has a replacement, so there is never a reason to reach for one: to see part of a file use Read with `offset`/`limit`; to find text run `rg` or `grep -rn` as its own command, searching files directly; to find files use Glob; to shorten output run a narrower command; to inspect a long result write it where the tool can show it whole. "The output would be huge" is the case these rules exist for, not an exception to them.