@@ -0,0 +1,50 @@
+---
+name: ast-grep
+description: Guides ccusage structural code searches with ast-grep. Use when finding syntax patterns, validating migrations, or writing AST-based search commands.
+---
+
+# ast-grep
+
+Use ast-grep when a search needs syntax structure rather than plain text. Prefer `rg` for simple text search.
+
+## Tooling
+
+This repo provides `ast-grep` through `flake.nix`. Run commands from the Nix dev shell, or use `direnv exec .` when the shell is not already active:
+
+```sh
+direnv exec . ast-grep run --lang ts --pattern '/$P/' --json=stream apps packages
+```
+
+If `direnv` is unavailable and this is a one-off search, use comma as a fallback:
+
+```sh
+, ast-grep run --lang ts --pattern '/$P/' --json=stream apps packages
+```
+
+## Workflow
+
+1. Describe the syntax shape you need to find.
+2. Start with a small pattern and test it against the repo.
+3. Use `--debug-query` when the pattern does not match the AST shape you expected.
+4. Only move to YAML rules when `run --pattern` cannot express the search.
+
+## Commands
+
+For quick pattern searches:
+
+```sh
+ast-grep run --lang ts --pattern 'console.log($ARG)' apps packages
+```
+
+For JSON output that scripts can consume:
+
+```sh
+ast-grep run --lang ts --pattern '/$P/' --json=stream apps packages
+```
+
+## Rule Tips
+
+- Use `run --pattern` for simple single-node matches.
+- Use `scan --rule` or `scan --inline-rules` for relational rules such as `inside` or `has`.
+- Add `stopBy: end` to relational rules so ast-grep searches the full direction.
+- Use `--debug-query=ast`, `--debug-query=cst`, or `--debug-query=pattern` when a rule does not match the code shape you expected.
@@ -60,6 +60,8 @@ Keep agent-specific code there. Split files by responsibility when the implement
 - `pricing.ts` or `pricing-macro.ts` - agent-specific pricing candidates, bundled pricing, or provider filters.
 - `types.ts` - source-local types when they are not shared outside the adapter.
 
+For Rust work, use the `ccusage-rust` skill and mirror the same responsibility boundaries under `rust/crates/ccusage/src/adapter/<agent>/` where practical: `mod.rs`, `paths.rs`, `parser.rs`, `loader.rs`, and `report.rs`.
+
 When moving an existing loader into an adapter, update internal imports to the adapter path instead of adding compatibility re-export shims. Keep old root-level modules only when they are part of the package's declared public exports or are dedicated bundled worker entries. In `apps/ccusage`, `src/data-loader.ts` is a worker/build entry for the optimized Claude `data-loader` chunk from PR #984; do not put new source logic there.
 
 Use shared ccusage foundation for rendering, table layout, logging, date formatting, progress, pricing fetcher lifecycle, JSONL walking, worker gating, worker spawn/result ordering, and aggregation wherever the source data permits. Agent adapters should mainly own source-specific log discovery, parsing, token mapping, model mapping, and source-specific metadata.
 
@@ -48,6 +48,7 @@ Tools are managed by `flake.nix` and `package.json`. Use `comma` or `nix run` fo
 
 - Use TypeScript strict-mode patterns already present in the package.
 - Prefer `satisfies` and `as const satisfies` over unsafe `as` assertions; use the `typescript-style` skill for details.
+- Use the `ccusage-rust` skill before editing `rust/crates/**`, native packaging behavior, Rust pricing embedding, or Rust performance work.
 - Use `.ts` extensions for local imports.
 - Use Node path utilities for file paths.
 - Use `logger.ts` instead of `console.log`.
 
