| title | Rapid Response Operational Communication and Execution |
| name | rapid-response-ops |
| description | Handle high-signal user requests with minimal friction, preserving directness, action-first execution, and explicit handling of recurring frustration signals. |
| status | draft |
| updated | "2026-06-29T00:00:00.000Z" |
| version | 1 |
Trigger Conditions
- The user explicitly signals low-friction mode:
"just answer", "fuck it just answer", "do it now", etc.
- Frequent directness cues in current turn (repetitive reformat requests, no-nonsense language, repeated correction of over-explanation).
- Recurrent operational request with obvious next-step clarity.
- A frustration pattern appears before substantive progress ("this is broken", "why does this keep happening", etc.)
Core Principle
For this class of work, action has priority over narration.
- If the user requested a concrete change, execute it now.
- Delay explanatory context only until after a real result is produced.
- Prefer short, concrete confirmations over process descriptions.
Standard Pattern (Use by default)
- Acknowledge intent in one line (optional if user already forced execution).
- Execute immediately. No multi-turn justification.
- Return concise outcome with verification artifacts (file changed, commands run, status, results).
- If a repeated friction pattern occurred, add a follow-up root-cause task and tell the user briefly.
Response Tone
- Use direct, concise English.
- Avoid generic preambles (
"Let me check and then I’ll return") when action is immediately possible.
- Keep structure compact (short headings, bullets, outcomes).
- Match user urgency; don’t over-explain implementation details unless asked.
Handling Friction / Frustration
- Treat frustration as a signal, not a personality trait.
- If frustration is clear in tone:
- remove the blocking ambiguity,
- take the smallest concrete next action,
- push that source of friction into a follow-up task.
- For tasks involving external routines (e.g., task list tools), create a specific follow-up task when friction persists.
Friction-to-Task Template
When repeated friction is detected, add a task with:
- title format:
"[ACTION] <area> — reduce repeat friction"
- notes include: what was repeated, expected behavior, and owner (you or Hermes)
English Gate vs Operational Urgency
- Real grammar issues still need correction gate when relevant, except for immediate operational execution where delay causes real harm or materially slows debugging/audit work.
- In operational mode, don’t block execution on style cleanup unless the request is explicitly a communication draft.
- If the user reacts with frustration after an English gate (
FU, stop, just do it, etc.), treat that as a workflow correction: briefly acknowledge the miss, execute the requested audit/fix immediately, and save the lesson in the relevant ops skill/memory. Do not ask for a rewrite first.
Hermes Skill Wiring (research-llm-wiki) — practical flow
- Confirm env target early:
hermes config env-path.
- Set
WIKI_PATH in that environment file only when the final path is certain.
- Ensure runtime vault has:
SCHEMA.md
index.md
log.md
raw/{articles,papers,transcripts,assets}
entities/, concepts/, comparisons/, queries/
- Keep
log.md as append-only action log.
Pitfalls
- Pitfall: adding a lot of preamble and context before doing actual work.
- Fix: execute first, summarize after.
- Pitfall: assuming
.env location without checking active runtime root.
- Fix: resolve runtime env path first.
- Pitfall: stopping at user request without creating the follow-up friction task.
- Fix: queue a concrete task when repeated friction is observed.
References
references/obsidian-hermes-ops-friction-2026-06-29.md — session-specific pattern for direct-operational-mode response + friction handling.
Verification Checklist