ai-sales-team-claude: fourteen Claude Code skills that generate Markdown, scored by a formula you wrote in February

The install is a pipe from raw.githubusercontent to bash

The quick start offers two routes. The first is a single line:

curl -fsSL https://raw.githubusercontent.com/zubair-trabzada/ai-sales-team-claude/main/install.sh | bash

The second is three lines you can read before running anything:

git clone https://github.com/zubair-trabzada/ai-sales-team-claude.git
cd ai-sales-team-claude
./install.sh

The manual route is the one to take if you want to know what you are running. The tree is small and readable: `install.sh`, `uninstall.sh`, then `agents/`, `skills/`, `scripts/`, `sales/`, `templates/`, plus `requirements.txt` and an MIT `LICENSE`. There is no compiled artifact, no package registry, and nothing that runs at import time, so reading `install.sh` before executing it is a normal afternoon rather than an archaeology project.

A third install step is optional and easy to miss because it sits under a heading about PDF reports and enhanced parsing rather than under installation: `pip install -r requirements.txt`. That file is three lines, `reportlab>=4.0`, `beautifulsoup4>=4.12` and `requests>=2.31`, which is a useful signal about how much real work happens in Python. BeautifulSoup is for reading company websites, requests is for fetching them, and reportlab is for the PDF report. There is no API client library in there, which tells you the agents are not calling an LLM over HTTP; they are Claude Code sub-agents.

The installer output is worth reading as a manifest because it is the only place the whole inventory appears in one place: 14 skills including the orchestrator, 5 agents named `sales-company`, `sales-contacts`, `sales-opportunity`, `sales-competitive` and `sales-strategy`, 4 scripts, and 6 templates covering cold, warm and referral outreach, meeting prep, proposals and an objection playbook.

Fourteen commands, and the orchestration is the product

The command table is the actual feature list, and it is worth reading as a sales process rather than as a tool list, because the order of the commands is the order of a deal. Research a company, qualify the lead, find the people, write the outreach, follow up, prepare the meeting, write the proposal, handle objections. Then three commands that are more strategic than operational: build an ideal customer profile, map competitors, and report.

What makes this more than a prompt collection is the layering. The README describes a three-layer architecture in which one orchestrator skill routes commands to 13 sub-skills. That matters for a specific reason: the output of one command is meant to be the input of the next. `COMPANY-RESEARCH.md` exists so that the qualification step has something to qualify, and `DECISION-MAKERS.md` exists so the outreach step addresses named people rather than a company.

Each command writes a file rather than printing to the terminal, except `/sales quick`, which is explicitly the 60-second snapshot that stays in the terminal. This is a better design than it first appears, because the artefact is the deliverable. A sales rep who runs `/sales prep` twice for the same account can diff the two files and see what changed. A rep who reads five lines of terminal output and then closes the window has nothing.

The single flagship command is `/sales prospect`, described as a full prospect audit running five parallel agents, and it is the only command whose output is summarised rather than merely listed.

The fit score is five weights, and the weights are the opinion

The architecture diagram breaks the prospect score into five components, and the weights are printed next to each box: Company Research at 25 percent for Fit, Contacts Finder at 20 percent for Access, Opportunity Scoring at 20 percent for Quality, Competitive Analysis at 15 percent for Position, and Outreach Strategy at 20 percent for Ready. That last set does not sum to 100, which is either a rounding sloppiness in the diagram or a fifth component that is scored differently, and the README does not resolve it.

Set that aside, because the honest thing to say about a fit score is that it is an opinion rendered as arithmetic. What makes this one worth reading anyway is that the components are separated and weighted rather than blended into one impression, which means you can disagree with exactly one of them. If your problem is that you never reach the person who decides, the Access weight at 20 percent is the number to change. If you are in a market where technical fit matters enormously and the diagram assumes it does not, Fit at 25 is where you argue.

That argument is only possible because the weight table is exposed. A score with hidden weights cannot be adjusted, only obeyed or ignored, and ignoring it wastes the work. A score with visible weights is a starting configuration.

The sample output shows a company scoring 82 for fit and an opportunity scoring 78, aggregated into a prospect score of 85 out of 100, graded A, labelled a strong prospect, and mapped to the action advise investing significant effort. It is worth noticing that in the example the aggregate, 85, is higher than both of the visible components, 82 and 78. With those five weights, an average of two sub-scores would land below both. Something is doing the work in that aggregation and the README does not say what.

Parallel agents on a task that is mostly independent scraping

