Claude for Manufacturing: how to use its 17 skills, and what to connect above them

Claude for Manufacturing 1.0.0 has twelve atomic skills, each doing one job, and five chains that run several of them end to end. The source is public on GitHub, marked as a reference implementation: provided as is, not actively maintained, not taking contributions. That makes it a pattern to copy as much as a product to install.

• Setup and data: onboarding, data-consolidate (joins the plant’s exports into one dataset), custom-connector (reaches a system with no vendor connector).
• Quoting: customer-inquiry-intake, quote-build, and the chain rfq-to-quote.
• Quality: ncr-writeup, root-cause-capa, and the chain inspection-to-capa.
• Maintenance: breakdown-diagnosis, and the chain breakdown-to-next-report.
• Sourcing: supplier-quote-request, and the chain supplier-escape-to-alternate-source.
• Production: daily-production-report, and the chain morning-plant-pulse.
• Design: design-space-explore (variants in Autodesk Fusion) and trade-study-report.

Claude for Manufacturing is offered on Claude Team and Enterprise plans, and starts with one sentence: install it from the Claude plugin directory and say “set us up”. The onboarding skill asks which ERP, CAD, maintenance and document systems the plant uses, tests the four connectors it works with (Microsoft 365, Oracle NetSuite, Infor M3, Autodesk Fusion), takes a drop of the plant’s documents, learns its exports, shift pattern and vocabulary, and hands back the list of what is still missing and which skills that limits.

Connectors are optional for most of the plugin. Its README says that without any connector eleven of the twelve atomic skills still work from a folder of scheduled CSV exports. The exception is design-space-explore, which needs a live CAD connection: Autodesk Fusion on the desktop with its local MCP server enabled, or a CAD system connected through custom-connector. Any other system, a CMMS, an MES or a quality system, reaches the plugin as a scheduled export until custom-connector finds a better path.

The skills are triggered by what you say, not by their names. The phrases below are the plugin’s own examples:

• “Morning report”: daily-production-report gives output against plan, OEE split into availability, performance and quality, downtime ranked by minutes and by frequency, scrap and downtime priced in money. The morning-plant-pulse chain prepares the same page before anyone asks, from a scheduled task in Cowork or Claude Code, and keeps a dashboard per site.
• “We found bad parts”: ncr-writeup writes the nonconformance against the requirement it violates, cited to a document and a page, scopes the suspect parts, and searches prior NCRs to say whether the last fix held.
• “Write the 8D”: root-cause-capa puts sensor, inspection, maintenance and ticket history on one timeline, ranks candidate causes with the evidence for and against, and drafts D1 to D5 and D7.
• “The machine is down”: breakdown-diagnosis reads the sensor window, the maintenance history and the manufacturer’s manual; breakdown-to-next-report carries the diagnosis into the next production report.
• “An RFQ came in” and “price this job”: customer-inquiry-intake and quote-build, with every cost traced to where it came from.
• “Source this part”: supplier-quote-request builds the RFQ package and mandates the format of the bids, so they come back comparable; it never awards the business itself.

The value of Claude for Manufacturing is as much in its rules as in its skills. Every skill that would change something pauses first: nothing is applied, sent or written to the plant’s systems without approval, and Anthropic writes that “Claude for Manufacturing doesn’t operate equipment.” Figures are computed, not estimated by the model. Missing data stays missing instead of becoming a zero. The 8D stops at D5 and D7, because D6 and D8 need something to have actually happened. These are the same stop rules we describe in agentic lean: where to start.

Claude for Manufacturing knows the plant’s standard and its deviations, which is daily management in Yoji Akao’s sense. It does not know the plant’s annual objectives, the targets of its indicators or the initiatives meant to move them, which is hoshin kanri. The morning report ranks downtime by minutes and by frequency, not by which loss this year’s objective is about. ncr-writeup says whether an earlier fix held, and the 8D’s D7 changes the system for this defect and says why the earlier fix did not hold. Nothing in them asks whether the pattern deserves an improvement initiative this year, who owns it, or when it will be reviewed.

A strategy layer multiplies what the skills produce because the same record is used again instead of once. Without it, a morning report serves the morning meeting and is gone. With it, the same records feed a monthly reading of a strategic indicator, the review that discusses it, the comparison between sites and the evidence of the site’s maturity. hoshin.app keeps that layer as data and exposes it to any agent through MCP; it reads no plant system itself, the agent does.

• Priorities: the agent ranks the plant’s gaps against this year’s targets, not only against yesterday.
• One record, several uses: a monthly KPI reading keeps its source (tool, record, extraction date) and the days it rests on.
• Patterns become improvements: a defect that comes back becomes one improvement idea linked to an objective, then an initiative with an owner, instead of another 8D.
• Several sites, one view: each plant keeps its own dashboards; the X-Matrix cascades from group to site, and the lean excellence roadmap compares the sites’ maturity side by side.
• The review cycle: before each review, the agent is told what is due, prepares it from the plant’s records, and records what the review decided.

Both plugins can be installed side by side in the same Claude; we have not yet run them together. Add the hoshin-kanri plugin from its marketplace (wellknownmcp/hoshin-kanri) and connect its hoshin connector, which signs you in to hoshin.app. Its plant-pulse-to-matrix skill tells the agent how to carry the plant’s records up: find the plant dashboards by their exact titles (“<Site>: Operations Command Center” and “<Site>: Quality Register”), read their records, and write only the period readings, one idea per repeating pattern and roadmap evidence as a draft. The monthly quality reading comes from the morning pulse records, and the Quality Register feeds the improvement ideas. Then ask, for example: “put this month’s quality reading from the plant pulse in the Dayton matrix.”

One condition: the plant dashboards are private pages in the plant team’s Claude account, so the agent that reads them must run in that account, or the dashboards must be shared with it. Reading them from another account has not been tested.

We tried the strategy side on November 13, 2026, on a copy of our demo plant, with synthetic records in the exact format of the plugin’s morning pulse and Quality Register: 22 production days, two of them missing the downtime export, and a defect that comes back after a fix that did not hold. The agent found the dashboards by title, wrote a monthly reading of 646 PPM resting on the 20 complete days, wrote no downtime or loss figure because the data was incomplete, opened one improvement idea for the repeated defect, and proposed maturity level 3 rather than 4 because the fix had not held.

Not tested: the Claude for Manufacturing skills producing those records themselves, a real plant, dashboards shared from another account, and an unattended run publishing its dashboard, which the plugin’s documentation says has not been verified yet. The broader method, and where the agent must stop, are in agentic lean: where to start; the manufacturing use of hoshin kanri is in hoshin kanri for manufacturing.