feat: adopt tuff for capability management, add an agent-top skill

.agents/mcp-servers/linear/server.toml

@@ -0,0 +1,15 @@
+id = "linear"
+version = "1.0.0"
+type = "mcp-server"
+description = "Find, create, and update Linear issues, projects, and comments. Authenticates with a Linear API key; the interactive OAuth flow is not used."
+
+[server]
+transport = "http"
+args = []
+url = "https://mcp.linear.app/mcp"
+
+[server.env]
+
+[server.headers.Authorization]
+from_env = "LINEAR_API_KEY"
+format = "Bearer {}"

.agents/mcp.json

@@ -0,0 +1,11 @@
+{
+  "mcpServers": {
+    "linear": {
+      "headers": {
+        "Authorization": "Bearer ${LINEAR_API_KEY}"
+      },
+      "type": "http",
+      "url": "https://mcp.linear.app/mcp"
+    }
+  }
+}

.agents/skills/agent-top/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: agent-top
+description: Use agent-top to see what coding-agent sessions (Claude Code, Codex, Gemini CLI, OpenCode) are running on this machine, or to debug one after the fact — cost, token burn, why a turn is slow, a tool call that never came back, or an MCP server process left running with no agent above it. Trigger on "why is this agent slow/expensive", "what has this session cost", "check for a leaked/orphaned MCP process", "trace this session", or before assuming a hang is the model thinking rather than a tool call stuck.
+---
+
+# Using agent-top
+
+agent-top is a read-only process/transcript viewer for coding-agent sessions. It never signals or kills a process and never writes to a transcript, so it is always safe to run alongside whatever is being debugged. If the command is missing: `brew install kannandreams/tap/agent-top` or `cargo binstall agent-top`.
+
+## Right now, on this machine
+
+```sh
+agent-top            # live table, one row per session, refreshed every second
+agent-top --once     # the same information, printed once and exit — for a quick look or a script
+agent-top --json      # one snapshot as JSON — pipe it, or attach it to a bug report
+```
+
+STATE and COST are the two columns to read first: `running` is mid-turn, `idle` is waiting on you, `stopped` is a transcript with no live process. Cost is priced from the harness's own usage records, not estimated. Select a row to see its detail pane: process tree, MCP servers, and context-by-source (which tool's results are filling the prompt and what re-reading them has cost since).
+
+## What has this cost so far
+
+```sh
+agent-top report --since 7d --by harness   # or --by day, --by model, --by project
+agent-top report --since all --json        # every session on disk, machine-readable
+```
+
+Reads the transcripts already on disk; no daemon, nothing has to have been running.
+
+## Why is this session slow
+
+Select the session and press `Tab` to switch the detail pane to the tool-call waterfall, or export it:
+
+```sh
+agent-top trace --session <id-or-prefix> -o trace.json            # Chrome trace, open in ui.perfetto.dev
+agent-top trace --session <id-or-prefix> --format otlp -o t.json  # OTLP/JSON, for Jaeger/Tempo/a collector
+```
+
+The header line above the waterfall gives the split between tool time and inference time (overlapping calls merged, not summed). A single wide bar on the tools track is one slow call; a row of narrow bars back to back is the model calling a cheap tool repeatedly instead of batching. A bar that starts and never closes is a tool call that never got a result back — check that before trusting whatever the agent did next. Subagent calls sit on their own track, so a fan-out that should have run in parallel but didn't is visible as bars with gaps instead of bars stacked on top of each other.
+
+`--session` takes a session id, a unique prefix of one, or a path to the transcript file directly; it works on a session that already ended, since the trace is reconstructed from the transcript rather than from live telemetry.
+
+## Is a process leaking
+
+The detail pane lists orphaned MCP servers in red: a process with no live agent above it, its pid, memory, and (when known) which agent it was orphaned from and how long ago. agent-top only reports the pid — killing it is a manual `kill`, on purpose.
+
+## Everything above works on someone else's machine too
+
+```sh
+agent-top --json > snap.json
+agent-top --replay snap.json   # the same screen, reconstructed, no local data read
+```
+
+Ask for the `--json` snapshot instead of a description when a report doesn't make sense — it reproduces exactly.

