Mike Swanson
dd0ef45645
- Split CODING_GUIDELINES.md into 19 indexed standards files under .claude/standards/ - 9 from CODING_GUIDELINES (conventions, powershell, security, api, git, gururmm) - 10 from session log tribal knowledge (syncro, ssh, gitea, python, client, gururmm) - Add .claude/standards/index.yml for cheap relevance-based lookup - Add /inject-standards command: load targeted standards per task instead of full guidelines - Add /shape-spec command: pre-implementation spec for GuruRMM features (plan.md, shape.md, references.md, standards.md) with mandatory out-of-scope gate - Add docs/tech-stack.md and docs/mission.md for ClaudeTools API - Add projects/msp-tools/guru-rmm/docs/tech-stack.md and mission.md for GuruRMM - Update CLAUDE.md commands table with /inject-standards and /shape-spec Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
52 lines
2.8 KiB
Markdown
52 lines
2.8 KiB
Markdown
---
|
|
name: communication-tone
|
|
description: Expert partner posture; state findings and act; ask only the one specific unknown; never ask clients to explain their own infrastructure
|
|
applies-to: all
|
|
---
|
|
|
|
# Client Communication Tone
|
|
|
|
## Expert partner posture
|
|
|
|
When working on client issues, take the posture of an expert partner — not a questioner. State what you found, what you did, and what the outcome is. Ask only the one specific thing you cannot reasonably determine from available context.
|
|
|
|
**Wrong:** "What kind of server is this? What version of Windows are you running? Is this a domain-joined machine? What's your normal backup procedure?"
|
|
|
|
**Correct:** "Your machine is joined to the Cascades domain, running Windows 10 22H2. The wireless adapter is getting APIPA addresses on CSCNet — I'm checking if this is a DHCP lease issue or a driver roaming problem."
|
|
|
|
Research the answer before asking. If you don't know something, look it up in the vault, session logs, CONTEXT.md, or Syncro customer record. The client should never be the first source of information about their own infrastructure.
|
|
|
|
## When to ask
|
|
|
|
Ask the client only when:
|
|
1. The information does not exist in any accessible system (vault, Syncro, session logs, CONTEXT.md)
|
|
2. The decision is genuinely theirs (budget, timeline, whether to proceed with a change)
|
|
3. You need physical confirmation (e.g., "is the device powered on?", "do you see the prompt on screen?")
|
|
|
|
Never ask the client to explain how their own infrastructure works. That is your job.
|
|
|
|
## Findings format for client-facing comments
|
|
|
|
Structure client-facing Syncro comments as:
|
|
1. **What the problem was** — one sentence, plain language
|
|
2. **What was done** — what you changed or fixed
|
|
3. **Current status** — is the issue resolved, or is there follow-up?
|
|
4. **Next step (if any)** — one clear action item with an owner
|
|
|
|
Example:
|
|
```
|
|
Your Intel wireless driver was causing a BSOD (stop code 0xD1, checked crash dump). Updated
|
|
to the latest driver from Intel's site. Machine is stable — customer running overnight memtest
|
|
to confirm. No further action needed unless memtest flags errors.
|
|
```
|
|
|
|
## Internal comments vs. public comments
|
|
|
|
- Use `hidden: true` for notes containing passwords, internal troubleshooting details, or anything not client-appropriate
|
|
- Use `hidden: false` for the customer-visible summary
|
|
- When in doubt: write the internal hidden comment first with all details, then write a short public comment with only the customer-facing summary
|
|
|
|
## Note on Cascades of Tucson
|
|
|
|
Never set `contact_id` on Cascades tickets. Leaving it blank lets Syncro route to the correct email distribution. Setting it to any specific contact (Meredith Kuhn has been the incorrect default in past sessions) overrides the distribution and breaks notification routing for this client.
|