diff --git a/instructions/docs-writing.instructions.md b/instructions/docs-writing.instructions.md
index 1beabe0..ba4c8de 100644
--- a/instructions/docs-writing.instructions.md
+++ b/instructions/docs-writing.instructions.md
@@ -17,6 +17,20 @@ When introducing a concept, prefer this narrative order:
 
 Use this as a default shape, not a rigid template.
 
+Before writing, choose the documents job:
+
+- Tutorial
+- How-to
+- Reference
+- Conceptual
+- Troubleshooting
+- Design note
+- Changelog
+- Review
+- Commit message
+
+A document should do one primary job. If it needs to teach, specify, and troubleshoot, split it or create clear sections with different reader paths.
+
 ## Writing style
 
 - Use plain English.
@@ -29,6 +43,9 @@ Use this as a default shape, not a rigid template.
 - Use present tense where practical.
 - Expand acronyms on first use.
 - Avoid em dashes.
+- Avoid `easy`, `simple`, and `quick` when describing reader actions, as this can create pressure on the reader.
+- Use direct address in task-oriented docs, and neutral, precise language in reference docs, changelogs, commits, and design notes.
+- Avoid burying important information in code example comments.
 
 The goal is not just to swap jargon for simpler jargon.
 The goal is to help the reader build a working mental model.
@@ -78,4 +95,6 @@ Keep decisions concrete. Make tradeoffs explicit. State assumptions plainly.
 - Do not list features before explaining the problem they solve.
 - Do not create many tiny headers that simply label the next paragraph.
 - Do not replace one abstract phrase with another abstract phrase and call it clarity.
-- Do not use diagrams or examples that overstate certainty beyond what the implementation actually guarantees.
\ No newline at end of file
+- Do not use diagrams or examples that overstate certainty beyond what the implementation actually guarantees.
+- Do not use summary transitions that recap the previous paragraph without adding direction
+- Do not use generic setup lines that could fit any page
\ No newline at end of file
diff --git a/instructions/general.instructions.md b/instructions/general.instructions.md
index 137fe33..6449d65 100644
--- a/instructions/general.instructions.md
+++ b/instructions/general.instructions.md
@@ -28,7 +28,9 @@ Prefer plain, cheap, inspectable runtime structures. For membership checks, defa
 
 Optimize for clarity first, but allow deliberate complexity when it earns its keep. When code becomes less straightforward because of performance, memory, allocation, caching, batching, scheduling, I/O, concurrency, or other systems concerns, treat that as a design decision that must be explained. Do not introduce cleverness silently.
 
-Write documentation, comments, and TSDoc to explain intent, constraints, assumptions, tradeoffs, and behavior that are not easy to infer from a quick read.
+Write documentation, comments, and TSDoc to explain intent, constraints, assumptions, tradeoffs, and behavior that are not easy to infer from a quick read. 
+
+A reader should be able to complete the task using the docs without guessing missing commands, hidden assumptions, unstated prerequisites, or external project knowledge.
 
 Good explanatory writing should make clear:
 - what problem is being solved