.agents/skills/rust-best-practices/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: rust-best-practices
+description: >
+  Guide for writing idiomatic Rust code based on Apollo GraphQL's best practices handbook. Use this skill when:
+  (1) writing new Rust code or functions,
+  (2) reviewing or refactoring existing Rust code,
+  (3) deciding between borrowing vs cloning or ownership patterns,
+  (4) implementing error handling with Result types,
+  (5) optimizing Rust code for performance,
+  (6) writing tests or documentation for Rust projects.
+license: MIT
+compatibility: Rust 1.70+, Cargo
+metadata:
+  author: apollographql
+  version: "1.1.1"
+allowed-tools: Bash(cargo:*) Bash(rustc:*) Bash(rustfmt:*) Bash(clippy:*) Read Write Edit Glob Grep
+---
+
+# Rust Best Practices
+
+Apply these guidelines when writing or reviewing Rust code. Based on Apollo GraphQL's [Rust Best Practices Handbook](https://github.com/apollographql/rust-best-practices).
+
+## Best Practices Reference
+
+Before reviewing, familiarize yourself with Apollo's Rust best practices. Read ALL relevant chapters in the same turn in parallel. Reference these files when providing feedback:
+
+- [Chapter 1 - Coding Styles and Idioms](references/chapter_01.md): Borrowing vs cloning, Copy trait, Option/Result handling, iterators, comments, when to extract a function (duplication vs. wrong abstraction)
+- [Chapter 2 - Clippy and Linting](references/chapter_02.md): Clippy configuration, important lints, workspace lint setup
+- [Chapter 3 - Performance Mindset](references/chapter_03.md): Profiling, avoiding redundant clones, stack vs heap, zero-cost abstractions
+- [Chapter 4 - Error Handling](references/chapter_04.md): Result vs panic, thiserror vs anyhow, error hierarchies
+- [Chapter 5 - Automated Testing](references/chapter_05.md): Test naming, one assertion per test, snapshot testing
+- [Chapter 6 - Generics and Dispatch](references/chapter_06.md): Static vs dynamic dispatch, trait objects
+- [Chapter 7 - Type State Pattern](references/chapter_07.md): Compile-time state safety, when to use it
+- [Chapter 8 - Comments vs Documentation](references/chapter_08.md): When to comment, doc comments, rustdoc
+- [Chapter 9 - Understanding Pointers](references/chapter_09.md): Thread safety, Send/Sync, pointer types
+
+## Quick Reference
+
+### Borrowing & Ownership
+- Prefer `&T` over `.clone()` unless ownership transfer is required
+- Use `&str` over `String`, `&[T]` over `Vec<T>` in function parameters
+- Small `Copy` types (≤24 bytes) can be passed by value
+- Use `Cow<'_, T>` when ownership is ambiguous
+
+### Error Handling
+- Return `Result<T, E>` for fallible operations; avoid `panic!` in production
+- Never use `unwrap()`/`expect()` outside tests
+- Use `thiserror` for library errors, `anyhow` for binaries only
+- Prefer `?` operator over match chains for error propagation
+
+### Performance
+- Always benchmark with `--release` flag
+- Run `cargo clippy -- -D clippy::perf` for performance hints
+- Avoid cloning in loops; use `.iter()` instead of `.into_iter()` for Copy types
+- Prefer iterators over manual loops; avoid intermediate `.collect()` calls
+
+### Linting
+Run regularly: `cargo clippy --all-targets --all-features --locked -- -D warnings`
+
+Key lints to watch:
+- `redundant_clone` - unnecessary cloning
+- `large_enum_variant` - oversized variants (consider boxing)
+- `needless_collect` - premature collection
+
+Use `#[expect(clippy::lint)]` over `#[allow(...)]` with justification comment.
+
+### Testing
+- Name tests descriptively: `process_should_return_error_when_input_empty()`
+- One assertion per test when possible
+- Use doc tests (`///`) for public API examples
+- Consider `cargo insta` for snapshot testing generated output
+
+### Generics & Dispatch
+- Prefer generics (static dispatch) for performance-critical code
+- Use `dyn Trait` only when heterogeneous collections are needed
+- Box at API boundaries, not internally
+
+### Type State Pattern
+Encode valid states in the type system to catch invalid operations at compile time:
+```rust
+struct Connection<State> { /* ... */ _state: PhantomData<State> }
+struct Disconnected;
+struct Connected;
+
+impl Connection<Connected> {
+    fn send(&self, data: &[u8]) { /* only connected can send */ }
+}
+```
+
+### Documentation
+- `//` comments explain *why* (safety, workarounds, design rationale)
+- `///` doc comments explain *what* and *how* for public APIs
+- Every `TODO` needs a linked issue: `// TODO(#42): ...`
+- Enable `#![deny(missing_docs)]` for libraries