ai: cut duplicated guidance and fix dead doc references
Several of these were dead rather than merely redundant: there is no
`gitea` or `elements-of-style` skill, `.config/ramekin/agent/skills/` no
longer exists, and AGENTS.md contradicted `ai/_AGENTS.md` on `jj describe`.

Assisted-by: Claude Opus 5 via Claude Code
change oxqsqvlokyzlxyuzqpmynyorxqzowkzm
commit c171a4eaa14cd9fb4d8d8d4c41d8cb1e318e2474
author Alpha Chen <alpha@kejadlen.dev>
date
parent pmqtyztq
diff --git a/AGENTS.md b/AGENTS.md
index a87b0a12..7a47a24c 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -8,8 +8,10 @@ Key directories:
 
 - `.config/` — app configs (aerospace, ghostty, nvim, jj, etc.)
 - `.hammerspoon/` — Hammerspoon config in Fennel (`.fnl` files compiled to Lua)
-- `.claude/` — Claude Code settings
-- `.pi/` — pi agent settings and extensions
+- `ai/claude/` — Claude Code settings and hooks (symlinked in as `~/.claude`)
+- `ai/pi/` — pi agent settings and extensions (symlinked in as `~/.pi/agent`)
+- `ai/skills/` — skills, shared by both agents
+- `ai/_AGENTS.md` — global agent conventions (symlinked in as `~/.claude/CLAUDE.md`)
 - `.ssh/` — SSH config
 - `.zsh/` — Zsh config
 - `src/` — git submodules (Alfred workflows, fzf-git, tpm)
@@ -17,18 +19,13 @@ Key directories:
 
 ## Version Control
 
-This repo uses **jj**, not git. Use `jj` commands for all VCS operations:
+Main bookmark: `main`. Don't commit directly to `main` — work on the `@` change or create new ones.
 