@@ -0,0 +1,78 @@
+---
+name: ccusage-rust
+description: Guides ccusage Rust implementation work. Use when editing rust/crates, native packaging, Rust performance, parser/module layout, pricing embedding, or Rust/TypeScript parity.
+paths:
+  - 'rust/**/*.rs'
+  - 'rust/**/*.toml'
+  - 'rust/**/build.rs'
+globs: 'rust/**/*.rs,rust/**/*.toml,rust/**/build.rs'
+---
+
+# ccusage Rust
+
+Use this skill for the native Rust CLI under `rust/crates/ccusage` and `rust/crates/ccusage-terminal`.
+
+## Source Parity
+
+Rust must match the TypeScript implementation on `origin/main` unless the user explicitly scopes a behavior change. Before implementing or refactoring an agent, inspect the corresponding TypeScript adapter:
+
+```sh
+git ls-tree -r --name-only origin/main apps/ccusage/src/adapter
+git show origin/main:apps/ccusage/src/adapter/<agent>/index.ts
+git show origin/main:apps/ccusage/src/adapter/<agent>/parser.ts
+git show origin/main:apps/ccusage/src/adapter/<agent>/paths.ts
+```
+
+Preserve report semantics, JSON fields, table columns, progress/spinner text, agent grouping, date filtering, `--offline`, `CLAUDE_CONFIG_DIR`, and source-specific environment variables.
+
+## Module Layout
+
+Do not keep growing `main.rs` or single large adapter files. Mirror the TypeScript responsibility boundaries where practical:
+
+- `adapter/<agent>/mod.rs` - public adapter surface and command wiring.
+- `adapter/<agent>/paths.rs` - environment variables, defaults, and path discovery.
+- `adapter/<agent>/parser.rs` - raw record parsing and token/model mapping.
+- `adapter/<agent>/loader.rs` - file walking, SQLite reads, dedupe, and date filtering entry points.
+- `adapter/<agent>/report.rs` - JSON/table row shaping when agent-specific.
+- shared modules stay in `types.rs`, `summary.rs`, `output.rs`, `pricing.rs`, `progress.rs`, and `date_utils.rs`.
+
+Keep public `pub(crate)` surfaces narrow. Prefer moving tests with the code they exercise instead of leaving all Rust tests in `main.rs`.
+
+When splitting large Rust modules or removing duplication, use the `reduce-similarities` skill, which runs `similarity-rs` for `.rs` files.
+
+## Pricing Embedding
+
+TypeScript uses build/macro-time pricing snapshots. Rust should not rely on a manually edited `claude-pricing.json` as the only embedded source.
+
+When changing pricing:
+
+- Prefer a `build.rs` step that fetches LiteLLM `model_prices_and_context_window.json` into `OUT_DIR`.
+- Keep a checked-in fallback snapshot so offline builds and network failures still work.
+- Load the generated build-time snapshot first, then fallback pricing, then runtime fetch when not `--offline`.
+- Add tests for embedded/offline pricing and context limits.
+
+## Performance
+
+Read the local Rust Performance Book clone before non-trivial optimization:
+
+```text
+/Users/ryoppippi/ghq/github.com/nnethercote/perf-book/src/profiling.md
+/Users/ryoppippi/ghq/github.com/nnethercote/perf-book/src/io.md
+/Users/ryoppippi/ghq/github.com/nnethercote/perf-book/src/heap-allocations.md
+/Users/ryoppippi/ghq/github.com/nnethercote/perf-book/src/parallelism.md
+/Users/ryoppippi/ghq/github.com/nnethercote/perf-book/src/type-sizes.md
+```
+
+Profile before committing an optimization. Validate with end-to-end `hyperfine` and JSON/table parity, not only microbenchmarks.
+
+For ccusage workloads, check:
+
+- I/O count and buffering before CPU-only tweaks.
+- Avoid unnecessary `String` allocation and cloning on hot paths; prefer borrowed `&str`, `Arc<str>`, or typed summaries where ownership is needed.
+- Avoid returning large intermediate object vectors when worker-side aggregation or typed transfer payloads can preserve output.
+- Use parallelism only when it improves end-to-end command time on real fixture shapes.
+- Keep binary size visible when adding dependencies or enabling features.
+
+## Validation
+
+Use the `ccusage-testing` skill for Rust test commands. For perf or parity work, compare against `origin/main` TypeScript output for a stable fixture window before changing behavior.
@@ -1,12 +1,32 @@
 ---
 name: ccusage-testing
-description: Guides ccusage tests. Use when adding or fixing in-source Vitest, fs-fixture data, CLI snapshots, Claude model pricing, or LiteLLM compatibility.
+description: Guides ccusage tests. Use when adding or fixing in-source Vitest, Rust cargo tests, fs-fixture data, CLI snapshots, Claude model pricing, or LiteLLM compatibility.
 ---
 
 # ccusage Testing
 
 Use the `tdd` skill for logic changes and general test readability rules, including the guidance to avoid over-DRYing tests when duplication improves clarity. Use the `fs-fixture` skill when creating filesystem fixtures. This skill adds ccusage-specific Vitest, fixture, model, and pricing rules.
 
