agentleFS
Sign inStart free
jabbott-iiijabbott-iii/Tidepool/.claude/skills/add-managed-tool/SKILL.md

add-managed-tool

Skill1 starsChanged 12 days agoApache-2.0View on GitHub

Use when Tidepool must find, install, update or drive a new outside program (or change how it handles an existing one), such as rust-analyzer, git, an SDK package, Xcode tools, a debug adapter or an LSP server. Adds the descriptor, detection, install plan, tests and Toolchains-panel row per ADR-0002.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If a fact can't be verified, write "unverified" and leave the roadmap box unchecked with a ⏳ note.

    line 29
  2. Very specific:

    Run cargo xtask tools. Until M5.1 lands it exits 1 as not yet implemented.

    line 37
  3. Very specific:

    Add or update the row in docs/02-dependency-policy.md → "Managed tools" and in docs/subsystems/toolchains.md.

    line 66
  4. Very specific:

    Ask security-reviewer to review.

    line 68

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Add or update a managed tool

Request: $ARGUMENTS

Outside programs are managed tools (ADR-0002): Tidepool installs, updates, configures and drives them through their official channels, and never bundles or reimplements them. Read docs/subsystems/toolchains.md and the "Managed tools" table in docs/02-dependency-policy.md first.

1. Research the tool (with the web tools; cite sources)

  • Official install and update channel per OS (installer, package manager, vendor tool such as rustup or sdkmanager), and whether it needs admin rights.
  • Official download URL and published checksum, if Tidepool downloads anything itself.
  • License, and how the user accepts it.
  • How to detect it: env vars, standard locations, PATH name, version command and output format. Check the installed tool's --help if this session has it.
  • Output formats Tidepool will parse (machine-readable flags such as --porcelain, --message-format=json, -z).
  • If a fact can't be verified, write "unverified" and leave the roadmap box unchecked with a ⏳ note.

2. Descriptor (toolchains/<tool>.toml)

  • id, purpose, platforms, minimum and recommended versions, detection rules, install/update steps per OS, download URL + SHA-256 (pinned; never fetched at runtime), license entry, and the features it unlocks.
  • Run cargo xtask tools. Until M5.1 lands it exits 1 as not yet implemented; say so rather than report a pass.

3. Code in tidepool-toolchain

  • Detection and version parsing (with a timeout).
  • Install and update plans: every step is listed to the user before anything runs; downloads go through download and are SHA-256 checked; license prompts and admin commands run in the integrated terminal when the user presses Run; nothing is piped into prompts.
  • Spawning through process/sessions only: argv vector, explicit env, output caps, kill on shutdown. Secrets only through SecretArg / SecretEnv.
  • Respect workspace files that pin versions (rust-toolchain.toml, Gradle wrapper) and workspace trust (ADR-0014).

4. Tests

  • A fake tool in crates/testkit/fake-tools/ reproducing real output for found, missing, outdated and error cases, including slow responses.
  • Parser fuzz target for any output format parsed.
  • A gated real-tool test (TIDEPOOL_IT_<AREA>=1) that prints SKIPPED: <reason> when unavailable.
  • A test that no constructed argv contains a secret, if the tool takes any.

5. UI and docs

  • A Toolchains-panel card (status dot, version, path, actions) and, if needed, the tool's own panel in editor.
  • Add or update the row in docs/02-dependency-policy.md → "Managed tools" and in docs/subsystems/toolchains.md.
  • Ask security-reviewer to review.

6. Report

Sources checked, descriptor values, tests run with results, gated tests not run, and anything still unverified.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free