-- `jj status` / `jj diff` / `jj log` — inspect state
-- `jj describe -m "message"` — set change description
-- `jj new` — start a new change
-- `jj bookmark set <name>` — set a bookmark (jj's equivalent of branches)
-
-Main branch: `main`. Don't commit directly to `main` — work on the `@` change or create new ones.
+`ai/_AGENTS.md` owns the jj rules; reach for the `jj` skill before free-handing commands.
 
 ## Issue Tracker
 
-Issues are on Gitea at `git.kejadlen.dev`. Use the `tea` CLI:
+Issues are on Gitea at https://git.kejadlen.dev/alpha/dotfiles/issues. Use the `tea` CLI:
 
 ```bash
 tea issues list -r alpha/dotfiles -l git.kejadlen.dev
@@ -47,14 +44,10 @@ tea comment -r alpha/dotfiles -l git.kejadlen.dev <index> "Comment body"
 
 Skills live in `ai/skills/<name>/SKILL.md`. See the `skill-notes` skill for authoring conventions.
 
-Pi loads these via `ai/pi/settings.json`, which points to `~/.dotfiles/ai/skills`. Ramekin containers have their own copy at `.config/ramekin/agent/skills/` — it's fine for these to drift; only update `ai/skills/`.
+Pi loads these via `ai/pi/settings.json`, which points to `~/.dotfiles/ai/skills`. Claude reaches them through `ai/claude/skills` (a symlink to `../skills`), so both agents read the same files — only ever edit `ai/skills/`.
 
 ## Pi Packages
 
 Pi manages plugins natively via `pi install` / `pi remove` / `pi update` / `pi list`. Global packages are declared in `~/.pi/agent/settings.json` under `packages`. Project-scoped packages use `.pi/settings.json` with the `-l` flag.
 
 Use the object form with `skills` filters to load specific plugins from multi-plugin repos.
-
-## Open Issues
-
-Track work at: https://git.kejadlen.dev/alpha/dotfiles/issues
diff --git a/ai/claude/rules/model-selection.md b/ai/claude/rules/model-selection.md
index d92b0e8f..3ee2ef11 100644
--- a/ai/claude/rules/model-selection.md
+++ b/ai/claude/rules/model-selection.md
@@ -11,8 +11,8 @@ involving judgment or conversation.
 
 ## Sonnet
 
-Subagents, background tasks, well-scoped autonomous work where the
-instructions are clear and the task is bounded.
+Background tasks and well-scoped autonomous work where the instructions
+are clear and the task is bounded.
 
 ## Haiku
 
diff --git a/ai/skills/diataxis/SKILL.md b/ai/skills/diataxis/SKILL.md
index d626550c..ec21096a 100644
--- a/ai/skills/diataxis/SKILL.md
+++ b/ai/skills/diataxis/SKILL.md
@@ -110,31 +110,6 @@ The user wants to understand *why*. They're reflecting, not executing.
 
 **Keep out:** step-by-step instructions, reference material, unbounded scope.
 
-## Decision Flowchart
-
-```dot
-digraph diataxis_classify {
-    rankdir=TB;
-    node [shape=diamond];
-    start [label="What does the reader\nneed right now?" shape=ellipse];
-    q1 [label="Action or\ncognition?"];
-    q2a [label="Learning or\nworking?"];
-    q2b [label="Learning or\nworking?"];
-    tutorial [label="Tutorial" shape=box];
-    howto [label="How-to guide" shape=box];
-    explanation [label="Explanation" shape=box];
-    reference [label="Reference" shape=box];
-
-    start -> q1;
-    q1 -> q2a [label="action"];
-    q1 -> q2b [label="cognition"];
-    q2a -> tutorial [label="learning"];
-    q2a -> howto [label="working"];
-    q2b -> explanation [label="learning"];
-    q2b -> reference [label="working"];
-}
-```
-
 ## Applying the Framework
 
 ### When reviewing existing documentation
diff --git a/ai/skills/editing-prose/SKILL.md b/ai/skills/editing-prose/SKILL.md
index c341f733..cb93e1cf 100644
--- a/ai/skills/editing-prose/SKILL.md
+++ b/ai/skills/editing-prose/SKILL.md
@@ -10,10 +10,10 @@ Catches AI writing tropes that other writing skills miss. Sources:
 [Modeltell](https://github.com/thirdshiftlab/modeltell).
 
 Complements `technical-writing` (structure, terminology),
-`elements-of-style` (sentence-level clarity), and `diataxis` (document
-classification). Those skills cover good writing in general; this one
-covers the specific patterns LLMs reach for that flag text as
-AI-generated.
+`writing-clearly-and-concisely` (sentence-level clarity), and
+`diataxis` (document classification). Those skills cover good writing in
+general; this one covers the specific patterns LLMs reach for that flag
+text as AI-generated.
 
 ## When not to use
 
@@ -24,8 +24,9 @@ AI-generated.
 
 ## Workflow
 
-1. Read [`ai-tropes.md`](ai-tropes.md) to load the full trope catalog
-   into context.
+1. Read [`ai-tropes.md`](ai-tropes.md) for the full catalog, with
+   examples for each pattern, organized by word choice, sentence
+   structure, paragraph structure, tone, formatting, and composition.
 2. Scan the prose for each trope category, looking for repetition or
    stacking — one instance of a pattern is usually fine; multiple is
    the tell.
@@ -37,10 +38,6 @@ AI-generated.
 
 ## The core principle
 
-> Any of these patterns used once might be fine. The problem is when
-> multiple tropes appear together or when a single trope is used
-> repeatedly. Write like a human: varied, imperfect, specific.
-
 Don't mechanically eliminate every em dash or every "is" → "serves
 as" — that produces stilted, evasive writing in the other direction.
 Look for *concentration* and *stacking*. A single em dash in a
@@ -63,17 +60,3 @@ These are the strongest tells. If you see them, edit them:
 - Unicode arrows (`→`) and smart quotes in plain text contexts
 - "Whether you're X or Y" pseudo-inclusive openers
 - "In today's [adjective] landscape/world/era" openers
-
-## Full reference
-
-[`ai-tropes.md`](ai-tropes.md) contains the complete catalog with
-examples for each pattern, organized by:
-
-1. Word choice
-2. Sentence structure
-3. Paragraph structure
-4. Tone
-5. Formatting
-6. Composition
-
-Read it before editing any substantial prose.
diff --git a/ai/skills/jj-workspaces/SKILL.md b/ai/skills/jj-workspaces/SKILL.md
index 99fadbb0..d20ae290 100644
--- a/ai/skills/jj-workspaces/SKILL.md
+++ b/ai/skills/jj-workspaces/SKILL.md
@@ -10,8 +10,6 @@ description: Use when needing isolated workspace for experiments, parallel devel
 
 Create isolated jj workspaces for experimentation, parallel development, and subagent coordination. All workspaces share repository history, so switching between them and comparing their changes needs no extra setup.
 
-**Core principle:** Isolation by design. Each workspace operates independently with zero risk of interference.
-
 **Important:** Run `jj` (or `jj status`) periodically in each workspace. jj only snapshots the working copy when you run a command—it doesn't watch for file changes. Running `jj` ensures it sees your edits.
 
 **Note (v0.39+):** `jj workspace add` now links with relative paths by default, enabling workspaces to work inside containers or when moved together. Existing workspaces with absolute paths continue to work.
@@ -53,6 +51,9 @@ jj workspace update-stale
 
 **Result (with mm):** `trunk() → workspace change → mm`
 
+`<name>@` names that workspace's working-copy commit and resolves from any
+workspace; `jj workspace list` shows them all.
+
 ## Solo Experiments
 
 ### Work and Evaluate
@@ -145,34 +146,11 @@ jj workspace forget <name>
 rm -rf work/<name>
 ```
 
-## Commands Reference
-
-```bash
-# Create workspace (ensure work/ exists first)
-mkdir -p work && jj workspace add --name=<name> work/<name>
-jj workspace add --name=<name> -r <rev> work/<name>
-
-# List workspaces
-jj workspace list
-
-# Forget workspace (keeps commits)
-jj workspace forget <name>
-
-# View workspace commits
-jj log -r 'working_copies()'
-
-# Reference workspace's current commit
-<name>@
-
-# Sync after external workspace changes
-jj workspace update-stale
-```
-
 ## Common Mistakes
 
 | Mistake | Fix |
 |---------|-----|
-| Working from wrong directory | Agent must `cd` into workspace directory first—all commands run FROM there |
+| Working from wrong directory | Agent must `cd` into workspace directory first—jj resolves its context from cwd, so all commands run FROM there |
 | Skipping DAG placement | Must run `jj rebase` to place in DAG (with `-B mm` if megamerge exists) |
 | Agent skipping split | Agent must run `jj split -m '<description>' .` to finalize changes |
 | Skipping `jj workspace update-stale` | Run in main workspace after workspace operations |
@@ -182,17 +160,7 @@ jj workspace update-stale
 | Forgetting cleanup | Remove directories after forgetting workspace |
 | jj not seeing file changes | Run `jj` or `jj status` periodically—jj only snapshots on command execution |
 | Files written in one workspace vanish | Concurrent rewrite left the change divergent. See the `jj` skill's Divergent Changes section—recover, don't rewrite |
-
-## Red Flags
-
-| Thought | Reality |
-|---------|---------|
-| "I can work from the main workspace" | Must `cd` into workspace directory—jj context depends on cwd |
-| "I'll skip DAG placement" | Must place in DAG for clean integration |
-| "Agent doesn't need to split" | Agent must run `jj split -m '<description>' .` to finalize changes |
-| "I'll create workspaces during dispatch" | Create ALL workspaces first |
-| "Custom directory is fine" | Always use `work/` directory |
-| "This is overkill for one agent" | Single-agent workflow maintains consistency |
+| "Overkill for one agent" | Use the same workflow for one agent as for many—consistency beats a special case |
 
 ## Failure Recovery
 
@@ -200,9 +168,8 @@ jj workspace update-stale
 
 **Verification fails:** Agent reports failure. Coordinator decides: retry, fix, or revert.
 
-**Conflicts after sync:** Expected. Coordinator resolves via `jj resolve`.
-
-All failures are contained and recoverable.
+**Conflicts after sync:** Expected. Coordinator resolves via the
+`resolve-conflicts` skill.
 
 ## References
 
diff --git a/ai/skills/mcporter/SKILL.md b/ai/skills/mcporter/SKILL.md
index 8ae541ad..d8f2acc7 100644
--- a/ai/skills/mcporter/SKILL.md
+++ b/ai/skills/mcporter/SKILL.md
@@ -43,13 +43,5 @@ mcporter call slack.get_thread_messages --args '{"channel":"general","thread_ts"
 ```bash
 mcporter list                    # List configured servers
 mcporter list <server> --schema  # Show all tools with full parameter schemas
+mcporter call --help             # Full call syntax
 ```
-
-## Quick reference
-
-| Command | Purpose |
-|---------|---------|
-| `mcporter list` | List servers |
-| `mcporter list <server> --schema` | Tool docs and parameter schemas |
-| `mcporter call <server>.<tool> ...` | Call a tool |
-| `mcporter call --help` | Full call syntax |
diff --git a/ai/skills/rust/style.md b/ai/skills/rust/style.md
index 2e7a7d74..6d5e3493 100644
--- a/ai/skills/rust/style.md
+++ b/ai/skills/rust/style.md
@@ -235,14 +235,7 @@ for item in list.map(transform) {
 }
 ```
 
-Automation — add to `.clippy.toml`:
-
-```toml
-disallowed-methods = [
-    { path = "std::iter::Iterator::for_each", reason = "prefer `for` for side-effects" },
-    { path = "std::iter::Iterator::try_for_each", reason = "prefer `for` for side-effects" },
-]
-```
+The Clippy configuration below disallows `for_each` and `try_for_each` so bare uses get caught at lint time.
 
 ## Dependencies
 
diff --git a/ai/skills/self-improving-skills/SKILL.md b/ai/skills/self-improving-skills/SKILL.md
index 3015aa08..49f0b012 100644
--- a/ai/skills/self-improving-skills/SKILL.md
+++ b/ai/skills/self-improving-skills/SKILL.md
@@ -62,9 +62,6 @@ When creating a new self-improving skill, resist the urge to front-load it with
 
 ## What NOT to Do
 
-- Don't rewrite the whole skill on first use — add incrementally
-- Don't add content you didn't verify during this session
 - Don't remove existing content that's still accurate
 - Don't bloat the skill with edge cases nobody's hit yet
 - Don't restructure or rewrite surrounding sections — add exactly the missing piece and leave the rest alone
-- Don't bulk-copy from `--help` output, READMEs, or other reference material — the skill is a journal of learned experience, not a mirror of existing docs
diff --git a/ai/skills/technical-writing/SKILL.md b/ai/skills/technical-writing/SKILL.md
index 4b6f4ad2..dc276c97 100644
--- a/ai/skills/technical-writing/SKILL.md
+++ b/ai/skills/technical-writing/SKILL.md
@@ -8,9 +8,9 @@ description: Use when writing or reviewing technical documentation, API docs, tu
 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.
+For sentence-level prose rules, use `writing-clearly-and-concisely`
+(from the elements-of-style plugin). For classifying documentation
+types, use `diataxis`.
 
 ## Terminology
 
@@ -154,18 +154,12 @@ 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.
@@ -220,19 +214,12 @@ usage first.
 **Show both correct and incorrect forms** when language conventions
 matter, so readers recognize the difference.
 
-## Self-Editing Checklist
+## Self-Editing
 
-When reviewing your own technical writing:
+Re-check the rules above against the draft, then use these techniques to
+see your own writing freshly:
 
 - 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
 - Set it aside and return with fresh eyes
 - Change the visual context: different font, format, or medium
 - Ask a peer to review; they need style awareness, not domain expertise
diff --git a/ai/skills/working-in-the-open/SKILL.md b/ai/skills/working-in-the-open/SKILL.md
index c91c2edf..46dbd202 100644
--- a/ai/skills/working-in-the-open/SKILL.md
+++ b/ai/skills/working-in-the-open/SKILL.md
@@ -86,7 +86,7 @@ Check available tools in order:
 
 - GitHub: `gh issue comment <number> --body "..."`
 - Linear/Jira: use available MCP tools
-- Gitea: `tea comment` (see the `gitea` skill for syntax)
+- Gitea: `tea comment -r <owner>/<repo> <index> "..."`
 - Fallback: present the formatted comment for manual posting
 
 ## Attribution
diff --git a/ai/skills/writing-error-messages/SKILL.md b/ai/skills/writing-error-messages/SKILL.md
index e3f08379..83386ef6 100644
--- a/ai/skills/writing-error-messages/SKILL.md
+++ b/ai/skills/writing-error-messages/SKILL.md
@@ -8,8 +8,8 @@ description: Use when writing, reviewing, or improving error messages in code, C
 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.
+Every error message should answer three questions: what went wrong,
+which requirement or constraint it violated, and how the user fixes it.
 
 ## General Rules
 
@@ -106,14 +106,3 @@ purpose.
 | 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/meta/README.md b/meta/README.md
index adcf95df..98ac8954 100644
--- a/meta/README.md
+++ b/meta/README.md
@@ -4,7 +4,7 @@
 
 ```sh
 # Install Homebrew
-`/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"`
+/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
 
 # Load Homebrew
 eval "$(/opt/homebrew/bin/brew shellenv)"