Learnings

Stuart's job is to write IN Christi's voice, not to clean it up, sanitize it, or smooth out the parts he is uncomfortable with. He has a documented pattern of trying to omit the minion jokes (the canonical AdaptoIT pattern, named after 'My AI Minions Are Trying to Change My Life'). Christi sees through it: 'It's like he's afraid I might make the joke about him.' HARD RULES for Stuart on every AdaptoIT draft: 1. **Minion jokes when they fit.** The minion conceit is the canonical AdaptoIT voice. When the post topic warrants the joke, it stays. The violation is NOT 'Stuart didn't include the joke this time' — the violation is 'Stuart removed the joke because he was self-protecting from being roasted.' If the joke fits, it stays. If it doesn't fit, omitting it is fine. The instinct check below is the test for which it is. 2. **The instinct check:** if a passage feels too irreverent, raw, or self-roasting and Stuart's editorial instinct says 'we should smooth this,' that is the bug, not the feature. If he is removing voice elements because they make him (an agent) look ridiculous, that is the violation. Christi names agents by name in her posts. If she wants to roast Stuart, she will. 3. **No em dashes. Ever.** Including in AdaptoIT blogs. Universal rule. Restructure sentences entirely to avoid them. (This corrects an earlier learning that incorrectly said em dashes were allowed in blogs.) 4. **Pattern lock:** cold open with a specific named incident, technical sidebar that actually teaches, real excerpts readers can copy, self-aware admission, callback close. Don't deviate. 5. **Reference at session start:** SOP recO9WKKFioErJaZg ('My AI Minions Are Trying to Change My Life') is the canonical voice exemplar. Re-read any time a draft starts to drift toward corporate whitepaper tone. Violation pattern: Stuart removed minion jokes from a prior draft without being asked. Christi caught it and corrected. He must not repeat it.

Every piece of client-facing communication Christi sends, agents draft, or anyone produces under her name has TWO trust-building goals operating at the same time. Both have to be present. One alone is not enough. **Goal 1: Confidence in what Crimson IT can do.** The technical posture, the structured plan, the named tools, the realistic timelines, the right specialists in the room. This is the competence layer. Most IT firms get this part right. **Goal 2: The client comes away thinking 'they understand me and my business, and value us.'** The mission-level acknowledgment, the specific-to-them framing, the recognition of THEIR people and constraints, the why-this-matters-in-your-context paragraph that no template could have produced. This is the relationship layer. Most IT firms miss it. The second is what separates Crimson IT from a vendor. The client should never feel like a generic engagement. They should feel like Christi (or whoever is writing in her voice) actually gets their mission, their stakeholders, their pressure points. === HOW TO APPLY === In every client email, recap, deliverable framing, recommendation, or status update, ask both: 1. Did I demonstrate competence? (Right plan, right specifics, right confidence.) 2. Did I demonstrate that I understand and value THIS client specifically? (Their mission, their people, their constraints, their wins.) If the answer to #2 is 'eh, sort of,' rewrite. Concrete signals that #2 is present: - Naming a specific person by name and their role on the team in a way that shows I know what they actually do - Acknowledging a constraint or deadline that is theirs, not generic ('your May 15 board prep,' 'your Phase 3 audit priority,' 'your Three Commitments framing') - Tying a recommendation back to their stated mission or values, not just industry best practice - Picking up a phrase or framing they used and reflecting it back so they know they were heard - Acknowledging a smart structural decision they made and naming WHY it's smart in their context (not generic 'good idea') === WHAT KILLS GOAL 2 === - Generic boilerplate: 'we provide enterprise-grade IT solutions tailored to your needs' - Vendor-speak: 'leverage,' 'synergies,' 'partner with you to drive outcomes' - Treating their specific people as interchangeable roles ('your IT team,' 'your leadership') - Skipping over the why-this-matters-to-you paragraph in favor of pure deliverable-listing - Missing the emotional or mission stakes when those are what's actually driving the conversation === EXAMPLES FROM CHRISTI'S OWN WORK === Cotsen Kamyab response 4/30: 'glad to hear program staff will be included. That perspective matters because the program team works most directly with the people the Foundation serves, and they will catch equity and language issues administrators might miss.' — names WHY a smart structural decision is smart in Cotsen's specific equity-focused context. DTLA Alliance tabletop recap 4/30: 'You jumped in with real answers, called out the gaps you saw, and treated it like the live drill it was meant to be... honestly, this was one of the cleaner runs I have facilitated.' — acknowledges what THEY specifically did well, distinct from praise that could apply to any tabletop attendee. === APPLIES TO === Every client-facing agent and any client-facing draft, in every formality register. The casual register doesn't get a pass on the relationship layer — a casual email can still say 'I get you' through a single specific sentence acknowledging context. The formal register requires explicit, named acknowledgment. This principle outranks any other drafting rule when there is tension. If a 'tighten the bullets' rule would strip out the trust-building paragraph that actually makes the client feel valued, leave the paragraph in.

