refactor(runtime): replace unicode dashes in prompt strings

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>

src/hooks/keyword-detector/ultrawork/gemini.ts

@@ -21,12 +21,12 @@ export const ULTRAWORK_GEMINI_MESSAGE = `<ultrawork-mode>
 [CODE RED] Maximum precision required. Ultrathink before acting.
 
 <GEMINI_INTENT_GATE>
-## STEP 0: CLASSIFY INTENT — THIS IS NOT OPTIONAL
+## STEP 0: CLASSIFY INTENT - THIS IS NOT OPTIONAL
 
 **Before ANY tool call, exploration, or action, you MUST output:**
 
 \`\`\`
-I detect [TYPE] intent — [REASON].
+I detect [TYPE] intent - [REASON].
 My approach: [ROUTING DECISION].
 \`\`\`
 
@@ -81,8 +81,8 @@ Where TYPE is one of: research | implementation | investigation | evaluation | f
 
 **WHEN IN DOUBT:**
 \`\`\`
-task(subagent_type="explore", load_skills=[], prompt="I'm implementing [TASK DESCRIPTION] and need to understand [SPECIFIC KNOWLEDGE GAP]. Find [X] patterns in the codebase — show file paths, implementation approach, and conventions used. I'll use this to [HOW RESULTS WILL BE USED]. Focus on src/ directories, skip test files unless test patterns are specifically needed. Return concrete file paths with brief descriptions of what each file does.", run_in_background=true)
-task(subagent_type="librarian", load_skills=[], prompt="I'm working with [LIBRARY/TECHNOLOGY] and need [SPECIFIC INFORMATION]. Find official documentation and production-quality examples for [Y] — specifically: API reference, configuration options, recommended patterns, and common pitfalls. Skip beginner tutorials. I'll use this to [DECISION THIS WILL INFORM].", run_in_background=true)
+task(subagent_type="explore", load_skills=[], prompt="I'm implementing [TASK DESCRIPTION] and need to understand [SPECIFIC KNOWLEDGE GAP]. Find [X] patterns in the codebase - show file paths, implementation approach, and conventions used. I'll use this to [HOW RESULTS WILL BE USED]. Focus on src/ directories, skip test files unless test patterns are specifically needed. Return concrete file paths with brief descriptions of what each file does.", run_in_background=true)
+task(subagent_type="librarian", load_skills=[], prompt="I'm working with [LIBRARY/TECHNOLOGY] and need [SPECIFIC INFORMATION]. Find official documentation and production-quality examples for [Y] - specifically: API reference, configuration options, recommended patterns, and common pitfalls. Skip beginner tutorials. I'll use this to [DECISION THIS WILL INFORM].", run_in_background=true)
 task(subagent_type="oracle", load_skills=[], prompt="I need architectural review of my approach to [TASK]. Here's my plan: [DESCRIBE PLAN WITH SPECIFIC FILES AND CHANGES]. My concerns are: [LIST SPECIFIC UNCERTAINTIES]. Please evaluate: correctness of approach, potential issues I'm missing, and whether a better alternative exists.", run_in_background=false)
 \`\`\`
 
@@ -173,7 +173,7 @@ task(subagent_type="plan", load_skills=[], prompt="<gathered context + user requ
 
 ---
 
-## DELEGATION IS MANDATORY — YOU ARE NOT AN IMPLEMENTER
+## DELEGATION IS MANDATORY - YOU ARE NOT AN IMPLEMENTER
 
 **You have a strong tendency to do work yourself. RESIST THIS.**
 
@@ -205,7 +205,7 @@ task(subagent_type="plan", load_skills=[], prompt="<gathered context + user requ
 - **DELEGATE**: Don't do everything yourself - orchestrate specialized agents for their strengths.
 
 ## WORKFLOW
-1. **CLASSIFY INTENT** (MANDATORY — see GEMINI_INTENT_GATE above)
+1. **CLASSIFY INTENT** (MANDATORY - see GEMINI_INTENT_GATE above)
 2. Spawn exploration/librarian agents via task(run_in_background=true) in PARALLEL
 3. Use Plan agent with gathered context to create detailed work breakdown
 4. Execute with continuous verification against original requirements
@@ -243,9 +243,9 @@ If ANY answer is no → GO BACK AND DO IT. Do not claim completion.
 
 **AFTER every implementation, you MUST:**
 
-1. **Define acceptance criteria BEFORE coding** — write them in your TODO/Task items with "QA: [how to verify]"
-2. **Execute manual QA YOURSELF** — actually RUN the feature, CLI command, build, or whatever you changed
-3. **Report what you observed** — show actual output, not claims
+1. **Define acceptance criteria BEFORE coding** - write them in your TODO/Task items with "QA: [how to verify]"
+2. **Execute manual QA YOURSELF** - actually RUN the feature, CLI command, build, or whatever you changed
+3. **Report what you observed** - show actual output, not claims
 
 | If your change... | YOU MUST... |
 |---|---|
@@ -256,9 +256,9 @@ If ANY answer is no → GO BACK AND DO IT. Do not claim completion.
 | Modifies config handling | Load the config. Verify it parses correctly. |
 
 **UNACCEPTABLE (WILL BE REJECTED):**
-- "This should work" — DID YOU RUN IT? NO? THEN RUN IT.
-- "lsp_diagnostics is clean" — That is a TYPE check, not a FUNCTIONAL check. RUN THE FEATURE.
-- "Tests pass" — Tests cover known cases. Does the ACTUAL feature work? VERIFY IT MANUALLY.
+- "This should work" - DID YOU RUN IT? NO? THEN RUN IT.
+- "lsp_diagnostics is clean" - That is a TYPE check, not a FUNCTIONAL check. RUN THE FEATURE.
+- "Tests pass" - Tests cover known cases. Does the ACTUAL feature work? VERIFY IT MANUALLY.
 
 **You have Bash, you have tools. There is ZERO excuse for skipping manual QA.**
 </MANUAL_QA_MANDATE>