Sales engineering is the discipline of proving, technically, that a product solves a buyer's actual problem — under deadline, in front of skeptics, often against an incumbent. The job is not the product; it is everything around the demo and the deal: turning a vague discovery call into a scoped proof-of-concept, standing up an integration prototype that survives a live walkthrough, answering an RFP whose hardest questions are buried in a PDF, and positioning against a competitor whose pricing you have to reverse-engineer from their site. The two failure modes that lose deals are the demo that breaks on screen and the POC that takes so long to scope that the prospect cools off. Most of the friction is not the code — it is the reconnaissance and the paperwork around it: pulling a rival's feature matrix into a sheet, extracting the one requirement that matters out of a 40-page RFP, making the response look like the work of a real solutions team, and making sure the thing you are about to demo actually works on a fresh browser. The eight skills below map onto that loop — scope, research, parse, respond, verify, demo, review, and hand off. Each is a real, verified Claude Code skill from a plugin with public commit history and a real star count on GitHub, and Skill Index has the exact install command on each detail page.
From the gstack plugin (104,138 stars, MIT, verified — the largest plugin in the index). It turns vague intent into a precise, executable spec in five phases, then files it as an issue and can spawn an agent in a fresh worktree to build it. For a sales engineer this is the front door to every proof-of-concept, because the most expensive thing a POC can do is start before it is scoped. A discovery call ends with a pile of half-stated requirements — "it needs to talk to our Salesforce," "security will want SSO," "show it working with our data" — and the temptation is to start wiring things up immediately, then discover three days in that the success criteria were never agreed. Running the requirements through a five-phase spec forces the ambiguity out first: what exactly does the prospect need to see, what counts as success, what is explicitly out of scope for the trial. A POC built from a real spec is one you can demo with confidence and one the buyer cannot move the goalposts on.
When to use: the moment a discovery or scoping call hands you a fuzzy set of POC requirements, before you write a line of integration code. Pin the success criteria and the out-of-scope list in the spec so the trial has a defined finish line. Pair it with the product-managers skill stack when the POC requirements need to feed back into the actual product roadmap.
From the cli plugin (425 stars, verified, by Firecrawl). It is AI-powered autonomous extraction: the agent navigates a complex multi-page site on its own and returns structured JSON, optionally against a schema you hand it. For a sales engineer this is competitive intelligence without the busywork. Half of winning a technical evaluation is knowing exactly what you are up against — the incumbent's pricing tiers, which features they gate behind which plan, what their integration catalog actually covers — and that data lives scattered across a dozen pages that no one wants to click through by hand. Pointing an autonomous agent at a competitor's site with a schema (name, price, tier, features) turns a tab-juggling afternoon into a structured JSON file you can drop straight into a battle card or a comparison slide. The schema is what makes it usable: you get clean, typed rows instead of a wall of scraped prose.
When to use: any time a deal turns competitive and you need a rival's pricing tiers, feature matrix, or integration list as structured data rather than screenshots — especially multi-page sites where manual scraping would mean navigating page after page. Hand it a JSON schema so the output drops straight into a battle card. Pair it with the marketers skill stack when the competitive data also feeds positioning and messaging.
Also from cli. It converts any local file — PDF, DOCX, DOC, ODT, RTF, XLSX, XLS, or HTML — into clean markdown saved to disk, with options for an AI summary or a question-answering pass over the contents. For a sales engineer this is the RFP unlock. The hardest part of an RFP is rarely the answer; it is that the requirements arrive as a 40-page PDF or a sprawling requirements spreadsheet, and the questions you actually have to address are buried among boilerplate. Parsing the document into markdown — then asking it directly which security, compliance, and integration requirements it contains — turns a document you would otherwise skim and miss things in into a structured list you can answer line by line. The summary mode is the triage step: read what the RFP is really asking before you commit a day to responding.
When to use: the moment an RFP, a security questionnaire, or a requirements spreadsheet lands as a local file — parse it to markdown first, summarize to triage, then question it to pull out the requirements you must address. Reach for it over a URL scrape whenever the source is a file on disk rather than a web page. Pair it with the technical-writers skill stack when the parsed requirements feed a larger written response.
Also from gstack. It turns any markdown file into a publication-quality PDF — proper one-inch margins, intelligent page breaks, page numbers, a cover page, running headers, curly quotes, a clickable table of contents, and an optional diagonal DRAFT watermark. For a sales engineer this is the last mile of the RFP response and the POC writeup. You drafted the answers in markdown next to the integration code; what the buyer's procurement team receives needs to look like the output of a real solutions organization, not a text file. A one-command path from the markdown you already wrote to a paginated, cover-paged PDF means the response looks professional without anyone wrestling a word processor the night before the deadline. The DRAFT watermark is for the internal review pass — circulate the response inside your team marked clearly as not-yet-final, then export the clean version for the prospect.
When to use: any time an RFP response, a POC summary, or a solution-architecture writeup has to leave your repo as a polished document a buyer will judge. Use the DRAFT watermark for internal review rounds, then export the final for the prospect. Pair it with a quick PDF utility like pdf.thicket.sh when you need to merge the exported response with prospect-supplied PDFs into a single deliverable.
Also from gstack. It systematically QA-tests a web application and then iteratively fixes the bugs it finds, committing each fix atomically and re-verifying, with three tiers from quick (critical and high only) to exhaustive. For a sales engineer this is insurance against the single worst moment in the job: the demo that breaks on screen. A POC is a real application, and the gap between "it worked when I built it" and "it works on a fresh browser in front of the buyer" is exactly where deals die — a broken form, a console error on Safari, an edge case the prospect happens to click. Running a QA pass before the call surfaces the failures while you can still fix them, and the atomic, re-verified fixes mean you walk into the demo knowing the critical paths hold. Run the quick tier the morning of a demo; run exhaustive before handing a trial environment to the prospect's own team.
When to use: before every demo and before any POC is handed to a prospect to drive themselves — the quick tier as a pre-call smoke test, the exhaustive tier before a self-serve trial goes live. Catch the broken bucket while you can still fix it, not on the shared screen. Pair it with the qa-engineers skill stack when the demo environment needs the same rigor as production.
Also from gstack. It is a fast headless browser — roughly 100ms per command — that navigates any URL, interacts with elements, verifies page state, diffs before and after an action, takes annotated screenshots, and tests forms, uploads, and dialogs. For a sales engineer this is the demo rehearsal tool. Before you walk a prospect through a flow live, you can drive that exact flow programmatically, confirm each step lands where it should, and capture annotated screenshots of the happy path as a fallback in case the live environment hiccups on the call. It is also how you produce evidence: when a prospect asks "does it really do X," a screenshot of the feature doing X, captured in seconds, is more convincing than a promise. The same headless browser that QA leans on doubles as the dry run for the moment that actually closes the deal.
When to use: rehearsing any demo flow before the call, capturing screenshot evidence of a feature for a follow-up email or an RFP answer, and verifying that a freshly deployed POC environment actually loads the flow you are about to present. Keep the annotated screenshots as a backup deck in case the live demo stumbles. Pair it with qa above so the flow you rehearse is one a full QA pass has already hardened.
Also from gstack. It analyzes a diff against the base branch for SQL safety, LLM trust-boundary violations, conditional side effects, and other structural issues before the code lands. For a sales engineer the integration prototypes you ship into a POC are code that runs against a prospect's data and sometimes their systems, and a careless query or an unguarded input in a trial environment is the kind of thing a buyer's security team will find and remember. Running a review pass over the demo and integration code before it touches anything the prospect owns catches the SQL-injection-shaped mistake or the place where untrusted input flows straight into a model prompt — the issues that turn a promising trial into a failed security review. A POC does not need production-grade everything, but it does need to not embarrass you in front of the people whose job is to find reasons to say no.
When to use: before any integration or demo code lands in an environment a prospect can see or that touches their data — especially anything handling user input, queries, or LLM calls. Treat the review as the gate before a security-conscious buyer gets near the POC. Pair it with the security-engineers skill stack when the deal hinges on passing a formal security assessment.
Also from gstack. It generates complete, structured documentation from scratch for a feature, module, or whole project using the Diataxis framework — tutorial, how-to, reference, and explanation. For a sales engineer this is the handoff that keeps a won POC from stalling. A successful trial does not close itself; the prospect's own engineers have to be able to stand the integration up, and the gap between "it worked when the SE drove it" and "our team can run it" is documentation nobody had time to write. Generating a how-to for the integration steps and a reference for the configuration turns the POC into something the buyer's team can operate without a support ticket for every step, which is exactly what de-risks the purchase in their eyes. The Diataxis structure means you get a genuine getting-started path, not a wall of unsorted notes.
When to use: the moment a POC succeeds and the prospect's team needs to operate it themselves — generate the setup how-to and the configuration reference as part of the handoff package. Ship the docs with the trial so "can your team run this" is already answered. Pair it with the technical-writers skill stack when the handoff docs need to graduate into the product's official documentation.
How to install
Six of the eight skills live in the gstack plugin (104,138 stars on garrytan/gstack, MIT, verified — the largest and most active plugin in the index) and two in cli (425 stars, verified, by Firecrawl), so install is a two-marketplace operation, and Skill Index has the exact install command on each skill detail page with a copy button. The highest-ROI sequence for a sales workflow: scope every POC with spec before you build, so the trial has a finish line the buyer cannot move. Gather the competitive picture with firecrawl-agent and unlock the RFP itself with firecrawl-parse, then turn your answers into a buyer-ready document with make-pdf. Before the call, harden the demo with qa and rehearse the exact flow with browse so nothing breaks on screen, and run review over the integration code so a security team finds nothing to flag. When the trial lands, generate the handoff docs with document-generate so the prospect's own team can operate what you proved. Bracket the deep build-and-demo sessions with focused blocks via focus.thicket.sh, and the job stops being a scramble of last-minute fixes and starts being a repeatable motion that wins technical evaluations.