diff --git a/.claude/commands/cleanup.md b/.claude/commands/cleanup.md
new file mode 100644
index 0000000..1569b22
--- /dev/null
+++ b/.claude/commands/cleanup.md
@@ -0,0 +1,138 @@
+---
+name: cleanup
+description: Post-work cleanup — stale branches, orphaned worktrees, unclosed issues, stale labels
+allowed-tools: Bash, Read, Grep, Glob, Task
+---
+
+# /cleanup Skill
+
+Clean up stale branches, orphaned worktrees, unclosed issues, and stale labels after work is merged and deployed.
+
+## Usage
+
+```
+/cleanup              # Show report and clean interactively
+/cleanup --dry-run    # Show report only, no changes
+```
+
+## Workflow
+
+### Step 1: Ensure Labels Exist
+
+Create all lifecycle labels idempotently:
+
+```bash
+gh label create "priority:critical" --color "B60205" --description "Blocking other work" --force
+gh label create "priority:high" --color "D93F0B" --description "Important, should be next" --force
+gh label create "priority:medium" --color "FBCA04" --description "Standard priority" --force
+gh label create "priority:low" --color "0E8A16" --description "Nice to have" --force
+gh label create "in-progress" --color "6F42C1" --description "Actively being worked on" --force
+gh label create "ready-for-review" --color "0075CA" --description "PR submitted" --force
+gh label create "blocked" --color "9E9E9E" --description "Blocked by something" --force
+```
+
+### Step 2: Gather State (parallel)
+
+Launch parallel operations to collect cleanup candidates:
+
+**A — Stale local branches:**
+```bash
+git branch --list "issue-*"
+```
+For each branch, extract the issue number and check if the issue is CLOSED.
+
+**B — Stale remote branches:**
+```bash
+git fetch --prune origin
+git branch -r --list "origin/issue-*"
+```
+For each, check if there's a merged PR.
+
+**C — Orphaned worktrees:**
+```bash
+git worktree list --porcelain
+```
+For each worktree (not the main one), check if the branch still exists and if the associated issue is CLOSED. Worktree paths follow the pattern `../devsync-<N>-<description>`.
+
+**D — Issues with stale labels:**
+```bash
+gh issue list --label "in-progress" --state closed --json number,title
+gh issue list --label "ready-for-review" --state closed --json number,title
+```
+
+**E — Open issues with stale in-progress label:**
+```bash
+gh issue list --label "in-progress" --state open --json number,title
+```
+Check if a corresponding branch exists locally or remotely.
+
+### Step 3: Reconcile Merged PRs with Open Issues
+
+Find merged PRs whose closing issues are still OPEN:
+```bash
+gh pr list --state merged --limit 20 --json number,title,closingIssuesReferences
+```
+
+### Step 4: Display Report
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  🧹 Cleanup Report
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📋 Local Branches to Delete
+  issue-83-zed-tool-support        → #83 — Add Zed AI tool support (CLOSED)
+
+📋 Remote Branches to Prune
+  origin/issue-83-zed-tool-support → PR #100 — feat: zed tool support (merged)
+
+📋 Worktrees to Remove
+  ../devsync-83-zed-tool-support   → #83 — Add Zed AI tool support (CLOSED)
+
+📋 Issues to Close
+  #128 — Handle missing manifest    → merged via PR #135
+
+📋 Stale Labels to Remove
+  #91 — Install crash on empty lib  → remove `in-progress` (issue closed)
+
+────────────────────────────────────────────
+  📊 Summary: N branches, N worktrees, N issues, N labels
+────────────────────────────────────────────
+```
+
+### Step 5: Check for Dry Run
+
+If `--dry-run` was passed, stop here.
+
+### Step 6: Prompt for Action
+
+Options: Clean all / Pick categories / Abort
+
+### Step 7: Execute Cleanup
+
+For each approved category: delete branches, remove worktrees, close issues, clean labels.
+
+### Step 8: Post-Cleanup Report
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  ✅ Cleanup Complete
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  🔀 Branches deleted:  N local, N remote
+  📂 Worktrees removed: N
+  📋 Issues closed:     N
+  🏷️ Labels cleaned:    N
+
+────────────────────────────────────────────
+  👉 Next: /next to find your next task
+────────────────────────────────────────────
+```
+
+## Guidelines
+
+- Always show `#N — title` for issue references
+- Always show `PR #N — title` for PR references
+- Never delete branches or worktrees without user confirmation
+- Be careful with `git worktree remove --force` — only use when the worktree's branch is confirmed gone
+- If a worktree has uncommitted changes, warn the user and skip it
diff --git a/.claude/commands/code-review.md b/.claude/commands/code-review.md
new file mode 100644
index 0000000..f1df8f0
--- /dev/null
+++ b/.claude/commands/code-review.md
@@ -0,0 +1,163 @@
+---
+name: code-review
+description: Code review a pull request with security audit and test verification
+allowed-tools: Bash, Read, Edit, Grep, Glob, Task, WebFetch
+---
+
+# /code-review Skill
+
+Review a pull request for bugs, security issues, CLAUDE.md compliance, and test results.
+
+## Usage
+
+```
+/code-review 85        # Review PR #85
+/code-review           # Review PR for current branch
+```
+
+## Workflow
+
+### Step 1: Resolve PR Number
+
+If a PR number is provided as an argument, use it. Otherwise, detect the PR for the current branch:
+```bash
+gh pr view --json number --jq '.number'
+```
+
+### Step 2: Eligibility and Context Detection
+
+Check if the PR is eligible for review:
+```bash
+gh pr view <PR> --json state,isDraft,author,title,body,reviews
+gh api repos/{owner}/{repo}/issues/<PR>/comments --jq '.[].body'
+```
+
+Do NOT proceed if: PR is closed/merged, is a draft, is automated, or already has a code review comment.
+
+**Submit-PR detection:** Check if a `/submit-pr` validation comment exists. If found, set `submit_pr_ran = true`.
+
+### Step 2b: PR Size Check
+
+```bash
+gh pr diff <PR> --stat | tail -1
+```
+If under 300 lines, set `small_pr = true`.
+
+### Step 3: Gather Context (parallel Haiku agents)
+
+**Agent A — CLAUDE.md paths:** Find all relevant CLAUDE.md files.
+
+**Agent B — PR summary:** Run `gh pr view <PR>` and `gh pr diff <PR>`. Return summary.
+
+**Agent C — Run unit tests:** Run `pytest tests/unit/ -v --tb=short 2>&1 | tail -80` or `invoke test-unit`.
+
+### Step 4: Deep Review (conditional parallel agents)
+
+| Condition | Agents to run |
+|-----------|--------------|
+| `submit_pr_ran = true` | #2 Bug scan, #4 Historical context, #5 Code comments |
+| `small_pr = true` AND standalone | #2 Bug scan, #3 Security, #4 Historical context |
+| Standalone, large PR | All 7 agents |
+
+**Bug scan (#2) ALWAYS runs.**
+
+**IMPORTANT:** Report ONLY failures. Do not report PASS or N/A items. Keep response under 500 words.
+
+---
+
+**Agent #1 — CLAUDE.md compliance (Sonnet):** *(skipped when `submit_pr_ran`)*
+
+- [ ] New modules follow existing naming conventions
+- [ ] New AI tools follow `AITool` base class pattern
+- [ ] New CLI commands use Typer patterns
+- [ ] No hardcoded paths or credentials
+- [ ] Commits follow `type(scope): description (#issue)`
+- [ ] No Co-Authored-By or Claude attribution lines
+
+---
+
+**Agent #2 — Bug scan (Sonnet):** *(ALWAYS runs)*
+
+- [ ] **Return values**: Unchecked None returns?
+- [ ] **Off-by-one**: Loop bounds, slice indices
+- [ ] **Type mismatches**: Wrong types in YAML parsing, dict access
+- [ ] **Null/empty handling**: Empty lists, missing dict keys, blank strings
+- [ ] **Resource leaks**: Files/connections not closed? Missing `with`?
+- [ ] **Exception handling**: Too broad? Swallowed silently?
+- [ ] **String formatting**: Command concatenation with user input?
+- [ ] **Import errors**: Missing or circular imports?
+- [ ] **Logic inversion**: Negated conditions, `and`/`or` confusion?
+- [ ] **Path handling**: Platform-specific paths? Unsanitized joins?
+
+---
+
+**Agent #3 — Security audit (Sonnet):** *(skipped when `submit_pr_ran`)*
+
+- [ ] **Command injection**: `subprocess` with `shell=True` + user input?
+- [ ] **Path traversal**: File ops with unsanitized `..`?
+- [ ] **Hardcoded secrets**: API keys/passwords/tokens in source?
+- [ ] **Insecure defaults**: Debug mode, disabled checks?
+- [ ] **Input validation**: User input not validated?
+- [ ] **Unsafe deserialization**: `pickle.loads`, `yaml.load()` without SafeLoader, `eval()`, `exec()`?
+- [ ] **Credential safety**: Credentials stored in manifests or JSON trackers?
+- [ ] **Git URL safety**: Credentials embedded in repo URLs?
+
+---
+
+**Agent #4 — Historical context (Haiku):** *(ALWAYS runs)*
+
+Maximum 15 tool calls. Check:
+- [ ] **Reverted fixes**: Does this undo a previous fix?
+- [ ] **Recurring patterns**: Similar bugs in this file before?
+- [ ] **TODO/FIXME regression**: TODOs addressed or ignored?
+- [ ] **Breaking assumptions**: Violated documented assumptions?
+
+---
+
+**Agent #5 — Code comments and intent (Sonnet):** *(ALWAYS runs)*
+
+- [ ] **Invariant violations**: "must be called after X" / "never modify without Y" — violated?
+- [ ] **TODO completion**: TODOs this change should address but didn't?
+- [ ] **Warning heeds**: `# WARNING:` / `# IMPORTANT:` — complied with?
+- [ ] **Docstring accuracy**: Modified functions still match their docstrings?
+
+---
+
+**Agent #6 — Vision and scope alignment (Haiku):** *(skipped when `submit_pr_ran`)*
+
+- [ ] Not an IDE / cloud service / code generator / plugin framework / package registry / config burden
+- [ ] New dependencies justified
+- [ ] New config options have sensible defaults
+- [ ] Lean: could this be simpler?
+
+---
+
+**Agent #7 — Documentation freshness (Haiku):** *(skipped when `submit_pr_ran`)*
+
+- [ ] New modules not in CLAUDE.md?
+- [ ] Modified modules with stale CLAUDE.md descriptions?
+- [ ] New CLI commands/flags missing from README?
+
+### Step 5: Confidence Scoring (parallel Haiku agents)
+
+For each FAIL item, independently verify and score confidence (0-100).
+
+### Step 6: Filter
+
+Keep only issues scoring 80+.
+
+### Step 7-10: Report, Post Comment, Summary
+
+Display local report, post condensed version as PR comment, show final summary.
+
+### Link Format
+
+```
+https://github.com/troylar/devsync/blob/<full-40-char-sha>/path/to/file.py#L10-L15
+```
+
+## Notes
+
+- Do NOT run builds or typechecks — CI handles those separately
+- Use `gh` for all GitHub interactions
+- Cite and link every issue
diff --git a/.claude/commands/commit.md b/.claude/commands/commit.md
new file mode 100644
index 0000000..10ff1cb
--- /dev/null
+++ b/.claude/commands/commit.md
@@ -0,0 +1,168 @@
+---
+name: commit
+description: Create a well-formatted commit with enforced conventions
+allowed-tools: Bash, Read, Grep, Glob
+---
+
+# /commit Skill
+
+Create a commit that follows this project's conventions. Validates format, issue references, and test status before committing.
+
+## Usage
+
+```
+/commit                              # Auto-detect type, scope, and message from changes
+/commit fix(core): handle empty manifest gracefully (#91)
+/commit --amend                      # Amend the last commit (use sparingly)
+```
+
+If a message is provided, validate and use it. If no message is provided, generate one from the staged/unstaged changes.
+
+## Workflow
+
+### Step 1: Assess Changes
+
+Run in parallel:
+```bash
+git status --short
+git diff --cached --stat
+git diff --stat
+```
+
+- If nothing is staged and nothing is modified, abort: "Nothing to commit."
+- If nothing is staged but files are modified, show the modified files and ask what to stage.
+
+### Step 2: Determine the Issue Number
+
+The current branch should be named `issue-<N>-...`. Extract the issue number:
+```bash
+git branch --show-current
+```
+
+If the branch name doesn't contain an issue number:
+1. Check recent commits for an issue reference
+2. If still not found, ask the user: "Which GitHub issue does this commit relate to?"
+
+Verify the issue exists:
+```bash
+gh issue view <N> --json state,title --jq '"\(.state): \(.title)"' 2>&1
+```
+
+### Step 3: Generate or Validate Message
+
+**If a message was provided:** Validate it matches `type(scope): description (#N)`:
+- Correct type (feat/fix/docs/refactor/test/chore)
+- Scope matches a known module (cli, core, storage, ai_tools, tui, utils)
+- Issue reference present and matches the branch issue
+- Description is lowercase, imperative, no trailing period
+
+If validation fails, show what's wrong and suggest a corrected version.
+
+**If no message was provided:** Generate one:
+1. Analyze the diff to determine:
+   - **type**: new files/functions -> `feat`, bug fix -> `fix`, tests only -> `test`, docs only -> `docs`, restructuring -> `refactor`, everything else -> `chore`
+   - **scope**: primary module being changed (by file count or significance)
+   - **description**: concise summary of what changed, imperative mood
+2. Draft: `type(scope): description (#N)`
+
+### Step 4: Stage Files
+
+If files aren't staged yet:
+1. Show the list of modified/untracked files
+2. Stage the relevant files (not `.env`, credentials, or large binaries):
+   ```bash
+   git add <specific files>
+   ```
+3. Never use `git add -A` or `git add .` — always add specific files
+
+### Step 5: Pre-commit Checks
+
+Get the list of staged Python files first:
+```bash
+git diff --cached --name-only --diff-filter=ACMR -- '*.py'
+```
+
+Run checks scoped to staged files:
+```bash
+ruff check <staged files> 2>&1 | tail -20
+black --check <staged files> 2>&1 | tail -20
+```
+
+Run tests:
+```bash
+pytest tests/unit/ -x -q 2>&1 | tail -20
+```
+
+- If lint fails: auto-fix with `ruff check --fix <staged files>`, then re-stage only those files
+- If format fails: auto-fix with `black <staged files>`, re-stage only those files, continue
+- If tests fail: abort and show failures. Do not commit with failing tests.
+- Never auto-fix or re-stage files that aren't already staged
+
+### Step 5b: Complexity Check
+
+Scan the staged diff for vision-relevant changes:
+
+1. **New dependencies**: Check if `pyproject.toml` is staged and has new entries in `dependencies` or `dev` dependencies. If so, note them.
+2. **New config options**: Check if config-related files are staged with new user-facing settings. Flag if a default would suffice.
+3. **New infrastructure**: Check for Docker files, external service integrations, or daemon-like patterns.
+
+If any are found, report them briefly:
+```
+  [WARN] New dependency: <package> — is this justified?
+  [WARN] New config option: <option> — could a default work?
+```
+
+This is informational, not blocking — but the warnings should prompt the developer to reconsider if the addition is necessary.
+
+### Step 6: Commit
+
+**IMPORTANT:** Do NOT include any Co-Authored-By line or Claude attribution.
+
+```bash
+git commit -m "type(scope): description (#N)"
+```
+
+### Step 7: Report
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  ✅ Committed
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  💬 Message:  type(scope): description (#N)
+  🔑 SHA:      <short sha>
+  📁 Files:    <N> changed, <N> insertions(+), <N> deletions(-)
+  🔗 Issue:    #<N> — <issue title>
+
+  🧪 Checks:   ✅ lint, format, tests (<N> passed)
+  ⚠️ Warnings: <any complexity warnings, or "none">
+
+────────────────────────────────────────────
+  👉 Next: <context-aware suggestion>
+────────────────────────────────────────────
+```
+
+To determine the next step suggestion, check for an existing PR:
+```bash
+gh pr list --head "$(git branch --show-current)" --json number,url --jq '.[0]' 2>/dev/null
+```
+
+- **If a PR exists**: `👉 Next: push to update PR #<N>, or continue working`
+- **If no PR exists**: `👉 Next: /submit-pr when ready, or continue working`
+
+## Amend Mode
+
+If `--amend` is passed:
+1. Show the current HEAD commit message and changes
+2. Confirm with the user before amending
+3. Use `git commit --amend` instead of `git commit`
+4. Warn if the commit has already been pushed
+
+## Guidelines
+
+- Never commit without a passing test suite
+- Never commit secrets, `.env` files, or credentials
+- Never use `git add -A` or `git add .`
+- Never include Co-Authored-By or Claude attribution lines
+- If in doubt about the scope, prefer the more specific module name
+- One logical change per commit — if the staged changes span unrelated work, suggest splitting into multiple commits
diff --git a/.claude/commands/deploy.md b/.claude/commands/deploy.md
new file mode 100644
index 0000000..3cfc94f
--- /dev/null
+++ b/.claude/commands/deploy.md
@@ -0,0 +1,238 @@
+---
+name: deploy
+description: Merge PR, verify CI, bump version, and publish via GitHub Actions
+allowed-tools: Bash, Read, Edit, Grep, Glob, WebFetch
+---
+
+# /deploy Skill
+
+Deploy the current branch by merging the PR, bumping the version, and triggering automated PyPI publishing via GitHub Actions.
+
+## Usage
+
+```
+/deploy              # auto-detect PR and version bump
+/deploy patch        # force patch bump
+/deploy minor        # force minor bump
+/deploy major        # force major bump
+```
+
+## Workflow
+
+### Step 1: Pre-flight Checks
+
+1. Confirm we're on a feature branch (not main)
+2. Find the open PR for this branch: `gh pr view --json number,title,state,mergeable`
+3. If no PR exists, abort with message
+4. Show the PR title and number, confirm with user before proceeding
+5. **Verify every commit references a GitHub issue.** Run:
+   ```bash
+   gh pr view --json commits --jq '.commits[].messageHeadline'
+   ```
+   Every commit message MUST contain a `(#NNN)` issue reference. If any commit is missing one, warn the user and ask them to fix it before proceeding.
+
+### Step 1b: PR Queue Context
+
+Show the user all other open PRs:
+
+```bash
+gh pr list --state open --json number,title,headRefName,mergeable --jq '.[] | "\(.number)\t\(.mergeable)\t\(.title)"'
+```
+
+### Step 2: Quick Documentation Check
+
+Run a lightweight staleness check:
+
+1. **New modules** — check for any new `.py` files under `devsync/` not documented in CLAUDE.md. Flag if any are missing.
+2. **Version** — note the pre-bump version in `pyproject.toml` for reference.
+
+If updates are needed, commit them before merging:
+```bash
+git add CLAUDE.md
+git commit -m "docs: update CLAUDE.md for vX.Y.Z release (#<primary issue>)"
+git push
+```
+
+### Step 3: Rebase, Validate Freshness, and Merge
+
+#### 3a. Check if main has moved
+
+```bash
+git fetch origin main
+MERGE_BASE=$(git merge-base HEAD origin/main)
+MAIN_HEAD=$(git rev-parse origin/main)
+```
+
+Report whether main is unchanged or has moved since branch was based.
+
+#### 3b. Rebase
+
+```bash
+git rebase origin/main
+git push --force-with-lease
+```
+
+#### 3c. Wait for CI
+
+If main had moved, wait for CI to re-run. Poll every 15 seconds, up to 10 minutes:
+```bash
+gh pr checks <PR> --json name,state
+```
+
+#### 3d. Evaluate check results
+
+- **All checks pass**: proceed to merge
+- **Only non-required checks fail**: proceed with `--admin` — log which checks were bypassed
+- **Required checks fail** (tests, lint): abort and show failure URL
+
+#### 3e. Merge (worktree-aware)
+
+```bash
+gh pr merge <PR> --squash
+```
+
+Clean up worktree and branch if running from a worktree:
+```bash
+WORKTREE_PATH=$(git rev-parse --show-toplevel)
+MAIN_WORKTREE=$(git worktree list --porcelain | grep -A0 'worktree ' | head -1 | sed 's/worktree //')
+if [ "$WORKTREE_PATH" != "$MAIN_WORKTREE" ]; then
+    BRANCH=$(git branch --show-current)
+    cd "$MAIN_WORKTREE"
+    git worktree remove "$WORKTREE_PATH"
+    git branch -d "$BRANCH" 2>/dev/null || true
+fi
+```
+
+Pull merged changes:
+```bash
+cd <main worktree path>
+git checkout main && git pull
+```
+
+### Step 3f: Post-Merge Queue Check
+
+Check whether other open PRs are affected by this merge.
+
+### Step 4: Determine Version Bump
+
+Read `pyproject.toml` to get current version.
+
+If the user passed a bump level (patch/minor/major), use that.
+
+Otherwise, determine from the merged PR:
+- `feat:` or new files added -> **minor**
+- `fix:`, `docs:`, `chore:`, `refactor:`, `test:` -> **patch**
+- `BREAKING CHANGE` or `!:` in any commit -> **major**
+
+### Step 5: Run Pre-Release Checks
+
+```bash
+invoke release-check
+```
+
+This runs clean, quality, and test. If it fails, abort.
+
+### Step 6: Update Version and CHANGELOG
+
+1. Bump version in `pyproject.toml`
+2. Update `CHANGELOG.md` with changes since last release:
+   ```bash
+   git log <PREVIOUS_TAG>..HEAD --oneline
+   ```
+3. Commit:
+   ```bash
+   git add pyproject.toml CHANGELOG.md
+   git commit -m "chore: bump version to X.Y.Z"
+   ```
+4. Tag:
+   ```bash
+   git tag -a vX.Y.Z -m "Release version X.Y.Z"
+   ```
+5. Push:
+   ```bash
+   git push origin main --tags --no-verify
+   ```
+
+Note: `--no-verify` bypasses the pre-push hook that blocks direct pushes to main. This is intentional for the deploy skill.
+
+### Step 7: Create GitHub Release (Triggers Automated Publishing)
+
+Generate release notes from the PR and all referenced issues.
+
+```bash
+gh release create vX.Y.Z --title "vX.Y.Z" --notes "<generated notes>"
+```
+
+**What happens next:** The `.github/workflows/publish.yml` workflow will automatically:
+1. Run quality checks and tests
+2. Build the package
+3. Publish to PyPI using trusted publishing
+
+### Step 7b: Clean Up Issue Labels
+
+For each issue closed by the merged PR, remove workflow labels:
+```bash
+gh issue edit <N> --remove-label "in-progress" --remove-label "ready-for-review"
+```
+
+### Step 7c: Suggest Cleanup
+
+Check for stale local branches and suggest `/cleanup` if any exist.
+
+### Step 8: Monitor and Verify
+
+```bash
+gh run watch
+```
+
+Wait for the workflow to complete, then verify:
+```bash
+pip install --upgrade devsync
+devsync --version
+```
+
+## Error Handling
+
+- If merge fails: show error, do not proceed
+- If CI fails: show failure URL, do not proceed
+- If release-check fails: show error, do not proceed
+- If GitHub Actions publish fails: the tag and version commit are already pushed; show error and link to workflow run
+- Never force-push or amend commits on main
+- If commits are missing issue references: warn, do not proceed until fixed
+
+## Output
+
+On success:
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  📦 Deployed devsync vX.Y.Z
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  🔗 PR:       #NN (merged)
+  🧪 CI:       ✅ passed
+  🔄 Freshness: ✅ CI ran against current main / ⚠️ rebased and re-validated
+  📖 Docs:     ✅ up to date / ⚠️ N updates committed
+  📦 PyPI:     https://pypi.org/project/devsync/X.Y.Z/
+  🏷️ Tag:      vX.Y.Z
+  🏷️ Release:  https://github.com/troylar/devsync/releases/tag/vX.Y.Z
+  📊 Version:  X.Y.Z-1 → X.Y.Z (<type> bump)
+  📋 Queue:    N open PRs remaining (N mergeable, N conflicting)
+
+────────────────────────────────────────────
+  ✅ Deploy complete
+────────────────────────────────────────────
+```
+
+On failure:
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  ❌ Deploy Failed
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Step:    <which step failed>
+  Error:   <error message>
+
+────────────────────────────────────────────
+  👉 Next: <what to do to fix it>
+────────────────────────────────────────────
+```
diff --git a/.claude/commands/dev-help.md b/.claude/commands/dev-help.md
new file mode 100644
index 0000000..fb474c0
--- /dev/null
+++ b/.claude/commands/dev-help.md
@@ -0,0 +1,228 @@
+---
+name: dev-help
+description: Show the developer workflow guide with all available skills and conventions
+allowed-tools: Bash, Read, Grep, Glob
+---
+
+# /dev-help Skill
+
+Display a comprehensive, visually formatted guide to DevSync's developer workflow for experienced developers who are new to the project's command structure.
+
+## Workflow
+
+### Step 1: Gather Context
+
+Read the following to ensure the help is accurate:
+1. List all skill files: `ls .claude/commands/`
+2. Read `VISION.md` for the project tagline and core principles
+3. Read the branch name: `git branch --show-current`
+4. Check for open issues: `gh issue list --limit 5 --json number,title,state`
+
+### Step 2: Display the Guide
+
+Print the following formatted guide:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  📦 DevSync Developer Guide
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  DevSync distributes AI coding assistant configs across
+  teams. pip install devsync — that's the whole pitch.
+
+  📖 Read VISION.md for the full product vision.
+  📖 Read CLAUDE.md for architecture and conventions.
+
+
+🔄 Development Lifecycle
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  The workflow follows this order:
+
+  📋 Prioritize    →  /next
+  🏷️ Triage        →  /triage <issue#> <priority>
+  💭 Explore idea  →  /ideate
+  💡 Create issue  →  /new-issue
+  🚀 Start coding  →  /start-work <issue#>
+  💾 Save work     →  /commit
+  📤 Submit + review → /submit-pr  (auto-runs /code-review)
+  🔍 Review others →  /code-review <pr#>
+  📦 Ship          →  /deploy
+  🧹 Clean up      →  /cleanup
+
+
+📋 Skills Reference
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  /ideate <rough idea>
+    Explore a feature idea before committing to an issue.
+    Checks vision, feasibility, and alternatives.
+    Presents lean vs. full approaches for discussion.
+    No issue created until you're ready.
+
+  /new-issue <description>
+    Turn a refined idea into a structured GitHub issue.
+    Checks vision alignment before creating.
+    Warns if the idea conflicts with product identity.
+
+  /start-work <issue#> [--no-worktree]
+    Create a worktree + branch, explore code, plan implementation.
+    Worktree is the default — keeps your current branch clean.
+    Use --no-worktree for a traditional branch instead.
+    Runs 3 parallel agents for deep code exploration.
+
+  /commit
+    Stage, validate, and commit with enforced conventions.
+    Auto-detects type/scope from changes.
+    Runs lint + format + tests on staged files only.
+    Format: type(scope): description (#issue)
+    No co-author attribution lines.
+
+  /submit-pr [--draft] [--checks-only] [--skip-checks]
+    Full validation suite + PR creation + auto code review.
+    Runs 5 parallel agents: test thoroughness,
+    CLAUDE.md compliance, docs freshness, vision, security.
+    After creating the PR, automatically runs /code-review.
+    If issues found, offers to fix and re-review (max 2 rounds).
+
+  /pr-check --pr <N>
+    Validate someone else's PR in a temp worktree.
+    Same checks as /submit-pr but read-only.
+
+  /code-review [<pr#>]
+    Deep review with up to 7 parallel agents using
+    structured checklists (not open-ended scanning).
+    Posts condensed results as a PR comment.
+
+  /next [--all] [--area <area>]
+    Prioritized work queue sorted by priority labels.
+    Groups issues by VISION.md direction areas.
+    Recommends next item with rationale.
+
+  /triage <issue#> <priority> | --reassess
+    Set priority on a single issue (critical/high/medium/low).
+    --reassess: AI evaluates all open issues against VISION.md.
+    Optionally updates ROADMAP.md.
+
+  /cleanup [--dry-run]
+    Post-work cleanup: stale branches, orphaned worktrees,
+    unclosed issues, stale labels.
+
+  /deploy [patch|minor|major]
+    Merge PR, wait for CI, bump version, update CHANGELOG,
+    create GitHub release (triggers automated PyPI publish).
+
+  /write-docs <page-path>
+    Write or update documentation pages.
+    Cross-references source code for accuracy.
+
+
+⚡ Rules (always active)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  These rules are enforced automatically in every session:
+
+  📌 No code without a GitHub issue
+     Every change must reference an issue. No exceptions.
+
+  📌 Commit format: type(scope): description (#issue)
+     No co-author attribution. Issue reference required.
+
+  📌 Tests required for new code
+     New modules need test files. Bug fixes need
+     regression tests.
+
+  📌 Security patterns
+     Safe file operations, credential handling, input
+     validation, no hardcoded secrets, no eval/exec.
+
+  📌 Vision alignment
+     Features are checked against VISION.md principles.
+     "What DevSync Is Not" guardrails flag scope drift.
+
+  📌 Consistent output formatting
+     All skills use emoji + box-drawing for reports.
+
+
+🎯 Vision Quick Reference
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Core principles:
+    1. Zero-friction distribution (pip install && go)
+    2. IDE-agnostic (8+ tools, one format)
+    3. Git as distribution (no central server)
+    4. Lean CLI (no daemons, no services)
+    5. Credential safety (never in repos)
+    6. Standards-first (MCP, markdown, YAML)
+
+  What DevSync is NOT:
+    ❌ An IDE                ❌ A cloud service
+    ❌ A code generator      ❌ A plugin framework
+    ❌ A package registry    ❌ A config burden
+
+
+🛠️ Common Workflows
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Explore an idea:
+    /ideate version constraints for packages
+
+  Start a new feature:
+    /new-issue add Zed AI tool support
+    /start-work 92
+
+  Save progress:
+    /commit
+
+  Ready to submit (includes auto code review):
+    /submit-pr
+
+  Review a teammate's PR:
+    /pr-check --pr 86
+    /code-review 86
+
+  Ship a release:
+    /deploy
+
+  Find your next task:
+    /next
+
+  Triage after a sprint:
+    /triage --reassess
+
+  Post-deploy cleanup:
+    /cleanup
+
+
+📂 Project Structure
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  devsync/
+  ├── ai_tools/           # AI tool integrations
+  │   ├── base.py        # AITool abstract base class
+  │   ├── claude.py      # Claude Code integration
+  │   ├── cursor.py      # Cursor integration
+  │   └── detector.py    # Tool detection logic
+  ├── cli/                # Typer CLI commands
+  │   ├── main.py        # CLI app definition
+  │   ├── install.py     # Install command
+  │   └── package.py     # Package management
+  ├── core/               # Core business logic
+  │   ├── models.py      # Data models
+  │   └── repository.py  # Manifest parsing
+  ├── storage/            # Data persistence
+  │   ├── library.py     # Library manager
+  │   └── tracker.py     # Installation tracker
+  ├── tui/                # Terminal UI
+  │   └── installer.py   # Interactive browser
+  └── utils/              # Utilities
+
+  tests/unit/             # Fully mocked unit tests
+  tests/integration/      # Real file I/O + Git tests
+
+
+────────────────────────────────────────────────────────────
+  💡 Tip: Run any skill with no arguments for usage help.
+  📖 Full details: VISION.md, CLAUDE.md
+────────────────────────────────────────────────────────────
+```
diff --git a/.claude/commands/ideate.md b/.claude/commands/ideate.md
new file mode 100644
index 0000000..32bcaf5
--- /dev/null
+++ b/.claude/commands/ideate.md
@@ -0,0 +1,148 @@
+---
+name: ideate
+description: Explore and refine a feature idea before committing to an issue
+allowed-tools: Bash, Read, Grep, Glob, Task
+---
+
+# /ideate Skill
+
+Have a structured conversation about a feature idea before creating an issue. Explore feasibility, vision alignment, complexity, and alternative approaches — without committing to anything.
+
+## Usage
+
+```
+/ideate version constraints for package dependencies
+/ideate what if we added a central package registry
+/ideate I want to make credential management more seamless
+```
+
+The argument is a rough idea — it can be vague, ambitious, or half-formed. That's the point.
+
+## Workflow
+
+### Step 1: Understand the Idea
+
+Parse the user's input and restate it back clearly:
+- What is the user trying to achieve?
+- Who benefits from this?
+- What problem does it solve?
+
+Ask clarifying questions if the idea is too vague to evaluate. Keep it to 1-2 targeted questions, not an interrogation.
+
+### Step 2: Vision Check
+
+Read `VISION.md` and evaluate the idea against the product vision.
+
+Check against **"What DevSync Is Not"** negative guardrails:
+- Does this make DevSync an IDE?
+- Does this make DevSync a cloud service?
+- Does this make DevSync a code generator?
+- Does this make DevSync a plugin framework?
+- Does this make DevSync a package registry?
+- Does this add configuration burden?
+
+Check against **Out of Scope** (hard no): cloud/SaaS, AI model interaction, IDE plugins, auto-syncing, instruction content creation, complex deployment.
+
+Run the **Litmus Test**:
+- Does it work with `pip install`?
+- Is it IDE-agnostic?
+- Is it lean? Could we do this with less?
+- Does it work offline?
+- Would the team use this regularly?
+
+Display the alignment:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  🎯 Vision Alignment
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Supports:     <which core principles>
+  Guardrails:   ✅ / ⚠️ <any "Is Not" concerns>
+  Scope:        ✅ / ❌ <if it hits an out-of-scope area>
+  Litmus test:  ✅ / ⚠️ <flag any concerns>
+
+────────────────────────────────────────────
+```
+
+Do NOT stop here if there are warnings. This is ideation — explore the tension, don't block on it.
+
+### Step 3: Explore Feasibility (parallel Sonnet agents)
+
+Launch 2 parallel Sonnet agents:
+
+**Agent A — Technical landscape:**
+1. Read `CLAUDE.md` for architecture overview
+2. Search the codebase for related modules, patterns, and existing infrastructure
+3. Identify what exists, what's new, which parts are affected, rough complexity
+
+**Agent B — Prior art and alternatives:**
+1. Search existing GitHub issues: `gh issue list --search "<keywords>" --state all --limit 10`
+2. Check if similar features exist in the codebase
+3. Think about simpler alternatives that achieve 80% of the goal with 20% of the effort
+
+### Step 4: Present the Analysis
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  💡 Ideation: <idea summary>
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📐 Feasibility
+  Complexity:     Small / Medium / Large
+  Builds on:      <existing modules/patterns>
+  New code:       <what would be created>
+  Affected files: <list of areas>
+  Blockers:       <any technical blockers, or "none">
+
+🔗 Related
+  Existing issues: <list any related issues, or "none found">
+  Existing code:   <anything in the codebase that helps>
+
+💡 Approaches
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  A) <Lean approach>
+     Complexity: <Small/Medium>
+     Trade-offs: <what you give up>
+     Vision fit: ✅ / ⚠️
+
+  B) <Full approach>
+     Complexity: <Medium/Large>
+     Trade-offs: <what you gain vs. cost>
+     Vision fit: ✅ / ⚠️
+
+  C) <Alternative framing> (if applicable)
+     Vision fit: ✅ / ⚠️
+
+────────────────────────────────────────────
+```
+
+Always present at least 2 approaches — a lean version and a fuller version.
+
+### Step 5: Open Discussion
+
+```
+────────────────────────────────────────────
+  🗣️ What do you think?
+
+  Options:
+    → Discuss further — ask questions, refine the idea
+    → Pick an approach — I'll draft as /new-issue
+    → Park it — save the idea for later
+    → Drop it — this isn't the right direction
+
+────────────────────────────────────────────
+```
+
+### Step 6: Resolution
+
+Based on the user's decision: hand off to `/new-issue`, create a `discussion` issue, or move on.
+
+## Guidelines
+
+- This is a **safe space for ideas** — don't shut things down, explore them
+- Always present alternatives, even for well-aligned ideas
+- Vision warnings are discussion points, not stop signs
+- Be honest about complexity
+- Keep the tone collaborative
diff --git a/.claude/commands/new-issue.md b/.claude/commands/new-issue.md
new file mode 100644
index 0000000..0caf2ef
--- /dev/null
+++ b/.claude/commands/new-issue.md
@@ -0,0 +1,180 @@
+---
+name: new-issue
+description: Create a well-structured GitHub issue from a feature idea or bug report
+allowed-tools: Bash, Read, Grep, Glob, Task
+---
+
+# /new-issue Skill
+
+Turn a feature idea, bug report, or task description into a structured GitHub issue.
+
+## Usage
+
+```
+/new-issue add support for Zed AI tool
+/new-issue the install command crashes when library is empty
+/new-issue refactor package tracker to support version constraints
+```
+
+The argument is a natural-language description of the work. It can be a sentence, a paragraph, or bullet points.
+
+## Workflow
+
+### Step 1: Vision Alignment Check
+
+Before anything else, evaluate the idea against the product vision.
+
+1. Read `VISION.md` for the full product vision
+2. Check against **"What DevSync Is Not"** negative guardrails:
+   - Does this make DevSync an IDE? (providing AI assistance, running models)
+   - Does this make DevSync a cloud service? (hosted registry, accounts, SaaS)
+   - Does this make DevSync a code generator? (creating or modifying instruction content)
+   - Does this make DevSync a plugin framework? (providing a runtime or API)
+   - Does this make DevSync a package registry? (central catalog, approval process)
+   - Does this add configuration burden? (feature that doesn't work without configuration)
+3. Check against **Out of Scope** (hard no): cloud/SaaS, AI model interaction, IDE plugins, auto-syncing/file watching, instruction content creation, complex deployment
+4. Run the **Litmus Test**:
+   - Does it work with `pip install`?
+   - Is it IDE-agnostic?
+   - Is it lean? Could we do this with less?
+   - Does it work offline?
+   - Would the team use this regularly?
+5. Identify which **Core Principles** the idea supports (zero-friction, IDE-agnostic, git-as-distribution, lean CLI, credential safety, standards-first)
+
+**Report the alignment:**
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  🎯 Vision Alignment
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Supports:     <which core principles>
+  Guardrails:   ✅ / ⚠️ <any "Is Not" concerns>
+  Scope:        ✅ / ❌ <if it hits an out-of-scope area>
+  Litmus test:  ✅ / ⚠️ <flag any concerns>
+
+────────────────────────────────────────────
+```
+
+- If the idea **conflicts** (❌): explain the conflict clearly, suggest an alternative that aligns, and ask the user how to proceed. Do not create the issue until resolved.
+- If the idea triggers **warnings** (⚠️): explain the concern, ask the user to confirm. If they proceed, the issue will get the `vision-review` label.
+- If the idea is **ambiguous**: ask the user to clarify how it serves the core use cases (team config distribution, multi-tool support, package management).
+- If the idea **aligns** (✅): proceed to Step 2.
+
+### Step 2: Understand the Request
+
+Parse the user's input to determine:
+- **Type**: `enhancement` (new feature), `bug` (something broken), `documentation`, `testing`, `refactor`
+- **Scope**: Which parts of the codebase are likely affected
+- **Urgency**: Is this blocking other work?
+
+### Step 3: Explore Relevant Code (Sonnet agent)
+
+Launch a Sonnet agent to understand the codebase context:
+
+1. Read `CLAUDE.md` for architecture overview
+2. Based on the described work, find relevant source files:
+   - Search for related modules, functions, CLI commands
+   - Read the key files to understand current implementation
+3. Identify:
+   - Which files will likely need changes
+   - What existing patterns to follow
+   - Any related existing issues: `gh issue list --search "<keywords>" --json number,title,state --limit 5`
+   - Potential blockers or dependencies
+
+### Step 4: Check for Duplicates
+
+Search for existing issues that might cover this work:
+```bash
+gh issue list --search "<keywords from description>" --state all --json number,title,state,labels --limit 10
+```
+
+If a duplicate or closely related issue exists:
+- Show the user the existing issue(s)
+- Ask if they want to proceed with a new issue, update the existing one, or skip
+
+### Step 5: Draft the Issue
+
+Create a structured issue body:
+
+```markdown
+## Description
+
+<1-3 sentences explaining what and why, written clearly enough for any contributor to understand>
+
+## Context
+
+<Brief explanation of the current state — what exists today, what's missing or broken>
+
+## Affected Files
+
+- `devsync/<path>` — <what changes here>
+- `devsync/<path>` — <what changes here>
+- `tests/unit/<path>` — <new or modified tests>
+
+## Acceptance Criteria
+
+- [ ] <Specific, testable criterion>
+- [ ] <Another criterion>
+- [ ] <Tests pass: `invoke test-unit`>
+- [ ] <Lint passes: `invoke lint`>
+
+## Implementation Notes
+
+<Optional: suggested approach, patterns to follow, gotchas to watch for. Only include if genuinely helpful — omit if the approach is obvious.>
+```
+
+### Step 6: Determine Labels
+
+Assign labels based on type:
+- `enhancement` — new feature or capability
+- `bug` — something broken or incorrect
+- `documentation` — docs-only changes
+- `testing` — test additions or improvements
+- `refactor` — code restructuring without behavior change
+- `security` — security-related changes
+
+Check which labels exist in the repo first:
+```bash
+gh label list --json name --jq '.[].name'
+```
+
+Only use labels that exist. If a needed label doesn't exist, skip it rather than creating new labels.
+
+### Step 7: Create the Issue
+
+Show the user a preview of the issue title, labels, and body. Ask for confirmation.
+
+Once confirmed:
+```bash
+gh issue create --title "<title>" --label "<label>" --body "$(cat <<'EOF'
+<body content>
+EOF
+)"
+```
+
+### Step 8: Report
+
+Print:
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  📋 Issue Created
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  🔗 Issue:    #<N> — <title>
+  🏷️ Labels:   <labels>
+  🌐 URL:      <url>
+  🎯 Vision:   ✅ supports <principles>
+
+────────────────────────────────────────────
+  👉 Next: /start-work <N>
+────────────────────────────────────────────
+```
+
+## Guidelines
+
+- **Title**: imperative mood, concise, under 70 characters. Example: "Add Zed AI tool support", not "Zed tool feature"
+- **Body**: written for a contributor who knows the codebase but not the specific context. No jargon without explanation.
+- **Acceptance criteria**: specific and testable. "Works correctly" is not a criterion. "Installs instructions to `.zed/rules/` with correct file extension" is.
+- **Don't over-specify**: if the implementation approach is obvious from the criteria, skip "Implementation Notes"
+- **Related issues**: if this work depends on or relates to other issues, mention them in the description
diff --git a/.claude/commands/next.md b/.claude/commands/next.md
new file mode 100644
index 0000000..ebafa9d
--- /dev/null
+++ b/.claude/commands/next.md
@@ -0,0 +1,140 @@
+---
+name: next
+description: Prioritized work queue sorted by priority labels and VISION.md alignment
+allowed-tools: Bash, Read, Grep, Glob, Task
+---
+
+# /next Skill
+
+Show a prioritized work queue of open issues, sorted by priority labels and grouped by VISION.md direction areas.
+
+## Usage
+
+```
+/next                      # Prioritized queue (excludes in-progress/blocked)
+/next --all                # Include in-progress and blocked issues
+/next --area mcp           # Filter by vision direction area
+```
+
+## Workflow
+
+### Step 1: Ensure Labels Exist
+
+Create all lifecycle labels idempotently:
+
+```bash
+gh label create "priority:critical" --color "B60205" --description "Blocking other work" --force
+gh label create "priority:high" --color "D93F0B" --description "Important, should be next" --force
+gh label create "priority:medium" --color "FBCA04" --description "Standard priority" --force
+gh label create "priority:low" --color "0E8A16" --description "Nice to have" --force
+gh label create "in-progress" --color "6F42C1" --description "Actively being worked on" --force
+gh label create "ready-for-review" --color "0075CA" --description "PR submitted" --force
+gh label create "blocked" --color "9E9E9E" --description "Blocked by something" --force
+```
+
+### Step 2: Fetch Data (parallel)
+
+**A — All open issues:**
+```bash
+gh issue list --state open --limit 100 --json number,title,labels,assignees,body
+```
+
+**B — VISION.md direction areas:**
+Read `VISION.md` and extract the "Direction (Current)" section. Identify the 5 direction areas:
+- AI Tool Integration
+- Package Management
+- MCP Integration
+- CLI & UX
+- Docs & Quality
+
+**C — In-progress and blocked issues:**
+```bash
+gh issue list --label "in-progress" --state open --json number,title,labels,assignees
+gh issue list --label "blocked" --state open --json number,title,labels,assignees
+```
+
+### Step 3: Categorize Each Issue
+
+For each open issue:
+
+1. **Priority** — from `priority:*` labels:
+   - `priority:critical` -> Critical
+   - `priority:high` -> High
+   - `priority:medium` -> Medium
+   - `priority:low` -> Low
+   - No priority label -> Medium (default)
+
+2. **Vision area** — keyword match the issue title and body against direction areas:
+   - AI Tool Integration: ai tool, IDE, cursor, claude, windsurf, copilot, kiro, roo, cline, codex, translator, detection
+   - Package Management: package, manifest, template, version, dependency, bundle, component
+   - MCP Integration: MCP, server config, credential, sync
+   - CLI & UX: CLI, command, TUI, Typer, Rich, output, error, UX
+   - Docs & Quality: doc, test, CI, coverage, lint, quality, README
+   - Other: anything that doesn't match
+
+3. **Status:**
+   - `in-progress` label -> In Progress
+   - `blocked` label -> Blocked
+   - `ready-for-review` label -> Ready for Review
+   - None -> Ready
+
+4. **Dependencies** — scan issue body for "depends on #N" / "blocked by #N"
+
+### Step 4: Filter
+
+- Default: exclude issues with `in-progress`, `blocked`, or `ready-for-review` labels
+- With `--all`: include everything
+- With `--area <area>`: only show issues matching that vision area
+
+### Step 5: Display Queue
+
+Sort by priority tier (critical -> high -> medium -> low), then by issue number.
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  📋 Work Queue
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📋 AI Tool Integration
+  🟡 #83 — Add Zed AI tool support
+  🟢 #91 — Improve cursor rule translation
+
+📋 Package Management
+  🟡 #95 — Add version constraint support
+  🟢 #110 — Template system for packages
+
+📋 MCP Integration
+  🟡 #88 — Credential sync improvements
+
+📋 CLI & UX
+  🟡 #102 — Better error messages for install failures
+
+📋 Docs & Quality
+  🟢 #115 — Increase test coverage
+
+────────────────────────────────────────────
+
+  🔴 Critical: 0  🟠 High: 0  🟡 Medium: 4  🟢 Low: 3
+  📊 Total: 7 issues ready to work
+
+────────────────────────────────────────────
+```
+
+### Step 6: Recommend Next Item
+
+```
+  ⭐ Recommended: #83 — Add Zed AI tool support
+     Rationale: Highest priority in AI Tool Integration,
+     no dependencies, aligns with IDE-agnostic principle.
+
+────────────────────────────────────────────
+  👉 Next: /start-work 83
+────────────────────────────────────────────
+```
+
+## Guidelines
+
+- Always show `#N — title` for issue references
+- Default view should be actionable — only show issues you can start right now
+- If there are 0 issues ready, say so and suggest `/triage --reassess` or `/new-issue`
+- Priority indicators: 🔴 Critical, 🟠 High, 🟡 Medium, 🟢 Low
diff --git a/.claude/commands/pr-check.md b/.claude/commands/pr-check.md
new file mode 100644
index 0000000..4e4767d
--- /dev/null
+++ b/.claude/commands/pr-check.md
@@ -0,0 +1,67 @@
+---
+name: pr-check
+description: Validate an existing PR or remote branch without submitting
+allowed-tools: Bash, Read, Edit, Grep, Glob, Task
+---
+
+# /pr-check Skill
+
+Run the full validation suite on an **existing PR** or a **remote branch** — without creating or modifying anything. Use this to review someone else's work, or to re-check your own PR after updates.
+
+For validating and submitting your own branch, use `/submit-pr` instead (which includes all these checks plus PR creation).
+
+## Usage
+
+```
+/pr-check --pr 86                      # Check an existing GitHub PR by number
+/pr-check --branch feature/foo         # Check a local branch (without switching)
+/pr-check --worktree /path/to/wt       # Check code in an existing worktree
+/pr-check --pr 86 develop              # Check PR #86 against develop (not main)
+```
+
+## When to Use
+
+- **Reviewing a collaborator's PR** — run `/pr-check --pr 86` before approving
+- **Re-checking after updates** — run `/pr-check --pr 86` after the author pushes fixes
+- **Checking a branch without submitting** — run `/pr-check --branch feature/foo`
+- **For your own work before submitting** — use `/submit-pr --checks-only` instead
+
+## Workflow
+
+### Step 0: Resolve Target
+
+1. **Determine the base branch.** Use the bare positional argument if provided, otherwise default to `main`.
+2. **Determine the working directory** based on the flags:
+
+   | Flag | Action | Working directory |
+   |------|--------|-------------------|
+   | `--pr <N>` | `git fetch origin pull/<N>/head:pr-<N>-check`, create temp worktree | Temp worktree path |
+   | `--branch <name>` | Create temp worktree from local branch | Temp worktree path |
+   | `--worktree <path>` | Validate path exists and is a git worktree | Provided path |
+
+3. **For temp worktrees:** create under `<repo-parent>/devsync-pr-check-<id>`.
+
+### Steps 1–7: Full Validation Suite
+
+Run the same validation steps as `/submit-pr` Steps 1–7, but with all commands prefixed with `cd $DIR &&`.
+
+Quality commands for devsync:
+- Lint: `ruff check devsync/ tests/` or `invoke lint`
+- Format: `black --check devsync/ tests/` or `invoke format --check`
+- Tests: `pytest tests/unit/ -v --tb=short` or `invoke test-unit`
+- Types: `mypy devsync/` or `invoke typecheck`
+
+### Step 8: Cleanup
+
+If a temp worktree was created, remove it and its branch.
+
+### Step 9: Recommendations
+
+```
+────────────────────────────────────────────
+  👉 Next steps:
+    - <if issues found> Request changes on the PR
+    - <if clean> Approve and merge
+    - <if docs stale> Suggest doc updates to the author
+────────────────────────────────────────────
+```
diff --git a/.claude/commands/start-work.md b/.claude/commands/start-work.md
new file mode 100644
index 0000000..9c76761
--- /dev/null
+++ b/.claude/commands/start-work.md
@@ -0,0 +1,233 @@
+---
+name: start-work
+description: Begin work on a GitHub issue — create branch, explore code, plan implementation
+allowed-tools: Bash, Read, Edit, Grep, Glob, Task
+---
+
+# /start-work Skill
+
+Set up everything needed to begin implementing a GitHub issue.
+
+## Usage
+
+```
+/start-work 83                  # Start work on issue #83 (worktree, default)
+/start-work 83 --no-worktree    # Start on a branch in the current tree instead
+/start-work 83 --plan-only      # Just create the plan, don't create a branch or worktree
+```
+
+The argument is a GitHub issue number.
+
+By default, work is set up in a **git worktree** — a separate working directory linked to the same repo. This keeps your current branch clean and lets you work on multiple features simultaneously without stashing. Use `--no-worktree` if you prefer a traditional branch in the current tree.
+
+## Workflow
+
+### Step 1: Fetch and Validate the Issue
+
+```bash
+gh issue view <N> --json number,title,body,labels,state,assignees
+```
+
+- If the issue is closed, warn the user and ask if they want to proceed
+- If the issue is assigned to someone else, warn the user
+
+### Step 1c: Check Assignment and Status
+
+Ensure lifecycle labels exist (idempotent):
+```bash
+gh label create "in-progress" --color "6F42C1" --description "Actively being worked on" --force
+gh label create "ready-for-review" --color "0075CA" --description "PR submitted" --force
+gh label create "blocked" --color "9E9E9E" --description "Blocked by something" --force
+```
+
+Check if the issue is already being worked on:
+
+1. **Assignment check:** If the issue is assigned to someone else, warn:
+   ```
+   ⚠️ #<N> — <title> is assigned to @<user>. Continue anyway?
+   ```
+
+2. **Double-up check:** If the issue has the `in-progress` label, warn:
+   ```
+   ⚠️ #<N> — <title> is already marked as in-progress. Continue anyway?
+   ```
+
+3. If the user confirms, assign the issue and add the label:
+   ```bash
+   gh issue edit <N> --add-assignee @me --add-label "in-progress"
+   ```
+
+### Step 1d: Vision Alignment Check
+
+Read `VISION.md` and evaluate the issue against the product vision.
+
+1. Check against the **"What DevSync Is Not"** negative guardrails:
+   - Does this make DevSync an IDE? (providing AI assistance, running models)
+   - Does this make DevSync a cloud service? (hosted registry, accounts, SaaS)
+   - Does this make DevSync a code generator? (creating or modifying instruction content)
+   - Does this add a plugin framework? (providing a runtime or API)
+   - Does this add configuration burden? (feature that doesn't work without configuration)
+   - Does this make DevSync a package registry? (central catalog, approval process)
+
+2. Check against **Out of Scope** (hard no): cloud/SaaS, AI model interaction, IDE plugins, auto-syncing, instruction content creation, complex deployment
+
+3. Run the **Litmus Test**:
+   - Does it work with `pip install`?
+   - Is it IDE-agnostic?
+   - Is it lean?
+   - Does it work offline?
+   - Would the team use this regularly?
+
+4. Check for **complexity creep**: Does this issue add new dependencies, new config options, or new infrastructure requirements? If so, is each one justified?
+
+**Report:**
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  🎯 Vision Alignment: #<N>
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Supports:     <which core principles this advances>
+  Guardrails:   ✅ / ⚠️ <any "Is Not" concerns>
+  Litmus test:  ✅ / ⚠️ <any concerns>
+  Scope:        ✅ / ❌
+  Complexity:   ✅ / ⚠️ <new deps, config, or infra>
+
+────────────────────────────────────────────
+```
+
+- If **[FAIL]**: explain the conflict, suggest alternatives, ask the user how to proceed. Do not create a branch.
+- If **[WARN]**: show the concern, ask the user to confirm before proceeding.
+- If all **[PASS]**: continue to Step 2.
+
+### Step 2: Check for Existing Work
+
+Check if work has already started on this issue:
+
+```bash
+git branch --list "issue-<N>-*"
+gh pr list --search "head:issue-<N>" --json number,title,state,headRefName
+```
+
+If a branch or PR already exists, show it and ask the user how to proceed:
+- Continue on the existing branch
+- Start fresh (new branch)
+- Abort
+
+### Step 3: Create Branch and Workspace
+
+Generate a branch name from the issue:
+- Format: `issue-<N>-<short-description>`
+- `<short-description>`: 2-4 words from the issue title, kebab-case, max 50 chars total
+- Example: issue #83 "Add Zed AI tool support" -> `issue-83-zed-tool-support`
+
+If `--plan-only` was passed, skip branch/workspace creation.
+
+#### Default: Worktree
+
+Create a branch and set up a worktree in a sibling directory:
+
+```bash
+git fetch origin main
+git branch issue-<N>-<description> origin/main
+git worktree add ../devsync-<N>-<short-description> issue-<N>-<description>
+```
+
+Install dev dependencies in the worktree:
+```bash
+cd ../devsync-<N>-<short-description> && pip install -e ".[dev]" -q
+```
+
+The worktree path follows the pattern: `../devsync-<N>-<short-description>` (sibling to the main repo directory).
+
+#### With `--no-worktree`: Traditional Branch
+
+```bash
+git checkout main && git pull origin main
+git checkout -b issue-<N>-<short-description>
+```
+
+### Step 4: Deep Code Exploration (parallel agents)
+
+Launch parallel agents to understand the codebase context for this issue:
+
+**Agent A — Architecture context (Sonnet):**
+1. Read `CLAUDE.md` for architecture overview
+2. Identify which layer(s) this issue touches (ai_tools, cli, core, storage, tui, utils)
+3. List the key files and patterns relevant to this change
+
+**Agent B — Existing implementation (Sonnet):**
+1. Based on the issue description and affected files, read the current code
+2. Understand existing patterns: how similar features are implemented
+3. Identify integration points and dependencies
+4. Note any TODOs, FIXMEs, or comments related to this work
+
+**Agent C — Test landscape (Sonnet):**
+1. Find test files related to the affected modules
+2. Understand testing patterns: fixtures, mocking approach
+3. Identify what new tests will be needed
+
+### Step 5: Create Implementation Plan
+
+Based on the exploration, create a structured plan:
+
+```markdown
+## Implementation Plan: #<N> — <title>
+
+### Summary
+<1-2 sentences on what this change does>
+
+### Files to Create
+- `devsync/<path>` — <purpose>
+- `tests/unit/test_<name>.py` — <what it tests>
+
+### Files to Modify
+- `devsync/<path>` — <what changes and why>
+- `devsync/<path>` — <what changes and why>
+
+### Implementation Steps
+1. <First thing to do — be specific about what code to write/change>
+2. <Next step>
+3. <Continue...>
+N. Run tests: `invoke test-unit`
+N+1. Run lint: `invoke lint`
+
+### Testing Strategy
+- <What to test, how to test it>
+- <Edge cases to cover>
+- <Integration points to verify>
+
+### Risks & Considerations
+- <Anything tricky, breaking changes, migration needs>
+```
+
+### Step 6: Report
+
+Print:
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  🚀 Ready to Work: #<N> — <title>
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  🔀 Branch:     issue-<N>-<description>
+  📂 Worktree:   ../devsync-<N>-<description>  (or "current directory" if --no-worktree)
+  👤 Assigned:   @<user>
+  🏷️ Status:     in-progress
+  📋 Plan:       <number> steps across <number> files
+  🧪 Tests:      <number> existing, <number> new needed
+  🎯 Vision:     ✅ supports <principles>
+
+<The implementation plan from Step 5>
+
+────────────────────────────────────────────
+  👉 Next: cd ../devsync-<N>-<description> and say "go",
+           or adjust the plan
+────────────────────────────────────────────
+```
+
+## Guidelines
+
+- The plan should be detailed enough that another developer (or Claude session) could follow it
+- Don't start coding — this skill only sets up the context and plan
+- If the issue description is vague or missing acceptance criteria, flag what's unclear and suggest criteria
+- If the issue touches security-sensitive code (credential handling, file operations, Git commands), note security requirements
diff --git a/.claude/commands/submit-pr.md b/.claude/commands/submit-pr.md
new file mode 100644
index 0000000..75869e3
--- /dev/null
+++ b/.claude/commands/submit-pr.md
@@ -0,0 +1,468 @@
+---
+name: submit-pr
+description: Validate, audit, and create a pull request with full pre-submission checks
+allowed-tools: Bash, Read, Edit, Grep, Glob, Task
+---
+
+# /submit-pr Skill
+
+Run a full validation suite on the current branch and create a pull request with a well-structured description. This is the single skill for "validate and submit my work."
+
+## Usage
+
+```
+/submit-pr                          # Submit PR against main
+/submit-pr develop                  # Submit PR against a specific base branch
+/submit-pr --skip-checks            # Skip validation (not recommended)
+/submit-pr --draft                  # Create as draft PR
+/submit-pr --checks-only            # Run all checks but don't create the PR
+```
+
+## Workflow
+
+### Step 1: Pre-flight (parallel)
+
+**A — Branch status:**
+```bash
+git branch --show-current
+git status --short
+git log --oneline main..HEAD
+```
+
+**B — Remote status:**
+```bash
+git remote -v
+git rev-list --left-right --count main...HEAD
+```
+
+**C — Merge conflicts:**
+```bash
+git merge-tree $(git merge-base main HEAD) main HEAD
+```
+
+Verify:
+- We're on a feature branch (not main)
+- There are commits ahead of the base branch
+- No uncommitted changes (warn if present, suggest committing first)
+- Branch can merge cleanly (if not, list conflicting files)
+
+### Step 2: Extract Issue References
+
+From the branch name and all commits, collect issue references:
+
+```bash
+git branch --show-current
+git log --oneline main..HEAD
+```
+
+- Extract all `#N` references from commit messages
+- Extract issue number from branch name (`issue-<N>-...`)
+- Deduplicate
+- Verify each issue exists:
+  ```bash
+  gh issue view <N> --json state,title --jq '"\(.state): \(.title)"'
+  ```
+- The primary issue (from branch name) gets `Closes #N` treatment
+- Secondary issues get `Addresses #N` or `Related to #N`
+
+If NO issue references are found, abort: "Every PR must reference at least one GitHub issue. Run `/new-issue` to create one."
+
+### Step 3: Code Quality (parallel, unless --skip-checks)
+
+If `--skip-checks` is passed, warn that this is not recommended and skip to Step 9.
+
+Run all checks in parallel:
+
+**A — Lint:**
+```bash
+ruff check devsync/ tests/ 2>&1 | tail -30
+```
+
+**B — Format:**
+```bash
+black --check devsync/ tests/ 2>&1 | tail -30
+```
+
+**C — Unit tests:**
+```bash
+pytest tests/unit/ -v --tb=short 2>&1 | tail -80
+```
+
+**D — Type check:**
+```bash
+mypy devsync/ --ignore-missing-imports 2>&1 | tail -30
+```
+
+These are **blocking** — if any fail, abort. The user must fix issues before submitting.
+
+### Step 3b: Dependency Health (parallel with Steps 4 and 5)
+
+Run these checks in parallel with Steps 4 and 5 — do not wait for 3b to complete before starting Step 4.
+
+**E — Vulnerability audit:**
+```bash
+pip install pip-audit 2>/dev/null
+pip-audit --desc on 2>&1 | tail -30
+```
+- If `pip-audit` is not installed, skip with warning (non-blocking)
+- If vulnerabilities found: **blocking** — abort and show findings
+
+**F — Outdated dependencies:**
+```bash
+pip list --outdated --format=json 2>/dev/null | python3 -c "
+import json, sys
+pkgs = json.load(sys.stdin)
+for p in pkgs[:10]:
+    print(f\"  {p['name']:30s} {p['version']:>10s} → {p['latest_version']}\")
+if len(pkgs) > 10:
+    print(f'  ... and {len(pkgs)-10} more')
+"
+```
+- **Non-blocking** warning. Show top 10 outdated packages.
+
+**G — New dependency review** (only if `pyproject.toml` changed):
+```bash
+git diff $BASE..HEAD -- pyproject.toml
+```
+For each new dependency added to `[project.dependencies]` or `[project.optional-dependencies]`:
+1. Query PyPI JSON API: `curl -s --max-time 5 https://pypi.org/pypi/<package>/json`
+2. Flag warnings:
+   - Unknown or empty license
+   - Last release older than 2 years
+   - Missing summary/description
+3. If PyPI query fails, skip that package (non-blocking)
+
+**Non-blocking** — new deps are informational, not blocking.
+
+**H — Semgrep security scan:**
+```bash
+pip install semgrep 2>/dev/null
+semgrep scan --config p/python --config p/security-audit --config p/owasp-top-ten --error devsync/ 2>&1 | tail -40
+```
+- If `semgrep` is not installed, skip with warning (non-blocking)
+- If Semgrep finds errors (`--error` flag): **blocking** — abort and show findings
+- If Semgrep finds only warnings: non-blocking, show in report
+
+### Step 4: Test Coverage for New Code
+
+Check that new or modified Python source files have corresponding unit tests.
+
+1. Get the list of added/modified Python files under `devsync/`:
+   ```bash
+   git diff --name-only --diff-filter=AM $BASE..HEAD -- 'devsync/**/*.py'
+   ```
+2. For each file (e.g., `devsync/ai_tools/zed.py`), check if a corresponding test file exists:
+   - Expected location: `tests/unit/test_<module_name>.py` (e.g., `tests/unit/test_zed.py`)
+   - Also check: `tests/unit/test_<parent>_<module>.py` (e.g., `tests/unit/test_ai_tools_zed.py`)
+3. For modified files (not new), check if the test file was also modified — warn if source changed but tests didn't.
+4. Flag any new Python modules under `devsync/` that have zero corresponding test files.
+
+Report format:
+```
+🧪 Test Coverage:
+  devsync/ai_tools/zed.py          -> ❌ MISSING (no test file found)
+  devsync/cli/package.py           -> ⚠️ WARNING (source changed, tests unchanged)
+  devsync/core/repository.py       -> ✅ OK (tests/unit/test_repository.py exists)
+```
+
+### Step 5: Deep Analysis (parallel agents, unless --skip-checks)
+
+Launch 5 parallel agents. Use **Haiku** for Agents C and D (docs freshness, vision alignment — lightweight checks). Use **Sonnet** for Agents A, B, and E (test analysis, compliance, security — require deeper reasoning).
+
+**IMPORTANT for ALL agents:** Report ONLY failures and warnings. Do not report passing checks. Keep response under 500 words.
+
+**Agent A — Test Thoroughness (Sonnet):**
+
+Read the new/modified source files and their corresponding test files. Check:
+- [ ] Every public function/method has at least one test
+- [ ] Both happy path and error paths covered
+- [ ] Branching logic (if/else, try/except) has tests for each branch
+- [ ] External dependencies (file I/O, Git, network) are mocked
+- [ ] Input validation functions tested with valid and invalid inputs
+
+Rate: GOOD (>80% paths), WEAK (50-80%), POOR (<50%).
+
+**Agent B — CLAUDE.md Compliance (Sonnet):**
+
+Get the diff (`git diff $BASE..HEAD`) and read `CLAUDE.md`. Check:
+- [ ] Commit messages follow `type(scope): description (#issue)`
+- [ ] Every commit references a GitHub issue
+- [ ] New AI tools follow `AITool` base class pattern
+- [ ] New CLI commands use Typer patterns
+- [ ] No hardcoded paths or credentials
+
+**Agent C — Documentation Freshness (Haiku, Authoritative):**
+
+This is the authoritative doc review — identifies stale/missing docs AND applies fixes.
+
+1. Get changed files: `git diff --name-only $BASE..HEAD`
+2. Read `CLAUDE.md`, `README.md`, `VISION.md`
+3. Check each surface — flag as MISSING or STALE:
+
+**CLAUDE.md:** New modules not documented? Modified modules with stale descriptions? New config/model fields undocumented?
+
+**README.md:** New CLI commands/flags missing? Feature descriptions stale? Install instructions accurate?
+
+**VISION.md:** New capabilities not in "Direction"? Scope boundary changes?
+
+4. **Apply fixes** for MISSING/STALE items directly.
+5. Rate: UP TO DATE / FIXED (list files) / NEEDS MANUAL REVIEW.
+
+**Agent D — Vision Alignment (Haiku):**
+
+Read `VISION.md` and the diff (`git diff $BASE..HEAD`). Check:
+- [ ] Not an IDE / cloud service / code generator / plugin framework / package registry / config burden
+- [ ] New `pyproject.toml` dependencies justified
+- [ ] New config options have sensible defaults
+- [ ] Lean: could this be simpler? Unnecessary abstractions?
+
+Flag only issues **introduced by this PR**, not pre-existing patterns.
+
+**Agent E — Security Scan (Sonnet):**
+
+Get the diff (`git diff $BASE..HEAD`) and read modified Python files. Check against OWASP ASVS Level 2:
+- [ ] **Command injection**: No `subprocess` with `shell=True` + user input
+- [ ] **Path traversal**: File ops validate paths (no unsanitized `..`)
+- [ ] **Hardcoded secrets**: No API keys/passwords/tokens in source
+- [ ] **Insecure defaults**: No debug mode, disabled checks
+- [ ] **Input validation**: User input validated at boundaries
+- [ ] **Unsafe deserialization**: No `pickle.loads`, `yaml.load()` without SafeLoader, `eval()`, `exec()` with external input
+- [ ] **Credential safety**: No credentials stored in manifests or installation records
+- [ ] **SQL injection**: Parameterized queries only (if applicable)
+- [ ] **Cookie security**: HttpOnly, Secure, SameSite flags (if applicable)
+- [ ] **Rate limiting**: Public endpoints rate-limited (if applicable)
+
+Note: Semgrep runs automatically in Step 3b for pattern-based detection. This agent provides deeper semantic analysis that Semgrep cannot catch (data flow, business logic flaws, context-dependent vulnerabilities).
+
+### Step 6: Commit Documentation Fixes
+
+If Agent C in Step 5 flagged documentation as FIXED (it applied updates to CLAUDE.md, README.md, VISION.md):
+
+1. Stage and commit the doc fixes. Extract the primary issue number from the branch name:
+   ```bash
+   git add CLAUDE.md README.md VISION.md
+   git commit -m "docs: update documentation for current changes (#<primary issue>)"
+   ```
+2. Update the validation report to show docs as fixed rather than stale.
+
+If Agent C rated docs as UP TO DATE, skip this step. If NEEDS MANUAL REVIEW, flag in the report but do not block PR creation.
+
+### Step 7: GitHub Issue Check
+
+Verify all commits reference a GitHub issue:
+```bash
+git log --oneline $BASE..HEAD
+```
+
+For each commit, check that it contains `(#N)` where N is a valid issue number.
+
+### Step 8: Display Validation Report
+
+Display the full validation results locally in the chat:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  🔍 PR Validation
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  🔀 Target:   <branch> → main
+  📊 Commits:  N commits, M files changed
+
+📋 Branch Status
+  Uncommitted:    ✅ / ⚠️ N files
+  Merge:          ✅ / ⚠️ N conflicts
+  Issues:         ✅ / ⚠️ N commits missing references
+
+📋 Code Quality
+  Lint:           ✅ / ❌ N errors
+  Format:         ✅ / ❌ N files
+  Tests:          ✅ / ❌ N passed, M failed
+  Type Check:     ✅ / ❌ / ⏭️
+
+🧪 Test Coverage
+  Test Files:     ✅ / ❌ N new modules missing tests
+  Thoroughness:   GOOD / WEAK / POOR
+
+📦 Dependency Health
+  Vulnerabilities: ✅ / ❌ N vulnerabilities found
+  Outdated:        ✅ / ⚠️ N packages outdated
+  New Deps:        ✅ / ⚠️ N new deps to review / ⏭️ no pyproject.toml changes
+  Semgrep:         ✅ / ❌ N findings / ⏭️ not installed
+
+📝 Compliance
+  CLAUDE.md:      ✅ / ⚠️ N issues
+
+🔒 Security
+  Scan:           ✅ / ⚠️ N issues
+
+📖 Documentation
+  CLAUDE.md:      ✅ / ✅ fixed / ⚠️ needs manual review
+  README.md:      ✅ / ✅ fixed / ⚠️ <details>
+  VISION.md:      ✅ / ✅ fixed / ⚠️ <details>
+
+🎯 Vision Alignment
+  Guardrails:     ✅ / ⚠️ <details>
+  Complexity:     ✅ / ⚠️ <new deps, config>
+  Lean:           ✅ / ⚠️ <simplicity>
+
+────────────────────────────────────────────
+  ✅ Result: READY  /  ❌ Result: NOT READY
+────────────────────────────────────────────
+```
+
+If `--checks-only` was passed, stop here. Do not create the PR.
+
+If Result is NOT READY, abort and show what to fix.
+
+### Step 9: Generate PR Description
+
+Analyze all commits and changed files to generate the PR body:
+
+```bash
+git log --format='%s%n%b' main..HEAD
+git diff --stat main..HEAD
+git diff main..HEAD
+```
+
+Structure the PR body:
+
+```markdown
+## Summary
+
+<2-4 bullet points describing what this PR does and why, written for a reviewer>
+
+## Changes
+
+<Grouped by area — ai_tools, cli, core, storage, tui, tests, etc.>
+
+### <Area>
+- `file.py` — <what changed and why>
+
+## Issue References
+
+Closes #<primary issue>
+Addresses #<secondary issue>
+
+## Test Plan
+
+- [ ] Unit tests pass: `invoke test-unit`
+- [ ] Lint passes: `invoke lint`
+- [ ] <Specific test scenarios relevant to this PR>
+
+## Security Considerations
+
+<Only include if the PR touches credential handling, file operations, Git commands, or manifest parsing. Otherwise omit this section.>
+
+## Vision Alignment
+
+<Include a brief note on which core principles this PR supports. If the PR adds new dependencies, config options, or infrastructure requirements, note them here with justification. Omit this section for trivial changes.>
+
+---
+Generated with [Claude Code](https://claude.ai/code)
+```
+
+### Step 10: Push and Create PR
+
+```bash
+git push -u origin $(git branch --show-current)
+```
+
+Then create the PR:
+
+```bash
+gh pr create --title "<title>" --body "$(cat <<'EOF'
+<generated body>
+EOF
+)" <--draft if requested>
+```
+
+**Title rules:**
+- Under 70 characters
+- Format: `<type>: <description> (#<primary issue>)`
+- Examples: `feat: add zed ai tool support (#83)`, `fix: handle empty library in install (#91)`
+
+### Step 10b: Transition Issue Labels
+
+After the PR is created, transition the primary issue's label from `in-progress` to `ready-for-review`:
+
+```bash
+gh label create "ready-for-review" --color "0075CA" --description "PR submitted" --force
+gh issue edit <N> --remove-label "in-progress" --add-label "ready-for-review"
+```
+
+### Step 11: Post-creation Report
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  🚀 PR Created
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  🔗 PR:       #<N> — <title>
+  🌐 URL:      <url>
+  🔀 Base:     main ← <branch>
+  📎 Issues:   Closes #<N>, Addresses #<N>
+  📌 Status:   <ready | draft>
+  🧪 Checks:   ✅ lint, format, tests, types
+  📦 Deps:     ✅ / ⚠️ N vulnerabilities, M outdated
+  🔒 Security: ✅ / ⚠️ N issues (Semgrep + agent)
+  📖 Docs:     ✅ up to date / ✅ N fixes committed / ⚠️ N need manual review
+  🎯 Vision:   ✅ supports <principles>
+
+────────────────────────────────────────────
+  🔍 Running code review automatically...
+────────────────────────────────────────────
+```
+
+### Step 12: Automatic Code Review
+
+Immediately after PR creation, run the full `/code-review` workflow on the new PR.
+
+### Step 13: Fix Loop (if issues found)
+
+If the code review finds issues (score 80+):
+
+1. Display all issues with full context
+2. Ask the user for action (Fix all / Fix specific / Skip)
+3. If fixing: apply fixes, run checks, commit, push, re-review (max 2 rounds)
+
+### Step 14: Final Summary
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  ✅ PR Ready for Review
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  🔗 PR:          #<N> — <title>
+  🌐 URL:         <url>
+  🔍 Code Review: ✅ clean / ⚠️ N issues remaining
+  🔄 Fix Rounds:  <0-2> rounds applied
+
+────────────────────────────────────────────
+  👉 Next: wait for CI, or request human review
+────────────────────────────────────────────
+```
+
+## Guidelines
+
+- Never create a PR without at least one issue reference
+- Never create a PR with failing tests (unless --skip-checks)
+- Keep the PR title concise — details go in the body
+- Group changes logically in the description
+- If the PR is large (>500 lines changed), suggest breaking it up
+- Security section only when relevant — don't add boilerplate
+
+## Blocking vs Non-Blocking
+
+**Blocking** (abort if failed):
+- Lint, format, tests, type check (Step 3)
+- pip-audit vulnerabilities (Step 3b-E)
+- Semgrep errors (Step 3b-H)
+- Missing test files for new modules (Step 4)
+- POOR test thoroughness (Step 5-A)
+
+**Non-blocking** (warn, continue):
+- Outdated dependencies (Step 3b-F)
+- New dependency metadata warnings (Step 3b-G)
+- Tools not installed (pip-audit, semgrep — skip with warning)
+- WEAK test thoroughness (Step 5-A)
+- Documentation needing manual review (Step 5-C)
diff --git a/.claude/commands/triage.md b/.claude/commands/triage.md
new file mode 100644
index 0000000..38ceb64
--- /dev/null
+++ b/.claude/commands/triage.md
@@ -0,0 +1,189 @@
+---
+name: triage
+description: Set or reassess priority on issues against VISION.md
+allowed-tools: Bash, Read, Grep, Glob, Task
+---
+
+# /triage Skill
+
+Set priority on individual issues or reassess all open issues against VISION.md.
+
+## Usage
+
+```
+/triage 83 high                          # Set priority on issue #83
+/triage 83 critical                      # Set critical priority
+/triage 83 medium                        # Set medium priority
+/triage 83 low                           # Set low priority
+/triage 83 blocked "waiting on #95"      # Mark as blocked with reason
+/triage 83 unblock                       # Remove blocked label
+/triage --reassess                       # Full reassessment of all open issues
+```
+
+## Workflow — Single Issue Mode
+
+### Step 1: Ensure Labels Exist
+
+Create all lifecycle labels idempotently (same as /next Step 1).
+
+### Step 2: Fetch Issue Details
+
+```bash
+gh issue view <N> --json number,title,labels,body,state,assignees
+```
+
+### Step 3: Update Priority
+
+Set/change priority labels or mark as blocked/unblocked.
+
+### Step 4: Report Change
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  🏷️ Triage: #<N> — <title>
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  Previous:  🟡 medium
+  Updated:   🟠 high
+
+────────────────────────────────────────────
+  👉 Next: /next to see the updated queue
+────────────────────────────────────────────
+```
+
+---
+
+## Workflow — Reassess Mode (`--reassess`)
+
+### Step 1: Ensure Labels Exist
+
+Same as single issue mode.
+
+### Step 2: Fetch All Data (parallel)
+
+**A — All open issues:**
+```bash
+gh issue list --state open --limit 100 --json number,title,labels,body,assignees
+```
+
+**B — VISION.md:**
+Read `VISION.md` and extract:
+- Core principles
+- Direction areas (AI Tool Integration, Package Management, MCP, CLI & UX, Docs & Quality)
+- Negative guardrails ("What DevSync Is Not")
+
+**C — Recent activity:**
+```bash
+gh issue list --state closed --limit 20 --json number,title,labels,closedAt
+```
+
+### Step 3: Evaluate Each Issue
+
+Launch a Sonnet agent to evaluate all open issues against VISION.md. For each issue, determine:
+
+1. **Vision alignment** — which direction area does it support?
+2. **Type** — bug, enhancement, refactor, documentation, testing
+3. **Impact** — how many users/use cases does this affect?
+4. **Effort** — rough estimate (small/medium/large)
+5. **Dependencies** — does it depend on or block other issues?
+6. **Suggested priority:**
+   - **Critical** — security bugs, data loss, blocking other work
+   - **High** — bugs affecting core functionality, features in current sprint direction
+   - **Medium** — enhancements aligned with vision, non-blocking improvements
+   - **Low** — nice-to-haves, cosmetic, future-looking
+
+### Step 4: Display Proposed Changes
+
+Show table of all issues with current and proposed priorities.
+
+### Step 5: Prompt for Action
+
+Apply all / Pick / Skip
+
+### Step 6: Apply Changes
+
+Set priority labels as approved.
+
+### Step 7: Update ROADMAP.md (optional)
+
+Ask user if they want to regenerate ROADMAP.md based on current priorities.
+
+### Step 8: Summary Report
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  ✅ Triage Complete
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+  🔴 Critical:  N issues
+  🟠 High:      N issues
+  🟡 Medium:    N issues
+  🟢 Low:       N issues
+  📖 ROADMAP:   updated / skipped
+
+────────────────────────────────────────────
+  👉 Next: /next to see the prioritized queue
+────────────────────────────────────────────
+```
+
+---
+
+## ROADMAP.md Generation
+
+When generating or updating `ROADMAP.md`, use this structure:
+
+```markdown
+# DevSync Roadmap
+
+Aligned with [VISION.md](VISION.md). Updated YYYY-MM-DD.
+
+## Critical
+- [ ] #N — title
+
+## AI Tool Integration
+
+### High
+- [ ] #N — title
+
+### Medium
+- [ ] #N — title
+
+## Package Management
+
+### High
+- [ ] #N — title
+
+## MCP Integration
+
+### Medium
+- [ ] #N — title
+
+## CLI & UX
+
+### Medium
+- [ ] #N — title
+
+## Docs & Quality
+
+### Low
+- [ ] #N — title
+
+## Other
+
+### Medium
+- [ ] #N — title
+```
+
+Rules:
+- Omit empty sections and subsections
+- Critical issues go in a top-level section regardless of area
+- Use checkbox format so progress is visible at a glance
+- Only include OPEN issues
+
+## Guidelines
+
+- Always show `#N — title` for issue references
+- Priority indicators: 🔴 Critical, 🟠 High, 🟡 Medium, 🟢 Low
+- In reassess mode, be thorough but not over-triage — when in doubt, suggest medium
+- Don't change priorities on `in-progress` issues unless the user specifically targets them
+- Blocked issues keep their priority label — `blocked` is a status, not a priority
diff --git a/.claude/commands/write-docs.md b/.claude/commands/write-docs.md
new file mode 100644
index 0000000..4ee0a52
--- /dev/null
+++ b/.claude/commands/write-docs.md
@@ -0,0 +1,58 @@
+---
+name: write-docs
+description: Write or update DevSync documentation pages
+allowed-tools: Bash, Read, Edit, Grep, Glob
+---
+
+Write or update DevSync documentation pages.
+
+## Arguments
+
+The first argument is the doc page path (e.g., `cli/commands.md`). Any additional text describes what to write or update.
+
+## Instructions
+
+You are updating the DevSync documentation. Follow these steps:
+
+### 1. Read the Target Page
+
+If the page exists at `docs/$ARGUMENTS`, read it. If it doesn't exist, you'll create it from scratch.
+
+### 2. Read Source Code
+
+Read the corresponding source code to ensure documentation accuracy:
+
+- CLI commands -> `devsync/cli/`
+- AI tool integrations -> `devsync/ai_tools/`
+- Core models -> `devsync/core/models.py`
+- Repository/manifest parsing -> `devsync/core/repository.py`
+- Library management -> `devsync/storage/library.py`
+- Installation tracking -> `devsync/storage/tracker.py`
+- Package tracking -> `devsync/storage/package_tracker.py`
+- TUI -> `devsync/tui/installer.py`
+- Package installation -> `devsync/cli/package_install.py`
+- Configuration -> `devsync/core/models.py` (Package, PackageComponents)
+
+### 3. Write the Documentation
+
+Follow these style conventions:
+
+- **Voice**: Direct, second-person ("you"), active voice
+- **Tone**: Professional but approachable. No filler, no "In this section you will learn..."
+- **Opening**: Every page starts with a one-sentence summary, then dives straight in
+- **Code examples**: Every concept gets a working example. Use `$ ` prefix for shell commands
+- **Tables**: Use for reference material, feature comparisons, parameter lists
+- **Cross-references**: Link between pages liberally. Use relative paths
+
+### 4. Verify
+
+Run any available doc build commands to check for issues:
+
+```bash
+# Check that referenced files exist
+grep -r "devsync/" docs/ | grep -v ".pyc"
+```
+
+### 5. Cross-Reference Check
+
+Ensure links to and from the new page are consistent. Update `README.md` if the new page covers functionality documented there.
diff --git a/.claude/rules/commit-format.md b/.claude/rules/commit-format.md
new file mode 100644
index 0000000..db31815
--- /dev/null
+++ b/.claude/rules/commit-format.md
@@ -0,0 +1,48 @@
+# Commit Message Format
+
+Every commit in this repository MUST follow this format:
+
+```
+type(scope): description (#issue)
+```
+
+## Rules
+
+- **type** must be one of: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
+- **scope** must be a module name: `cli`, `core`, `storage`, `ai_tools`, `tui`, `utils`
+- **description** is lowercase, imperative mood, no period
+- **#issue** is a valid GitHub issue number — every commit MUST reference one
+
+**IMPORTANT:** Do NOT include Claude as a co-author in commit messages. Do NOT add:
+- `Co-Authored-By: Claude <noreply@anthropic.com>`
+- `Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>`
+- Any other Claude attribution lines
+- `Generated with [Claude Code]` lines
+
+## Examples
+
+Good:
+- `feat(ai_tools): add kiro tool support (#83)`
+- `fix(storage): handle missing installations.json (#91)`
+- `test(core): add package model validation tests (#88)`
+- `docs: update CLAUDE.md architecture section (#95)`
+
+Bad:
+- `fixed bug` (no type, scope, or issue)
+- `feat: add new feature` (missing issue reference)
+- `feat(ai_tools): Add Kiro Support (#83)` (capitalized description)
+
+## Scope Exception
+
+`docs` type may omit scope when the change is project-wide (e.g., README, CLAUDE.md).
+
+## When Creating Commits
+
+Before running `git commit`, verify:
+1. The message matches `type(scope): description (#issue)` format
+2. The issue number exists: `gh issue view <N> --json state`
+3. The scope matches the primary module being changed
+4. The type accurately reflects the change (feat = new, fix = bug, etc.)
+5. There is NO co-author attribution line
+
+If the user provides a commit message that doesn't match this format, reformat it. If no issue number is provided, ask for one — do not commit without it.
diff --git a/.claude/rules/no-code-without-issue.md b/.claude/rules/no-code-without-issue.md
new file mode 100644
index 0000000..368b7da
--- /dev/null
+++ b/.claude/rules/no-code-without-issue.md
@@ -0,0 +1,34 @@
+# All Work Requires a GitHub Issue
+
+This is a non-negotiable project requirement. Before writing ANY code, modifying ANY file, or creating ANY branch:
+
+1. **Confirm a GitHub issue exists** for the work being done
+2. **If no issue exists**, create one before proceeding:
+   ```bash
+   gh issue create --title "<clear title>" --label "<type>" --body "<description with acceptance criteria>"
+   ```
+3. **Reference the issue** in the branch name: `issue-<N>-short-description`
+4. **Reference the issue** in every commit: `type(scope): description (#N)`
+
+## When This Applies
+
+- Feature development
+- Bug fixes
+- Refactoring
+- Documentation changes
+- Test additions
+- Configuration changes
+
+## When This Does NOT Apply
+
+- Reading/exploring code (research only, no changes)
+- Running tests or linting (no commits)
+- Reviewing PRs
+
+## If the User Skips This
+
+If the user asks to make code changes without mentioning an issue, ask:
+
+> "Which GitHub issue does this work relate to? I can create one with `/new-issue`."
+
+Use `/new-issue` to create issues — it includes vision alignment checks and proper formatting. Do not proceed with code changes until an issue is established.
diff --git a/.claude/rules/output-formatting.md b/.claude/rules/output-formatting.md
new file mode 100644
index 0000000..ac6fb44
--- /dev/null
+++ b/.claude/rules/output-formatting.md
@@ -0,0 +1,109 @@
+# Output Formatting
+
+All skill output and reports should be visually striking, scannable, and consistent. Use emoji as status indicators and visual anchors.
+
+## Status Indicators
+
+Use these consistently across all output:
+- ✅ `[PASS]` — check passed, no issues
+- ❌ `[FAIL]` — check failed, must fix
+- ⚠️ `[WARN]` — warning, should review
+- ⏭️ `[SKIP]` — check skipped
+- 🔄 `[....]` — in progress
+
+## Report Structure
+
+Every skill that produces a report should follow this pattern:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  🔍 <Skill Name>
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📋 <Section heading>
+  ✅ Check description
+  ❌ Check description — details on what failed
+  ⚠️ Check description — why this is a warning
+
+📋 <Next section>
+  ...
+
+────────────────────────────────────────────
+  ✅ Result: READY
+  — or —
+  ❌ Result: NOT READY — 2 issues to fix
+────────────────────────────────────────────
+
+👉 Next steps:
+  1. Fix lint error in `devsync/cli/main.py:45`
+  2. Add tests for new `package_install()` function
+  3. Run: `/commit`
+```
+
+## Section Icons
+
+Use these emoji as section headers to create visual rhythm:
+- 📋 General sections (branch status, code quality)
+- 🧪 Test-related sections
+- 🔒 Security sections
+- 🎯 Vision alignment sections
+- 📦 Build/deploy sections
+- 📝 Documentation sections
+- 🔗 Issue/PR reference sections
+
+## Section Separators
+
+- Use `━━━` (heavy box line) for top/bottom borders of the report
+- Use `────` (light box line) for section separators and footer
+- Use blank lines between sections for readability
+
+## Tables
+
+When presenting structured data, use aligned markdown tables:
+
+```
+| File                          | Status | Details              |
+|-------------------------------|--------|----------------------|
+| devsync/ai_tools/claude.py    | ✅     | tests exist          |
+| devsync/cli/package.py        | ⚠️     | source changed       |
+| devsync/core/repository.py    | ❌     | no test file found   |
+```
+
+## Progress Updates
+
+When a skill has multiple steps, show progress with step indicators:
+
+```
+🔄 Step 1/5: Checking branch status...
+✅ Step 1/5: Branch status OK
+🔄 Step 2/5: Running code quality checks...
+```
+
+## Summaries
+
+End every skill with a clear, actionable summary. Don't just list results — tell the user what to do next:
+
+```
+────────────────────────────────────────────
+  ❌ Result: NOT READY — 2 issues to fix
+────────────────────────────────────────────
+
+👉 Next steps:
+  1. Fix lint error in `devsync/cli/main.py:45`
+  2. Add tests for new `package_install()` function
+  3. Run: `/commit`
+```
+
+## Colors and Emphasis
+
+- Use **bold** for key values, status results, and file paths in narrative text
+- Use `code` for commands, file paths in instructions, and config values
+- Use > blockquotes for important callouts or warnings
+- Keep formatting consistent within a single report — don't mix styles
+
+## What NOT to Do
+
+- No ASCII art or decorative banners beyond the box-drawing separators
+- No walls of text — if output exceeds 40 lines, summarize and offer details on request
+- No "Great!" or "Successfully!" preambles — just state what happened
+- Don't overuse emoji in prose — they're for status indicators and section headers, not every sentence
diff --git a/.claude/rules/product-vision.md b/.claude/rules/product-vision.md
new file mode 100644
index 0000000..7c555c1
--- /dev/null
+++ b/.claude/rules/product-vision.md
@@ -0,0 +1,62 @@
+# Product Vision Alignment
+
+Before creating issues, planning features, or starting work, check that the proposed work aligns with the product vision in `VISION.md`.
+
+## Quick Reference — Core Principles
+
+1. **Zero-friction distribution** — pip install and go. No Docker, no external services required.
+2. **IDE-agnostic** — 8+ AI tools, one package format, no lock-in.
+3. **Git as distribution** — no central server, any Git repo works.
+4. **Lean CLI** — Typer + Rich, no daemons, no background processes.
+5. **Credential safety** — credentials never in repos, always prompted or env vars.
+6. **Standards-first** — MCP protocol, conventional markdown, YAML manifests.
+
+## What DevSync Is Not (Negative Guardrails)
+
+These are identity-level constraints. If a feature makes DevSync more like any of these, flag it.
+
+- **Not an IDE** — DevSync manages configs, it doesn't provide AI assistance, run models, or execute code
+- **Not a cloud service** — no hosted registry, no accounts, no SaaS tier. Local CLI only
+- **Not a code generator** — distributes instructions, doesn't create or modify them
+- **Not a plugin framework** — installs files to the right places, doesn't provide a runtime or API
+- **Not a package registry** — no central registry, no publishing step, no approval process. Any Git repo is a valid source
+- **Not a configuration burden** — zero configuration must always work. Every option needs a sensible default
+
+## Out of Scope (Hard No)
+
+Do not build or propose features in these areas:
+- Cloud hosting or SaaS
+- AI model interaction or content generation
+- IDE plugins or extensions
+- Automatic syncing or file watching (daemons)
+- Instruction content creation or editing
+- Complex deployment requirements
+
+## The Litmus Test
+
+When evaluating a feature idea, ask:
+1. Does it work with `pip install`?
+2. Is it IDE-agnostic?
+3. Is it lean? Could we do this with less?
+4. Does it work offline (for downloaded repos)?
+5. Would the team use this regularly?
+
+If the answer to any of these is "no," flag the concern before proceeding. Read `VISION.md` for the full product vision.
+
+## When Ideas Don't Align
+
+If a user proposes work that conflicts with the vision:
+- Don't silently proceed — raise the concern directly
+- Explain which principle it conflicts with
+- Suggest an alternative approach that aligns, if one exists
+- If the user wants to proceed despite the concern: go ahead, but:
+  1. Add the `vision-review` label to the issue/PR
+  2. Note the specific vision tension in the issue/PR description
+  3. This ensures the project owner can batch-review vision-flagged work
+
+## When Ideas Are Ambiguous
+
+If alignment isn't clear:
+- Ask the user how the feature relates to the core use cases (team config distribution, multi-tool support, package management)
+- Check if the feature adds external dependencies or infrastructure requirements
+- Consider whether it increases or decreases the "pip install to productive" time
diff --git a/.claude/rules/security-patterns.md b/.claude/rules/security-patterns.md
new file mode 100644
index 0000000..36d6de2
--- /dev/null
+++ b/.claude/rules/security-patterns.md
@@ -0,0 +1,57 @@
+# Security Patterns
+
+> Vision principle: **"Credential safety."** Credentials never in repos, always prompted or from environment variables. DevSync touches file systems, Git repos, and MCP server configs — security here means safe file operations and credential handling.
+
+These patterns are enforced on ALL code in this repository. Violations must be fixed before committing.
+
+## Forbidden — Never Generate These
+
+- `eval()`, `exec()`, `compile()` with any user-controlled input
+- `subprocess` calls with `shell=True` and user input
+- Hardcoded secrets, API keys, passwords, or tokens
+- `pickle.loads()` on untrusted data
+- Logging of passwords, API keys, or credentials
+- Path traversal via unsanitized `..` in file operations
+- Writing credentials to manifest files, installation records, or package trackers
+- `verify=False` or `rejectUnauthorized: false` in HTTP/TLS clients
+
+## Required Patterns
+
+### File Operations
+- Validate all file paths before read/write operations
+- Prevent path traversal: reject paths containing `..` that escape intended directories
+- Validate file extensions match expected types
+- Check file sizes before reading (prevent memory exhaustion)
+- Use `pathlib.Path` over string manipulation for path construction
+
+### Git Operations
+- Never embed credentials in Git URLs
+- Sanitize repository URLs before passing to Git commands
+- Validate Git output before parsing (don't assume format)
+- Use `subprocess` with `shell=False` for all Git operations
+
+### Credential Handling
+- MCP server credentials: prompt at install time or read from environment
+- Never store credential values in `.devsync/packages.json` or `.devsync/installations.json`
+- Never log credential values, even at debug level
+- Credential environment variable names (not values) may be stored in manifests
+
+### Input Validation
+- Validate all input at system boundaries (CLI args, manifest files, Git output)
+- Allowlists over denylists for validation
+- YAML parsing: use `yaml.safe_load()`, never `yaml.load()` without SafeLoader
+- Validate manifest structure before accessing nested fields
+
+### Package Security
+- Verify file checksums when specified in manifests
+- Validate package manifests before installation
+- Reject packages with paths that escape the package directory
+- Warn on packages that modify security-sensitive paths
+
+## When Adding New Features
+
+1. Validate all input parameters at the entry point
+2. Use `pathlib.Path.resolve()` to canonicalize paths
+3. Never interpolate user input into shell commands
+4. Log security-relevant events (installation, credential prompts, conflicts)
+5. Test with adversarial inputs (paths with `..`, oversized files, malformed YAML)
diff --git a/.claude/rules/test-requirements.md b/.claude/rules/test-requirements.md
new file mode 100644
index 0000000..113c2ee
--- /dev/null
+++ b/.claude/rules/test-requirements.md
@@ -0,0 +1,32 @@
+# Test Requirements
+
+> Vision principle: **"Lean over sprawling."** Tests prevent sprawl by catching regressions early. They're the safety net that lets the codebase stay lean — you can refactor aggressively when tests confirm nothing broke.
+
+## New Code Must Have Tests
+
+When adding or modifying code under `devsync/`:
+
+1. **New modules** (`devsync/<name>.py` or `devsync/<dir>/<name>.py`) MUST have a corresponding test file at `tests/unit/test_<name>.py`
+2. **New public functions/methods** MUST have at least one unit test covering the happy path
+3. **Bug fixes** MUST include a regression test that would have caught the bug
+4. **Modified functions** — if you change behavior, update or add tests to cover the change
+
+## Test Conventions
+
+- Test files: `tests/unit/test_<module>.py`
+- Test functions: `test_<function_name>_<scenario>()`
+- Mock all external dependencies (file I/O, Git operations, network) in unit tests
+- Use `pytest` fixtures from `conftest.py`, not setUp/tearDown
+- Integration tests go in `tests/integration/` and may use real file I/O and Git
+- Minimum coverage target: 80%
+
+## What Doesn't Need Tests
+
+- Private helper functions (tested indirectly through public API)
+- Type definitions and dataclasses (unless they have methods with logic)
+- Configuration constants
+- `__init__.py` re-exports
+
+## Before Committing
+
+Run `pytest tests/unit/ -v --tb=short` or `invoke test-unit` and confirm all tests pass. Do not commit with failing tests.
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index 59777ca..7dba468 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -73,6 +73,34 @@ jobs:
           file: ./coverage.xml
           fail_ci_if_error: false
 
+  security:
+    name: Security Scan
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Set up Python
+        uses: actions/setup-python@v6
+        with:
+          python-version: '3.10'
+          cache: 'pip'
+
+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
+          pip install -e .[dev]
+
+      - name: Run Semgrep
+        run: |
+          pip install semgrep
+          semgrep scan --config p/python --config p/security-audit --config p/owasp-top-ten --error devsync/
+
+      - name: Run pip-audit
+        run: |
+          pip install pip-audit
+          pip-audit --desc on
+        continue-on-error: true
+
   dependency-review:
     name: Dependency Review
     runs-on: ubuntu-latest