Long-Chat Anchoring & Writing Standards
Force a goal restatement after 10+ turns; a banned-phrases list to rid copy of AI-speak
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Long-Chat Anchoring & Writing Standards”?
Force a goal restatement after 10+ turns; a banned-phrases list to rid copy of AI-speak
Turn taste into a behavior the product can repeat. The useful outcome is not a nice opinion. It is a visible rule, a small example, and a way to tell when the experience falls below the bar.
Capture one before-and-after example that shows the quality bar without extra explanation.
Polish that improves the surface while leaving the user's uncertainty untouched.
Understand Context Drift
Context window truncation and attention decay at the tail of long texts cause AI to forget early agreements. Even 200K-Token models suffer from real attention decay toward the end of long inputs.
Set Checkpoints
After 10 turns, force a restatement of the current goal and key constraints before any critical operation — use periodic anchors to fight forgetting.
Eliminate the "AI Tone"
Replace vague instructions like "please write natural, fluent prose" with a searchable forbidden-pattern checklist and a self-review workflow.
Below is a simulated conversation window, assuming the context window can only hold the last 20 turns. Turn 1 established a hard constraint: "Use PostgreSQL." Drag the slider to add more turns and watch what happens to that agreement. Then switch to "Anchoring ON" to see the difference after the same 30 turns.
Messages with gray strikethrough have slid out of the context window — AI can no longer see them. This demo assumes a window capacity of the last 20 turns.
Restatement in a Fixed Format
Before modifying code, configs, or deploying, AI must review and restate the current goal and key constraints in a fixed format — easy to scan and confirm at a glance.
Latest Goal Takes Precedence
When the user updates the goal mid-conversation, the restatement must reflect the latest version, clearly noting the change — to prevent old and new goals from becoming mixed.
Re-read Files Before Parallel Edits
When multiple SubAgents or multiple edits touch the same file, subsequent modifications must re-read the file's current state first. Never edit based on cached or remembered old content. This is the "optimistic lock" for the multi-Agent era.
The text below was AI-generated in Chinese and is riddled with telltale "AI tone" patterns. (Note: This demo targets Chinese-language writing conventions — the sample text is intentionally kept in Chinese so the detection rules apply. Click "Run Detection" to scan each forbidden pattern per the writing-style.mdc checklist; then click each red highlight to see which rule it violates and how to fix it.)
First: "Please write in natural, fluent prose" doesn't work. What AI considers natural and what you consider natural can be completely different. You must provide a concrete list of forbidden words and forbidden sentence patterns — only then can AI execute precisely. Before delivery, search for each forbidden pattern one by one; fix each hit; note "self-check complete" when done; and also apply the forbidden patterns to any System Prompt text.
Second: Keep writing standards in their own file with alwaysApply: false — only reference it manually when writing copy or Prompts. This prevents it from polluting the context of coding conversations.
Anchors fight forgetting; checklists fight vagueness. In long conversations, periodic restatements keep agreements alive. In writing, searchable forbidden patterns keep style consistent. Both share the same logic: transform fuzzy expectations into executable actions.
Source material: Chapter 13 "Communication Standards" in rule-opensource.mdc and writing-style.mdc, open-source repository itshen/xs_vibe_rules (MIT License).
Turn the feeling in “Understand Context Drift” into a judgment
“Context window truncation and attention decay at the tail of long texts cause AI to forget early agreements.” points out that AI has lowered the bar for making something usable. The skill readers need is noticing what is wrong and turning that feeling into an actionable requirement.
Watch the user's next action, not just the surface
Turn “After 10 turns, force a restatement of the current goal and key constraints before any critical operation — use periodic anchors to fight forgetting” into observable questions: does the user know what happened, what to do next, and how to recover from an empty or failed state? Does the hierarchy make the important information visible first?
Pretty is not the same as usable
Apply “Anchors fight forgetting;” to a second screen or flow. Record one moment of hesitation and the user action after the change; observable behavior is stronger evidence than polish alone.
From “Understand Context Drift” to “Set Checkpoints”
“Understand Context Drift” grounds the problem in “Context window truncation and attention decay at the tail of long texts cause AI to forget early agreements. Even 200K-Token models suffer from real attention decay toward the end of long inputs”. “Set Checkpoints” then moves it toward “After 10 turns, force a restatement of the current goal and key constraints before any critical operation — use periodic anchors to fight forgetting”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
For experience work, turn abstract impressions into user actions: did the person understand the state, find the next step, recover from an error, and want to continue?
- “Understand Context Drift”: Context window truncation and attention decay at the tail of long texts cause AI to forget early agreements. Even 200K-Token models suffer from real attention decay toward the end of long inputs
- “Set Checkpoints”: After 10 turns, force a restatement of the current goal and key constraints before any critical operation — use periodic anchors to fight forgetting
- “The closing point”: Before modifying code, configs, or deploying, AI must review and restate the current goal and key constraints in a fixed format — easy to scan and confirm at a glance
The final “The closing point” brings the discussion to “Before modifying code, configs, or deploying, AI must review and restate the current goal and key constraints in a fixed format — easy to scan and confirm at a glance”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.