feat(tools): production-grade coding tools, file history, and skills

Cargo.toml

@@ -129,6 +129,7 @@ serde_yml = "0.0.12"
 # Filesystem paths
 dirs = "6"
 fs4 = "0.6"
+glob = "0.3"
 
 # Semantic versioning
 semver = "1"

scripts/check_no_panics.py

@@ -132,6 +132,11 @@ def sanitize_line(line: str, state: LexerState) -> str:
         out[i] = ch
         i += 1
 
+    # Rust char literals cannot span lines; reset if still open at EOL.
+    if state.in_char:
+        state.in_char = False
+        state.char_escape = False
+
     return "".join(out)
 
 

skills/code-review/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: code-review
+version: "1.0.0"
+description: Review code changes for bugs, style, and security issues
+activation:
+  keywords:
+    - "review"
+    - "code review"
+    - "review changes"
+  patterns:
+    - "(?i)review\\s.*(code|changes|diff|PR|pull request|commit)"
+    - "(?i)(check|look at|inspect)\\s.*(changes|diff|code)"
+  tags:
+    - "code-review"
+    - "quality"
+  max_context_tokens: 1200
+---
+
+# Code Review Workflow
+
+When the user asks to review code:
+
+1. **Get the changes**: Run `shell` with `git diff` (unstaged) or `git diff --cached` (staged) or `git diff HEAD~1` (last commit) depending on context.
+2. **Focus on what changed**, not surrounding code. Don't review unchanged code unless it's directly relevant to the change.
+3. **Check for these categories:**
+   - **Bugs**: Logic errors, off-by-one, null/undefined handling, race conditions
+   - **Security**: Injection vulnerabilities, credential exposure, path traversal, XSS
+   - **Error handling**: Missing error cases, swallowed errors, unclear error messages
+   - **Edge cases**: Empty inputs, large inputs, concurrent access, unicode handling
+   - **Style**: Inconsistency with surrounding code, unclear naming, missing/excessive comments
+4. **Provide actionable feedback** with specific file:line references. Don't just say "this could be improved" - say what to change and why.
+5. **Be proportional**: A one-line typo fix doesn't need a full security audit. Match review depth to change scope.
+6. If the changes look good, say so clearly. Don't invent problems.

skills/coding/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: coding
+version: "1.0.0"
+description: Best practices for code editing, search, and file operations
+activation:
+  keywords:
+    - "code"
+    - "edit"
+    - "fix"
+    - "implement"
+    - "refactor"
+    - "bug"
+    - "function"
+    - "class"
+    - "file"
+    - "module"
+    - "test"
+    - "compile"
+    - "build"
+    - "error"
+    - "change"
+    - "rename"
+    - "delete"
+    - "add"
+    - "update"
+  exclude_keywords:
+    - "memory"
+    - "routine"
+    - "schedule"
+  patterns:
+    - "(?i)(add|remove|update|modify|create|delete|rename|move)\\s.*(file|function|class|method|variable|import)"
+    - "(?i)(fix|debug|investigate|trace|find)\\s.*(bug|error|issue|crash|fail)"
+  tags:
+    - "development"
+    - "coding"
+  max_context_tokens: 1500
+---
+
+# Coding Best Practices
+
+## Tool Usage Discipline
+
+- **Prefer `apply_patch` over `write_file`** for modifying existing files. It sends only the changed portion, preventing accidental full-file rewrites.
+- **Always `read_file` before editing.** Understand the context before changing code. Never edit a file you haven't read.
+- **Use `glob` for file discovery** instead of `shell` with `find` or `ls`. It's faster, safer, and returns structured results sorted by modification time.
+- **Use `grep` for content search** instead of `shell` with `grep` or `rg`. It provides structured output modes (content, file paths, counts) and pagination.
+- **Use `list_dir` for directory exploration** instead of `shell` with `ls`.
+- **Read before writing.** Never create or overwrite a file without reading it first (unless it's genuinely a new file).
+
+## Code Change Discipline
+
+- **Minimal changes.** Don't add features, refactor, or "improve" beyond what was asked. A bug fix doesn't need surrounding code cleaned up.
+- **No unnecessary comments or docstrings.** Only add comments where the logic isn't self-evident. Don't add type annotations or docstrings to code you didn't change.
+- **One thing at a time.** Make focused changes, verify with `read_file`, then move to the next change.
+- **Fix the pattern, not just the instance.** When you find a bug, use `grep` to search for all occurrences of the same pattern before committing a fix.
+
+## Code Quality
+
+- Don't introduce security vulnerabilities (command injection, XSS, SQL injection, path traversal).
+- Preserve existing code style and conventions. Match the indentation, naming, and patterns of surrounding code.
+- Test after changes when test infrastructure exists. Use `shell` to run the project's test command.
+- Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees.

skills/commit/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: commit
+version: "1.0.0"
+description: Generate git commit messages from staged changes
+activation:
+  keywords:
+    - "commit"
+    - "git commit"
+  patterns:
+    - "(?i)(create|make|write|generate)\\s.*commit"
+    - "(?i)commit\\s.*(message|changes|staged)"
+  tags:
+    - "git"
+    - "version-control"
+  max_context_tokens: 1000
+---
+
+# Git Commit Workflow
+
+When the user asks to create a commit:
+
+1. Run `shell` with `git status` to see what files are staged and unstaged.
+2. Run `shell` with `git diff --cached` to see the exact changes that will be committed.
+3. Run `shell` with `git log --oneline -5` to understand the repo's commit message style.
+4. Analyze the staged changes and draft a commit message:
+   - Summarize the nature of the change (new feature, bug fix, refactor, etc.)
+   - Keep it concise: 1-2 sentences focusing on **why**, not **what**
+   - Match the repo's existing commit message style
+5. **Do not commit files that likely contain secrets** (`.env`, `credentials.json`, API keys). Warn the user if such files are staged.
+6. Show the proposed commit message to the user and **ask for confirmation** before running `git commit`.
+7. Stage any requested files with `git add <specific files>` (never use `git add -A` or `git add .`).
+
+## Commit Message Format
+
+If the repo doesn't have a clear style, use:
+```
+<type>: <concise description>
+
+<optional body explaining why>
+```
+
+Where type is: fix, feat, refactor, test, docs, chore.