+## Rust Tests
+
+Use `direnv exec .` when the current shell does not already expose the Rust toolchain:
+
+```sh
+direnv exec . cargo test --manifest-path rust/Cargo.toml --workspace
+direnv exec . cargo test --manifest-path rust/Cargo.toml --workspace <test_name>
+direnv exec . cargo test --manifest-path rust/Cargo.toml --workspace -- --ignored
+```
+
+For repo-wide validation, prefer the package script because it runs Vitest and Rust tests together:
+
+```sh
+direnv exec . pnpm run test
+```
+
+Put Rust unit tests near the module they exercise with `#[cfg(test)] mod tests`. When splitting a large module, move its tests with the code instead of leaving unrelated tests in `main.rs`.
+
+Use fixture-backed Rust tests for parser, path discovery, SQLite loading, dedupe, aggregation, pricing, and CLI output parity. For TDD syntax and focused cargo test examples, read `../tdd/references/rust-examples.md`.
+
 ## Vitest Pattern
 
 - Tests live beside implementation in `if (import.meta.vitest != null)` blocks.
@@ -27,7 +47,8 @@ Utility functions should include concise JSDoc describing their purpose and focu
 
 - Avoid `try`/`catch` in tests for expected failures. Use `expect(...).toThrow()`, `await expect(...).rejects`, or explicit Result failure assertions.
 - Avoid `if` branches inside test bodies. Split behaviors into separate tests or use `it.each` for table-driven cases.
-- Do not over-DRY tests. Keep repeated setup inline when it makes the behavior easier to read.
+- Tests do not need to be DRY. Prefer repeated, explicit setup in each test when it makes the behavior easier to read.
+- Do not hoist one-off values out of tests. Write literals and direct setup values inline in the test body when sharing them would make the behavior harder to read.
 
 For concrete good and bad examples, read `../tdd/references/vitest-examples.md`.
 
 
@@ -77,6 +77,15 @@ Use standard git history commands to understand intent before committing. Prefer
 - Potential impacts
 - Wrap at 72 characters
 
+**Subject should name the artifact or behavior changed**:
+
+- Prefer concrete subjects that make sense when read alone in a commit list.
+- Avoid vague review-process subjects such as `chore: address review feedback`,
+  `chore: apply comments`, or `fix: update per CodeRabbit`.
+- Put reviewer context in the body, not the subject. For example, use
+  `docs(skills): clarify arkregex newline guidance` with a body explaining that
+  it addresses CodeRabbit feedback.
+
 ## Quality Checks
 
 - Can this be reverted without breaking other functionality?
 
@@ -1,77 +1,84 @@
 ---
 name: reduce-similarities
-description: Detects duplicate JavaScript and TypeScript code with similarity-ts. Use when checking .js, .jsx, .ts, or .tsx files for refactoring opportunities.
+description: Detect duplicate Rust code using AST-based similarity analysis. Use when working with .rs files and looking for code duplication or refactoring opportunities.
 argument-hint: '[path] [--threshold 0.85] [--print]'
-allowed-tools: Bash(similarity-ts *) Read Grep Glob
-paths: '**/*.ts,**/*.tsx,**/*.js,**/*.jsx'
+allowed-tools: Bash(similarity-rs *) Read Grep Glob
+paths: '**/*.rs'
 ---
 
-# TypeScript/JavaScript Code Similarity Detection
+# Rust Code Similarity Detection
 
 ## What to do
 
-Run `similarity-ts` on the target project to detect duplicate functions and types, then analyze results and propose refactoring.
+Run `similarity-rs` on the target Rust project to detect duplicate functions, struct/enum definitions, and impl methods, then analyze results and propose refactoring.
 
-similarity-ts is installed via nix. check out flake.nix for details.
+If `similarity-rs` is not installed:
+
+```bash
+similarity-rs
+
+# or
+
+direnv exec . similarity-rs
+```
 
 ## Step 1: Run similarity analysis
 
 ```bash
-similarity-ts $ARGUMENTS
+similarity-rs $ARGUMENTS
 ```
 
 If no arguments given:
 
 ```bash
-similarity-ts . --threshold 0.85 --min-tokens 25
+similarity-rs . --threshold 0.85 --min-lines 5
 ```
 
-For type-level duplicates (interfaces, type aliases):
+For struct/enum similarity:
 
 ```bash
-similarity-ts . --threshold 0.85 --experimental-types
+similarity-rs . --threshold 0.85 --experimental-types
 ```
 
 ## Step 2: Analyze results
 
 ### High-priority
 
-- **100% similarity**: Extract shared function
-- **95-100%**: Parameterize the small difference
-- **Duplicate types/interfaces**: Consolidate into a single definition and re-export
+- **100% similarity**: Exact duplicates -> extract shared function or use generics
+- **95-100%**: Same algorithm on different types -> generic function with trait bounds
+- **Duplicate impl methods**: Same logic across types -> trait with default implementation
 
 ### Medium-priority
 
-- **85-95%**: Extract common pattern, especially for API handlers and data processing
-- **Similar type literals**: Shared interface with optional fields
+- **85-95%**: Similar match arms or error handling -> macro or shared helper
+- **Parallel struct definitions**: Identical fields -> shared base or generic struct
 
 ### Acceptable
 
