Merge upstream origin/main (v2.60.0) with fork customizations preserved

Incorporates 78 upstream commits while preserving all local fork intent:
- Keep deleted: dhh-rails, kieran-rails, dspy-ruby, andrew-kane-gem-writer (FastAPI pivot)
- Merge both: ce-review (zip-agent-validator + design-conformance-reviewer wiring),
  kieran-python-reviewer (upstream pipeline + FastAPI conventions),
  ce-brainstorm/ce-plan/ce-work (upstream improvements + deploy wiring checks),
  todo-create (upstream template refs + assessment block),
  best-practices-researcher (upstream rename + FastAPI refs)
- Accept remote: 142 remote-only files, plugin.json, README.md
- Keep local: 71 local-only files (custom agents, skills, commands, voice)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
John Lamb
2026-03-31 12:27:52 -05:00
parent 1840b0c7cc
commit bf1f79aba4
58 changed files with 6413 additions and 1229 deletions

View File

@@ -0,0 +1,53 @@
# Tone Guide for Ticket Writing
## Core Principle
A human will read this ticket. Write like a teammate asking for help, not an AI generating a spec.
## Pressure Test Checklist
Review every sentence against these questions:
### 1. Patronizing language
- Does any sentence explain the reader's own domain back to them?
- Would you say this to a senior engineer's face without feeling awkward?
- Are you telling them HOW to implement something in their own system?
- Are you preemptively arguing against approaches they haven't proposed?
**Examples of patronizing language:**
- "This is a common pattern in Kubernetes deployments" (they know)
- "Helm charts support templating via {{ .Values }}" (they wrote the chart)
- "Why X, not Y" sections that dismiss alternatives before anyone suggested them
### 2. AI-isms to remove
- Em dashes used more than once per paragraph
- Every thought is a bullet point instead of a sentence
- Rigid structure that feels generated (Ask -> Why -> Context -> AC)
- Spec-writing voice: "When absent or false, existing behavior is preserved"
- Overuse of "ensures", "leverages", "facilitates", "streamlines"
- Unnecessary hedging: "It should be noted that..."
- Filler transitions: "Additionally", "Furthermore", "Moreover"
- Lists where prose would be more natural
### 3. Human voice check
- Does it sound like something you'd type in Slack, cleaned up slightly?
- Are there moments of humility? ("you'd know better than us", "if we're missing something")
- Is the tone collaborative rather than directive?
- Would you feel comfortable putting your name on this?
### 4. Kindness check
- Frame requests as requests, not demands
- Acknowledge the reader's expertise
- Offer context without over-explaining
- "Happy to chat more" > "Please advise"
## What to keep
- Technical detail and specifics (the reader needs these)
- Code snippets showing current state and desired state
- File references with line numbers
- Clear "done when" criteria (but keep them minimal)