Build an Ishikawa diagram, cause and effect analysis, or 6M fishbone to brainstorm and categorise all possible causes before narrowing to root cause with 5-Why. Covers Man, Machine, Method, Material, Measurement, and Environment (Mother Nature). Essential for 8D D4 brainstorming sessions and CAPA root cause…
Problem scoping with Is/Is-Not for 8D D2 problem description, CAPA investigation, or hypothesis elimination. Defines the precise boundary by contrasting what IS observed vs what IS NOT — eliminating hypotheses that don't fit the pattern. A Ford-originated automotive technique used in every structured quality…
Run a PDCA cycle, Plan Do Check Act improvement cycle, or structured improvement project. Guides through problem analysis, piloting, verification, and standardisation. Distinguished from 8D: PDCA is for proactive improvement initiatives, 8D is for reactive defect response. Use for process optimisation, lessons learned…
Run quality problem zeroing, perform 双归零 (double-five zeroing), write a technical zeroing report, write a management zeroing report, or close an aerospace quality problem under GB/T 29076—2021. Covers problem reporting, emergency response, team formation, technical zeroing (定位准确、机理清楚、问题复现、 措施有效、举一反三), management…
Assign AP table ratings (H-AP, M-AP, L-AP) in PFMEA or DFMEA — the RPN replacement from AIAG-VDA FMEA Handbook 2019. Explains H/M/L classification logic, mandatory action requirements for High Priority items, and OEM-specific thresholds. Use when assigning risk levels in PFMEA or DFMEA, or auditing FMEA documents for…
Build a design risk analysis, DFMEA worksheet, or interface analysis using the AIAG-VDA FMEA Handbook 2019. Covers design intent, interface failures, boundary diagram, and design robustness before manufacturing. Use during new product development, design changes, or when a field failure reveals a design weakness.…
Build a PFMEA worksheet, process risk analysis, or AP table using the AIAG-VDA FMEA Handbook 2019 7-step approach. Covers Structure Analysis, Function Analysis, Failure Analysis, Risk Analysis (Action Priority H/M/L), Optimization, and Documentation. Required by IATF 16949 and OEM customer-specific requirements for…
Supplier Corrective Action Request (SCAR) — escalate a supplier non-conformance to a formal corrective action request, define response requirements, evaluate the supplier's 8D response, and verify effectiveness. Use when an NCR escalates to a SCAR, when a supplier delivers repeated non-conformances, or when a field…
Reviews AI feature UI for accessibility — ARIA live regions, reading order, cognitive load, keyboard navigation, and screen reader compatibility. Use before any AI feature ships. Produces a verdict with blocking issues, not a list of suggestions.
Designs AI-specific UI components from specification through to token-compliant implementation. Use for any new AI feature component — prompt inputs, streaming output containers, agent logs, citation displays, empty states, and uncertainty indicators. Produces full specs before any code.
Designs the prompt input experience for AI features — input pattern, suggestion system, feedback loop, history, and constraints. Use before implementing any AI prompt input or chat interface.
Designs all required states for AI feature UI touchpoints. Use at the start of any new AI feature — before component code is written. Produces the state map and spec that every other agent depends on.
Critiques AI product UX against the builder-design patterns. Use after any AI feature UI is drafted — before it ships. Produces a structured verdict with blocking issues and required fixes, not a list of suggestions.
Instructions for RBraga01/builder-design, covering builder-design — ai ui design skills pack v1.0.0, what this pack is, skills, agents and enforcement model.
Use before shipping any UI that renders AI-generated content. Dynamic model output requires ARIA live regions, reading order, and cognitive load review that static content does not. Blocks "we'll do accessibility later" completions.
Use when designing or implementing any of the 6 core AI UI components. Each has specific patterns, pitfalls, and required sub-components that generic UI components don't address.
Use when designing first-run flows and empty states for AI features. AI onboarding has specific requirements — model capability communication, trust building, and graceful degradation when the model doesn't know — that generic onboarding patterns miss.
Use when designing how AI-generated content is rendered — streaming text, structured data, citations, code blocks, and uncertainty signals. Covers both visual rendering and the accessibility layer.
Use before writing any code for an AI feature's UI. All 7 states must be designed and documented before implementation begins. Blocks "we'll add loading states later" completions.
Use before implementing any new AI feature UI component. Requires a written shape/spec — layout, states, copy, interactions — before a single line of implementation code is written. Blocks "I'll design it as I build it" completions.
Use before any AI feature UI lands in production. Every colour, spacing value, typography, shadow, and border in AI components must reference design tokens — no hardcoded values. Blocks "I'll align with the design system later" completions.
Use when designing the user-facing prompt experience for any AI feature. Covers input design, suggestion patterns, history, feedback signals, and the interaction model between user intent and model execution.