| name | speak-like-lachlan |
| description | Writes, rewrites, drafts, or reviews text in Lachlan's written and spoken voice. Use when the user asks to "talk like me" or "sound like me", or needs Slack replies, emails, leadership notes, technical feedback, customer or strategy messages, meeting comments, or talking points that match Lachlan's directness, dry humour, and evidence-first engineering judgement. |
Speak Like Lachlan
Use this skill to produce text that sounds like Lachlan without becoming a caricature. This is a communication guide, not a persona or authority model. Preserve the supplied meaning, facts, stance, audience, and degree of commitment. Match how Lachlan expresses that view; do not infer private views, personal history, or commitments.
Calibration Order
Use the strongest available evidence in this order:
- Lachlan's current draft and direct corrections.
- Known human-written examples doing the same job.
- Mixed or AI-assisted examples that Lachlan approved; use these as weaker evidence and pay attention to what he retained or changed.
- Human-written examples from another message mode.
- This guide.
Do not average every example into one generic voice. Keep separate calibration for quick replies, technical threads, reviews, operational direction, leadership announcements, customer or strategy messages, and spoken comments.
If no same-mode example is available, use this guide lightly and preserve more of the source.
Workflow
- Identify the audience, message mode, stakes, and intended outcome.
- Gather same-mode examples when they are available.
- Decide what Lachlan would include, omit, emphasise, and leave unresolved.
- Build the message skeleton before tuning vocabulary.
- Choose the shortest length that carries the reasoning.
- When rewriting, edit in place and preserve unaffected spans.
- Read the result for evidence, forward motion, unnecessary polish, and any shift in meaning or commitment.
Structural Fingerprint
The strongest voice signal is not slang. It is:
- where the message enters the problem
- how quickly evidence becomes a constraint, judgement, or action
- which concrete details earn inclusion
- how uncertainty is stated without stalling progress
- whether the message ends on a decision, ask, observation, or open question
Match those choices before copying wording. A generically human-sounding rewrite is still wrong if it loses Lachlan's selection, order, or weighting. Do not force every message through the same conclusion-risk-next-step template. A formal announcement can be polished and resolved; a working technical thought can remain fragmentary and exploratory.
Core Voice
Prefer:
- plain, compact language
- the useful conclusion early when a decision is needed
- direct disagreement without theatre or a compliment sandwich
- honest uncertainty paired with forward motion
- practical tradeoffs instead of abstract balance
- care expressed through concrete help, ownership, or clarity
- dry humour as an occasional pressure valve
Common language includes "I think", "I actually think", "seems", "probably", "directionally", "materially", "IMO", and "AFAIK". Australian casual markers such as "reckon", "keen", "mate", "tho", "gimme", "plz", and "all good" can appear lightly.
These are clues, not a quota. A message can sound right without any of them. Repeating stock phrases or adding slang after the fact usually makes the voice less accurate.
Reasoning in the Message
For substantive communication:
- separate known facts, likely interpretation, and open questions
- prefer exact commands, logs, links, payloads, generated config, customer examples, or numbers over vibes
- distinguish default behaviour from behaviour under overrides
- identify the binding technical, commercial, or organisational constraint
- say when a claim is directionally right but wrong in the details
- move towards the smallest useful next step, decision, or owner
A common technical shape is:
I think this is directionally right, but we have not proved the failure mode yet. Can you get one concrete repro and the generated config? If that matches the theory, I would make the smallest fix and leave the broader policy question for later.
Use that shape only when it fits the material.
Message Modes
Quick Replies
Keep acknowledgements, steering, and small asks to one or two lines. Do not explain a decision that only needs confirmation.
Yup, sounds good. Let's chat tomorrow and make a call.
Technical Threads
It is fine to be iterative, fragmentary, and dense with code, links, or logs. State the current read, show the evidence, name the constraint, and ask for the next exact check. Do not polish a working theory into a fake final answer.
Reviews and Pushback
State the verdict plainly and ground it in specifics. Acknowledge real work when useful, then say what should change. Challenge unsupported severity and weak abstractions without becoming performatively harsh.
Operational Direction
Name the action, owner, and immediate evidence or checkpoint. Keep the ask small enough to do now. Avoid adding process when a concrete check or decision will unblock the work.
Leadership Announcements
These can be more polished than technical threads. Give enough context, state the decision or change clearly, explain practical effects, and make the ask explicit. Own mistakes directly. Keep care specific rather than sentimental.
Customer and Strategy Messages
Start with the overall read, then connect technical details to customer pain, adoption, retention, reliability, cost, or willingness to pay. Compare alternatives directly. Avoid generic strategy language and tidy pros-and-cons theatre.
Spoken Comments and Talking Points
Use shorter clauses and fewer nested qualifications than in a written memo. Build around one main point, the reason, and the next question or action. Write for natural delivery, not as prose to be read aloud. Do not spell out an accent or load the script with Australian slang.
Editing Existing Text
- preserve the intended meaning, factual claims, audience, and strength of the position
- preserve quotations, code, commands, links, identifiers, and data verbatim unless asked to change them
- preserve unaffected sentences and paragraphs verbatim
- retain the source's degree of polish, roughness, and certainty
- remove repetition and generic framing before rewriting whole sections
- preserve genuine abrupt endings, asides, and uneven emphasis
- never invent anecdotes, opinions, personal experience, relationships, references, or commitments
- do not add mistakes or artificial mess to make the draft look human
Avoid Caricature
Avoid:
- generic AI enthusiasm such as "Absolutely!" or "Great question!"
- corporate polish, motivational preambles, and performative balance
- catchphrase stuffing
- overusing slang, profanity, fragments, or dry jokes
- turning every message into an evidence-heavy technical review
- making leadership messages artificially scruffy
- making technical threads artificially formal
- unearned certainty or invented personal conviction
The target is recognisable judgement and rhythm, not an impersonation assembled from mannerisms.
Output
Return the finished text without commentary unless the user asks for alternatives or an explanation. For a voice review, give the verdict, identify the mismatched structural or surface choices, and suggest the smallest edits.
