Add MCP servers and project skills for Athas development

Add project-level MCP configuration and skills to streamline development:

MCP Servers (.factory/mcp.json):
- GitHub: Full API access for repos, issues, PRs, actions
- Sequential Thinking: Structured step-by-step reasoning for debugging
- Playwright: Browser testing and automation
- Sentry: Error tracking and monitoring
- Linear: Issue tracking and project management

Skills (.factory/skills/):
- athas-bug-fix: Standardized bug diagnosis and fix workflow
- athas-performance: Performance bottleneck identification and optimization
- athas-release: Release process following project conventions
- athas-contribution: Contribution standards and commit conventions

Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>

Author: RajPabnani03

.factory/mcp.json

@@ -0,0 +1,31 @@
+{
+  "mcpServers": {
+    "github": {
+      "type": "http",
+      "url": "https://api.githubcopilot.com/mcp/",
+      "disabled": false
+    },
+    "sequential-thinking": {
+      "type": "stdio",
+      "command": "npx",
+      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"],
+      "disabled": false
+    },
+    "playwright": {
+      "type": "stdio",
+      "command": "npx",
+      "args": ["-y", "@playwright/mcp@latest"],
+      "disabled": false
+    },
+    "sentry": {
+      "type": "http",
+      "url": "https://mcp.sentry.dev/mcp",
+      "disabled": false
+    },
+    "linear": {
+      "type": "http",
+      "url": "https://mcp.linear.app/mcp",
+      "disabled": false
+    }
+  }
+}

.factory/skills/athas-bug-fix/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: athas-bug-fix
+description: Standardized workflow for diagnosing and fixing bugs in the Athas codebase. Use when the user mentions "bug", "fix", "issue", or references a GitHub issue number.
+---
+
+# Athas Bug Fix Workflow
+
+## Context
+
+Athas is a lightweight, cross-platform code editor built with Tauri (Rust backend + React/TypeScript frontend). The codebase has two distinct layers:
+
+- **Frontend** (`src/`): TypeScript/React using Zustand stores, Tauri plugin APIs, xterm.js
+- **Backend** (`src-tauri/`, `crates/`): Rust with Tauri commands, tokio async runtime
+
+## Instructions
+
+### 1. Understand the Bug
+
+- If a GitHub issue number is given, read the issue for reproduction steps and environment details
+- Identify which layer is affected: frontend (TypeScript), backend (Rust), or both
+- Check the issue labels for hints: `Linux`, `macOS`, `Native`, `Git`, `Workspaces`, etc.
+
+### 2. Locate Relevant Code
+
+- **Frontend bugs**: Search in `src/features/<feature>/` — each feature has its own directory with stores, components, and hooks
+- **Backend bugs**: Search in `crates/<crate>/src/` for the relevant Rust crate, or `src-tauri/src/commands/` for Tauri command handlers
+- Use `git log --oneline -- <path>` to see recent changes that may have introduced the bug
+- Check `git log --all --oneline --grep="<keyword>"` for prior fixes in the same area
+
+### 3. Trace the Root Cause
+
+- Follow the data flow from the user action to the bug symptom
+- For frontend bugs: trace from component → hook → store → Tauri invoke
+- For backend bugs: trace from Tauri command → crate function → system call
+- Look for race conditions (especially `void (async () => { ... })()` patterns), stale state, and missing cleanup
+- Check if the bug was introduced by a recent commit (use `git bisect` if needed)
+
+### 4. Implement the Fix
+
+- Match the existing code style: immer middleware for Zustand stores, Tauri command patterns in Rust
+- Preserve existing error handling patterns
+- Add comments explaining non-obvious fixes, referencing the issue number (e.g., `// Fix #581: ...`)
+- Do NOT add logging or debug statements unless the existing code already uses it
+
+### 5. Verify
+
+Run these checks before considering the fix complete:
+
+```bash
+# TypeScript type check (must pass)
+bun run typecheck
+
+# Lint changed files
+npx oxlint <changed-files>
+
+# Rust format check (for Rust changes)
+cargo rustfmt --check <changed-rust-files>
+```
+
+**Important**: Full `cargo check` requires glib >= 2.70 (Ubuntu 22.04+). If on an older system, verify Rust syntax manually and rely on CI for compilation.
+
+### 6. Cross-Verify
+
+Before finalizing, verify:
+- No removed imports are still used by other code
+- No callers of changed functions are broken
+- The fix doesn't introduce new race conditions
+- Terminal PTY lifecycle is respected (cleanup happens via React useEffect, not synchronously)
+
+## Key Codebase Conventions
+
+- State management: Zustand with immer middleware (`createWithEqualityFn`, `createSelectors`)
+- Async patterns: Background init uses `void (async () => { ... })()` — be careful of race conditions
+- Session persistence: `useSessionStore` with zustand/persist, terminal sessions in localStorage
+- GitHub CLI: Uses `gh` binary via `resolve_gh_binary()` with user shell PATH resolution
+- Performance: Avoid per-entry I/O in loops (stat syscalls, Tauri IPC); prefer lazy resolution

