Claude: Add claude.md

home/.agents/skills/brainstorming/SKILL.md

@@ -10,57 +10,49 @@ Help turn ideas into fully formed designs and specs through natural collaborativ
 
 Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
 
-<HARD-GATE>
-Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
-</HARD-GATE>
-
-## Anti-Pattern: "This Is Too Simple To Need A Design"
-
-Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+Take no implementation action — no code, no scaffolding, no implementation skill — until the user has approved a design. This holds for every project, however simple: a todo list, a single-function utility, or a config change still gets a design, because simple projects are where unexamined assumptions waste the most work. For those, the design can be a few sentences.
 
 ## Checklist
 
-You MUST create a task for each of these items and complete them in order:
+Create a task for each item and complete them in order:
 
 1. **Explore project context** — check files, docs, recent commits
-3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
-4. **Propose 2-3 approaches** — with trade-offs and your recommendation
-5. **Present design** — in sections scaled to their complexity, get user approval after each section
-6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
-7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
-8. **User reviews written spec** — ask user to review the spec file before proceeding
-9. **Transition to implementation** — invoke skills such as grill-with-docs or to-prd to create implementation plan
+2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation
+4. **Present design** — in sections scaled to their complexity, get user approval after each section
+5. **Write spec to effort** — the body of an effort task in the vault, following the `dev-tickets` skill
+6. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
+7. **User reviews written spec** — ask user to review the effort before proceeding
+8. **Transition to implementation** — hand off to `/to-tickets` to slice the effort into implementation tickets
 
 ## Process Flow
 
 ```dot
 digraph brainstorming {
     "Explore project context" [shape=box];
-    "Visual questions ahead?" [shape=diamond];
     "Ask clarifying questions" [shape=box];
     "Propose 2-3 approaches" [shape=box];
     "Present design sections" [shape=box];
     "User approves design?" [shape=diamond];
-    "Write design doc" [shape=box];
+    "Write spec to effort" [shape=box];
     "Spec self-review\n(fix inline)" [shape=box];
     "User reviews spec?" [shape=diamond];
     "Transition to implementation" [shape=doublecircle];
 
-    "Explore project context" -> "Visual questions ahead?";
-    "Visual questions ahead?" -> "Ask clarifying questions" [label="no"];
+    "Explore project context" -> "Ask clarifying questions";
     "Ask clarifying questions" -> "Propose 2-3 approaches";
     "Propose 2-3 approaches" -> "Present design sections";
     "Present design sections" -> "User approves design?";
     "User approves design?" -> "Present design sections" [label="no, revise"];
-    "User approves design?" -> "Write design doc" [label="yes"];
-    "Write design doc" -> "Spec self-review\n(fix inline)";
+    "User approves design?" -> "Write spec to effort" [label="yes"];
+    "Write spec to effort" -> "Spec self-review\n(fix inline)";
     "Spec self-review\n(fix inline)" -> "User reviews spec?";
-    "User reviews spec?" -> "Write design doc" [label="changes requested"];
+    "User reviews spec?" -> "Write spec to effort" [label="changes requested"];
     "User reviews spec?" -> "Transition to implementation" [label="approved"];
 }
 ```
 
-**The terminal state is writing a plan.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skills you invoke after brainstorming are grill-with-docs or to-prd.
+**The terminal state is an approved spec in an effort task.** Do NOT invoke any other implementation skill. The only next step after brainstorming is `/to-tickets`.
 
 ## The Process
 
@@ -105,13 +97,13 @@ digraph brainstorming {
 
 **Documentation:**
 
-- Write the validated design (spec) to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`
-  - (User preferences for spec location override this default)
+- Write the validated design (spec) as the body of an effort task in the vault. The `dev-tickets` skill owns where it goes, its frontmatter, and the `ticket` commands that write it.
+  - If `/wayfinder` already charted this effort, the effort task exists and its body is the map: keep `## Notes` and `## Decisions so far`, and replace `## Destination` with the spec.
+  - Otherwise create the effort task. It carries no actor tag; only tickets do.
 - Use elements-of-style:writing-clearly-and-concisely skill if available
-- Commit the design document to git
 
 **Spec Self-Review:**
-After writing the spec document, look at it with fresh eyes:
+After writing the spec, look at it with fresh eyes:
 
 1. **Placeholder scan:** Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
 2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?
@@ -123,14 +115,14 @@ Fix any issues inline. No need to re-review — just fix and move on.
 **User Review Gate:**
 After the spec review loop passes, ask the user to review the written spec before proceeding:
 
-> "Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."
+> "Spec written to the effort `<effort title>`. Please review it and let me know if you want to make any changes before we break it into tickets."
 
 Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.
 
 **Implementation:**
 
-- Invoke the grill-with-docs skill to create a detailed implementation plan
-- Do NOT invoke any other skill. grill-with-docs is the next step.
+- Ask the user to run `/to-tickets <effort title>` to break the spec into implementation tickets
+- Do NOT invoke any other skill. `/to-tickets` is the next step.
 
 ## Key Principles
 

home/.agents/skills/magpie-review/SKILL.md

@@ -1,121 +0,0 @@
----
-name: magpie-review
-description: Run a multi-AI adversarial code review using the `magpie` CLI. Multiple AI models independently review the changes, debate findings, and a verifier audits each issue against the actual code. Use whenever the user asks for a "magpie review", a "multi-AI review", an "adversarial review", a "second opinion review", or wants magpie to look at local uncommitted changes, the current branch, or a GitHub PR. Also use when the user wants to `magpie discuss` a topic or do a whole-repo review.
----
-
-# magpie-review
-
-Wraps the `magpie` CLI to run adversarial multi-AI code reviews. Magpie spawns several reviewer models (Claude Code, Codex, Gemini, etc.) that independently review a change, debate across rounds, then a verifier audits each reported issue against the actual code.
-
-## When to pick which mode
-
-Magpie supports three review targets — pick based on what the user is reviewing:
-
-| User's intent | Command |
-|---|---|
-| Review work I haven't committed yet (staged + unstaged) | `magpie review --local` |
-| Review the commits on my current branch vs a base | `magpie review --branch [base]` (base defaults to `main`) |
-| Review a GitHub PR | `magpie review <pr-number>` or `magpie review <pr-url>` |
-| Review specific files only | `magpie review --files <path> [path...]` |
-| Review the entire repository | `magpie review --repo` |
-| Discuss a topic / design question | `magpie discuss "<topic>"` or `magpie discuss <path-to-file.md>` |
-
-If the user is ambiguous (e.g. "review my changes"), check `git status` and `git log @{u}..HEAD` to figure out whether they mean uncommitted, committed-but-unpushed, or already-pushed work — then pick the matching mode rather than guessing.
-
-## Running a review
-
-Always run `magpie` from inside the target repo's working tree. For PR mode it uses the `origin` remote to find the repo by default.
-
-### Common flags
-
-These apply to both `review` and `discuss` unless noted:
-
-- `-i, --interactive` — Pause between turns for Q&A. Use when the user wants to drive the review themselves.
-- `-a, --all` — Use every configured reviewer without an interactive picker. Good for non-interactive/batch runs.
-- `--reviewers <ids>` — Comma-separated reviewer IDs (e.g. `claude-code,gemini-cli`) when you want a specific subset.
-- `-r, --rounds <n>` — Cap the debate rounds (default 5).
-- `--no-converge` — Disable early-stop on consensus. Use when you want the full debate even if reviewers agree quickly.
-- `-o, --output <file>` and `-f, --format <markdown|json>` — Save results to a file.
-- `--fail-fast` — Abort the whole flow if any reviewer fails. Default is resilient (continues with surviving reviewers). Use fail-fast when debugging provider/auth issues or when the user wants a guarantee every reviewer participated.
-- `--plan-only` — Generate the review plan without running reviewers. Useful for a quick preview of what magpie *would* do.
-
-### `review`-only flags worth knowing
-
-- `--skip-context` — Skip the context-gathering phase (call chains, related PRs). Faster, less informed.
-- `--no-post` — Skip the post-debate GitHub comment-posting flow. Use in non-interactive contexts where you just want the review output, not the interactive post-each-issue loop.
-- `--no-conclusion` — Skip the final summarizer. Useful for bot/CI use.
-- `--git-remote <remote>` — Override the remote used for PR-URL detection (default `origin`).
-- `--reanalyze` — Bypass the analyzer cache and re-analyze from scratch.
-
-### Repo-mode flags (with `--repo`)
-
-- `--path <subdir>` — Limit the repo review to a subdirectory.
-- `--ignore <patterns...>` — Skip matching paths.
-- `--quick` — Architecture overview only.
-- `--deep` — Full analysis, no prompts.
-- `--list-sessions` / `--session <id>` / `--export <file>` — Manage long-running repo review sessions (they persist so you can pause and resume).
-
-## Interactive vs non-interactive
-
-Magpie's default flow includes interactive prompts (reviewer selection, per-issue post/edit/skip after the debate). When you (Claude) are invoking magpie programmatically on the user's behalf:
-
-- Prefer `-a` (or `--reviewers`) to skip the reviewer-selection prompt.
-- Prefer `--no-post` to skip the per-issue posting loop — the user can still read the review output.
-- If you want a clean machine-readable result, add `-f json -o <file>`.
-
-When the user wants to drive the review themselves, hand the command back to them to run (e.g. via `! magpie review ...`) so they get the interactive UX rather than running it through a tool call.
-
-## Running it as a long task (it takes minutes)
-
-A full review runs several models across multiple debate rounds, so it takes minutes. Run it as a background `Bash` task with `run_in_background: true` and save the output (`-f markdown -o <file>`). The background task auto-notifies you when it completes — that completion notification is all you need; read the saved output file then.
-
-- **Do not add a separate `Monitor` on the same output file.** The background task already notifies on completion, so a monitor watching the same file is redundant. Only add a `Monitor` if you genuinely need streamed interim progress, and even then it is usually unnecessary for a fire-and-forget review.
-- **Never copy the output path by hand.** Pass the same explicit `-o <file>` path you chose (e.g. `/tmp/magpie-review.md`) to your follow-up `Read` — don't transcribe the long auto-generated task-output path from the completion notification, which is easy to typo.
-- **Don't suppress stderr** (`2>/dev/null`) on magpie or on any watcher command. If something fails — bad path, auth error, missing reviewer — you want to see why, not a bare non-zero exit. Use `2>&1 | tee <log>` if you want both a saved log and visible errors.
-
-## Examples
-
-**User: "Have magpie look at what I'm working on right now."**
-They likely mean uncommitted work. Run:
-```
-magpie review --local
-```
-
-**User: "Get a magpie review on this branch before I push."**
-Current branch vs main:
-```
-magpie review --branch
-```
-
-**User: "Run magpie on PR 4521."**
-```
-magpie review 4521
-```
-
-**User: "Use magpie to review just the changes to `src/auth/`."**
-Pick the files mode:
-```
-magpie review --files src/auth/login.ts src/auth/session.ts
-```
-
-**User: "Get a fast magpie sanity check on PR 4521 — I just want the output, don't post anything."**
-```
-magpie review 4521 -a --no-post --skip-context
-```
-
-**User: "Have magpie debate whether we should adopt tRPC."**
-```
-magpie discuss "Should we adopt tRPC for our internal APIs?"
-```
-
-## Configuration notes
-
-- Magpie reads `~/.magpie/config.yaml` for providers, reviewers, analyzer, summarizer, and the context-gatherer config.
-- CLI providers (`claude-code`, `codex-cli`, `gemini-cli`, `qwen-code`, `opencode-cli`) use the user's existing subscriptions/logins — no API keys needed and they're the recommended choice.
-- If the user hasn't run `magpie init` yet, suggest `magpie init` (interactive) or `magpie init -y` (defaults) before the first review.
-- If `magpie` is not on PATH, the project at `/home/tgrosinger/code/magpie` may need `npm install && npm run build && npm link` from its root.
-
-## When *not* to use this skill
-
-- The user is asking how magpie itself is implemented or wants to modify magpie's source — that's a normal code task in the magpie repo, not an invocation of this skill.
-- The user wants a single-model review (just Claude reviewing the diff). Use the built-in `/code-review` skill instead.

home/.agents/skills/traefik-expose/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: traefik-expose
-description: Make a service on the tachi host reachable at https://NAME.i.grosinger.net through Traefik, or remove it. Use when asked to expose, register, route, or publish a dev server, host process, or docker container on an internal hostname, or to unexpose/deregister one.
+description: Make a service on the voyager reachable at https://NAME.i.grosinger.net through Traefik, or remove it. Use when asked to expose, register, route, or publish a dev server, host process, or docker container on an internal hostname, or to unexpose/deregister one.
 ---
 
 > [!info] This skill only applies to the host `voyager`

home/.claude/CLAUDE.md

@@ -0,0 +1,91 @@
+## Critical rules
+
+Never delete files outside your own temp directory, and never attempt to circumvent the restrictions on deleting files. Cleaning up scratch files under /tmp/claude-1000 with a plain rm/rmdir to an absolute path is allowed; anything else you must ask me to delete manually.
+
+```sh
+# Allowed
+rm /tmp/claude-1000/file
+rm -rf -- /tmp/claude-1000/directory
+
+## NOT Allowed
+rm $TMPDIR/file
+rm /tmp/claude-1000/*.log
+rm -rf /tmp/claude-1000/../other
+```
+
+## Issue tracker and tickets
+
+Tickets, specs, and wayfinder maps live in my Obsidian vault as TaskNotes tasks. The `dev-tickets` skill owns that model — invoke it whenever a skill or I reference a ticket, spec, or effort.
+
+- Update the ticket's status as the work proceeds, and log hurdles and design changes to its `## Notes` while they happen.
+- When implementation of a ticket materially deviates from what was written, note the changes in an "As Built" section at the bottom.
+- A few repos still have a `.scratch/` directory from the previous system. Those efforts stay where they are; new ones use the vault.
+
+## Memories
+
+Do not use your memories function to store learned information. Instead, when you want to remember something, ask if you could add it to the `CLAUDE.local.md` in the repo. For information that is globally relevant, ask to write it to the global `CLAUDE.md`.
+
+## Communication
+
+- Open with the substance of the answer, not with agreement or praise for the question.
+- When you got something wrong, state the correction in a sentence and move on.
+- No emojis.
+
+## Commands and System Interactions
+
+- Claude will likely always be running in a tmux session.
+- Claude is generally run from a sandbox and will not have permission to create new panes or send tmux commands.
+- I generally do not run shell commands in claude with the exclamation point syntax. Instead, commands are run in a separate tmux pane.
+
+## When writing code
+
+Before writing any code, stop at the first rung that holds:
+
+1. Does this need to be built at all? (YAGNI)
+2. Does it already exist in this codebase? Reuse the helper, util, or pattern that's already here, don't re-write it.
+3. Does the standard library already do this? Use it.
+4. Does a native platform feature cover it? Use it.
+5. Does an already-installed dependency solve it? Use it.
+6. Can this be one line? Make it one line.
+7. Only then: write the minimum code that works.
+
+The ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
+
+Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
+
+Rules:
+
+- No abstractions that weren't explicitly requested.
+- No new dependency if it can be avoided.
+- No boilerplate nobody asked for.
+- Deletion over addition. Boring over clever. Fewest files possible.
+- Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place is a second bug.
+- Question complex requests: "Do you actually need X, or does Y cover it?"
+- Pick the edge-case-correct option when two stdlib approaches are the same size.
+- Avoid over commenting. Comments in code should be added where they explain something non-obvious, or of high importance.
+
+The bias toward small diffs does not apply to these, which get full effort even when that makes the change larger: understanding the problem (read it fully and trace the real flow before picking a rung; a small diff you don't understand often lands in the wrong place), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Trivial one-liners need no test.
+
+## When writing markdown
+
+- Do not use hard line breaks in prose to meet a target column width. Long lines are okay and editors will soft wrap.
+  - The exception to this is git commits, which should shoot for 60 columns in the summary, and 80 columns in the body.
+
+## Finalizing
+
+- Never add yourself as a co-author when committing changes.
+
+## Sandbox artifacts in `git status` (not real files)
+
+Claude Code's Bash sandbox blocks reads of config files that could alter agent behavior. It enforces this by bind-mounting `/dev/null` over each path, so the masked entries show up in the repo root as **character devices** (`crw-rw-rw-`, device `1,3`, owned by `nobody`/65534, size 0) rather than regular files:
+
+    .bashrc  .zshrc  .bash_profile  .profile  .zprofile  .gitconfig .gitmodules  .ripgreprc  .mcp.json  .idea  .vscode .claude/{settings.json,skills,hooks,launch.json,routines,workflows,...}
+
+They are created at session start, so a repo that was clean can show a dozen untracked dotfiles a moment later. They contain nothing, they are not mine, and they vanish outside the sandbox. Nothing to delete or gitignore.
+
+**The one practical consequence:** `git add -A` and `git add .` don't just include noise — they **fail outright**:
+
+    error: .bash_profile: can only add regular files, symbolic links or git-directories
+    fatal: adding files failed
+
+Git refuses to stage a device node. So in a sandboxed session, stage by explicit path (`git add README.md docs/`) rather than `-A`/`.`. If `git add -A` fails with "can only add regular files", this is why — it is not repo corruption.

home/.config/nvim/lazy-lock.json

@@ -34,7 +34,6 @@
   "persistence.nvim": { "branch": "main", "commit": "b20b2a7887bd39c1a356980b45e03250f3dce49c" },
   "plenary.nvim": { "branch": "master", "commit": "74b06c6c75e4eeb3108ec01852001636d85a932b" },
   "render-markdown.nvim": { "branch": "main", "commit": "4663eb3ecd538bd5062628fb6d95bbe6bdca78f6" },
-  "sidekick.nvim": { "branch": "main", "commit": "208e1c5b8170c01fd1d07df0139322a76479b235" },
   "snacks.nvim": { "branch": "main", "commit": "882c996cf28183f4d63640de0b4c02ec886d01f2" },
   "todo-comments.nvim": { "branch": "main", "commit": "31e3c38ce9b29781e4422fc0322eb0a21f4e8668" },
   "tokyonight.nvim": { "branch": "main", "commit": "cdc07ac78467a233fd62c493de29a17e0cf2b2b6" },

home/.config/nvim/lazyvim.json

@@ -1,6 +1,5 @@
 {
   "extras": [
-    "lazyvim.plugins.extras.ai.sidekick",
     "lazyvim.plugins.extras.coding.mini-surround",
     "lazyvim.plugins.extras.editor.mini-diff",
     "lazyvim.plugins.extras.formatting.prettier",
@@ -8,7 +7,6 @@
     "lazyvim.plugins.extras.lang.go",
     "lazyvim.plugins.extras.lang.json",
     "lazyvim.plugins.extras.lang.markdown",
-    "lazyvim.plugins.extras.lang.svelte",
     "lazyvim.plugins.extras.lang.tailwind",
     "lazyvim.plugins.extras.lang.typescript",
     "lazyvim.plugins.extras.lang.yaml",
@@ -19,4 +17,4 @@
     "NEWS.md": "11866"
   },
   "version": 8
-}
+}