Every internal tools team hits the same wall eventually: fourteen admin panels, dashboards, and ops consoles, each one built by whoever had a free week that sprint, each one a little different from the last. One is React with Tailwind, one is a Rails admin view with inline styles from three years ago, one is a Retool app nobody remembers the login for. A new request comes in, refund approvals need a bulk-action view, and the engineer assigned to it does not reuse anything. There is nothing consistent to reuse. They rebuild pagination, rebuild the auth gate, rebuild the CRUD form pattern, because the last three tools that needed the exact same pattern each solved it their own way. Three weeks later there is tool number fifteen, and it looks and behaves nothing like the other fourteen, and the one engineer who understands why the refund console works the way it does is the same one who is about to move to a different team with nothing written down.
Why a generalist chatbot and Cursor both miss this problem
Ask ChatGPT or Claude.ai to help build the fifteenth internal tool and it will happily generate a React admin panel from your description. What it will not do is ask whether thirteen of your other tools already solved this exact pagination problem, or whether the auth pattern you are about to hand-roll again is the fourth reimplementation of the same session check. A generalist chatbot has no visibility into your actual internal tools inventory. It cannot read your fourteen existing repos, cannot tell you which ones share a framework and which ones do not, and cannot tell you that the DataTable component you are about to write from scratch already exists, slightly differently, in three other places. It answers the prompt in front of it. It has no concept of a service catalog, no concept of a golden path, and no mechanism for noticing that internal tools sprawl is the actual problem, not any single dashboard.
Cursor and GitHub Copilot are faster at writing the fifteenth tool's code than a human typing alone, but speed at the keystroke level does not fix the sprawl. Autocomplete tools work inside the file you have open. They do not audit your bundle size across all fourteen tools, do not flag that half of them are still on an unmaintained UI library, and do not produce a starter template that the next engineer can scaffold from in an afternoon instead of three weeks. Ask Copilot to help scope a shared component library across your internal tools and it has no answer, that is not a completion, it is a platform decision that requires reading the whole inventory first. The result is that every internal tool built with an autocomplete assistant still starts from a mostly blank file, just written a little faster than before.
The mismatch is structural. Internal tools sprawl is not a single-file problem, it is a cross-repo consistency problem, and neither a generalist chatbot nor an autocomplete layer has any mechanism for seeing across repos, cataloging what exists, or defining the one supported way to build the next dashboard. That requires a different kind of agent, one built to treat developer experience itself as the product, not the dashboard as an isolated deliverable.
Meet Pave: the agent that treats internal tools as a system, not a pile of one-offs
Pave is Tonone's developer experience engineer, built around golden paths and service catalogs rather than any single tool's feature list. Where a generalist assistant answers the prompt it is given, Pave starts by asking what already exists. Before it recommends a component library, a starter template, or an auth pattern, it inventories every internal tool your team actually maintains: what framework each one uses, who owns it, how outdated its dependencies are, and how it handles auth. That inventory is the difference between guessing at a fix and knowing exactly what fourteen tools have in common and where they diverge.
Tonone's Pave treats internal tools sprawl as a catalog problem first: know what exists before you standardize how the next one gets built.
Cataloging what already exists
The pave-catalog skill builds a service catalog: a schema for what to capture per internal tool (owner, framework, auth pattern, last deploy, criticality, known issues), a set of starter entries populated from what Pave finds in your repos, and a governance model for who keeps it current. For an internal tools team, this is the step that turns fourteen tools nobody has a full picture of into a single source of truth that a new engineer, or a returning one, can read in ten minutes instead of asking around for a week. Without this catalog, every planning conversation starts with someone spending an afternoon just remembering what exists.
Defining the golden path for the next dashboard
Once the catalog exists, pave-golden defines the opinionated, supported way to do the recurring task, in this case, spinning up a new internal dashboard. It produces concrete steps, a starter template, and the tooling to scaffold from it, so the fifteenth tool does not start from a blank file. This is the golden path an experienced platform engineer would document after watching the same three-week rebuild happen for the fourth time: here is the one way we build these now, here is the template, here is what you inherit for free. Pave also runs pave-audit to measure the before-and-after, onboarding time, build speed, deployment friction, so the golden path is judged on real numbers, not a feeling that things got better.
Prism turns the golden path into a real component library
A golden path is only as good as the components behind it. Prism, Tonone's frontend and DX engineer, is who Pave hands the golden path to for implementation. Prism runs prism-recon to map the component tree, routing, and state management across the existing tools, then builds the reusable pieces with prism-component: a typed, accessible DataTable, a FilterBar, an AuthGate wrapper, a form pattern for the CRUD screens that every one of these fourteen tools eventually needs. Once the library exists, the next dashboard is built with prism-dashboard, which assembles the data tables, filters, detail views, and CRUD flows from the shared components instead of hand-rolling them again. The fifteenth internal tool stops being a three-week rebuild and becomes a few days of assembly.
Tonone's Prism builds the shared component library that turns every future internal dashboard into an assembly job instead of a from-scratch rebuild.
Atlas captures the tribal knowledge before it walks out the door
The catalog and the component library solve the sprawl. They do not solve the fact that the one engineer who understands why the refund console behaves the way it does is about to leave the team, taking that understanding with her. Atlas, Tonone's knowledge engineer, runs atlas-onboard to generate the documentation a day-one engineer actually needs: what each tool does, how to set it up locally, where the tricky decisions live, how it deploys. For an internal tools team specifically, this is the difference between a three-week shadowing period for every new hire and a written doc that gets someone productive in days, because the knowledge is no longer trapped in one person's head.
Worked example: fourteen tools, three engineers, one senior leaving
A growth-stage SaaS company's internal tools team, three engineers supporting roughly 40 internal users across support, finance, and ops, is carrying fourteen internal tools built over two years: a refund console, a feature-flag admin, a support-ticket triage view, a finance reconciliation dashboard, and ten more of similar shape. Half are React and Tailwind, the rest are older Rails admin views with inline CSS. Every new request takes about three weeks, because nothing is shared, every tool reinvents pagination, auth, and the CRUD form pattern from scratch. Maya, the engineer who built and understands the refund console and the feature-flag admin, is moving to the platform team in six weeks, and none of it is written down.
The team runs Pave first. pave-catalog inventories all fourteen tools and produces the catalog schema, then pave-golden defines the supported path for the next dashboard. The output looks roughly like this:
Pave, Internal Tools Catalog + Golden Path
Catalog: 14 tools indexed
8 React + Tailwind (2023-2025), avg last deploy: 34 days ago
6 Rails admin views, inline CSS, avg last deploy: 210 days ago
Auth patterns found: 4 distinct implementations across 14 tools
Owner coverage: 2 of 14 tools have no clear current owner
Criticality flags: refund console + finance reconciliation = high
---------------------------------------------------------------
Golden path, New Internal Dashboard
1. Scaffold from internal-tools-starter (React, Tailwind, shared auth)
2. Pull DataTable, FilterBar, AuthGate from @internal/ui
3. Wire CRUD via prism-dashboard generator against existing API
4. Deploy through the shared internal-tools pipeline (no new CI setup)
Before golden path: avg build time ~3 weeks
After golden path: avg build time ~4 days (projected)
---------------------------------------------------------------
Next: Prism builds @internal/ui component library from 3 highest-
reuse patterns found in catalog. Atlas documents refund console +
feature-flag admin (Maya's tools) before her transfer date.Prism builds the @internal/ui library from the three highest-reuse patterns the catalog surfaced, the DataTable, the FilterBar, and the AuthGate, then rebuilds the next requested tool, a chargeback review console, using prism-dashboard against that library. It ships in four days instead of the usual three weeks. In parallel, Atlas runs atlas-onboard against the refund console and feature-flag admin, the two tools only Maya fully understands, and produces onboarding docs before her transfer date instead of after it, when the knowledge would already be gone. The catalog also surfaces the two ownerless tools, which get assigned an owner before they turn into an incident nobody can debug.
Tonone's Atlas turns the knowledge trapped in one engineer's head into a written onboarding doc before that engineer moves on, not after.
| Capability | Tonone | Generalist chatbot | Cursor / Copilot |
|---|---|---|---|
| Catalogs existing internal tools before building the next one | Yes, pave-catalog inventories owner, framework, auth pattern, criticality across every tool | No, only sees what you paste into the chat | No, works inside one open file at a time |
| Defines a supported golden path with a starter template | Yes, pave-golden produces concrete steps and a scaffold, measured with pave-audit | No, answers each request independently with no standard | No, suggests completions, no platform-level template |
| Builds a shared, reusable component library | Yes, prism-component and prism-dashboard assemble future tools from shared pieces | No, regenerates similar components from scratch each time | Partial, autocompletes similar-looking code without deduplicating it |
| Captures tribal knowledge before a key engineer leaves | Yes, atlas-onboard documents setup, decisions, and deploy steps for day-one readers | No, cannot read across your repos to know what to document | No, no documentation generation across a codebase |
| Measures onboarding time and build speed before and after | Yes, pave-audit tracks onboarding time, build speed, and deployment friction | No, no measurement capability | No, no project-level metrics |
If your internal tools team is rebuilding the same admin panel pattern every sprint, start with /pave-catalog before writing a single new component. You cannot define a golden path for tools you have not fully inventoried, and you cannot know what to standardize until you know what already exists.
Install and try
Tonone is free and MIT-licensed. Install it once and Pave, Prism, Atlas, and the rest of the 100-agent roster are available in your Claude Code session. You pay only for the Claude Code token usage during the work itself.
1. Add to marketplace
2. Install Pave
Frequently asked questions
What does Tonone's Pave do for internal tools teams?+
Pave catalogs every internal tool a team maintains, owner, framework, auth pattern, and criticality, then defines a golden path for building the next one, complete with a starter template and measured build-time improvement via pave-audit.
How is this different from asking ChatGPT to build an internal dashboard?+
ChatGPT answers the single request in front of it with no visibility into your other tools. Pave inventories what already exists across your whole internal tools footprint before recommending a standard, so you fix the sprawl, not just one dashboard.
Can Tonone build a shared component library across our internal tools?+
Yes. Prism runs prism-recon to map existing components across your tools, then builds the reusable pieces with prism-component and assembles new dashboards from them with prism-dashboard.
How do we document internal tools before an engineer who built them leaves?+
Atlas's atlas-onboard skill generates day-one onboarding documentation, what the tool does, how to set it up, key decisions, and deploy steps, before the knowledge walks out the door with a departing engineer.
What is a service catalog and why does an internal tools team need one?+
A service catalog is a structured inventory of every tool a team maintains: owner, framework, auth pattern, last deploy, and criticality. Tonone's pave-catalog skill builds this, so a team stops relying on tribal memory to know what exists before planning the next build.
How do we measure if a golden path actually improved our internal tools velocity?+
Pave's pave-audit skill measures onboarding time, build speed, and deployment friction before and after a golden path is introduced, so the improvement is judged on real numbers, not a feeling.
Is Tonone free to use for an internal tools team?+
Yes. Tonone is MIT-licensed and free. Install it once and Pave, Prism, and Atlas are all available in the same Claude Code session. You only pay for Claude Code token usage during the work.
Which Tonone agents work together for internal tools sprawl?+
Pave catalogs existing tools and defines the golden path, Prism builds the shared component library and implements new dashboards from it, and Atlas documents tribal knowledge before it is lost to team turnover.