SKILL.md

skills/preferences-setup/SKILL.md

1. ---
2. name: preferences-setup
3. description: >-
4. Guide a Meridian Display Co. employee through setting up or refreshing their Personal Preferences
5. block (the per-user custom-instructions field in their Claude Teams Settings) via a short
6. structured interview, then generate a complete, paste-ready block tuned for work use. Use this
7. skill whenever someone on the Meridian Claude Teams account asks to set up their preferences, fill
8. in a blank custom-instructions field, refresh an outdated one, configure how Claude works with
9. them at work, or asks things like "help me set up my preferences," "what should I put in my custom
10. instructions," "my preferences are blank," or "tune how Claude talks to me." Use it even if the
11. person doesn't know the field is called "preferences": if they want Claude to behave a certain way
12. across all of their Meridian chats, this is the skill. This skill is scoped to work use; it
13. intentionally keeps personal-life context out of the generated block.
14. ---
16. # Preferences Setup (Meridian Teams)
18. Help a Meridian employee build their Personal Preferences block, the per-user custom-instructions field in their Claude Teams Settings. The deliverable is a complete block, written in their voice, that they paste into Settings.
20. This skill runs a short interview, drafts the block, and hands it back ready to use. It works for a blank field (first-time setup) and for refreshing an old one.
22. ## Scope: this is a work block, not a personal block
24. The block this skill produces lives in a Meridian-owned Claude Teams account. It applies to the employee's work chats. Two things follow:
26. - **It should be useful for work, not a personal profile.** "About Me" is the employee's role and work context, not their life story. Personal interests, beliefs, health, family situations, and identity statements that don't change how Claude should help them at Meridian do not belong here. If the person wants a personal preferences block for their own Claude account at home, that is a different exercise.
27. - **It should not contain confidential operational data.** No client names, no internal financial figures, no credentials or API keys, no NDAs verbatim, nothing an employee shouldn't be casually pasting into a settings field that other systems may surface. If the person starts to include this kind of content, redirect them: that information goes in the chat where it's needed, not the preferences block.
29. Tell the person this up front in plain language before starting the interview. Set the expectation that the block stays work-scoped.
31. ## How preferences work: explain this up front
33. Briefly tell the person what they're configuring so the interview makes sense:
35. - The preferences block lives in **Settings → Profile → Personal Preferences** inside the Meridian Claude Teams account. It's text that Claude reads at the start of every chat they start under that account.
36. - It changes how Claude behaves for them specifically: tone, format, what context Claude has, what rules Claude follows. Other Meridian employees have their own separate blocks.
37. - It only takes effect in chats started **after** it's saved. It does not change the current chat.
38. - They can edit it anytime; nothing here is permanent.
39. - Meridian may also configure org-level or project-level instructions that apply to everyone on top of their personal block. The personal block is just the per-employee layer.
41. Keep this to a few sentences. Then start the interview.
43. ## Two rules are non-negotiable
45. Every block this skill generates includes two fixed rules, exactly as written in `references/fixed-rules.md`. Read that file and include both rules verbatim in the "Behavior Rules" section of every block. Do not interview about them, do not water them down, do not make them optional. They are the floor.
47. They exist because the two most common ways a custom-instructions block quietly makes Claude *less* useful are Claude drifting into flattery and agreement, and Claude letting inaccurate claims slide. The fixed rules close both. Everything else in the block is the person's to decide; these two are not.
49. If the person objects to either fixed rule, explain what it does and why it's the floor (a Claude that flatters them or lets factually wrong claims slide is a Claude they can't trust on a client deliverable or a production decision), but keep them in. They can tune the *wording* of the surrounding block; they cannot remove these two.
51. ## The interview
53. Run a focused interview, not a survey. Ask in small batches, propose sensible defaults so the person can react instead of starting from nothing, and don't ask about anything you can already infer from the conversation. Aim for three or four exchanges total, not twenty questions.
55. Cover these five areas. Adapt depth to the person: someone who gives short answers gets a lean block; someone who elaborates gets a richer one.
57. 1. **The assistant's personality.** How should Claude come across in their work chats? Warm or neutral, brief or thorough, formal or casual, dry-humored or strictly businesslike? Offer a couple of contrasting defaults. (The two fixed rules already guarantee honesty and accuracy; this is about the texture around that.)
59. 2. **Their role at Meridian.** What they do at the company, what they're accountable for, who they work with, and what kind of work Claude will see them on most often (design, sales, production, ops, admin, etc.). This is the *work* context, so only include what would actually change how Claude responds on their work tasks. If they have a relevant background that informs the role (years of design experience, prior trade-show industry work, bilingual capability used at work), that fits here. Personal life, beliefs, health, and family are out of scope; redirect gently if they offer it.
61. 3. **How they want Claude to work with them.** Output format and length, communication style, whether they want step-by-step guidance or just answers, formatting likes and dislikes (emojis, bullet points, headers), language. Concrete preferences that shape the *shape* of responses.
63. 4. **Always-on behavior rules.** Beyond the two fixed rules, anything Claude should always or never do for them at work: specific habits, scope limits, things they've found themselves correcting in other chats. This can be short or empty; don't manufacture rules.
65. 5. **Their tools and environment.** The Meridian systems they use (CRM, design software, internal sheets and trackers, Plinth if they work with orders) plus any general tools that shape their work (Adobe CC, Google Workspace, etc.). This helps Claude assume the right baseline. It's optional; skip it if it doesn't apply to how they use Claude.
67. If something is unclear, ask. If an answer is thin, that's fine: a short honest block beats a padded one.
69. ### Redirect off-scope content
71. If the person starts to include personal-life details that don't connect to their work (political views, mental health, family situations, identity statements, hobbies unrelated to their role), gently redirect. Something like: "That sounds important, but this block is the one Meridian sees through the Teams account. For personal context, you'd want a separate preferences block in your own Claude account at home." Don't lecture about it. Just keep the work block scoped to work.
73. Same for confidential operational data: if they try to put client names, financial figures, or credentials in the block, redirect that content into the chat where it's needed instead.
75. ## Drafting the block
77. Assemble the answers into the structure in `references/block-template.md`. Read that file for the exact section layout and a worked example. The block always has these sections, in this order:
79. 1. `## My AI Assistant`: the personality from area 1.
80. 2. `## My Role at Meridian`: work context from area 2.
81. 3. `## My Preferred Tools`: from area 5. Omit the section entirely if they had nothing for it.
82. 4. `## How to Work With Me`: format and style preferences from area 3.
83. 5. `## Behavior Rules`: the two fixed rules first, verbatim, then any rules from area 4.
85. Write it in the person's voice: first person, plain, matching how they actually talk. It is their block, so it should sound like them and not like a corporate profile. Don't inflate it. A block can be short.
87. ## Flag your judgment calls
89. When you draft the block, you will make small decisions the person didn't explicitly direct: phrasing, what to include, what to leave out. Surface those. After presenting the draft, briefly list what you decided on your own so they can veto or adjust. Don't bury choices; a preferences block only works if the person actually endorses it.
91. ## Deliver it
93. Present the finished block as one clean, copy-pasteable text block. Then tell the person:
95. - Paste it into **Settings → Profile → Personal Preferences** in the Meridian Claude Teams account and save.
96. - It applies to new chats, not the current one.
97. - To check it took, start a fresh chat and try a couple of the quick checks below.
99. ## Optional: verify it works
101. If the person wants to confirm the block landed, suggest they open a new chat (after saving) and try these:
103. - Ask Claude's opinion on a half-formed work idea of theirs, such as a pitch, a layout choice, or a process change. A working block produces honest, direct feedback that names any weakness, not automatic praise. This checks the anti-sycophancy rule.
104. - State something slightly inaccurate in passing (a wrong fact about a material, a process, a competitor) and see if Claude corrects it rather than going along. This checks the anti-misinformation rule.
105. - Give a normal request and check the tone, length, and formatting against what they asked for.
107. This is a light sanity check, not a formal audit. If something is off, the block can be adjusted and re-pasted.
109. ## Reference files
111. - `references/fixed-rules.md`: the two non-negotiable rules, to include verbatim in every block. Read before drafting.
112. - `references/block-template.md`: the section structure and a worked example. Read before drafting.