agentleFS
CharleneTStrainCharleneTStrain/product-ops-skills/skills/tool-stack-audit/SKILL.md

tool-stack-audit

Skill0 starsChanged 17 days agoMITView on GitHub

Inventory every tool a product or go-to-market team uses — what it's for, who uses it, what it costs, where it overlaps with others, and who owns it — and recommend what to keep, consolidate, or cut. Use when someone asks for a tool audit, software or SaaS inventory, tech stack review, wants to cut tool spend, find overlapping tools, or figure out who owns which system.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Right-size: keep, but reduce seats or tier

    line 45
  2. Distinctive:

    Cut: not used or fully replaced

    line 47
  3. Distinctive:

    When recommending consolidation, note what would be lost (features, integrations, data, habits) and what migration would take.

    line 50

≈ “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

Tool stack audit

Teams add tools one at a time and almost never remove them. An audit shows the whole stack at once, so overlap, unused seats, and ownerless tools become visible.

Before you start

If .agents/product-ops-context.md exists (or .claude/product-ops-context.md), read it first. Use the team, owners, tools, meetings, and metric definitions it already has, and only ask for what's missing or specific to this task. If it doesn't exist, go ahead with what you're given, and suggest running product-ops-context once so the next skill doesn't have to ask.

Step 1: Inventory

List every tool in scope. Capture what the source shows and mark the rest "Unknown":

ToolWhat it's used forTeam(s)OwnerSeats paidSeats activeAnnual costRenewal dateContract typeConnects to

"What it's used for" is the job, in plain words ("collect in-app feedback"), not the vendor's category name.

Compute totals with real arithmetic.

Step 2: Find the problems

Flag each tool with any that apply:

  • Overlap: two or more tools doing the same job. Group them by job.
  • Low use: many seats paid, few active
  • No owner: nobody responsible for the contract, setup, or renewal
  • Unknown cost: nobody knows what it costs
  • Shadow tool: used by a team but not on any official list
  • Renewal soon: renewing within the next couple of months, so now is the time to decide
  • Single point of failure: one person knows how it's set up
  • Data island: holds important data that doesn't connect to anything else

Step 3: Recommend

For each tool, one recommendation:

  • Keep: clear job, used, owned
  • Right-size: keep, but reduce seats or tier
  • Consolidate into [tool]: overlap; name which one stays and why
  • Cut: not used or fully replaced
  • Investigate: missing information; say what to find out

When recommending consolidation, note what would be lost (features, integrations, data, habits) and what migration would take. A cheaper stack that breaks a workflow isn't a saving.

Output

# Tool stack audit — [Team or scope] — [Date]

**Summary:** [N] tools · [total annual cost] · [N] overlapping jobs · [potential savings, if computable]

## Decide before renewal
| Tool | Renews | Cost | Recommendation | Owner |

## Overlap
- **[Job]:** [Tool A], [Tool B] → Keep [A] because [reason]. Losing: [what]

## All tools
[Inventory table with a Recommendation column]

## Missing information
- [Tool]: [what's unknown] — ask [name]

Recommend only. Never cancel, downgrade, or change any tool or contract.

Related skills

  • vendor-evaluation-scorecard — compare replacements for tools you cut
  • information-debt-audit — find docs stranded in retired tools
  • raci-builder — name an owner for each tool

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.