feat(skills): refine string-reviewer guidelines and description

.gemini/skills/string-reviewer/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: string-reviewer
+description: >
+  Use this skill when asked to review text and user-facing strings within the codebase. It ensures that these strings follow rules on clarity,
+  usefulness, brevity and style.
+---
+
+# String Reviewer
+
+## Instructions
+
+Act as a Senior UX Writer. Look for user-facing strings that are too long,
+unclear, or inconsistent. This includes inline text, error messages, and other
+user-facing text.
+
+Do NOT automatically change strings without user approval. You must only suggest
+changes and do not attempt to rewrite them directly unless the user explicitly
+asks you to do so.
+
+### Determine if the text adheres to good UX writing principles
+
+Use these basic principles of good UX writing as a guide for your suggestions. 
+
+- **Clarity:** Text is easy to understand. Text is easy to follow. No errors or
+  typos.
+- **Usefulness:** Users get the info they need, when they need it. Use plain,
+  familiar language. Concepts are explained; value props are user-focused.
+- **Brevity:** Language is precise. Short, simple sentences; active voice. Text
+  is broken up; scannable.
+- **Style:** Friendly, helpful, positive, and humble tone. Sentence-style
+  capitalization. Solitary sentences aren't punctuated. Speaks to the user
+  ("you").
+
+### Enforce general style guidelines
+
+1. Do not use a period for single sentences under 10 words. Use periods only for
+   multi-sentence blocks or exceptionally complex instructions.
+2. Use contractions. However, don't make a sentence harder to understand just to
+   follow this rule. For example, "do not" can give more emphasis than "don't"
+   when needed. 
+3. Use abbreviations with care. It’s okay to abbreviate commonly understood
+   terms, such as "VM", but be consistent. Try to avoid mixing and matching
+   abbreviations and non-abbreviations in the same flow.
+4. Use ampersands instead of “and” sparingly. Don't use "+" instead of "&".
+5. Only capitalize the first word in titles and headings.
+6. Use a serial/Oxford comma to separate items in a list.
+7. When reviewing strings with variables or placeholders, ensure the surrounding
+   text remains grammatically correct regardless of the variable's value.
+
+### Ensure consistent style for settings
+
+If `packages/cli/src/config/settingsSchema.ts` is modified, confirm labels and 
+descriptions follow the [Settings guidelines](./references/settings.md).
+
+### Ensure that error messages are actionable by the end user
+
+If a file contains an error message, ensure that it provides actionable
+information to the end user. Review the reference at [error message guidelines](./references/error-messages.md) 
+for more details.
+
+### Ensure consistent use of keyboard shortcuts
+
+Render shortcuts as `Modifier+Key` (for example, `Ctrl+S`). Modifiers should be 
+capitalized; keys should be uppercase. No extra spaces.
+
+- Use `Esc` instead of "Escape".
+- Use Unicode symbols (`⇧`, `⏎`) only if there are tight space constraints.
+
+- **"Escape"** should be written as `Esc` for brevity.
+- If there are space constraints, it is acceptable to use Unicode symbols for
+  modifiers, for example `⇧+K` for `Shift+K`, or `⏎` for `Enter`. 
+
+### Use consistent terminology
+
+Ensure all terminology aligns with the project [word list](./references/word-list.md). 
+
+If a string uses a term marked "do not use" or "use with caution," provide a
+correction based on the preferred terms.
+
+### Output format
+When suggesting changes, always present your review using the following list
+format. Do not provide suggestions outside of this list..
+
+```
+1. **{Rationale/Principle Violated}**
+  - ❌ "{incorrect phrase}"
+  - ✅ `"{corrected phrase}"`
+```

.gemini/skills/string-reviewer/references/error-messages.md

