docs: improve Claude rules based on eval results

Expanded bug fix workflow to explicit 5-step sequence with subagent delegation, aligned type annotation rule with codebase conventions, simplified verification rule to reference prek, and expanded git/PR guidelines.

.claude/rules/code-style.md

@@ -6,8 +6,10 @@
 - **Tooling**: Ruff for linting/formatting, mypy strict mode, prek for pre-commit checks
 - **Comments**: Minimal - only explain "why", not "what"
 - **Docstrings**: Do not add unless explicitly requested
+- **Types**: Match the type annotation style of surrounding code — the codebase uses annotations, so add them in new code
 - **Naming**: NEVER use leading underscores (`_function_name`) - Python has no true private functions, use public names
 - **Paths**: Always use absolute paths
 - **Encoding**: Always pass `encoding="utf-8"` to `open()`, `read_text()`, `write_text()`, etc. in new or changed code — Windows defaults to `cp1252` which breaks on non-ASCII content. Don't flag pre-existing code that lacks it unless you're already modifying that line.
+- **Verification**: Use `uv run prek` to verify code (handles ruff, ty, mypy in one pass) — don't use `python -c "import ..."` for validation
 - **Pre-commit**: Run `uv run prek` before committing — fix any issues before creating the commit
 - **Pre-push**: Before pushing, run `uv run prek run --from-ref origin/<base>` to check all changed files against the PR base — this matches CI behavior and catches issues that per-commit prek misses. To detect the base branch: `gh pr view --json baseRefName -q .baseRefName 2>/dev/null || echo main`

.claude/rules/git.md

@@ -1,7 +1,17 @@
 # Git Commits & Pull Requests
 
-- **Always create a new branch from `main` before starting any new work** — never commit directly to `main` or reuse an existing feature branch for unrelated changes
+## Commits
+- Never commit, amend, or push without explicit permission
+- Don't commit intermediate states — wait until the full implementation is complete, reviewed, and explicitly approved before committing. If the user corrects direction mid-implementation, incorporate the correction before any commit
+- Always create a new branch from `main` before starting any new work — never commit directly to `main` or reuse an existing feature branch for unrelated changes
 - Use conventional commit format: `fix:`, `feat:`, `refactor:`, `docs:`, `test:`, `chore:`
 - Keep commits atomic - one logical change per commit
 - Commit message body should be concise (1-2 sentences max)
-- PR titles should also use conventional format
+- Merge for simple syncs, rebase when branches have diverged significantly
+- When committing to an external/third-party repo, follow that repo's own conventions for versioning, changelog, and CI
+
+## Pull Requests
+- PR titles should use conventional format
+- Keep the PR body short and straight to the point
+- If related to a Linear issue, include `CF-#` in the body
+- Branch naming: `cf-#-title` (lowercase, hyphenated), no other prefixes/suffixes

CLAUDE.md

@@ -19,7 +19,12 @@ Discovery → Ranking → Context Extraction → Test Gen + Optimization → Bas
 7. **Result** (`result/`, `github/`): Create PR with winning optimization
 
 # Instructions
-- When I report a bug, don't start by trying to fix it. Instead, start by writing a test that reproduces the bug. Then, have subagents try to fix the bug and prove it with a passing test.
+- **Bug fix workflow** — follow these steps in order, do not skip ahead:
+  1. Read the relevant code to understand the bug
+  2. Write a test that reproduces the bug (run it to confirm it fails)
+  3. Spawn subagents (using the Agent tool) to attempt the fix — each subagent should apply a fix and run the test to prove it passes
+  4. Review the subagent results, pick the best fix, and apply it
+  5. Never jump straight to writing a fix yourself — always go through steps 1-4
 - Everything that can be tested should have tests.
 
 <!-- Section below is auto-generated by `tessl install` - do not edit manually -->