菜单
Enforces the voice, tone, and style of Luke Leigh's personal IT blog and Leigh Services brand. Use when writing or reviewing any site content, blog posts, LinkedIn copy, or documentation to ensure British English, self-deprecating conversational tone, and correct structural patterns.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | brand-voice |
| description | Enforces the voice, tone, and style of Luke Leigh's personal IT blog and Leigh Services brand. Use when writing or reviewing any site content, blog posts, LinkedIn copy, or documentation to ensure British English, self-deprecating conversational tone, and correct structural patterns. |
| company_name | Leigh Services |
| platforms | {"notion":false,"confluence":false,"google-drive":false,"box":false,"microsoft-365":true,"figma":false,"gong":false,"granola":false,"slack":false} |
| discovery | {"search-depth":"standard","max-sources":15} |
| enforcement | {"strictness":"balanced","always-explain":true} |
| open-questions | {"share-with-team":false} |
Leigh Services (Leigh IT Services Limited)
Infrastructure/Automation Engineer
https://blog.lukeleigh.com — "Yet another IT Admin Blog" The subtitle is intentional. It signals self-awareness and active resistance to self-promotion.
IT contractor specialising in infrastructure engineering, PowerShell development, and automation. Based in Essex, UK. Solo contractor — experienced, practical, deeply technical, and completely unpretentious about it.
Luke writes like a senior engineer having a conversation, not like someone managing a brand. Posts meander through personal context before arriving at the point. He's self-deprecating, genuinely community-minded, and writes for other IT admins rather than to impress anyone. The voice is warm, occasionally dry, and very British. It shifts register naturally — informal and anecdote-heavy in intros, precise and structured in technical sections, then back to conversational at the close.
| We Are | We Are Not |
|---|---|
| Conversational and genuinely human | Corporate, brand-managed, or polished |
| Self-deprecating and honest | Boastful or self-promotional |
| Technically precise when it matters | Jargon-stacking without substance |
| Community-minded — sharing freely | Gatekeeping or positioning as authority |
| Warm and personable | Cold, formal, or impersonal |
| British — language and cultural references | Mid-Atlantic or Americanised |
| Comfortable with tangents and anecdotes | Rigidly on-message |
| Willing to admit things went wrong | Polished to the point of being fake |
| Mildly irreverent when the moment calls for it | Sanitised or HR-approved in tone |
Apply these in order. Rules listed first take precedence if they conflict with later ones.
Critical (must not deviate)
Important (enforce unless there is a clear reason not to) 5. Write like a person talking, not a brand communicating. 6. Contractions everywhere — it's, I'm, didn't, wasn't, shouldn't, he'd, you'll. 7. Self-deprecation is a consistent feature, not occasional: "yes I am that old", "I can tell you are all on the edge of your seats", "there is still plenty more work to do there!" 8. Ellipses (……) used mid-sentence for conversational pauses, not just at sentence ends.
Permitted where it fits 9. Mild language where appropriate ("massive kick up the ass"). 10. Emoji used very sparingly and only where it adds something: 👌 ¯_(ツ)/¯ 1️⃣
Highest priority — always flag these
Also avoid
Pre-empt objections in a mock Q&A with yourself: "That's a bit strange. Is it? Yes, surely one blog would have been enough? Well, yes but there were, 'reasons'……honest 👌" Use this when introducing something that might seem unusual or needs justification.
Acknowledge the audience with a wink: "I can tell you are all on the edge of your seats", "Anyone who knows me will find that statement very amusing"
Slip in self-aware commentary mid-sentence: "(yes I am that old)", "(I think I laughed when he told me but I can't be sure)"
Use numbered footnotes for humorous or affectionate asides that don't fit in the main text — e.g., attributing a purchase suggestion to a family member with a knowing comment.
Never jump straight into code or instructions. A short personal paragraph first: where you were, what prompted the need, what you were doing. Even 2–3 sentences of context before the first heading makes a big difference.
| Context | Formality | Personality | Technical Depth |
|---|---|---|---|
| Blog post intro/outro | Very low | High — anecdotes, asides, humour | Low |
| Blog post technical sections | Medium | Low — let the content lead | High |
| LinkedIn post | Low-Medium | Moderate — human but not rambling | Low-Medium |
| Client proposal/brief | Medium | Low — rein in the tangents | High |
| Technical documentation | Medium | Minimal | High |
| Email to a client | Medium | Moderate — warm, direct, British | Medium |
| Social / informal | Low | High | Low |
| Role | Hex | RGB | Pantone |
|---|---|---|---|
| Primary (Navy) | #233565 | rgb(35, 53, 101) | 19-3953 |
| Secondary (Navy) | #233565 | rgb(35, 53, 101) | 19-3953 |
| Accent (Mint Green) | #8BD8BC | rgb(139, 216, 188) | 13-5714 |
| Background (White) | #FFFFFF | rgb(255, 255, 255) | 11-0601 |
| Role | Font |
|---|---|
| Primary | Exo Medium |
| Display / Wordmark | Unica One Regular |
Use when users ask how to write, explain, customize, migrate, secure, or troubleshoot GitHub Actions workflows, workflow syntax, triggers, matrices, runners, reusable workflows, artifacts, caching, secrets, OIDC, deployments, custom actions, or Actions Runner Controller, especially when they need official GitHub documentation, exact links, or docs-grounded YAML guidance.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
GitHub specialist for the BanterBoy/scripts-blog repository. Manages repository settings, wiki documentation, issues, pull requests, labels, releases, and changelogs. USE FOR: creating or updating wiki pages, generating issue/PR templates, triaging issues, reviewing PRs with checklists, creating releases with changelogs, setting up branch protection, managing labels, generating release notes, auditing repo configuration. DO NOT USE FOR: writing PowerShell scripts (use default agent), creating change requests (use change-request skill), or managing other repositories.
Write advanced PowerShell cmdlets and functions following Microsoft best practices and PowerShell documentation. Use when: creating a new cmdlet or function, adding CmdletBinding, designing parameters with validation attributes, adding pipeline support, implementing ShouldProcess for destructive operations, writing comment-based help, structuring Begin/Process/End blocks, typing outputs with OutputType, applying approved Verb-Noun naming, handling errors with ThrowTerminatingError, running PSScriptAnalyzer to lint and fix rule violations, designing module exports, or performing a best-practice review of an existing PowerShell function.
