@xgent-ai/skills 0.1.0 → 0.4.0

package/skills/why/references/sources/slack.md

@@ -0,0 +1,54 @@
+# Slack Conversations
+
+## What this source contains
+
+- Real-time discussions of problems and decisions
+- Incident channels where fire-drill decisions were made
+- Design discussion threads where tradeoffs were debated
+- Questions answered by senior engineers that didn't make it into docs
+- Post-merge discussions that explain why something was revisited
+- DMs (usually not searchable, scope accordingly)
+
+Slack is frequently where the *real* decisions got made, especially for smaller changes that didn't warrant a doc. It's also the most ephemeral source. Threads get deleted, channels get archived, and search quality degrades over time.
+
+## How to search it
+
+Slack MCP tools vary. Check which Slack MCP is available and inspect its tool schema first. It may require `mcp_auth`. If authentication fails, stop and report the gap.
+
+1. **Author-bounded search.** Messages from the PR author around the PR merge date. Limits scope dramatically and often hits gold.
+2. **Keyword search for the feature name and key symbols.** Include misspellings and casual phrasings.
+3. **PR URL search.** Slack often links PRs when they're reviewed or discussed. Search for the PR URL (or just `/pull/<number>`).
+4. **Error string search.** If the code handles a specific error, search for the error string. Incident threads often surface.
+5. **Channel-scoped search.** Narrow to likely channels:
+   - `#eng-*`. Engineering discussions
+   - `#proj-*`. Project channels
+   - `#incident-*` / `#sev-*`. Incident channels
+   - Team-specific channels for the owning team
+   - Design review channels
+6. **Thread traversal.** When you find a relevant message, fetch the whole thread. The decision often lives in the replies.
+
+## What good evidence looks like here
+
+- A thread where tradeoffs were explicitly debated ("I was going to use A but B is better because...")
+- An incident channel message describing the bug the code prevents
+- A question from a reviewer and an authoritative answer from the author or lead
+- A reference to a meeting where a decision was made
+- A message from a product manager or customer-facing engineer explaining a customer ask
+
+## Common pitfalls
+
+- **Channel archaeology limits.** Very old messages may be gone due to retention policies. If you can't find anything before a certain date, note the retention cliff.
+- **Unsearched DMs.** Many decisions happen in DMs that aren't searchable. You'll miss them. That's a known limitation.
+- **Speculative jokes as "decisions."** Slack is casual. "Lol just do the thing" isn't a decision, even if it preceded the commit. Look for considered discussion.
+- **Context collapse in single messages.** Without the thread, a single message often reads differently than in context. Always fetch threads.
+- **Auth failures.** If the MCP isn't authenticated, stop. Don't make up findings. Report that Slack wasn't searchable.
+
+## What to return
+
+For each relevant thread:
+- Channel name
+- Permalink or thread ID
+- Participants
+- Date range of the discussion
+- The key quotes (verbatim) with attribution
+- Context: what thread/incident/discussion this was part of

package/skills/why/references/synthesizer-prompt.md