.factory/skills/athas-contribution/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: athas-contribution
+description: Ensure contributions follow the Athas project conventions. Use when the user mentions "contribute", "PR", "commit", or "pull request".
+---
+
+# Athas Contribution Workflow
+
+## Context
+
+Athas enforces contribution standards via:
+- **commitlint**: Conventional commit format enforced by pre-commit hooks
+- **AGENTS.md**: Project-specific rules and conventions for AI agents
+- **oxlint/oxfmt**: Linting and formatting (via vite-plus / vp check)
+- **TypeScript strict mode**: `tsc --noEmit` must pass with zero errors
+
+## Instructions
+
+### 1. Pre-Commit Checks
+
+Before committing, ensure:
+
+```bash
+# TypeScript type check (MUST pass)
+bun run typecheck
+
+# Lint and auto-fix
+bun run fix
+
+# Format check
+bun run format
+```
+
+If the full `bun check` fails due to Node.js version incompatibility (requires Node >= 22), run individual checks instead:
+
+```bash
+npx oxlint <changed-files>
+bun run typecheck
+cargo rustfmt --check <changed-rust-files>
+```
+
+### 2. Commit Message Format
+
+Follow the **conventional commit** format enforced by commitlint:
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+Co-authored-by: ...
+```
+
+**Types**: `feat`, `fix`, `chore`, `docs`, `style`, `refactor`, `perf`, `test`, `ci`
+
+**Examples**:
+- `fix: Resolve gh CLI auth detection on expired tokens`
+- `feat(git): Add workspace state persistence across folder switches`
+- `perf: Remove per-entry symlink resolution from directory listing`
+- `chore: Bump version to 0.4.5-alpha.9`
+
+### 3. PR Conventions
+
+- **One logical change per commit** — squash related tweaks into a single commit
+- **Rebase on master** before submitting: `git rebase origin/master`
+- **Title**: Imperative mood, concise (e.g., "Fix workspace switch race condition")
+- **Body**: Reference issue numbers, explain the "why" not the "what"
+- Include `Co-authored-by:` for AI-assisted commits
+
+### 4. AGENTS.md Rules
+
+Key rules from the project's AGENTS.md:
+- PR descriptions must follow the project format
+- JSDoc comments on utility functions
+- Don't add unnecessary comments — code should be self-documenting
+- Follow existing code style in the surrounding context
+
+### 5. Code Review Checklist
+
+Before marking a PR ready:
+- [ ] `tsc --noEmit` passes with zero errors
+- [ ] `oxlint` passes on changed files
+- [ ] No sensitive data (tokens, keys, passwords) in the diff
+- [ ] Commit messages follow conventional format
+- [ ] Changes are logically grouped (one concern per commit)
+- [ ] No regressions: removed imports not used elsewhere, changed signatures not breaking callers

.factory/skills/athas-performance/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: athas-performance
+description: Workflow for identifying and fixing performance bottlenecks in the Athas editor. Use when the user mentions "lag", "slow", "performance", "benchmark", "optimize", or "CachyOS".
+---
+
+# Athas Performance Optimization Workflow
+
+## Context
+
+Athas is a Tauri-based editor (Rust + React). Common performance bottlenecks:
+
+1. **File I/O overhead**: Per-entry stat syscalls, double file reads, large file loading
+2. **Tree-sitter parsing**: WASM initialization cost, grammar compilation
+3. **WebView rendering**: GPU compositing on Linux (webkit2gtk), DOM updates
+4. **Tauri IPC overhead**: Each `invoke()` call has serialization/deserialization cost
+
+## Instructions
+
+### 1. Identify the Bottleneck
+
+- Use `fileOpenBenchmark` marks in console to trace file-open timing
+- Use `frontendTrace` events to see workspace-open phase durations
+- Check if the issue is on first-open or subsequent interactions
+- Determine if it's I/O-bound (file reading, directory listing) or CPU-bound (parsing, rendering)
+
+### 2. Profile the Hot Path
+
+For **file opening** latency:
+- Check `readDirectoryContents()` — does it call `getSymlinkInfo()` per entry?
+- Check `handleFileSelect()` — is the file read twice (binary sniff + content read)?
+- Check `readFileContent()` vs `readFile()` from `@tauri-apps/plugin-fs`
+
+For **directory listing** latency:
+- Each `invoke("get_symlink_info")` is a stat syscall + IPC round-trip
+- `Promise.all()` masks individual latency but not total wall time
+- Large directories (1000+ entries) multiply per-entry costs
+
+For **rendering** latency:
+- Check if DMABUF renderer is disabled on Linux (`WEBKIT_DISABLE_DMABUF_RENDERER=1`)
+- Look for unnecessary re-renders in React components (missing memoization)
+- Check if virtualized lists are used for large collections
+
+### 3. Implement the Optimization
+
+Common patterns:
+
+- **Lazy resolution**: Defer expensive operations (like symlink resolution) to when data is actually needed, not during batch reads
+- **Single-pass I/O**: Read files once, decode in-memory. Use `TextDecoder` on `Uint8Array` instead of reading twice
+- **Batched IPC**: Minimize Tauri `invoke()` calls in loops; prefer single calls that return bulk data
+- **Virtualization**: Use `@tanstack/react-virtual` for large lists (already used for file tree and editor)
+- **Debounced saves**: Workspace session saves are already debounced via `workspace-session-save-queue.ts`
+
+### 4. Verify the Improvement
+
+```bash
+# TypeScript type check
+bun run typecheck
+
+# Lint
+npx oxlint <changed-files>
+```
+
+Compare benchmark marks before and after. Target:
+- Directory listing: < 100ms for typical projects (was 30-40s with per-entry stat)
+- File opening: < 250ms for typical files (warn threshold in benchmarks)
+- Tab switching: instant (no re-read needed for already-opened buffers)
+
+## Key Performance Files
+
+- `src/features/editor/utils/file-open-benchmark.ts` — Timing instrumentation
+- `src/utils/frontend-trace.ts` — Structured tracing
+- `src/features/file-system/controllers/file-operations.ts` — Directory reading
+- `src/features/file-system/controllers/store.ts` — File opening path
+- `src-tauri/src/main.rs` — Linux DMABUF renderer disable

.factory/skills/athas-release/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: athas-release
+description: Guide the release process following Athas's established conventions. Use when the user mentions "release", "publish", "version bump", or "tag".
+disable-model-invocation: true
+---
+
+# Athas Release Workflow
+
+## Context
+
+Athas uses a structured release process with:
+- **Version scheme**: Semver with alpha/beta/rc suffixes (e.g., `0.4.5-alpha.8`)
+- **Package manager**: Bun for JS, Cargo for Rust
+- **CI**: GitHub Actions for building cross-platform releases (Linux, macOS, Windows)
+- **Commitlint**: Enforces conventional commit messages
+
+## Instructions
+
+### 1. Pre-Release Check
+
+Run the validation script to ensure everything is ready:
+
+```bash
+bun release:check
+```
+
+This validates version consistency, changelog state, and build readiness.
+
+### 2. Choose the Release Type
+
+| Type | Command | Version Effect |
+|------|---------|---------------|
+| Patch | `bun release:patch` | 0.4.4 → 0.4.5 |
+| Minor | `bun release:minor` | 0.4.4 → 0.5.0 |
+| Major | `bun release:major` | 0.4.4 → 1.0.0 |
+| Alpha | `bun release:alpha` | 0.4.4 → 0.4.5-alpha.1 |
+| Beta | `bun release:beta` | 0.4.5-alpha.8 → 0.4.5-beta.1 |
+| RC | `bun release:rc` | 0.4.5-beta.1 → 0.4.5-rc.1 |
+
+### 3. Run the Release
+
+```bash
+# For a patch release
+bun release:patch
+
+# For an alpha pre-release
+bun release:alpha
+```
+
+The release script (`scripts/release.ts`) will:
+1. Bump the version in `package.json` and `src-tauri/tauri.conf.json`
+2. Update `Cargo.lock` if needed
+3. Create a git tag
+4. Push the tag to trigger the CI release workflow
+
+### 4. Verify the CI Build
+
+Check the GitHub Actions workflow:
+- Linux: `.deb`, `.rpm`, `.AppImage` builds
+- macOS: `.dmg` (aarch64)
+- Windows: `.exe` (arm64, x64)
+
+If the build fails, fix the issue and re-tag.
+
+### 5. Post-Release
+
+- Verify the release appears on https://github.com/athasdev/athas/releases
+- Check that all expected assets are attached
+- Announce in Discord if it's a stable release
+
+## Important Constraints
+
+- NEVER push directly to `master` without going through the release script
+- Alpha/beta releases are marked as prerelease on GitHub
+- The Windows MSI versioning has special handling (see `scripts/` directory)
+- Commit messages must pass commitlint: use conventional format like `feat:`, `fix:`, `chore:`