Request a tool or add your own
How to ask for a tool or a guide, report a mistake, and get a tool you built listed in the catalog.
L.4.16 min readLast revised November 2026
On this page
The catalog grows in two ways: someone asks for a tool, or someone builds one. Both are welcome, and neither needs permission to start.
Where to send things#
| You want to | Do this |
|---|---|
| Ask for a new tool | Open an issue on this site’s repository, or email |
| Say a planned tool matters to you | The same. It moves the tool up the list |
| Report a wrong result | Open an issue in that tool’s repository, or email |
| Report a mistake in a guide or on the site | Open an issue on this site’s repository, or send a pull request |
| List a tool you built | Send a pull request to this site’s repository |
The email address is [email protected]. Use it if you would rather not post in public or do not have a GitHub account.
Issues on GitHub are public and permanent. Read What never goes in before you write one.
Request a tool#
A useful request covers three things:
- The job. What you need to produce, and what you do by hand today. “I rebuild a spreadsheet that turns our pools into rates for every proposal” is a job. “A pricing tool” is not.
- Who needs it. For example, a solo developer pricing a first bid, or a small company preparing for a first assessment.
- The public source. The regulation, standard or guide the tool would be based on, with a link if you have one.
You can copy this outline into an issue or an email:
The job:
What I do by hand today:
Who else would use it:
Public source (regulation, standard or guide), with a link:
Anything the tool must NOT do or ask for:
The last line matters more than it looks. If a tool would be useless to you the moment it asked for a company name, say so.
What happens to a suggestion
A suggestion is treated the same way as any other idea for a tool:
- 1RecordedThe request is written down as a candidate, and checked against ones already on the list.
- 2ScreenedTested against five knockout gates: public source, runs in the browser, private, one job, arithmetic not advice.
- 3ScoredRated on a 100-point rubric. How many people asked is one of the things that breaks a tie.
- 4DecidedA person decides whether to build it, link to something that already does the job, park it or decline it.
How we decide what to build has the gates and the rubric in full.
Ask for one that is already planned#
Every tool in the catalog starts out as Planned. Saying which of them you are waiting for helps decide what gets built first. Each tool’s own page has buttons that start the email or the issue for you. A one-line message is enough: the name of the tool and what you would use it for.
Report a mistake#
A wrong result is the most useful thing you can report. Include:
- what you entered, with made-up values in place of anything real
- what the tool showed
- what the correct answer is
- the section of the regulation that shows it
Check a tool’s answer explains how to find that section.
The same goes for the guides. If one is unclear, out of date or wrong, say which sentence and what it should say.
Ask for a guide#
If you looked for an explanation here and did not find it, ask. The guides are text files in the repository, and a request for one is handled the same way as a request for a tool.
Add a tool you built#
Tools live in their own repositories, under your own name or organization. ClearedStack lists them. It does not take them over. To be listed, a tool has to be:
- Free and open source, under an OSI-approved license, with no paid tier and no ads.
- Client-side. It runs in the browser or on the user’s own machine, and does not send what the user enters to any server.
- Free of tracking: no analytics, no third-party scripts, no accounts.
- Built from public sources, and clear about which ones.
- Honest about its limits, including that its output is not professional advice.
To list it:
- Fork this site’s repository.
- Add one entry to
src/data/catalog.ts. - Open a pull request that links to your tool and its repository.
The entry looks like this:
{
slug: "wrap-rate-calculator",
name: "Wrap Rate Calculator",
summary: "Build a fully burdened labor rate from base pay, fringe, overhead, G&A and fee.",
category: "pricing",
status: "live",
url: "https://example.com/wrap-rate/",
repo: "https://github.com/your-name/wrap-rate-calculator",
detail: "Enter an hourly wage and your indirect rates. The tool shows every layer of the build-up.",
sources: [{ name: "FAR Part 31", url: "https://www.acquisition.gov/browse/index/far" }],
guides: [{ slug: "labor-rates" }],
},
The home page, the catalog, the tool’s own page and every count are generated from that file, so the one entry is the whole change. An entry can also carry an optional provenance field that records where the idea came from. Work on this site lists every field, and Build a tool that can be listed goes through each condition in detail, with a checklist to run before you open the pull request.
How a listing is reviewed#
- 1. LicenseOSI-approved open sourceVerify LICENSE file exists with no commercial barriers or ads.
- 2. Client-sideZero network egressCheck Network tab is quiet and tool functions fully offline.
- 3. No trackingStrict Content Security PolicyNo remote fonts, scripts, analytics, or cookies loaded.
- 4. SourcesPublic regulations citedREADME and outputs link directly to authoritative rules.
- 5. Operational limitsClear boundariesClear statement that results are computational aids, not professional advice.
A person reads the pull request and uses the tool. The review checks the five conditions and nothing else:
- the license file is there
- the Network tab stays quiet while the tool is used, and the tool still works with the network disconnected
- the page loads nothing from other companies’ servers
- the README names the sources and says what the tool does not cover
- the examples and test data are made up
The review does not certify that every result is correct. That is why each tool has to name its sources: so that anyone can check.
A tool that later breaks a condition is taken off the list until it is fixed.
What never goes in#
Do not put any of these in a request, an issue, an email, a pull request, a tool or its test data:
- classified information
- controlled unclassified information (CUI)
- export-controlled technical data
- real contract data, real rates, or anything that identifies a real company’s bid
- text copied from a solicitation that is not publicly posted
“Public” means officially released. A document that leaked, or that is marked for limited distribution but can be found online anyway, is not public for this project. If you are unsure, leave it out and describe the problem in your own words with made-up numbers.
If you work for the government or hold a clearance#
Your own obligations come first. Contribute only on your own time and your own equipment, and only what you are free to share. If you are not sure whether something you know from work is public, treat it as not public.
What you agree to#
By contributing to this site’s repository you agree that your work is released under the MIT License. A tool in your own repository stays yours, under the open-source license you chose for it.
Found a mistake, or something that has gone out of date? Open an issue or write to [email protected]. This page is a text file you can read and correct: Source of this page.