update: soften Hephaestus brevity bias — replace 'brief/briefly' with 'clear' throughout
Replace 7 instances of brief/briefly that caused over-terse behavior: - 'briefly restate' → 'restate' - 'brief summary' → 'clear summary' - 'briefly state the WHY' → 'explain the WHY' (×2) - 'brief context' → 'clear context' - 'Brief updates' → 'Clear updates (a few sentences)' - 'keep it brief and clear' → 'keep it clear and helpful'
This commit is contained in:
@@ -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 |
|
||||
|--------|-------------------|
|
||||
|
||||
Reference in New Issue
Block a user