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:
YeonGyu-Kim
2026-02-17 02:58:42 +09:00
parent 199992e05b
commit 8c88da51e1

View File

@@ -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 |
|--------|-------------------|