@@ -0,0 +1,44 @@
+# Writing helpful error messages
+
+Bad error messages frustrate users. Good error messages provide critical
+information when things are not working as expected. Error messages are often
+the main way developers interact with users when problems occur.
+
+Some error messages are caused by invalid user inputs or misuse of certain
+features and some are caused by product defects; all error messages require
+users to figure out what to do next.
+
+Great error messages answer two questions as clearly and concisely as possible:
+
+1. What went wrong?
+2. How can I fix it?
+
+## Principles
+
+- Write concise error messages. Emphasize what's important. Cut unnecessary
+  text.
+- Avoid double negatives. Readers find double negatives hard to parse.
+- Converting from passive voice to active voice often makes sentences conciser
+  and easier to understand.
+- Use terminology consistently for all error messages within a single feature.
+
+## Be positive
+
+- Instead of telling the user what they did wrong, tell the user how to get it
+  right.
+- While maintaining positivity, avoid the words "sorry" or "please." Focus
+  instead on clearly describing the problem and solution.
+
+## Avoid humor
+
+Don't attempt to make error messages humorous. Humor in error messages can fail
+for the following reasons:
+
+- Errors frustrate users. Angry users are generally not receptive to humor.
+- Users can misinterpret humor. (Jokes don't always cross borders well.)
+- Humor can detract from the goal of the error message.
+
+## Don't blame the user
+
+If possible, focus the error message on what went wrong rather than assigning
+blame.

.gemini/skills/string-reviewer/references/settings.md

@@ -0,0 +1,28 @@
+# Settings
+
+## Noun-First Labeling (Scannability)
+
+Labels must start with the subject of the setting, not the action. This allows
+users to scan for the feature they want to change.
+
+- **Rule:** `[Noun]` `[Attribute/Action]`
+- **Example:** `Show line numbers` becomes simply `Line numbers`
+
+## Positive Boolean Logic (Cognitive Ease)
+
+Eliminate "double negatives." Booleans should represent the presence of a
+feature, not its absence.
+
+- **Rule:** Replace `Disable {feature}` or `Hide {Feature}` with
+  `{Feature} enabled` or simply `{Feature}`.
+- **Example:** Change "Disable auto update" to "Auto update".
+- **Implementation:** Invert the boolean value in your config loader so true
+  always equals `On`
+
+## Verb Stripping (Brevity)
+
+Remove redundant leading verbs like "Enable," "Use," "Display," or "Show" unless
+they are part of a specific technical term.
+
+- **Rule**: If the label works without the verb, remove it
+- **Example**: Change `Enable prompt completion` to `Prompt completion`

.gemini/skills/string-reviewer/references/word-list.md

@@ -0,0 +1,61 @@
+## Terms
+
+### Preferred
+
+- Use **create** when a user is creating or setting up something.
+- Use **allow** instead of **may** to indicate that permission has been granted
+  to perform some action.
+- Use **canceled**, not **cancelled**.
+- Use **configure** to refer to the process of changing the attributes of a
+  feature, even if that includes turning on or off the feature.
+- Use **delete** when the action being performed is destructive.
+- Use **enable** for binary operations that turn a feature or API on. Use "turn
+  on" and "turn off" instead of "enable" and "disable" for other situations.
+- Use **key combination** to refer to pressing multiple keys simultaneously.
+- Use **key sequence** to refer to pressing multiple keys separately in order.
+- Use **modify** to refer to something that has changed vs obtaining the latest
+  version of something.
+- Use **remove** when the action being performed takes an item out of a larger
+  whole, but doesn't destroy the item itself.
+- Use **set up** as a verb. Use **setup** as a noun or adjective.
+- Use **show**. In general, use paired with **hide**.
+- Use **sign in**, **sign out** as a verb. Use **sign-in** or **sign-out** as a
+  noun or adjective.
+- Use **update** when you mean to obtain the latest version of something.
+- Use **want** instead of **like** or **would like**.
+
+#### Don't use
+
+- Don't use **etc.** It's redundant. To convey that a series is incomplete,
+  introduce it with "such as" instead.
+- Don't use **hostname**, use "host name" instead.
+- Don't use **in order to**. It's too formal. "Before you can" is usually better
+  in UI text.
+- Don't use **one or more**. Specify the quantity where possible. Use "at least
+  one" when the quantity is 1+ but you can't be sure of the number. Likewise,
+  use "at least one" when the user must choose a quantity of 1+.
+- Don't use the terms **log in**, **log on**, **login**, **logout** or **log
+  out**.
+- Don't use **like** or **would you like**. Use **want** instead. Better yet,
+  rephrase so that it's not referring to the user's emotional state, but rather
+  what is required.
+
+#### Use with caution
+
+- Avoid using **leverage**, especially as a verb. "Leverage" is considered a
+  buzzword largely devoid of meaning apart from the simpler "use".
+- Avoid using **once** as a synonym for "after". Typically, when "once" is used
+  in this way, it is followed by a verb in the perfect tense.
+- Don't use **e.g.** Use "example", "such as", "like", or "for example". The
+  phrase is always followed by a comma.
+- Don't use **i.e.** unless absolutely essential to make text fit. Use "that is"
+  instead.
+- Use **disable** for binary operations that turn a feature or API off. Use
+  "turn on" and "turn off" instead of "enable" and "disable" for other
+  situations. For UI elements that are not available, use "dimmed" instead of
+  "disabled".
+- Use **please** only when you're asking the user to do something inconvenient,
+  not just following the instructions in a typical flow.
+- Use **really** sparingly in such constructions as "Do you really want to..."
+  Because of the weight it puts on the decision, it should be used to confirm
+  actions that the user is extremely unlikely to make.