Fix symlink paths after home directory rename, remove pinch-managed
skill symlinks (claude-md-improver, learning-opportunities), add
writing skills (technical-writing, error-messages, accessibility),
and fix allowed-tools delimiter in jj-commit skill.

Assisted-by: Claude Opus 4.6 via pi

diff --git a/ai/claude/skills/jj-commit/SKILL.md b/ai/claude/skills/jj-commit/SKILL.md
index cb010d02..c4a4f02f 100644
--- a/ai/claude/skills/jj-commit/SKILL.md
+++ b/ai/claude/skills/jj-commit/SKILL.md
@@ -2,7 +2,7 @@
 name: commit
 description: Use when the user asks to "commit changes", "commit my work", "/commit", "create a commit", or "jj commit"
 argument-hint: <fileset>
-allowed-tools: Bash(jj diff:*) Bash(jj show:*) Bash(jj log:*)
+allowed-tools: Bash(jj diff:*), Bash(jj show:*), Bash(jj log:*)
 ---
 
 # Commit Changes
diff --git a/ai/claude/skills/technical-writing/SKILL.md b/ai/claude/skills/technical-writing/SKILL.md
new file mode 100644
index 00000000..eba17ded
--- /dev/null
+++ b/ai/claude/skills/technical-writing/SKILL.md
@@ -0,0 +1,235 @@
+---
+name: technical-writing
+description: Use when writing or reviewing technical documentation, API docs, tutorials, READMEs, or developer guides. Covers terminology, audience analysis, document structure, lists, paragraphs, illustrations, and sample code. Complements elements-of-style (prose clarity) and diataxis (document classification).
+---
+
+# Technical Writing
+
+Actionable reference for technical documentation, distilled from
+Google's Technical Writing courses.
+
+For sentence-level prose rules, use elements-of-style. For classifying
+documentation types, use diataxis. This skill covers the technical
+writing concerns those skills do not.
+
+## Terminology
+
+**Define new terms.** Link to existing definitions when available.
+Collect multiple definitions into a glossary.
+
+**Use terms consistently.** When readers encounter two words that seem
+synonymous, they wonder whether the author signals a subtle distinction.
+Pick one term and stick with it. If you introduce an abbreviation
+(Protocol Buffers as "protobufs"), use only the short form after the
+first occurrence.
+
+**Handle acronyms deliberately.** On first use, spell out the full term
+with the acronym in parentheses, both bolded: **Telekinetic Tactile
+Network (TTN)**. Do not define acronyms that appear only a few times or
+that save little space.
+
+**Resolve ambiguous pronouns.** Pronouns like *it*, *they*, *this*, and
+*that* confuse readers when the referent is unclear. Place a pronoun
+within five words of its noun. If a second noun intervenes, repeat the
+original noun instead.
+
+## Audience
+
+**Define your audience before writing.** Identify their roles, existing
+knowledge, and proximity to the subject. The equation:
+
+> good documentation = (knowledge the audience needs) minus (knowledge
+> the audience already has)
+
+**List what the audience must learn or do.** Order prerequisites before
+dependent material.
+
+**Beware the curse of knowledge.** Expert understanding of a topic ruins
+explanations to newcomers. Experts reference subtle interactions they
+have internalized; newcomers have no frame for these references. After
+drafting, reread from the audience's perspective and unpack assumptions.
+
+**Use simple words.** Prefer straightforward vocabulary. Simple language
+aids native speakers, non-native speakers, and translation tools alike.
+
+**Avoid idioms and cultural references.** "Piece of cake," "ballpark
+figure," and "sticky wicket" exclude international readers. Replace
+with plain language.
+
+## Sentences
+
+**Choose strong, specific verbs.** Replace vague verbs (forms of *be*,
+*occur*, *happen*) with verbs that say what actually happens.
+
+| Weak | Strong |
+|---|---|
+| The exception occurs when... | Dividing by zero raises the exception |
+| This error message happens when... | The system generates this error when... |
+
+**Reduce "there is" and "there are."** These pair a generic noun with a
+generic verb. Find the true subject and verb.
+
+| Before | After |
+|---|---|
+| There is a variable that stores... | The variable stores... |
+| There are two facts you should know | You should know two facts |
+
+**Replace vague adjectives with data.** Subjective descriptors
+("blazingly fast") sound like marketing. Use numbers: "225-250%
+faster."
+
+**Distinguish *that* from *which* (US English).** *That* introduces
+essential clauses (no comma). *Which* introduces nonessential clauses
+(with comma). Test: if you hear a pause, use *which*.
+
+## Short Sentences
+
+**One idea per sentence.** Each sentence should convey a single thought,
+the way a program statement executes a single task.
+
+**Convert embedded lists to actual lists.** When a sentence contains
+"or" between multiple items or embeds a series of tasks, break it into
+a bulleted or numbered list.
+
+**Cut filler.** Common replacements:
+
+| Wordy | Concise |
+|---|---|
+| at this point in time | now |
+| determine the location of | find |
+| is able to | can |
+| causes the triggering of | triggers |
+
+**Reduce subordinate clauses that branch into separate ideas.** If a
+clause introduced by *which*, *because*, *since*, or *unless* carries
+its own distinct point, promote it to a separate sentence.
+
+## Lists and Tables
+
+**Bulleted lists** for unordered items. **Numbered lists** for sequences
+where order matters. Avoid embedding lists inside sentences.
+
+**Maintain parallel structure.** The first item establishes a pattern
+all items must follow in grammar, capitalization, and punctuation.
+
+**Start numbered list items with imperative verbs.** "Open the file,"
+"Click Submit," "Verify the output."
+
+**Introduce every list and table** with a sentence explaining what it
+represents. End the introduction with a colon. Use "following" when
+natural.
+
+**Table cells** should be concise (two sentences maximum). Keep data
+within a column parallel.
+
+## Paragraphs
+
+**Write a strong opening sentence.** Busy readers sometimes read only
+the first sentence of each paragraph. Make it carry the paragraph's
+central point.
+
+**One topic per paragraph.** Delete or move sentences unrelated to the
+current topic.
+
+**Three to five sentences per paragraph.** Walls of text intimidate
+readers. Long paragraphs (seven or more sentences) should be split.
+Excessive one-sentence paragraphs should be combined or converted to
+lists.
+
+**Address what, why, and how.** State what the thing is, why it matters
+to the reader, and how the reader can use or verify it.
+
+## Document Structure
+
+**State the scope.** Declare what the document covers. Define its
+non-scope: topics readers might expect but will not find. Non-scope
+entries should be genuinely related to the subject.
+
+**Specify the audience and prerequisites.** Help readers determine
+whether the document is meant for them.
+
+**Write a strong opening.** The first page determines whether readers
+continue. Summarize key points early.
+
+**Relate new concepts to familiar ones.** Compare and contrast with
+technologies or ideas the audience already knows.
+
+**Organize around audience needs.** Identify who reads the document,
+what they know beforehand, and what they should know afterward.
+
+## Organizing Large Documents
+
+**Outline before writing.** Explain *why* before asking readers to
+perform tasks. Limit each step to one concept. Share outlines with
+contributors.
+
+**Write introductions that orient.** State what the document covers,
+required prior knowledge, and what it excludes.
+
+**Provide navigation.** Include a table of contents, logical heading
+hierarchy, links to related resources, and "what to learn next"
+guidance.
+
+**Use task-based headings.** Describe what the reader does ("Configure
+the database") rather than abstract labels ("Configuration"). Avoid
+unfamiliar terminology in headings.
+
+**Disclose progressively.** Introduce terms near where they are used.
+Break large text blocks with tables, diagrams, and lists. Start with
+simple examples and advance to complex ones.
+
+## Illustrations
+
+**Write the caption before the illustration.** Effective captions are
+brief, clarify the takeaway, and direct attention in detailed visuals.
+
+**Limit information density.** Do not put more than one paragraph's
+worth of information in a single diagram. Break complex systems into a
+big-picture overview plus separate detail diagrams.
+
+**Focus the reader's eye.** Use callouts, arrows, or highlighted shapes
+to direct attention to the element that matters.
+
+**Revise iteratively.** Ask: can I simplify this? Should it split into
+multiple illustrations? Is text readable against the background?
+
+## Sample Code
+
+**Correct, concise, understandable, reusable, sequenced.** Good sample
+code your readers can run, understand quickly, and adapt.
+
+**Make sample code production-ready.** It should build without errors,
+perform its task, and follow language conventions including security
+considerations.
+
+**Explain how to run it.** Document prerequisites: library
+installations, environment variables, IDE configuration. Describe
+expected output.
+
+**Use descriptive names.** For learners, `MyLevel =
+go.so.Level(rank=5, dimension=28)` beats unnamed positional parameters.
+
+**Comment the non-obvious.** Keep comments brief. For experienced
+readers, explain *why*, not *what*. Place short descriptions in code
+comments; put longer explanations before the code block.
+
+**Sequence by complexity.** Start with a minimal "hello world" example,
+then progress through increasing complexity. Do not jump to advanced
+usage first.
+
+**Show both correct and incorrect forms** when language conventions
+matter, so readers recognize the difference.
+
+## Self-Editing Checklist
+
+When reviewing your own technical writing:
+
+- Read aloud to catch awkward phrasing
+- Check every pronoun: is the referent obvious?
+- Verify terminology consistency across the document
+- Confirm each paragraph opens with its main point
+- Ensure lists are parallel in grammar and punctuation
+- Replace vague verbs and filler phrases
+- Test sample code
+- Write captions for every illustration
+- Reread from the audience's perspective for curse-of-knowledge gaps
diff --git a/ai/claude/skills/writing-error-messages/SKILL.md b/ai/claude/skills/writing-error-messages/SKILL.md
new file mode 100644
index 00000000..e3f08379
--- /dev/null
+++ b/ai/claude/skills/writing-error-messages/SKILL.md
@@ -0,0 +1,119 @@
+---
+name: writing-error-messages
+description: Use when writing, reviewing, or improving error messages in code, CLI tools, APIs, or UIs. Covers identifying the cause, explaining the fix, and setting the right tone. Also use when error messages are vague, unactionable, or confusing.
+---
+
+# Writing Error Messages
+
+Actionable reference for writing helpful error messages, distilled from
+Google's Technical Writing course on error messages.
+
+Every error message should answer two questions: what went wrong, and
+how the user fixes it.
+
+## General Rules
+
+**Never fail silently.** Failure is inevitable; failing to report
+failures is inexcusable. Silent failures confuse users and complicate
+support.
+
+**Raise errors immediately.** Report errors as soon as detected. Early
+detection reduces debugging cost and prevents cascading failures.
+
+**Preserve root cause information.** Avoid generic messages like "Server
+error." Provide specific context about what actually failed.
+
+**Log numeric error codes alongside text.** Codes help support teams
+monitor and diagnose issues. Document all codes for internal and
+external use.
+
+## Explain the Problem
+
+**Name the specific cause.** Tell users exactly what went wrong. Vague
+messages frustrate users.
+
+| Vague | Specific |
+|---|---|
+| Bad directory. | Directory '/tmp/out' exists but is not writable. |
+| Invalid field 'picture'. | Field 'picture' appears multiple times. Only one instance is allowed. |
+
+**Identify invalid user inputs.** When the user provided bad input, say
+which input and why it failed.
+
+**State the requirements and constraints.** If the error involves a
+limit or format requirement, name the requirement explicitly. Include
+version context when relevant ("Prior to v3.0, duplicate fields were
+allowed").
+
+## Explain the Solution
+
+**Show how to fix it.** An error message that names the problem without
+a remedy is a dead end.
+
+| Dead end | Actionable |
+|---|---|
+| Client app no longer supported. | Client app no longer supported. Click **Update app** to install the latest version. |
+| Quota 'CPUS' exceeded. Limit: 1.0 | You requested 5 CPUs but the limit in us-central-1 is 1. Request a quota increase or deploy to a different region. |
+
+**Provide multiple solution paths when they exist.** Users have
+different constraints; offering alternatives gives them agency.
+
+**Link to documentation** for complex recovery procedures rather than
+cramming instructions into the message.
+
+**Include concrete examples** when format requirements are involved.
+Show the expected format alongside the rejected input.
+
+## Write Clearly
+
+**Be concise.** Omit words the user does not need. Error messages are
+read under stress; brevity reduces cognitive load.
+
+**Avoid double negatives.** "The value must not be non-empty" requires
+two negation inversions. Write "The value must be empty" or "Provide a
+non-empty value" depending on intent.
+
+**Write for your audience.** An API error seen by developers can include
+technical detail. An error in a consumer UI should use plain language.
+Match vocabulary to the reader.
+
+**Use terminology consistently.** If the system calls it a "project"
+everywhere, do not call it a "workspace" in one error message.
+
+**Format for readability.** In long messages, separate the problem
+statement from the solution. Use line breaks, bullet points, or
+structured fields when the environment supports them.
+
+## Tone
+
+**Be positive.** State what to do, not what the user did wrong.
+
+| Negative | Positive |
+|---|---|
+| You didn't enter a name. | Enter a name. |
+| You entered an invalid postal code. | Enter a valid postal code, such as 90210. |
+
+**Do not over-apologize.** Skip "sorry" and "please." Focus on the
+problem and solution. Cultural expectations around apologies vary; clear
+information serves all readers.
+
+**Skip humor.** Frustrated users do not appreciate jokes. Humor
+translates poorly across cultures and distracts from the message's
+purpose.
+
+**Do not blame the user.** Focus on what happened, not who caused it.
+
+| Blaming | Neutral |
+|---|---|
+| You specified a printer that's offline. | The specified printer is offline. |
+
+## Quick Reference
+
+Every error message should include:
+
+1. What went wrong (specific cause, not a generic label)
+2. Why it went wrong (the constraint or requirement that was violated)
+3. How to fix it (concrete next steps or links to documentation)
+
+When writing, check: Is it specific? Is it actionable? Is the tone
+neutral and constructive?
diff --git a/ai/claude/skills/writing-for-accessibility/SKILL.md b/ai/claude/skills/writing-for-accessibility/SKILL.md
new file mode 100644
index 00000000..a71bfbab
--- /dev/null
+++ b/ai/claude/skills/writing-for-accessibility/SKILL.md
@@ -0,0 +1,105 @@
+---
+name: writing-for-accessibility
+description: Use when writing documentation, alt text, diagrams, or any content that should be accessible to people with disabilities. Covers alt text, color contrast, inclusive language, and accessible visuals. Also use when reviewing documents for accessibility.
+---
+
+# Writing for Accessibility
+
+Actionable reference for making documentation accessible, distilled
+from Google's Tech Writing for Accessibility course.
+
+Accessible documentation is documentation anyone can read and
+understand, including people who use screen readers, have low vision,
+or have cognitive disabilities.
+
+## Alt Text
+
+**Write alt text for every informational image.** Screen readers read
+alt text aloud; without it, they read the filename instead.
+
+**Adjust descriptions to context.** The same image needs different alt
+text depending on what the surrounding text emphasizes. A photo of a
+chickadee in a birdwatching guide needs species detail; in an article
+about winter adaptations, it needs plumage description.
+
+**Keep it brief.** Use a short phrase or one to two sentences. Omit
+"Image of" or "Photo of" — screen readers already announce that an
+image is present. Capitalize the first word and end with a period to
+provide auditory separation from the body text.
+
+**Use empty alt text for decorative images.** When an image is purely
+decorative or duplicates adjacent text, use `alt=""`. Omitting the alt
+attribute entirely causes screen readers to read the filename.
+
+**Handle complex images in two parts.** For graphs, flowcharts, or
+detailed diagrams, write concise alt text summarizing the takeaway,
+then provide a full description in the document body or on a linked
+page. Data tables work well for chart data.
+
+**Omit demographic details unless essential.** Describe people by
+context ("musician," "teacher") unless demographics are relevant to the
+image's purpose.
+
+**Stay consistent.** Use the same alt text for the same image wherever
+it appears. Avoid all caps — they affect readability and screen reader
+interpretation.
+
+## Color Contrast
+
+**Meet WCAG contrast ratios.** Text must have sufficient contrast
+against its background. Small text needs a higher ratio than large text.
+Use a contrast checker tool before publishing.
+
+**Never rely on color alone to convey meaning.** Pair color with text
+labels, patterns, or icons. A chart that distinguishes series only by
+color is inaccessible to colorblind readers.
+
+## Inclusive Language
+
+**Center the person, not the disability.** Avoid language that defines
+people by a condition or implies they are lesser.
+
+**Prefer person-first language in general.** "Person with a cognitive
+impairment," not "cognitively impaired person."
+
+**Respect community preferences.** Some communities prefer
+identity-first language. Deaf and neurodivergent communities often
+prefer "Deaf person" and "neurodivergent person." Research the
+community's preference before writing about it.
+
+**Avoid euphemisms and patronizing terms.** Do not describe nondisabled
+people as "normal" or "healthy." Use "nondisabled," "sighted,"
+"hearing," or "neurotypical" as appropriate.
+
+**Avoid judgmental framing.** Replace "suffering from," "victim of,"
+and "wheelchair-bound" with "experiencing," "living with," and "uses a
+wheelchair."
+
+**Do not use collective nouns for groups.** Write "people with
+disabilities," not "the disabled."
+
+## Accessible Visuals
+
+**Introduce diagrams in body text.** Do not rely on alt text alone to
+explain a diagram's purpose or structure.
+
+**Use labels directly on diagrams** rather than requiring a separate
+legend when possible. Legends add cognitive load and create problems
+when the legend and diagram are not visible simultaneously.
+
+**Ensure text in images is readable.** Use sufficient font size and
+contrast. Text embedded in images cannot be resized by users and is
+invisible to screen readers — minimize it.
+
+## Editing for Accessibility
+
+When reviewing a document for accessibility:
+
+- Verify every informational image has descriptive alt text
+- Check that decorative images use empty alt text
+- Confirm color is never the sole indicator of meaning
+- Test color contrast with a tool, not by eye
+- Review language for person-first phrasing and community preferences
+- Ensure diagrams are introduced and explained in body text
+- Check that link text is descriptive ("Read the migration guide"),
+  not generic ("Click here")