CW-201c · Module 2

Team Consistency Standards

3 min read

When five people on a team each use Claude independently, they produce five different voices, five different formats, and five different quality levels. The proposal Alice writes with Claude reads like a different company from the proposal Bob writes with Claude. The analysis Carol produces uses different metrics than the analysis Dave produces. The client sees inconsistency and questions professionalism.

Team consistency standards solve this by defining the non-negotiable elements that every Claude-produced deliverable must include. Voice and tone: "We write in active voice, second person where possible, with confidence but not arrogance." Format: "Every proposal has these seven sections in this order." Metrics: "Revenue analysis always includes MRR, ARR, churn, and LTV." Quality gate: "Every external deliverable goes through the QA skill before sending."

The standards live in two places. First, in a shared style guide that team members reference when creating new prompts and skills. This is the human-readable version — it explains the reasoning behind each standard. Second, in shared skills that enforce the standards automatically. The proposal skill always uses the seven-section format. The analysis skill always includes the required metrics. The QA skill always checks for voice consistency.

The second location is what makes standards sticky. A style guide on a Wiki page requires discipline to follow. A skill that enforces the standard requires nothing — it just works. When you encode "always use active voice" into the writing skill, every team member's Claude output uses active voice without anyone having to remember the rule. The standard is infrastructure, not policy.

Do This

  • Define voice, format, metrics, and quality gates as team standards
  • Encode standards into skills that enforce them automatically
  • Review team output monthly for consistency drift — standards erode without maintenance
  • Onboard new team members by sharing the skills first, the style guide second

Avoid This

  • Assume team members will naturally produce consistent output — they will not
  • Put standards only in a document nobody reads — encode them into the tools people use
  • Set standards once and forget them — they need refinement as the team's work evolves
  • Apply the same standards to every deliverable type — a proposal has different requirements than an analysis