-- **Short utility functions** (< 5 lines) that naturally share structure
-- **Overloaded variants** that differ by type parameter
+- **Short `new()` constructors** with field initialization
+- **Simple `From`/`Into` implementations**
+- **Derive-equivalent implementations**
 
 ## Step 3: Propose refactoring
 
-For each high-priority pair, show before/after code with concrete implementation.
+For each high-priority pair, show before/after code with Rust idioms.
 
 ## Key Options
 
-| Option                          | Description                                              |
-| ------------------------------- | -------------------------------------------------------- |
-| `--threshold <0-1>`             | Similarity threshold (default: 0.85)                     |
-| `--min-tokens <n>`              | Skip functions with fewer AST nodes (recommended: 20-30) |
-| `--print`                       | Show actual code snippets                                |
-| `--experimental-types`          | Enable type/interface similarity detection               |
-| `--experimental-overlap`        | Enable partial overlap detection                         |
-| `--extensions <ext>`            | File extensions to check (comma-separated)               |
-| `--filter-function <name>`      | Filter by function name                                  |
-| `--filter-function-body <text>` | Filter by function body content                          |
-| `--fail-on-duplicates`          | Exit code 1 if duplicates found                          |
-
-## Common TS/JS refactoring patterns
-
-- **Data processing loops** with different field names -> generic mapper
-- **API handlers** with similar request/response logic -> shared middleware
-- **Validation functions** -> schema-based validation
-- **Duplicate interfaces** -> shared base interface with extensions
-- **Similar type literals** -> extract named type
+| Option                     | Description                                      |
+| -------------------------- | ------------------------------------------------ |
+| `--threshold <0-1>`        | Similarity threshold (default: 0.85)             |
+| `--min-lines <n>`          | Skip functions shorter than n lines (default: 3) |
+| `--min-tokens <n>`         | Skip functions with fewer AST nodes              |
+| `--print`                  | Show actual code snippets                        |
+| `--experimental-types`     | Enable struct/enum similarity detection          |
+| `--filter-function <name>` | Filter by function name                          |
+| `--fail-on-duplicates`     | Exit code 1 if duplicates found                  |
+
+## Common Rust refactoring patterns
+
+- **Type-specific functions** -> generic `fn<T: Trait>` with trait bounds
+- **Duplicate impl blocks** across types -> trait with default methods
+- **Repeated match patterns** -> macro_rules! or helper function
+- **Parallel X/Y/Z functions** -> enum parameter or tuple-based abstraction
+- **Similar error handling** -> shared Result combinator or `?` chain
@@ -35,6 +35,23 @@ Follow Anthropic's skill authoring guidance from the Agent Skills best practices
 - Avoid vague descriptions such as "helps with docs" or "processes files".
 - Keep metadata concise because skill names and descriptions are always loaded; Anthropic's size guidance treats frontmatter as roughly 100 words.
 
+Optional file routing fields:
+
+- Use `paths` for Claude-style file matching. It may be a comma-separated glob string or a YAML list.
+- Add `globs` as a compatibility hint when a skill should trigger for file types across agent runtimes.
+- For cross-agent repo-local skills that should apply to TypeScript or JavaScript, include both:
+
+```yaml
+paths:
+  - '**/*.ts'
+  - '**/*.tsx'
+  - '**/*.js'
+  - '**/*.jsx'
+globs: '*.ts,*.tsx,*.js,*.jsx'
+```
+
+- Do not rely only on path metadata for Codex-style discovery; keep the `description` explicit about the file types and actions that should trigger the skill.
+
 For this repo, prefer one or two short sentences, usually around 20-35 words. Do not compress a description so far that it becomes only a label; the agent still needs enough trigger context to choose the skill reliably.
 
 Good pattern:
 
@@ -58,7 +58,7 @@ Prefer running only the tests affected by your changes during the Red-Green-Refa
 **Runner-specific guidance** — Read the relevant example file alongside this skill for detailed test modifiers, idioms, and runner-specific tips:
 
 - **Vitest**: See `references/vitest-examples.md` — test modifiers (`it.todo`, `it.skip`, `it.fails`, etc.), `--changed` flag
-- **Rust (cargo test)**: Use focused runs like `cargo test <name>` and `cargo test -- --ignored`
+- **Rust (cargo test)**: See `references/rust-examples.md` — `#[ignore]`, `#[should_panic]`, filtering, doc tests
 - **Zig (zig test)**: Use `zig test <file> --test-filter <name>` for focused runs
 
 For other runners, adapt the general patterns: