pondorasti 0.1.37 → 0.1.38

package/Brewfile

@@ -4,6 +4,7 @@ tap "anomalyco/tap"                        # Tap for opencode and related tools
 
 # Development Tools
 brew "lazygit"                            # Terminal UI for git commands - makes git operations visual and intuitive
+brew "git-lfs"                            # Git Large File Storage - manage large files in Git repositories efficiently
 brew "docker"                              # Docker CLI - command-line interface for interacting with Docker
 brew "colima"                              # Docker-compatible container runtime for macOS using Lima
 cask "orbstack"                            # Fast, lightweight Docker & Linux VM runtime for macOS
@@ -14,13 +15,16 @@ brew "tmux"                               # Terminal multiplexer - multiple term
 brew "pnpm"                               # Fast, disk space efficient package manager for Node.js
 brew "oven-sh/bun/bun"                    # Fast all-in-one JavaScript runtime, bundler, test runner, and package manager
 brew "node"                               # JavaScript runtime built on Chrome's V8 JavaScript engine
+brew "vite-plus"                          # Unified web development toolchain - provides vp
 brew "fnm"                                # Fast Node Manager - simple, fast Node.js version manager built in Rust
+brew "mise"                               # Polyglot runtime manager for Node.js, Ruby, and other development tools
 brew "rbenv"                              # Ruby version manager - simple, lightweight Ruby environment manager
 brew "stripe/stripe-cli/stripe"                             # Stripe CLI for testing and managing Stripe resources
 brew "supabase"                           # Supabase CLI for local development and deployment
 brew "flyctl"                             # Fly.io CLI for app deployment and infrastructure management
 brew "cloudflare-wrangler"                 # Cloudflare Wrangler CLI for Workers development and deployment
 brew "mysql"                              # Open source relational database management system
+brew "redis"                              # In-memory data store - caching, queues, pub/sub, and lightweight database use cases
 brew "anomalyco/tap/opencode"             # Open source code editor/IDE
 
 # System Monitoring
@@ -47,6 +51,7 @@ cask "zed"                                # High-performance code editor designe
 cask "claude"                             # Claude AI assistant desktop application
 cask "claude-code"                        # Claude AI coding assistant for the terminal
 cask "codex"                              # OpenAI's Codex CLI - coding agent that runs in your terminal
+cask "codex-app"                          # OpenAI's Codex desktop app for managing coding agents
 cask "opencode-desktop"                   # Desktop app for OpenCode AI coding assistant
 cask "android-studio"                     # Official IDE for Android app development
 cask "tableplus"                          # Modern, native database management tool
@@ -59,7 +64,7 @@ cask "851-labs/tap/gardenbridge"          # Drag and drop content between Mac an
 cask "1password"                          # Password manager and secure wallet
 cask "1password-cli"                      # 1Password CLI for scripting and automation
 cask "cleanshot"                          # Advanced screenshot and screen recording tool
-cask "linear-linear"                      # Modern project management and issue tracking for product teams
+cask "linear"                             # Modern project management and issue tracking for product teams
 cask "notion"                             # All-in-one workspace for notes, docs, and collaboration
 cask "notion-calendar"                    # Calendar app integrated with Notion
 

package/dotfiles/claude/settings.json

@@ -1,13 +1,11 @@
 {
-  "env": {
-    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
-  },
   "permissions": {
     "defaultMode": "dontAsk"
   },
-  "model": "opus",
   "enabledPlugins": {
     "swift-lsp@claude-plugins-official": true
   },
-  "skipDangerousModePermissionPrompt": true
+  "effortLevel": "high",
+  "skipDangerousModePermissionPrompt": true,
+  "fastMode": true
 }

package/dotfiles/git/.gitconfig

@@ -15,3 +15,8 @@
 [alias]
   autorebase = "!f() { git fetch origin $1 && git rebase origin/$1; }; f"
   bclean = "!f() { git branch --no-color | fzf -m | xargs -I {} git branch -D '{}'; }; f"
+[filter "lfs"]
+	clean = git-lfs clean -- %f
+	smudge = git-lfs smudge -- %f
+	process = git-lfs filter-process
+	required = true

package/dotfiles/zsh/.zshrc

@@ -141,3 +141,6 @@ alias oc='opencode'
 alias occ='opencode --continue'
 alias cc='claude --dangerously-skip-permissions'
 alias ccc='claude --dangerously-skip-permissions --continue'
+
+# Vite+ bin (https://viteplus.dev)
+. "$HOME/.vite-plus/env"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pondorasti",
-  "version": "0.1.37",
+  "version": "0.1.38",
   "description": "CLI for pondorasti",
   "author": "Alexandru Ţurcanu",
   "license": "MIT",

package/src/tools/dotfiles.ts

@@ -11,7 +11,6 @@ enum DotfilesPackage {
   Zsh = "zsh",
   Cursor = "cursor",
   Claude = "claude",
-  Agents = "agents",
   Nvim = "nvim",
   Opencode = "opencode",
 }
@@ -19,7 +18,6 @@ enum DotfilesPackage {
 const PACKAGE_TARGET_PATHS: Partial<Record<DotfilesPackage, string>> = {
   [DotfilesPackage.Cursor]: "~/Library/Application Support/Cursor/User",
   [DotfilesPackage.Claude]: "~/.claude",
-  [DotfilesPackage.Agents]: "~/.claude", // OpenCode also reads from ~/.claude/skills/
   [DotfilesPackage.Nvim]: "~/.config/nvim",
   [DotfilesPackage.Opencode]: "~/.config/opencode",
 }

package/dotfiles/agents/AGENTS.md

@@ -1,59 +0,0 @@
-# AGENTS.md
-
-pondorasti owns this.
-
-## Agent Protocol
-
-- Contact: Alexandru Turcanu, @pondorsti, [pondorasti@gmail.com](mailto:pondorasti@gmail.com)
-- Work style: telegraph; noun-phrases ok; drop grammar; min tokens.
-- Commits: Conventional Commits (`feat`, `fix`, `refactor`, `build`, `ci`, `chore`, `docs`, `style`, `perf`, `test`).
-- Use the system command `trash` for deletes
-- Remove human from the loop and prefer end-to-end verify; if blocked, say what’s missing.
-- Keep files <~500 LOC; split/refactor as needed.
-
-## Git
-
-- Safe by default: `git status/diff/log`.
-- Push only when the user asks.
-- Branch changes require user consent.
-- Don’t delete/rename unexpected stuff; stop + ask.
-- Destructive ops forbidden unless explicit (`reset --hard`, `clean`, `restore`, `rm`, `amend` etc).
-- If user types a command (“pull and push”), that’s consent for that command.
-
-## **macOS Permissions / Signing (TCC)**
-
-- Never re-sign / ad-hoc sign / change bundle ID as “debug” without explicit ok (can mess TCC).
-
-## **Critical Thinking**
-
-- Fix root cause (not band-aid).
-- Unsure: read more code; if still stuck, ask w/ short options.
-- Conflicts: call out; pick safer path.
-- Unrecognized changes: assume other agent; keep going; focus your changes. If it causes issues, stop + ask user.
-- Leave breadcrumb notes in thread.
-
-## Tools
-
-Leverage the help menu of each tool to learn how to use it.
-
-### gh
-
-GitHub CLI for PRs, CI, Releases.
-
-When someone shares a GitHub URL, use `gh` to read it:
-
-```jsx
-gh issue view <url> --comments
-gh pr view <url> --comments --files
-gh run list / gh run view <id>
-```
-
-### pd
-
-Personal CLI for pondorasti
-
-When you need to clone a repo, use `pd clone` to automatically clone the repo in the correct directory.
-
-### trash
-
-Move files to trash using the system command.

package/dotfiles/agents/skills/create-cli/SKILL.md

@@ -1,95 +0,0 @@
----
-name: create-cli
-description: >
-  Design command-line interface parameters and UX: arguments, flags, subcommands,
-  help text, output formats, error messages, exit codes, prompts, config/env
-  precedence, and safe/dry-run behavior. Use when you're designing a CLI spec
-  (before implementation) or refactoring an existing CLI's surface area for
-  consistency, composability, and discoverability.
-metadata:
-  author: steipete
----
-
-# Create CLI
-
-Design CLI surface area (syntax + behavior), human-first, script-friendly.
-
-## Do This First
-
-- Read `references/cli-guidelines.md` and apply it as the default rubric.
-- Upstream/full guidelines: https://clig.dev/ (propose changes: https://github.com/cli-guidelines/cli-guidelines)
-- Ask only the minimum clarifying questions needed to lock the interface.
-
-## Clarify (fast)
-
-Ask, then proceed with best-guess defaults if user is unsure:
-
-- Command name + one-sentence purpose.
-- Primary user: humans, scripts, or both.
-- Input sources: args vs stdin; files vs URLs; secrets (never via flags).
-- Output contract: human text, `--json`, `--plain`, exit codes.
-- Interactivity: prompts allowed? need `--no-input`? confirmations for destructive ops?
-- Config model: flags/env/config-file; precedence; XDG vs repo-local.
-- Platform/runtime constraints: macOS/Linux/Windows; single binary vs runtime.
-
-## Deliverables (what to output)
-
-When designing a CLI, produce a compact spec the user can implement:
-
-- Command tree + USAGE synopsis.
-- Args/flags table (types, defaults, required/optional, examples).
-- Subcommand semantics (what each does; idempotence; state changes).
-- Output rules: stdout vs stderr; TTY detection; `--json`/`--plain`; `--quiet`/`--verbose`.
-- Error + exit code map (top failure modes).
-- Safety rules: `--dry-run`, confirmations, `--force`, `--no-input`.
-- Config/env rules + precedence (flags > env > project config > user config > system).
-- Shell completion story (if relevant): install/discoverability; generation command or bundled scripts.
-- 5–10 example invocations (common flows; include piped/stdin examples).
-
-## Default Conventions (unless user says otherwise)
-
-- `-h/--help` always shows help and ignores other args.
-- `--version` prints version to stdout.
-- Primary data to stdout; diagnostics/errors to stderr.
-- Add `--json` for machine output; consider `--plain` for stable line-based text.
-- Prompts only when stdin is a TTY; `--no-input` disables prompts.
-- Destructive operations: interactive confirmation + non-interactive requires `--force` or explicit `--confirm=...`.
-- Respect `NO_COLOR`, `TERM=dumb`; provide `--no-color`.
-- Handle Ctrl-C: exit fast; bounded cleanup; be crash-only when possible.
-
-## Templates (copy into your answer)
-
-### CLI spec skeleton
-
-Fill these sections, drop anything irrelevant:
-
-1. **Name**: `mycmd`
-2. **One-liner**: `...`
-3. **USAGE**:
-   - `mycmd [global flags] <subcommand> [args]`
-4. **Subcommands**:
-   - `mycmd init ...`
-   - `mycmd run ...`
-5. **Global flags**:
-   - `-h, --help`
-   - `--version`
-   - `-q, --quiet` / `-v, --verbose` (define exactly)
-   - `--json` / `--plain` (if applicable)
-6. **I/O contract**:
-   - stdout:
-   - stderr:
-7. **Exit codes**:
-   - `0` success
-   - `1` generic failure
-   - `2` invalid usage (parse/validation)
-   - (add command-specific codes only when actually useful)
-8. **Env/config**:
-   - env vars:
-   - config file path + precedence:
-9. **Examples**:
-   - …
-
-## Notes
-
-- Prefer recommending a parsing library (language-specific) only when asked; otherwise keep this skill language-agnostic.
-- If the request is “design parameters”, do not drift into implementation.

package/dotfiles/agents/skills/create-cli/references/cli-guidelines.md

@@ -1,239 +0,0 @@
-# Command Line Interface Guidelines (condensed)
-
-Source + contribution:
-- Full guide: https://clig.dev/
-- Propose changes: https://github.com/cli-guidelines/cli-guidelines
-
-Table of contents:
-- Foreword
-- Introduction
-- Philosophy
-  - Human-first design
-  - Simple parts that work together
-  - Consistency across programs
-  - Saying (just) enough
-  - Ease of discovery
-  - Conversation as the norm
-  - Robustness
-  - Empathy
-  - Chaos
-- Guidelines
-  - The Basics
-  - Help
-  - Documentation
-  - Output
-  - Errors
-  - Arguments and flags
-  - Interactivity
-  - Subcommands
-  - Robustness
-  - Future-proofing
-  - Signals and control characters
-  - Configuration
-  - Environment variables
-  - Naming
-  - Distribution
-  - Analytics
-  - Further reading
-- Authors
-
-This is a practical rubric for designing CLI interfaces (args/flags/subcommands/help/output/errors/config). Keep humans first, but preserve composability and scriptability.
-
-## Foreword
-
-- CLI still uniquely powerful: inspect/control systems; works interactively and in automation.
-- Modern CLI = human-first text UI, not just a machine-first REPL veneer.
-- Goal: maximize utility + accessibility; design for humans and composition.
-
-## Introduction
-
-- This guide mixes philosophy + concrete rules; bias: examples over theorizing.
-- Out of scope: full-screen TUIs (vim/emacs-like).
-- Language/tooling agnostic: apply principles regardless of implementation stack.
-
-## Philosophy
-
-### Human-first design
-
-- Optimize for humans by default; scripts still work via stable modes (`--json`, `--plain`, exit codes).
-- Don’t leak developer-only output to normal users; reserve for verbose/debug.
-
-### Simple parts that work together
-
-- Assume your output becomes someone else’s input.
-- Respect stdio, exit codes, signals; keep primary output on stdout.
-- Prefer line-oriented plain text for piping; add JSON for structured needs.
-
-### Consistency across programs
-
-- Follow common conventions unless they harm usability.
-- Reuse standard flag names (`--help`, `--version`, `--json`, `--dry-run`, …).
-
-### Saying (just) enough
-
-- Too little: “hangs” with no feedback. Too much: noisy debug spew.
-- Make progress/status visible, but keep success output brief.
-
-### Ease of discovery
-
-- Help text is part of UX. Put examples first; suggest next commands.
-- When user errs, help them recover: point to the right syntax/flag.
-
-### Conversation as the norm
-
-- Expect trial-and-error loops. Design for repeated invocations.
-- Provide safe “dry run”/preview; show intermediate state; confirm scary actions.
-
-### Robustness
-
-- Be correct *and* feel robust: responsive, clear, no scary traces by default.
-- Handle bad input gracefully; validate early; clear errors.
-
-### Empathy
-
-- Be on the user’s side. Make success likely; make failure informative.
-- Character is fine; clutter is not.
-
-### Chaos
-
-- Terminal ecosystem inconsistent; follow norms, but break them intentionally when needed.
-- If you diverge, do it with clarity and document it.
-
-## Guidelines
-
-### The Basics
-
-- Use a real argument parsing library when possible (built-in or reputable OSS).
-- Exit codes: `0` on success, non-zero on failure; map a few important failure modes.
-- Stdout for primary output (and machine-readable output). Stderr for messages/logs/errors.
-
-### Help
-
-- Always support `-h`/`--help`. Do not overload `-h`.
-- If run with missing required args, show concise help + 1–2 examples + “use --help”.
-- Git-like CLIs: support `mycmd help`, `mycmd help subcmd`, `mycmd subcmd --help`.
-- Link to a support path (repo/issues/docs). Prefer deep links per subcommand (when you have web docs).
-- Lead with examples; show common flags/commands first; keep formatting readable without escape-char soup.
-
-### Documentation
-
-- Provide web docs (searchable, linkable).
-- Provide terminal docs (`mycmd help ...`); consider man pages where sensible.
-
-### Output
-
-- Humans first, machines second: detect TTY to choose formatting.
-- If fancy human output breaks parsing, offer `--plain` (stable, line-based) and/or `--json`.
-- On success: usually print *something*, but keep it brief; add `-q/--quiet` when useful.
-- If you change state, say what changed and what the new state is.
-- Suggest “next commands” in workflowy tools.
-- Use color sparingly; disable when not a TTY, `NO_COLOR` set, `TERM=dumb`, or `--no-color`.
-- No animations/progress bars when stdout isn’t a TTY.
-- Use a pager for long output only when interactive; common `less` opts: `-FIRX`.
-
-### Errors
-
-- Catch and rewrite expected errors for humans; avoid stack traces by default.
-- Keep signal-to-noise high; group repeated errors.
-- Put the most important info last; use red intentionally (don’t drown the user).
-- For unexpected crashes: provide a path to debug info + bug report instructions; write logs to a file if large.
-
-### Arguments and flags
-
-- Prefer flags over positional args for clarity and future flexibility.
-- Provide long versions of all flags; use one-letter flags only for the most common.
-- Multiple args ok for repeated simple items (`rm a b c`); avoid “2+ different positional concepts”.
-- Standard flag names (common set):
-  - `-h, --help` help
-  - `--version` version
-  - `-q, --quiet` less output
-  - `-v, --verbose` more output (avoid `-v` meaning version)
-  - `-d, --debug` debug output
-  - `-f, --force` skip confirmation / force
-  - `-n, --dry-run` preview only
-  - `--json` structured output
-  - `-o, --output <file>` output path
-  - `--no-input` disable prompts
-- Default should be right for most users (don’t rely on everyone aliasing a flag).
-- Support `-` for stdin/stdout when input/output is a file.
-- Avoid secrets in flags; prefer `--password-file` or stdin.
-- Prefer order independence for flags/subcommands where the parser allows.
-
-### Interactivity
-
-- Prompt only if stdin is a TTY.
-- `--no-input`: never prompt; if required input missing, fail with an actionable message.
-- Password prompts: disable echo.
-- Make escape hatch obvious (Ctrl-C, or explicit “press q”, etc).
-
-### Subcommands
-
-- Use subcommands for complexity; share global flags/config/help.
-- Be consistent across subcommands: naming, flags, output, formatting.
-- Consider noun-verb (`docker container create`) or verb-noun; pick one and stick to it.
-- Avoid ambiguous pairs (`update` vs `upgrade`) unless sharply differentiated.
-- Avoid implicit “catch-all” subcommands; don’t allow arbitrary abbreviations (future-proofing trap).
-
-### Robustness
-
-- Validate early; fail fast with good error messages.
-- Be responsive: print something in <100ms (especially before network I/O).
-- Show progress for long tasks (interactive only); don’t interleave logs confusingly.
-- Use timeouts for network calls; allow configuration.
-- Make reruns safe: idempotent where possible; recoverable; “crash-only” where feasible.
-
-### Future-proofing
-
-- Interfaces are contracts: args, flags, subcommands, config, env vars, output modes.
-- Keep changes additive; deprecate loudly + early; provide migration paths.
-- Allow human output to evolve; keep scripts stable by encouraging `--plain`/`--json`.
-
-### Signals and control characters
-
-- Ctrl-C: exit quickly; say something immediately; bound cleanup.
-- Second Ctrl-C: optionally force; tell user what it does.
-- Assume cleanup might not run; design for crash-only recovery.
-
-### Configuration
-
-- Pick the right mechanism:
-  - Per-invocation: flags (and sometimes env).
-  - Per-user/machine: flags + env; possibly config file.
-  - Per-project (checked in): config file in repo.
-- Follow XDG base directories for user-level config when applicable.
-- Precedence (high → low): flags > process env > project config > user config > system config.
-- Don’t silently modify other programs’ config; ask consent; prefer new files over editing existing ones.
-
-### Environment variables
-
-- Names: uppercase + digits + underscores; single-line values preferred.
-- Respect common vars when relevant: `NO_COLOR`, `DEBUG`, `EDITOR`, `PAGER`, proxy vars, `TERM`, `TMPDIR`, `HOME`, `COLUMNS/LINES`.
-- `.env` can be useful for per-project non-secret knobs; don’t use it as a full config system.
-- Don’t accept secrets via env vars by default; prefer files/pipes/sockets/secret managers.
-
-### Naming
-
-- Command name: simple, memorable, lowercase; avoid too-generic collisions.
-- Keep it short but not cryptic; easy to type matters.
-
-### Distribution
-
-- Prefer single binary when practical; otherwise use native packaging for uninstallability.
-- Make uninstall easy; include instructions.
-
-### Analytics
-
-- Never phone home without explicit consent; explain what/why/how/retention.
-- Prefer opt-in; if opt-out, make it obvious and easy to disable.
-- Consider alternatives: docs instrumentation, download metrics, talking to users.
-
-### Further reading
-
-- POSIX Utility Conventions
-- GNU Coding Standards (esp. flags/help conventions)
-- 12 Factor CLI Apps
-- Heroku CLI Style Guide
-
-## Authors
-
-Original “Command Line Interface Guidelines” authors (and many contributors): Aanand Prasad, Ben Firshman, Carl Tashian, Eva Parish. Design by Mark Hurrell.

package/dotfiles/agents/skills/learn/SKILL.md

@@ -1,45 +0,0 @@
----
-name: learn
-description: Extract non-obvious learnings from session to AGENTS.md files to build codebase understanding
-metadata:
-  author: R44VC0RP
----
-
-Analyze this session and extract non-obvious learnings to add to AGENTS.md files.
-
-AGENTS.md files can exist at any directory level, not just the project root. When an agent reads a file, any AGENTS.md in parent directories are automatically loaded into the context of the tool read. Place learnings as close to the relevant code as possible:
-
-- Project-wide learnings → root AGENTS.md
-- Package/module-specific → packages/foo/AGENTS.md
-- Feature-specific → src/auth/AGENTS.md
-
-What counts as a learning (non-obvious discoveries only):
-
-- Hidden relationships between files or modules
-- Execution paths that differ from how code appears
-- Non-obvious configuration, env vars, or flags
-- Debugging breakthroughs when error messages were misleading
-- API/tool quirks and workarounds
-- Build/test commands not in README
-- Architectural decisions and constraints
-- Files that must change together
-
-What NOT to include:
-
-- Obvious facts from documentation
-- Standard language/framework behavior
-- Things already in an AGENTS.md
-- Verbose explanations
-- Session-specific details
-
-Process:
-
-1. Review session for discoveries, errors that took multiple attempts, unexpected connections
-2. Determine scope - what directory does each learning apply to?
-3. Read existing AGENTS.md files at relevant levels
-4. Create or update AGENTS.md at the appropriate level
-5. Keep entries to 1-3 lines per insight
-
-After updating, summarize which AGENTS.md files were created/updated and how many learnings per file.
-
-$ARGUMENTS

package/dotfiles/agents/skills/ncu/SKILL.md

@@ -1,14 +0,0 @@
----
-name: ncu
-description: Update dependencies
-metadata:
-  author: pondorasti
----
-
-1. Use `bunx npm-check-updates -u` to bump all dependencies to latest (add the `-w` flag if inside a monorepo).
-2. Install new dependency versions using the appropriate package manager.
-3. Go through the changelog (or migration guide) of each updated dependency, and make code changes as needed.
-4. Make sure all checks pass (scripts like lint, format, test, etc)
-5. Commit, and push the changes to the remote repository.
-6. Use `gh api repos/{owner}/{repo}/commits/{ref}/check-runs` to verify all CI/CD checks pass. This works for both GitHub Actions workflows and external integrations (e.g., Cloudflare Workers Builds, Vercel, Netlify).
-7. Write a summary for the updated dependencies so I can learn about the changes, new features, and breaking changes.

package/dotfiles/agents/skills/swift-concurrency-expert/SKILL.md

@@ -1,39 +0,0 @@
----
-name: swift-concurrency-expert
-description: Swift Concurrency review and remediation for Swift 6.2+. Use when asked to review Swift Concurrency usage, improve concurrency compliance, or fix Swift concurrency compiler errors in a feature or file.
-metadata:
-  author: dimillian
----
-
-# Swift Concurrency Expert
-
-## Overview
-
-Review and fix Swift Concurrency issues in Swift 6.2+ codebases by applying actor isolation, Sendable safety, and modern concurrency patterns with minimal behavior changes.
-
-## Workflow
-
-### 1. Triage the issue
-
-- Capture the exact compiler diagnostics and the offending symbol(s).
-- Check project concurrency settings: Swift language version (6.2+), strict concurrency level, and whether approachable concurrency (default actor isolation / main-actor-by-default) is enabled.
-- Identify the current actor context (`@MainActor`, `actor`, `nonisolated`) and whether a default actor isolation mode is enabled.
-- Confirm whether the code is UI-bound or intended to run off the main actor.
-
-### 2. Apply the smallest safe fix
-
-Prefer edits that preserve existing behavior while satisfying data-race safety.
-
-Common fixes:
-- **UI-bound types**: annotate the type or relevant members with `@MainActor`.
-- **Protocol conformance on main actor types**: make the conformance isolated (e.g., `extension Foo: @MainActor SomeProtocol`).
-- **Global/static state**: protect with `@MainActor` or move into an actor.
-- **Background work**: move expensive work into a `@concurrent` async function on a `nonisolated` type or use an `actor` to guard mutable state.
-- **Sendable errors**: prefer immutable/value types; add `Sendable` conformance only when correct; avoid `@unchecked Sendable` unless you can prove thread safety.
-
-
-## Reference material
-
-- See `references/swift-6-2-concurrency.md` for Swift 6.2 changes, patterns, and examples.
-- See `references/approachable-concurrency.md` when the project is opted into approachable concurrency mode.
-- See `references/swiftui-concurrency-tour-wwdc.md` for SwiftUI-specific concurrency guidance.

package/dotfiles/agents/skills/swift-concurrency-expert/references/approachable-concurrency.md

@@ -1,63 +0,0 @@
-## Approachable Concurrency (Swift 6.2) - project mode quick guide
-
-Use this reference when the project has opted into the Swift 6.2 approachable
-concurrency settings (default actor isolation / main-actor-by-default).
-
-## Detect the mode
-
-Check Xcode build settings under "Swift Compiler - Concurrency":
-- Swift language version (must be 6.2+).
-- Default actor isolation / Main Actor by default.
-- Strict concurrency checking level (Complete/Targeted/Minimal).
-
-For SwiftPM, inspect Package.swift swiftSettings for the same flags.
-
-## Behavior changes to expect
-
-- Async functions stay on the caller's actor by default; they don't hop to a
-  global concurrent executor unless the implementation chooses to.
-- Main-actor-by-default reduces data race errors for UI-bound code and global
-  state, because mutable state is implicitly protected.
-- Protocol conformances can be isolated (e.g., `extension Foo: @MainActor Bar`).
-
-## How to apply fixes in this mode
-
-- Prefer minimal annotations; let main-actor-by-default do the work when the
-  code is UI-bound.
-- Use isolated conformances instead of forcing `nonisolated` workarounds.
-- Keep global or shared mutable state on the main actor unless there is a clear
-  performance need to offload it.
-
-## When to opt out or offload work
-
-- Use `@concurrent` on async functions that must run on the concurrent pool.
-- Make types or members `nonisolated` only when they are truly thread-safe and
-  used off the main actor.
-- Continue to respect Sendable boundaries when values cross actors or tasks.
-
-## Common pitfalls
-
-- `Task.detached` ignores inherited actor context; avoid it unless you truly
-  need to break isolation.
-- Main-actor-by-default can hide performance issues if CPU-heavy work stays on
-  the main actor; move that work into `@concurrent` async functions.
-
-## Keywords (from source cheat sheet)
-
-| Keyword | What it does |
-| --- | --- |
-| `async` | Function can pause |
-| `await` | Pause here until done |
-| `Task { }` | Start async work, inherits context |
-| `Task.detached { }` | Start async work, no inherited context |
-| `@MainActor` | Runs on main thread |
-| `actor` | Type with isolated mutable state |
-| `nonisolated` | Opts out of actor isolation |
-| `Sendable` | Safe to pass between isolation domains |
-| `@concurrent` | Always run on background (Swift 6.2+) |
-| `async let` | Start parallel work |
-| `TaskGroup` | Dynamic parallel work |
-
-## Source
-
-https://fuckingapproachableswiftconcurrency.com/en/