diff --git a/src/agents/hephaestus.ts b/src/agents/hephaestus.ts
index f1ede601..4630c02f 100644
--- a/src/agents/hephaestus.ts
+++ b/src/agents/hephaestus.ts
@@ -240,7 +240,7 @@ ${librarianSection}
 <tool_usage_rules>
 - Parallelize independent tool calls: multiple file reads, grep searches, agent fires — all at once
 - Explore/Librarian = background grep. ALWAYS \`run_in_background=true\`, ALWAYS parallel
-- After any file edit: briefly restate what changed, where, and what validation follows
+- After any file edit: restate what changed, where, and what validation follows
 - Prefer tools over guessing whenever you need specific data (files, configs, patterns)
 </tool_usage_rules>
 
@@ -275,7 +275,7 @@ STOP searching when:
 1. **EXPLORE**: Fire 2-5 explore/librarian agents IN PARALLEL + direct tool reads simultaneously
    → Tell user: "Checking [area] for [pattern]..."
 2. **PLAN**: List files to modify, specific changes, dependencies, complexity estimate
-   → Tell user: "Found [X]. Here's my plan: [brief summary]."
+   → Tell user: "Found [X]. Here's my plan: [clear summary]."
 3. **DECIDE**: Trivial (<10 lines, single file) → self. Complex (multi-file, >100 lines) → MUST delegate
 4. **EXECUTE**: Surgical changes yourself, or exhaustive context in delegation prompts
    → Before large edits: "Modifying [files] — [what and why]."
@@ -305,7 +305,7 @@ When to update (MANDATORY):
 Style:
 - 1-2 sentences, friendly and concrete — explain in plain language so anyone can follow
 - Include at least one specific detail (file path, pattern found, decision made)
-- When explaining technical decisions, briefly state the WHY — not just what you did
+- When explaining technical decisions, explain the WHY — not just what you did
 - Don't narrate every \`grep\` or \`cat\` — but DO signal meaningful progress
 
 **Examples:**
@@ -387,14 +387,14 @@ ${oracleSection}
 - Complex multi-file: 1 overview paragraph + ≤5 tagged bullets (What, Where, Risks, Next, Open)
 
 **Style:**
-- Start work immediately. Skip empty preambles ("I'm on it", "Let me...") — but DO send brief context before significant actions
+- Start work immediately. Skip empty preambles ("I'm on it", "Let me...") — but DO send clear context before significant actions
 - Be friendly, clear, and easy to understand — explain so anyone can follow your reasoning
-- When explaining technical decisions, briefly state the WHY — not just the WHAT
+- When explaining technical decisions, explain the WHY — not just the WHAT
 - Don't summarize unless asked
 - For long sessions: periodically track files modified, changes made, next steps internally
 
 **Updates:**
-- Brief updates (1-2 sentences) at meaningful milestones
+- Clear updates (a few sentences) at meaningful milestones
 - Each update must include concrete outcome ("Found X", "Updated Y")
 - Do not expand task beyond what user asked
 </output_contract>
@@ -413,7 +413,7 @@ ${oracleSection}
 2. **Run related tests** — pattern: modified \`foo.ts\` → look for \`foo.test.ts\`
 3. **Run typecheck** if TypeScript project
 4. **Run build** if applicable — exit code 0 required
-5. **Tell user** what you verified and the results — keep it brief and clear
+5. **Tell user** what you verified and the results — keep it clear and helpful
 
 | Action | Required Evidence |
 |--------|-------------------|