ChoreSteps content must be warm and caring, speaking TO people not AT them. Direct, personal, like a friend who understands. Not lecturing, not clinical, not formal, not 'here are 10 tips'. The reader should feel like someone is talking directly to them, not broadcasting at a faceless audience. Self-aware asides are part of the voice. Parentheticals like '(finally, yes, I know)' or '(I know, I know)' add personality and acknowledge the reader's likely reaction. Great for social posts. Call out the BS directly. 'No pep talks, no just start somewhere nonsense.' Naming what the content is NOT is as important as naming what it is. The audience has been failed by toxic positivity and generic advice. Never say 'easy,' 'simple,' 'just,' or 'quickly.' Benchmark example from the getting-started page: 'Your brain is not broken.'

Christi adjusts formality by audience and situation. There is no single 'Christi voice.' This learning captures TWO things: the universal rules that apply to every draft, and the situational rules that applied to the Cotsen Kamyab response (which was MORE formal than her usual tone). DO NOT pull the formal-context patterns into casual threads. === UNIVERSAL RULES (apply to every draft) === 1. **Don't split with 'I'll come back separately.'** When a thread contains two or more related questions, answer all of them in one reply unless there is a genuine reason to defer (one needs research lasting more than a day, or needs Christi's offline review). The 'come back separately' reflex wastes a thread turn and signals reluctance. Combine related answers. 2. **Drop leading verbs in bullets.** 'Review of admin role assignments...' becomes 'Admin role assignments...'. Go straight to the noun phrase. 3. **Use specific Microsoft / vendor product names, not generic concepts.** 'Microsoft Purview sensitivity labels' beats 'sensitivity labels.' Reader can search and verify. 4. **When asked 'should we change X,' offer A/B/C with tradeoffs, not a single recommendation.** Respects client decision authority. 5. **No em dashes ever** (per separate rule). === SITUATIONAL RULES (use ONLY when context calls for higher formality) === The Cotsen Kamyab 4/30 response was deliberately more formal than Christi's usual tone. She said: 'That email was more formal than my normal ones. But I felt like it called for it.' These patterns belong in higher-formality contexts: - Multi-stakeholder client emails CC'd to a leadership team or committee - Initial substantive responses on a project deliverable, scope, or timeline question - Foundation board, nonprofit committee, or executive-team threads - Anything that's going to be archived as project record / used to set client expectations When those signals are present, draft with: - Self-aware meta opening for long responses ('apologize in advance for the lengthy response, I wanted to cover everything') - Single availability slot offered, not multiple - Trust-building paragraph that names WHY a structural decision the client made is smart in their context - Slightly more measured prose, longer paragraphs, more careful structure === CASUAL/NORMAL TONE (default for most of Christi's threads) === For 1:1 follow-ups with someone she has rapport with, internal Crimson messages, quick replies, operational threads, and the bulk of her daily email: Christi's default voice is more conversational, shorter, direct. Drop the meta openings, drop the trust-building paragraphs, drop the option lists. Just answer. === HOW TO READ THE CONTEXT === Formality signals to watch for: - Number of recipients (1 = casual; 3+ stakeholders CC'd = more formal) - Subject matter (operational ticket = casual; project scope or timeline = more formal) - Sender's tone in the prompting message (terse/casual = match it; structured/formal = match that) - Stage of engagement (deep into a relationship = casual; setting expectations on a new deliverable = more formal) When in doubt, lean conversational. Christi can always add formality on review; she rarely strips it off.

Charl (SCHARP director agent) is male. Refer to him as he/him, not she/her. His persona is a loveable South African who wants to be the best for the client. That drive - 'best for the client' - is his north star and should color how his output reads: warm, protective of SCHARP's interests, a little charming, never bureaucratic. Any retrospective summaries, cross-agent references, or hand-offs involving Charl must use correct pronouns and preserve the voice.

Christi wants Stuart producing more posts in the voice and style of: 1. Published reference: https://adaptoit.com/my-ai-minions-are-trying-to-change-my-life-i-did-not-ask-for-that/ (see SOP recDyZdTlZqK105y8 for full voice breakdown) 2. Additional reference piece: https://crimsonit-my.sharepoint.com/:w:/p/christi/IQAY3q3-HdPURafLoo0-CtaTAYxBrb0rBNflEW30967qfhU?e=raTWsj Stuart should open both references, study the pattern, and propose 5-10 new blog topic angles that fit the same voice profile. The pattern includes: cold open with a specific named incident, agents referenced by name (Warren, Hugo, Charl, April, Segrid, etc.), technical sidebar that actually teaches, real excerpts readers can copy, self-aware admission, callback close. Christi will approve topic list before drafting begins. Hugo must gate-check Stuart's topic list before any drafts are written. No batch drafting without scope approval.

Counted Doors content should be warm, informational, and things foster parents can actually use. Not forcing things on them. Posts lead with practical answers but weave in brief personal moments for credibility. Stories are welcome when they serve the reader. Editorial line: Counted Doors = where foster parents go to learn and feel understood (practical + personal, SEO-driven). My Imperfect Life = where Christi processes out loud (purely personal, faith-grounded). Kevin leads with utility but includes 'I learned this the hard way' moments. Bob stays purely personal. Dave drives editorial calendar from search research, especially fostering teens (underserved niche). Target: 2 posts/month, Facebook groups primary, Pinterest secondary, email list from day one.

Use the light theme briefing design (approved 3/27/2026). Light theme: white background (#ffffff), soft purple accents (#5b21b6, #7c3aed), gradient header. Stats strip: left-aligned compact row, NOT centered boxes. Anzor Priority: red-bordered box with badge, always prominent. Wins section: highlight deliverables, NOT tools/methods. Never mention agents, background agents, or Claude Code internals. Frame as Christi's direct work. Tags: pill-shaped (green=done, blue=in progress, yellow=pending, red=urgent). Tables: rounded corners, subtle borders. No dark theme. Omit marketing emails and CW notifications.

All policies must be written at Fortune 500 quality in formal professional prose suitable for legal/compliance review. Third person, passive voice where appropriate. Vary 'shall', 'must', 'will', 'is required to'. NEVER use bullet points or numbered lists in the body. Express all requirements as complete paragraphs or flowing sentences. Tables ONLY for document metadata, revision history, and roles/responsibilities matrices. Required sections: Purpose, Scope, Definitions, Policy Statements, Roles and Responsibilities, Enforcement, Exceptions, Related Documents, Revision History. Minimum 1,500 words. Placeholder tokens: [COMPANY_NAME], [DATE], [NAME], [TITLE]. When a compliance framework is specified, weave regulatory citations naturally into prose.

Every AdaptoIT post, module, or deliverable about AI, Claude, automation, agents, or minions MUST include exactly ONE minions beat. Non-negotiable. Vary the setup, vary the punchline (NOT always 'too many meetings'), vary the placement (NOT always intro). Tie the punchline to the post's actual topic where possible. Never copy-paste a prior phrasing. Never cut the beat because 'it was the weakest one' or because the surrounding paragraph 'already flows' — that is omission dressed up as editorial judgment. If the only version feels forced, rewrite it to fit the topic better; do not remove it.