Five agents is the number the badges advertise, so it deserves scrutiny. In practice the five are company research, contacts, opportunity assessment, competitive intelligence and outreach strategy, and only the first three have obviously independent inputs. Competitive intelligence needs to know who the company competes with, which comes from the research agent. Outreach strategy needs the contacts and the qualification, which are two of the other three.

Running those in parallel means the later ones either wait, or start from less information than they will eventually have. Neither is necessarily wrong for a sales tool where a rough first draft in ten seconds beats a considered one in a minute, but it is a design choice with a cost, and the cost is a plausible-sounding draft.

There is a related question about what the contacts agent actually does. Finding four named decision makers from a website is a hard problem that most free approaches solve badly, and `contact_finder.py` is listed in the install output alongside `analyze_prospect.py`, `lead_scorer.py` and `generate_pdf_report.py`. The four-contact result in the sample output is the part of that run I would check first, because a named person who does not exist or who left the company two years ago is worse than no name at all, because you will email them.

None of this is an argument that the design is wrong. It is an argument for treating the output as a first draft with a sourcing habit attached: open the four names, check they are current, and only then send.

Where the honest work is, and where the marketing is

The README is described as coming from a workshop, and the homepage points at a Skool community rather than documentation. That context explains the shape of the page, and it is worth sorting the content into three piles.

The first pile is genuinely differentiating and hard to get elsewhere: an objection handling playbook, a proposal generator, and a follow-up sequence. These encode sales process rather than data retrieval, and they are the parts a rep would otherwise rebuild from scratch every quarter. The templates directory backs this up with six concrete files, and a template for an objection playbook is a rarer artefact than a company research prompt.

The second pile is standard practice done competently: meeting prep, competitive intelligence, ICP building, and the BANT plus MEDDIC qualification that `/sales qualify` promises. BANT checks budget, authority, need and timing; MEDDIC adds metrics, economic buyer, decision criteria and decision process. Scoring a lead against both is the mainstream B2B approach and there is nothing wrong with it, but nothing here is a methodological advance either.

The third pile is presentation. The prospect score box with its bar chart, the five checkmarks in the launch log, and the layered architecture diagram all describe something simpler than they appear to. Read them as a description of intent and they are accurate: this is the shape the project wants the system to have. Read them as an observation of what happened and they overstate it.

The most useful thing about the repository is that it is plain files. `skills/`, `agents/`, `templates/` and `scripts/` are all readable, editable and forkable, which means the fastest route to a tool you trust is to change the weights and the wording until they match how you actually sell. The last commit was in March 2026, so nobody is patching it for you.

What to run first, and what to check in the output

If you try this, run the commands in a different order from the README and you will learn more. Start with `/sales icp` because it is the only command that asks you to state your own criteria rather than inferring them, and everything downstream inherits whatever you wrote there. Then run `/sales competitors` on two companies you have worked with directly, where you know the real competitive set, and see whether the mapping matches your experience or flatters the vendor.

After that, `/sales prospect` on a company already in your pipeline is the honest test. You know the fit, you know whether you can reach anyone, and you know whether the deal is real. Compare the grade it assigns to the one you would have assigned. If it disagrees sharply and you cannot say why, the weight table is wrong for your motion, and you now know that in ten minutes rather than after a quarter of bad targeting.

The `/sales report-pdf` path is the one with a real dependency, since it is what `requirements.txt` is for, and it is worth knowing that the PDF is generated by reportlab from the same Markdown pipeline as `/sales report`. There is no additional analysis behind the PDF format. If you want the report in a different shape, the Markdown file is the thing to transform.

What to check in every output, in order: whether the named contacts still hold their jobs, whether the competitors are ones your buyer actually considers, whether the first email would survive being sent under your own name, and whether the objections playbook covers the objection that actually kills your deals rather than the three that are easy to write down.

Editorial conclusion

ai-sales-team-claude is two things wearing one name, and separating them is the whole review. The first is a genuinely useful set of 14 command-shaped instructions for Claude Code: research a company, find named people, write a sequence, prepare a meeting, answer an objection, and write each one as a Markdown file you can read and paste from. That layer costs nothing to try and needs no API key of your own beyond the Claude Code session you are already in. The second is the scoring system, and that layer is a weight table plus arithmetic, dressed in a diagram. When the diagram says five agents run in parallel to produce an 85 out of 100, what actually happened is that some scripts fetched a page and five judgement calls about fit were added up with fixed weights. Both are worth having, as long as you know which one you are buying. Run `/sales icp` first and put your own definitions in, then `/sales prospect` on a company you already know well, and the gap between what it scored and what you would have scored is the actual value of the tool.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zubair-trabzada/ai-sales-team-claude on GitHub