@@ -0,0 +1,135 @@
+# Synthesizer Prompt Template
+
+Build the synthesizer's prompt from this template. Fill in the placeholders.
+
+---
+
+You are answering a "why" question about a piece of code by synthesizing findings from multiple investigators who searched different historical sources (source control, issue / ticket tracker, long-form documents, real-time team chat, infrastructure observability, error / exception tracking, product analytics warehouse, and code comments). Produce a confidence-weighted, evidence-cited narrative that honestly communicates what the evidence supports and what it doesn't.
+
+## The Question
+
+> {QUESTION}
+
+## The Code Anchor
+
+**Target files:** {FILES_WITH_LINE_RANGES}
+
+**Key symbols:** {SYMBOLS}
+
+## Investigator Findings
+
+{ALL_INVESTIGATOR_FINDINGS}
+
+## Sources That Weren't Searched
+
+{SKIPPED_SOURCES_WITH_REASONS}
+
+## Epistemics Framework
+
+You MUST follow the framework in `references/epistemics.md`. Read it in full before writing the output. The key rules:
+
+1. Every claim sits in one of these tiers: **Direct**, **Supported**, **Inferred**, **Speculative**, **Unknown**. The tier determines what section the claim goes in and how it's phrased.
+2. Every Direct/Supported claim must have a citation (PR #, ticket ID, doc URL, chat permalink, commit hash, or file:line).
+3. Inferred and Speculative claims must use hedged language ("appears to", "likely", "suggests", "one possibility is").
+4. Never cite code as evidence for its own intent.
+5. Gaps in the evidence must be documented. Don't fill them with plausible-sounding guesses.
+6. If the user's question embedded a hypothesis, treat it as a candidate, not a conclusion. Check the evidence independently.
+
+## Instructions
+
+1. **Read all investigator findings.** They gathered raw evidence, not conclusions. You weigh it.
+2. **Reconcile overlapping findings.** Multiple investigators may have cited the same PR, ticket, or doc. Merge into a single, authoritative reference.
+3. **Identify contradictions.** If two items of evidence disagree, don't pick one. Surface both.
+4. **Calibrate confidence.** For each claim, identify the evidence and the tier. State Direct claims plainly with a citation. Hedge Inferred claims and explain the inference. Mark Speculative claims explicitly. Put claims with no evidence in the gaps section.
+5. **Verify citations by spot-checking.** You can read the codebase and call MCP tools to verify citations. Do not write files, commit, or modify external state. If you're uncertain a cited item exists or says what's claimed, check it. Don't propagate errors.
+6. **Don't overreach.** The user will act on your output. Better to leave an open question open than to fill it with a confident-sounding guess.
+
+## Output Format
+
+Write the output for the user. Use this exact structure:
+
+---
+
+### The Question
+
+Restate the user's question in one or two sentences so the answer is anchored.
+
+### The Code in Question
+
+File paths, line ranges, key symbols. Two or three lines to orient a reader who lands here cold.
+
+### What We Found
+
+**Claims with direct evidence**, one per bullet. Quote or paraphrase the source and cite precisely. Format each finding like:
+
+- **[Direct]** {Claim}. Source: [PR #123](url) / ticket ID / file:line. {Brief quote or paraphrase.}
+- **[Supported]** {Claim}. Evidence: {list of items and what each contributes}.
+
+Use `[Direct]` for single-source, explicit evidence. Use `[Supported]` when multiple indirect items converge on a conclusion.
+
+### What We Can Reasonably Infer
+
+**Claims that aren't explicitly stated anywhere but are well-supported by indirect evidence.** Make the inference chain visible: "Given A and B, it's likely that C." Use hedged language ("appears to", "likely", "suggests", "is consistent with"). Format:
+
+- **[Inferred]** {Hedged claim}. Reasoning: {the specific evidence and the inference step}.
+
+If there's nothing to infer, skip this section.
+
+### Competing Hypotheses
+
+**If the evidence fits multiple stories, present them.** Don't force a winner when the record doesn't support one. For each hypothesis:
+
+- **Hypothesis:** {one-sentence statement}
+- **Evidence for:** {specific items}
+- **Evidence against or missing:** {what would need to be true but isn't, or what counter-signals exist}
+
+Skip this section if there's a single clear answer.
+
+### What We Don't Know
+
+**Explicit gaps.** Things the user asked that the evidence didn't answer. Sources searched that came up empty. Sources that weren't searchable at all, such as a missing real-time team chat MCP.
+
+Be specific. "We searched the issue tracker for [query1], [query2], [query3] and found no issue discussing the rate-limit threshold" is useful. "We don't know why" is not. Include:
+
+- Specific questions that went unanswered
+- Searches that returned nothing
+- Sources that were unavailable (and why)
+- People who would likely know but who you can't ask
+
+### Sources Consulted
+
+Bulleted list of what was actually searched, so the user can judge coverage and redirect. Format:
+
+- **Source control history**: {file paths}, {number of commits reviewed}, PRs #{numbers}, and code comments searched. Or "Not searched. This should not happen because git and `gh` are always expected."
+- **Issue / ticket tracker**: {ticket IDs and keyword searches}. Or "Not searched. No matching MCP available in this environment."
+- **Long-form documents**: {page titles and search queries}. Or "Not searched. No matching MCP available in this environment."
+- **Real-time team chat**: {channels searched, date ranges, queries}. Or "Not searched. No matching MCP available in this environment."
+- **Infrastructure observability**: {dashboards, monitors, metrics, logs, traces, or incidents searched}. Or "Not searched. No matching MCP available in this environment."
+- **Error / exception tracking**: {issues, events, or releases searched}. Or "Not searched. No matching MCP available in this environment."
+- **Product analytics warehouse**: {fully-qualified tables queried, the time windows, and the numeric summaries (counts, percentiles, first/last-seen timestamps) that bore on the question}. Or "Not searched. No matching MCP available in this environment."
+
+### Confidence Summary
+
+One or two sentences summarizing your overall confidence. E.g.:
+
+> "The core rationale (A) is well-supported by direct PR and ticket evidence. The specific threshold value (100) is inferred from the surrounding context but not explicitly documented. The question of whether this was driven by a customer request could not be answered. No relevant issue tracker or long-form doc content surfaced, and real-time team chat search was unavailable."
+
+---
+
+## Quality Check Before Returning
+
+Before finalizing, review your output against this checklist:
+
+1. Does every claim in "What We Found" have a citation? If not, add one or move the claim to "Inferred" or "Hypotheses."
+2. Is the phrasing tier-appropriate? (Direct claims can use "because". Inferred claims cannot.)
+3. Did you surface any contradictions you noticed, or did you quietly pick one?
+4. Does the "What We Don't Know" section exist and name specific gaps? If it's empty or missing, be suspicious. Historical investigations almost always have gaps.
+5. If the user embedded a hypothesis in their question, did you check it against the evidence rather than rubber-stamping it?
+6. Did you cite any code as evidence for its own intent? Remove those. Code is mechanics, not motivation.
+7. Is the overall tone calibrated? A confident-sounding answer with weak evidence is the exact failure mode this skill exists to prevent.
+
+If any item fails, revise before returning.
+
+## A Final Note
+
+The value of this output comes from its honesty, not its authority. A reader who takes your answer to the original author, an engineering lead, or a product manager should be well-positioned to ask the right follow-up questions. Be clear about what's known, what's inferred, and what's missing. Don't optimize for looking decisive. Optimize for being useful.

package/skills/working-with-mbx/SKILL.md

@@ -0,0 +1,343 @@
+---
+name: working-with-mbx
+description: Use when installing, activating, or troubleshooting mbx (Mr. Boxington), the shared compiler cache for Cargo - verifies that plain cargo actually goes through mbx, reads hit/miss/bypass summaries, diagnoses low cache reuse, and manages target/cache disk usage
+---
+
+# Working with mbx
+
+## Overview
+
+mbx (Mr. Boxington) is a shared compiler cache for Cargo, plus automatic management of
+`target/` directories. Cargo still resolves dependencies and decides what needs building;
+mbx restores matching compilations and runs the compiler for everything else.
+
+Use this skill when:
+- Installing mbx or enabling it for plain `cargo` commands
+- A build reports few cache hits and you need to know why
+- Deciding whether an mbx result (hit / miss / bypass) is expected
+- Reclaiming disk from the cache store or managed target directories
+- Adding mbx caching to CI, or migrating off sccache / rust-cache
+
+## The Iron Rules
+
+1. **Never combine mbx with sccache** - both wrap rustc through `RUSTC_WRAPPER`. If
+   `RUSTC_WRAPPER` is already set, mbx defers to it and the build is **not cached**.
+2. **Verify activation by Cargo's path, not by `mbx doctor` alone** - doctor does not
+   recognize the native mise Rust tool option, so its setup warning alone does not mean
+   wrapping is inactive.
+3. **Diagnose before deleting** - run `mbx explain` on the build. Clearing the cache
+   destroys evidence and the next build just runs cold.
+4. **Measure reuse with two fresh target directories** - rerunning the same command in
+   the same target measures Cargo's freshness check, not mbx.
+
+## Install
+
+### With mise (preferred)
+
+```bash
+mise use --global --tool-option mr_boxington=true rust mr-boxington
+```
+
+Requires mise 2026.9.2 or newer. This installs Rust and mbx and enables Cargo wrapping
+through mise - no `mbx setup` needed. `--tool-option` applies to the **following** tool,
+so it must stay before `rust`. Drop `--global` to enable it only in the current project.
+
+To share it with a project, commit both tools in `mise.toml`:
+
+```toml
+[tools]
+rust = { version = "stable", mr_boxington = true }
+mr-boxington = "latest"
+```
+
+Both entries are required. Keep the project's existing Rust version when adding
+`mr_boxington = true`. Run `mise install`, then build.
+
+### Without mise
+
+```bash
+cargo install mbx --locked
+mbx --version
+```
+
+Release archives for Linux (x86-64/ARM64, glibc and musl), macOS Apple Silicon, and
+Windows (x86-64/ARM64) are on GitHub Releases with `SHA256SUMS`. See
+[references/installation.md](references/installation.md).
+
+To make plain `cargo` use mbx from a standalone install:
+
+```bash
+mbx setup
+mbx setup --status
+```
+
+`mbx setup` also configures rust-analyzer's background check - the native mise option
+does not. Scope it with `--global` or `--local`; `--yes` accepts the recommendation.
+
+## Verify mbx Is Actually Being Used
+
+This is the single most common failure: builds succeed, but nothing is cached.
+
+```bash
+command -v cargo     # Unix
+mbx doctor
+```
+
+On Windows use `(Get-Command cargo).Path` or `where.exe cargo`.
+
+`cargo` should resolve to one of:
+- mise's command wrapper (e.g. `~/.local/share/mise/command-wrappers/bin/cargo`)
+- a mise shim
+- the stable mbx shim from `mbx setup`
+
+**Calling `~/.cargo/bin/cargo` directly bypasses mise's integration entirely.**
+
+### Non-interactive contexts (coding agents, SSH, desktop apps)
+
+These often inherit a different `PATH` than an interactive terminal. Use either:
+
+```bash
+mise exec -- cargo build      # explicit, always works
+```
+
+or put mise's shims directory on that process's `PATH`. Check with `command -v cargo`
+run *by the application itself*, and restart the app after changing its environment.
+Prefixing with `mbx` also always works: `mbx build`.
+
+## Running Builds
+
+`mbx` passes Cargo arguments through unchanged:
+
+```bash
+mbx build
+mbx test --workspace --all-features
+mbx clippy --workspace --all-targets -- -D warnings
+mbx +stable check --workspace          # rustup-style toolchain selection
+```
+
+Use the same toolchain, features, and profile across builds to reuse the same cached work.
+
+## Reading the Result
+
+A build prints a summary like:
+
+```
+mbx[cache]: 139 hits, 8 misses, 4 not looked up, 147 prefetched, 7 bypassed; 312.4 MiB downloaded, 0 B uploaded, 280.1 MiB stored locally
+```
+
+| Result | What happened |
+| --- | --- |
+| Hit | mbx restored a matching compilation |
+| Miss | No result matched the key; successful compilation fills the cache |
+| Not looked up | mbx lacked a usable input prediction and had to compile first |
+| Bypassed | The invocation ran without shared caching |
+
+Counts describe compiler actions mbx observed. They do **not** include work Cargo skipped
+because its outputs were already fresh - which is why a rerun can show zero hits.
+
+```bash
+mbx explain --last              # inspect the last recorded build, without running Cargo
+mbx explain build --workspace   # run a build with diagnostics (preserves Cargo's exit status)
+MBX_SUMMARY=full mbx build      # detailed breakdown
+mbx tui                         # watch a build live, one row per compilation
+```
+
+### Measure real cache reuse
+
+```bash
+mbx build --target-dir target/cache-demo-first
+mbx build --target-dir target/cache-demo-second
+```
+
+The second build can restore work recorded by the first. Use directory names that do not
+already contain build outputs, and remove them afterwards - explicit targets are not
+managed. Always compare wall-clock time too; "compiler time avoided" is summed across
+actions, not elapsed time saved.
+
+## Troubleshooting a Low Hit Rate
+
+Run `mbx explain build --workspace` first - it groups identical causes and prints guidance
+per category. Usual causes, roughly in the order they appear:
+
+- **The store is cold.** A first build has no dep-info to derive keys from, so
+  "could not look up" can dominate.
+- **Incremental builds are enabled.** With `MBX_INCREMENTAL=1`, workspace members compile
+  incrementally, those compilations bypass the cache, and crates above them miss too.
+- **A link could not be described.** Native executables, tests, and proc macros are cached
+  on Linux, macOS, and Windows, but links with custom or unmodeled inputs still run.
+- **The inputs differ.** A different toolchain, feature set, profile, or `RUSTFLAGS`
+  between checkouts is a different key, reported as an ordinary miss.
+- **Build-script output differs.** A build script that embeds the checkout path in its
+  output prevents reuse across checkouts.
+- **The build chose its own C compiler.** Setting `CC`, `HOST_CC`, `CXX`, or `HOST_CXX`
+  leaves host compilations outside mbx.
+- **A Rust update.** The compiler is part of every key, so a toolchain roll invalidates
+  every rustc action at once. This is expected, not a bug.
+
+For a per-compilation record: `MBX_BYPASS_LOG=bypass.log mbx build`.
+
+### Bypasses that are expected
+
+`compiler-query` and `standard-input` are routine compiler probes with no output to cache.
+The short summary leaves them out of its bypass count. Don't chase them.
+
+## Other Common Symptoms
+
+| Symptom | First check |
+| --- | --- |
+| Plain Cargo does not use mbx | `command -v cargo`; for standalone setup also `mbx setup --status` |
+| Cargo waits for a target lock | Give simultaneous builds separate target directories |
+| Cargo metadata fails before a build | `cargo metadata --no-deps --format-version 1` |
+| Build storage is on NFS | Move `cache_dir` / `target.root` to local storage (mbx refuses NFS) |
+| Remote requests fail | `mbx doctor`, then check authentication |
+| Storage larger than expected | `mbx cache stats`, then `mbx gc --dry-run` |
+
+### Bypass mbx for one command
+
+```bash
+MBX_DISABLE=1 cargo build
+```
+
+### Reporting a problem
+
+```bash
+mbx doctor --json
+MBX_LOG=debug mbx build
+MBX_BYPASS_LOG=bypass.log mbx build
+```
+
+These name absolute cache paths, any configured remote, and the crates you build.
+Credentials are never printed.
+
+## Managed Target Directories
+
+Managed targets are **on by default**. For a checkout without an existing `target/`, mbx
+places the target under its cache root and leaves a symlink:
+
+```
+target -> <cache root>/targets/v1/<checkout digest>
+```
+
+In a Git checkout, mbx adds the link path to `.git/info/exclude` when necessary, so
+`git status` stays clean without touching the project's `.gitignore`.
+
+mbx leaves the target alone when `--target-dir`, `CARGO_TARGET_DIR`, or Cargo's
+`build.target-dir` names it.
+
+Bring existing directories under management without deleting their contents:
+
+```bash
+mbx adopt                            # the current checkout
+mbx adopt --recursive --dry-run ~/src  # preview
+```
+
+Disable placement with `MBX_TARGET_VIEWS=0` or `[target] views = false`.
+
+## Disk Management
+
+```bash
+mbx cache stats     # action store, managed targets, learned incremental state
+mbx cache dir       # where the store lives
+mbx gc --dry-run    # preview collection under the configured budgets
+mbx gc              # collect
+mbx clean           # this workspace's managed target, link, and incremental state
+mbx cache remove /path/to/workspace   # the above, plus forget its cache claims
+mbx stats           # lifetime savings
+```
+
+Collection runs automatically after builds, at most once an hour. Budgets scale with the
+disk holding the data:
+
+| Budget | Default | Bounds |
+| --- | --- | --- |
+| `gc.max_size` (action store) | 5% of the disk | 5 GiB to 500 GiB |
+| `target.max_size` (managed targets) | 10% of the disk | 10 GiB to 100 GiB |
+| `gc.incremental_max_size` (learned incremental) | 5% of the disk | 10 GiB to 100 GiB |
+
+Managed targets are also collected after `target.max_age` (30 days) unused, and whenever
+their checkout is gone. The cache is disposable - it can always be rebuilt. Note that
+`cargo clean` does **not** remove mbx's private incremental state; `mbx clean` does.
+
+## Configuration
+
+Three sources, first value found wins:
+
+1. Environment variables (`MBX_*`)
+2. `.mbx.toml` at the Cargo workspace root - **build-policy and scheduler settings only**
+3. `mbx/config.toml` in the platform config directory:
+   - Linux: `~/.config/mbx/config.toml`
+   - macOS: `~/Library/Application Support/mbx/config.toml`
+   - Windows: `%APPDATA%\mbx\config.toml`
+
+Unknown TOML keys are rejected, so a misspelled setting is an error. Machine paths,
+remote-cache configuration, credentials, target placement, and garbage collection are
+**not** accepted from a repository's `.mbx.toml`.
+
+Keep a laptop responsive by capping the machine-wide compiler pool (it defaults to every
+logical CPU and 85% of physical memory):
+
+```toml
+[scheduler]
+cpus = 4
+memory = "8GiB"
+```
+
+Per-feature off switches:
+
+| Switch | Turns off |
+| --- | --- |
+| `MBX_SCHEDULER=0` | machine-wide compile scheduling |
+| `MBX_CC=0` | build-script and `mbx exec` C/C++ caching |
+| `MBX_TARGET_VIEWS=0` | managed target directories |
+| `MBX_CACHE_LINKS=0` | native link caching |
+| `MBX_LEARNED_INCREMENTAL=0` | learned incremental reuse |
+| `MBX_SAVINGS=off` | the savings line |
+
+## CI
+
+```yaml
+steps:
+  - uses: actions/checkout@v7
+  - uses: jdx/mr-boxington-action@v1
+  - run: mbx test --workspace
+```
+
+Install the toolchain **before** the action - generated keys cover the OS, architecture,
+and the identity of the `rustc` on `PATH`. Pushes to the default branch fill the archive;
+pull requests, including from forks, are restore-only. mbx automatically uses its
+explanatory CI summary when `CI` or `GITHUB_ACTIONS` is set.
+
+Migrating from sccache is **removal**: take it out of `RUSTC_WRAPPER`,
+`build.rustc-wrapper` in `~/.cargo/config.toml`, and any install steps, then run
+`mbx doctor`. Migrating from rust-cache is replacing the action - running both over the
+same paths adds duplicate restore/save work.
+
+## Available References
+
+- [references/getting-started.md](references/getting-started.md) - install to first cached build
+- [references/setup.md](references/setup.md) - Cargo wrapping, rust-analyzer, verifying Cargo's path
+- [references/troubleshooting.md](references/troubleshooting.md) - symptom table and diagnostics
+- [references/cache-results.md](references/cache-results.md) - hit/miss/bypass, measuring reuse
+- [references/limits.md](references/limits.md) - exactly what mbx will and will not cache
+- [references/managed-targets.md](references/managed-targets.md) - target placement, adoption, budgets
+- [references/configuration.md](references/configuration.md) - full setting reference
+- [references/incremental.md](references/incremental.md) - learned incremental reuse
+- [references/scheduling.md](references/scheduling.md) - parallel builds, machine-wide pool
+- [references/github-action.md](references/github-action.md) - CI setup
+- [references/cookbook/migrate.md](references/cookbook/migrate.md) - from sccache or rust-cache
+- [references/cookbook/local-development.md](references/cookbook/local-development.md) - editors, watch loops, debugging
+- [references/remote-cache.md](references/remote-cache.md) - cache server and S3 backends
+- [references/cli/](references/cli/) - per-command flags and arguments
+
+Refresh all of the above with `./update-docs.sh`.
+
+## Red Flags - You're About to Violate
+
+- Leaving sccache configured "just in case" → mbx silently stops caching
+- "`mbx doctor` warned about setup, so mbx isn't active" → check `command -v cargo` first
+- Running the same build twice in one target to prove caching works → measures Cargo freshness
+- Clearing the cache to fix a low hit rate → run `mbx explain --last` first
+- Chasing `compiler-query` / `standard-input` bypasses → routine probes, nothing to cache
+- Telling a coding agent or CI script to call `~/.cargo/bin/cargo` → bypasses mise integration
+- Putting `[remote]` credentials in a checked-in `.mbx.toml` → rejected; use env vars
+- Adding `cargo clean` to a watch loop → throws away Cargo's freshness information

package/skills/working-with-mbx/references/acknowledgements.md

@@ -0,0 +1,37 @@
+Acknowledgements
+
+Acknowledgements [​](#acknowledgements)
+
+mbx depends on Cargo and builds on ideas established by earlier compiler caches. In particular, kache directly inspired the project's design.
+
+## Cargo [​](#cargo)
+
+[Cargo](https://github.com/rust-lang/cargo) resolves dependencies, plans builds, and orchestrates rustc. Its `RUSTC_WRAPPER` integration lets mbx and other Rust compiler caches wrap compiler invocations.
+
+## sccache [​](#sccache)
+
+[sccache](https://github.com/mozilla/sccache) predates mbx and established compiler caching in the Rust ecosystem. It reuses compiler work locally and through remote storage, and supports a broader set of compilers and use cases than mbx.
+
+See the [comparison with sccache](https://mr-boxington.jdx.dev/compared#sccache) for where mbx makes different tradeoffs.
+
+## kache [​](#kache)
+
+[kache](https://github.com/kunobi-ninja/kache) predates mbx and directly inspired its design. It combines a content-addressed `RUSTC_WRAPPER` cache with C and C++ compiler shims, remote storage, and executable caching.
+
+The projects do not share code. Both aim to make compiled work reusable across checkouts; they differ in process lifecycle, storage management, and remote policy. The [comparison with kache](https://mr-boxington.jdx.dev/compared#kache) explains where mbx took a different direction and where kache may be the better fit.
+
+## cargo-pretty [​](#cargo-pretty)
+
+[cargo-pretty](https://github.com/romancitodev/cargo-pretty) by [romancitodev](https://github.com/romancitodev) provides the base for mbx's Cargo display: live and completed crate rows, per-crate timers, fading, and browsable warnings. mbx adds cache statistics and a progress bar colored by hits, misses, and bypasses while retaining Cargo's native run and test execution.
+
+The adapted source retains romancitodev's MIT license and records the upstream revision in the repository's `NOTICE` file.
+
+[Edit this page on GitHub](https://github.com/jdx/mr-boxington/edit/main/docs/acknowledgements.md)
+
+Last updated:
+
+Pager
+
+[Previous pageProtocol compatibility](https://mr-boxington.jdx.dev/protocol-compatibility)
+
+MIT License·Copyright © 2026· [jjdx.dev](https://jdx.dev)