Customer engineering is the discipline of making a product actually work inside someone else's environment — after the deal is signed, under a ticket clock, against a stack you did not build and cannot fully see. The job is not writing the product; it is everything that happens once a customer hits a wall: a support escalation that lands on your desk with a vague error, an integration that works on your machine and dies on theirs, an onboarding that stalls because nobody on the customer side can follow the setup, a 2 a.m. page from a live customer environment you are scared to touch. The two failure modes that burn a customer engineer are guessing at a root cause and shipping a fix, and breaking a customer's environment while debugging it. Most of the friction is not the fix itself — it is the reproduction, the reconnaissance, and the paperwork around it: rebuilding the failing flow from a screenshot and a hunch, figuring out what version of what library the customer is even running, writing the runbook their team will operate without you, and remembering how you solved the same escalation six months ago. The eight skills below map onto that loop — reproduce, investigate, research, guard, onboard, document, and remember. 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 runs a four-phase debugging method — investigate, analyze, hypothesize, implement — under one Iron Law: no fixes without a root cause first. For a customer engineer this is the front door to every escalation, because the most expensive mistake in support is shipping a fix for a symptom and watching the ticket reopen a week later. A customer report arrives as "it was working yesterday" or a bare 500 with a stack trace, and the temptation under ticket pressure is to pattern-match to the last thing that looked similar and push a patch. Forcing the work through investigate-then-analyze-then-hypothesize means you isolate what actually changed in the customer's environment before you touch anything — so the fix you hand back closes the ticket instead of reopening it. A root cause you can name is also the only thing that turns an escalation into a writeup the rest of the team learns from.
When to use: the moment a customer escalation lands as an error, a stack trace, or an "it suddenly broke" report — before you write a single line of fix. Make it produce the named root cause first, then the patch, so the resolution holds. Pair it with the backend-engineers skill stack when the root cause lives in the service the customer is calling rather than in their integration.
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 customer engineer this is the reproduction tool, and reproduction is half the battle: a ticket that says "the export button does nothing" is useless until you can make the export button do nothing on demand, because you cannot fix what you cannot trigger. Driving the customer's exact flow programmatically — the same clicks, the same form, the same upload that failed for them — turns a vague report into a reproducible failure you can attach a root-cause investigation to. The annotated screenshots are how you prove the bug to a backend team that insists it works, and how you prove the fix to the customer who reported it.
When to use: any time a customer report describes a broken UI flow you need to reproduce — drive the exact steps, capture the failure with annotated screenshots, then re-run after the fix to confirm it is gone. Use the before/after diff to show the customer the difference. Pair it with the qa-engineers skill stack when the reproduction reveals a class of bugs that needs a systematic pass, not a one-off fix.
From the cli plugin (425 stars, verified, by Firecrawl). It is web search with full page content extraction — you give it a query and it returns real search results as JSON, optionally with the full markdown of each result page rather than a snippet, with filters for news, time window, and source category. For a customer engineer this is the reconnaissance step before you escalate or guess. Every customer runs a different stack, and the error in front of you is often a known issue in a library version you have never used — a breaking change in their ORM, a deprecation in their runtime, a CVE in a dependency they pinned two years ago. Searching the exact error string and pulling the full text of the GitHub issue or release note that explains it, rather than skimming snippets, is the difference between escalating "the integration is broken" and escalating "the customer is on v3.2 of the SDK which dropped this endpoint in v3.0." The full-content extraction matters because the answer is usually three comments deep in a thread, not in the title.
When to use: the moment a customer's error points at their stack rather than yours — search the error string, the library version, the deprecation, and pull the full page so you read the actual fix, not a snippet. Use the news and time filters when a recent platform change is the suspect. Pair it with the devops-engineers skill stack when the research points at the customer's infrastructure or deployment rather than their application code.
Also from gstack. It is a safety mode that warns before destructive commands — rm -rf, DROP TABLE, TRUNCATE, git push --force, git reset --hard, kubectl delete, and similar — letting you override each warning deliberately, and it is built for exactly the situation of touching prod, debugging a live system, or working in a shared environment. For a customer engineer this is the seatbelt for the scariest part of the job: debugging inside a customer's environment where a mistyped command does not cost you a rebuild, it costs the customer their data and you the relationship. When an escalation has you running queries against a customer's database or commands against their cluster, the gap between a harmless SELECT and a catastrophic DELETE is one missing WHERE clause and a tired afternoon. A guardrail that pauses on the destructive pattern and makes you confirm is the cheapest possible insurance against the incident that turns a support call into a postmortem.
When to use: turn it on before you run anything against a customer's live database, cluster, or shared environment — especially during a high-pressure escalation when the temptation to move fast is highest. Let it catch the unguarded delete or the force-push before it lands, not after. Treat it as standing policy any session that touches a system you do not own.
Also from gstack. It wraps a project's existing tools — type checker, linter, test runner, dead-code detector, shell linter — into a single weighted composite score from 0 to 10 and tracks the trend over time. For a customer engineer this is the onboarding x-ray. When you inherit a customer's integration codebase — the glue they wrote against your API, the fork they maintain, the plugin their team built — you walk in blind, and the difference between a smooth onboarding and a six-week firefight is usually visible in the code quality on day one. Running a health pass on the customer's integration repo turns "their code looks fine" into a number and a list: failing types here, no tests there, dead code masking the real path. That score tells you where the onboarding risk actually is before the customer hits it in production, so you can flag the fragile spots while it is still a conversation and not an incident.
When to use: at the start of any onboarding or integration handoff where you inherit a customer's code — score the repo first so you know where the fragility is before you debug it under pressure. Re-run it across the engagement so a degrading trend surfaces as a number instead of a surprise outage. Pair it with the technical-writers skill stack when the health findings need to become a written remediation plan for the customer.
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 customer engineer this is the runbook that decides whether onboarding scales. A customer's team cannot operate an integration they cannot follow, and the gap between "it worked when the CE set it up" and "our people can run it" is documentation nobody on either side had time to write — which is why the same setup question comes back as a ticket every week. Generating a how-to for the integration steps and a reference for the configuration turns the engagement into something the customer runs without paging you, which is exactly what lets one customer engineer support more than a handful of accounts. The Diataxis structure means the customer gets a real getting-started path and a real reference, not a wall of Slack messages someone pasted into a doc.
When to use: the moment an onboarding or a resolved escalation needs to leave your head and live where the customer's team can find it — generate the setup how-to and the config reference as the handoff artifact. Ship the docs with the integration so "how do we run this" is already answered. Pair it with the technical-writers skill stack when the runbook needs to graduate into the product's official customer documentation.
Also from gstack. It is a persistent store of what a project has learned across sessions, with commands to review, search, prune, and export it, plus a proactive nudge when you ask about a past pattern or wonder "didn't we already hit this?" For a customer engineer this is the escalation memory that actually gets read, because it is searched from inside the same tool running the debugging rather than buried in a ticket archive nobody reopens. A support queue generates a relentless stream of hard-won fixes — this customer's CORS error was a proxy header, that timeout was their connection-pool setting, this onboarding always trips on the same webhook config — and the recurring waste is re-investigating an escalation whose answer is already in a closed ticket from last quarter. A searchable findings store is the cheapest defense against debugging the same root cause twice, and the fastest way a new teammate inherits the tribal knowledge of the queue.
When to use: write a learning every time an escalation resolves with a non-obvious root cause — the customer-side setting, the version mismatch, the environment quirk — and search it before you dig into a new ticket that smells familiar. Prune on a cadence so a fix tied to an old product version does not misdirect a current investigation. Pair it with the sre-engineers skill stack when a recurring escalation is really a reliability pattern worth fixing at the source.
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 customer engineer this is the last mile of an incident writeup or an onboarding packet. You investigated the root cause and drafted the resolution in markdown next to the code; what the customer's stakeholders receive — the post-incident report, the integration runbook, the onboarding guide — needs to look like the output of a real support organization, not a pasted text block. A one-command path from the markdown you already wrote to a paginated, cover-paged PDF means the deliverable reads as professional without anyone wrestling a word processor after a long escalation. The DRAFT watermark is for the internal review round — circulate the incident report inside your team marked clearly as not-yet-final, then export the clean version for the customer.
When to use: any time a post-incident report, an onboarding guide, or a resolution summary has to leave your repo as a document a customer's leadership will read and judge. Use the DRAFT watermark for the internal review pass, then export the final for the customer. Pair it with a quick PDF utility like pdf.thicket.sh when you need to merge the exported report with customer-supplied logs or screenshots into a single deliverable.
How to install
Seven 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 one 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 customer-engineering workflow: when an escalation lands, reproduce the failing flow with browse, run investigate to find the real root cause before you touch anything, and use firecrawl-search to pull the full page on whatever library version or platform change is the suspect. Before you run a command against the customer's live environment, switch on careful so a mistyped delete gets caught instead of executed. For onboarding, score the customer's integration repo with health to find the fragility early, generate the runbook and reference with document-generate, and write every non-obvious resolution into learn so the next ticket starts from what you already solved. When the writeup has to ship, turn it into a customer-ready document with make-pdf. Bracket the deep investigation sessions with focused blocks via focus.thicket.sh, and the job stops being a scramble of one-off firefights and starts being a repeatable motion that resolves escalations and onboards customers without breaking their environment.