RBraga01
User22 quality engineering skills and 8 agents for AI — ISO 9001, IATF 16949, AIAG-VDA FMEA, VDA 6.3, PPAP, APQP, SPC, MSA
Categories
Indexed Skills (71)
8d-coach
Interactive 8D coach for running a live G8D or TOPS-8D investigation step by step, validating root cause depth, rejecting weak containment, and checking D7 systemic prevention. Use when running an 8D investigation live, reviewing a draft 8D before customer submission, or training a team on the 8 Disciplines methodology.
fmea-reviewer
PFMEA and DFMEA gap audit against AIAG-VDA FMEA Handbook 2019 — reviews an existing FMEA for missing failure modes, incorrect AP ratings, unaddressed H-AP items, missing special characteristics, and PFMEA-to-Control Plan linkage gaps. Returns a structured gap report with specific findings and required actions before PPAP or audit submission.
ncr-writer
Write a non-conformance report or NCR fast — converts bullet-point inputs into professional objective-evidence language, suggests Critical/Major/Minor severity, recommends disposition, and flags missing required information. Use when writing an NCR quickly or when informal defect observations need to become formal quality records.
rca-facilitator
Interactive root cause analysis facilitator — runs a structured 5-Why why chain session, challenges each answer with evidence requirements, detects symptomatic and circular reasoning, and produces a validated Why chain with reversal check. Use for 8D D4, CAPA investigations, FMEA cause analysis, or any quality investigation requiring confirmed root cause identification.
skill-auditor
Audit a SKILL.md or REFERENCE file, score it 0–10, identify major and minor findings, and generate copy-paste improvements. Use when reviewing a new skill before merging, auditing an existing skill for gaps, checking cross-skill consistency, or validating that a skill meets the Quality-Engineering-Skills framework standards. Triggers: audit this skill, score this SKILL.md, review reference file, check skill quality, find gaps in skill, validate skill before PR.
control-plan-builder
Interactive Control Plan builder — takes PFMEA failure modes and process flow steps as input and builds a complete Control Plan row by row, with correct control methods, sample plans, and reaction plans for each characteristic. Use when building a new Control Plan, updating after a corrective action (8D D7), or converting a PFMEA into Control Plan format. Covers AIAG Control Plan reference manual and IATF 16949 §8.5.1.
ppap-checker
Interactive PPAP completeness checker — walks through all 18 PPAP elements for a given submission level, identifies missing or incomplete items, and generates a gap report before PSW signature. Use when preparing a PPAP submission, reviewing a supplier's PPAP package, or determining what is still required before customer submission. Covers AIAG PPAP 4th Edition.
iatf-16949-audit
Conduct an IATF audit, check supplemental requirements, or prepare for a manufacturing process audit or IATF 16949:2016 third-party assessment. Covers customer-specific requirements (CSR), all 16 automotive supplemental clauses, and the three required audit types: QMS audit, manufacturing process audit, and product audit. Use for internal IATF audits or supplier quality audits at automotive organisations.
iso-9001-internal-audit
Conduct an internal audit by clause, answer ISO 9001 internal audit questions, or prepare evidence for §4 §5 §6 §7 §8 §9 §10. Provides key audit questions by clause, finding classification (Major NC / Minor NC / OFI), and audit report writing. Use when planning or conducting an ISO 9001:2015 internal audit or preparing for third-party certification.
vda-6-3-audit
VDA 6.3 Process Audit — conduct or prepare for a process audit using the VDA 6.3 methodology, evaluate process elements P1–P7, calculate degree of fulfillment, classify findings, and generate an audit report. Use when a customer requests a VDA 6.3 audit, when auditing a supplier's manufacturing process, or when preparing for a VDA process audit visit. Covers VDA 6.3 4th edition (2023).
8d-report-writing
Submit an 8D to a customer, format a Ford 8D report, BMW G8D, VW QMSS, or OEM complaint response for formal submission. Covers OEM-specific format requirements, evidence standards, and discipline-by-discipline writing rules for D0–D8. Use when preparing an 8D report for Ford, BMW, VW/Audi, Stellantis, or any customer requiring formal 8D closure.
car-corrective-action
Write a corrective action report, CAPA, respond to an NCR or audit finding, or document an 8D D5 root cause action. Covers the full CAR structure: root cause analysis, corrective actions, implementation evidence, and verification of effectiveness (VOE) per ISO 9001 §10.2. Use for any quality escape requiring documented systemic corrective action.
ncr-writing
Write a non-conformance report, NCR, reject a supplier, or document a defect with objective-evidence language and correct severity grading (Critical/Major/Minor). Covers disposition recommendations and segregation requirements for incoming inspection failures, in-process defects, customer returns, and audit findings.
msa-gauge-rr
Measurement System Analysis (MSA) and Gauge Repeatability & Reproducibility (Gauge R&R) — plan, execute, and interpret an MSA study for variable or attribute measurement systems. Use when qualifying a gauge for a new part, validating a measurement system before PPAP, interpreting Gauge R&R results, or auditing MSA studies for adequacy. Covers AIAG MSA 4th edition.
spc-control-charts
Statistical Process Control (SPC) — select the correct control chart, interpret out-of-control signals using Western Electric rules, calculate and interpret Cp, Cpk, Pp, Ppk. Use when setting up SPC for a new characteristic, interpreting control chart signals, responding to special cause variation, or auditing SPC implementation. Covers AIAG SPC 2nd edition and IATF 16949 §8.3.3.
apqp
Advanced Product Quality Planning (APQP) — plan and track a new product launch through all 5 phases, identify deliverables per phase, run gate reviews, and ensure quality outputs are complete before Start of Production (SOP). Use when launching a new part, managing an APQP project, or auditing APQP completeness. Covers AIAG APQP 2nd edition and IATF 16949 §8.3.
control-plan
Control Plan — build, review, or audit a Prototype, Pre-launch, or Production Control Plan linked to PFMEA failure modes and controls. Use when creating a new control plan, updating after a process change or corrective action, or auditing an existing CP for completeness and PFMEA alignment. Covers AIAG Control Plan reference manual and IATF 16949 §8.5.1.
dvp-test-plan
Design Verification Plan and Report (DVP&R) — build or review a test plan that links each DFMEA failure mode to a specific test, pass/fail criterion, sample size, and timing. Use when creating a DVP for a new design, reviewing a supplier's DVP for completeness, or auditing whether all design risks are covered by validation testing. Covers IATF 16949 §8.3.4.3 and AIAG APQP Phase 2.
ppap
Production Part Approval Process (PPAP) — verify PPAP submission level, audit all 18 elements, check completeness for customer approval, prepare PSW. Use when a supplier needs to submit parts for approval, when reviewing a PPAP package, or when determining which PPAP level is required. Covers AIAG PPAP 4th edition with Ford, BMW, VW, and Stellantis OEM-specific requirements.
5why-root-cause
Drill into root cause with a 5-Why why chain, why analysis, or structured root cause investigation. Builds a Why chain from symptom to systemic root cause, validates each step with evidence, and detects circular reasoning. Use for 8D D4, CAPA, FMEA cause analysis, or any quality investigation requiring confirmed root cause identification.
8d-problem-solving
Open an 8D, run a G8D or TOPS-8D investigation, respond to a warranty complaint, or handle a customer quality escape with the 8 Disciplines methodology. Covers D0 emergency response through D8 team recognition with gate validation. Required for automotive OEM complaints — Ford, BMW, VW, Stellantis — and any quality escape needing documented root cause and PCA.
dmaic
DMAIC (Define-Measure-Analyze-Improve-Control) — Six Sigma structured problem-solving for chronic, data-driven quality improvement projects. Use when a problem recurs despite corrective actions, when a process needs systematic capability improvement, or when a customer requests a Six Sigma approach. Use 8D for reactive single-incident problems; use DMAIC for recurring systemic issues requiring statistical analysis. Covers IATF 16949 §10.1 and ISO 9001 §10.3.
fishbone-analysis
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 investigations.
is-is-not-scoping
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 investigation.
pdca-improvement
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 implementation, and quality objectives.
action-priority-ap
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 AP compliance.
dfmea-design
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. Required for IATF 16949 §8.3 scope.
pfmea-process
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 new processes, process changes, and post-escape PFMEA updates.
supplier-scar
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 failure is traced to a supplier. Covers ISO 9001 §8.4 and IATF 16949 §8.4.1.
accessible-ai-output
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.
ai-component-patterns
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.
ai-onboarding-design
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.
ai-output-design
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.
ai-states-required
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.
design-before-code
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.
design-token-audit
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.
prompt-ux-design
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.
ab-test-design
Use before running any experiment that will inform a product decision. All six elements — hypothesis, metric, sample size, duration, stopping rule, and decision rule — must be defined before the test starts. Blocks "we'll stop when we see something" completions.
feature-scoping
Use before any engineering estimate is made. Requires a written scope before an estimate, and a written estimate before a commit. Blocks "we'll scope as we go" and "just give me a rough number" completions.
metric-definition
Use before writing any implementation code for a new feature. North star metric, guardrail metrics, and diagnostic metrics must be defined — with baselines — before the build begins. Blocks "we'll figure out the metrics from the data" completions.
prd-quality-gate
Use before committing scope, estimate, or engineering time to any feature. Requires user problem, success metric, scope boundary, and anti-goals defined before any estimate is made. Blocks "we'll define success once we see the data" completions.
user-research-synthesis
Use after conducting user research and before making product decisions from it. Requires every insight to map to a decision. Blocks "users said X" reports that produce no actionable direction.
ai-messaging-review
Use before any AI product messaging ships externally. Audits capability claims for accuracy, quantified claims for evidence, and "AI" labels for specificity. Blocks "10x productivity" without measurement and "AI-powered" without definition.
copy-quality-gate
Use before any external-facing copy ships. Applies three tests — "so what?", "who cares?", and "why now?" — to every claim in the copy. Blocks "it explains what we do" completions.
experiment-design
Use before running any growth experiment — pricing test, copy variant, onboarding flow, feature gate — that will inform a ship/no-ship decision. All six elements must be defined before the test starts. Blocks "we'll run it for a while and see" completions.
funnel-analysis
Use before beginning any conversion rate optimisation effort. Requires the leak to be identified and root-caused before any solution is proposed. Blocks "let's improve our conversion rate" without knowing which step breaks.
positioning-audit
Use before any marketing copy is written for a product, feature, or campaign. Requires a clear category, a specific audience, and a differentiated claim — verified against the "so what?" test — before any copy is produced. Blocks "we'll develop the messaging as we write" completions.
retention-design
Use before launching any new feature or product. Requires the activation moment, habit loop, and reactivation path to be designed before launch. Blocks "users will come back if they like it" completions.
api-contract-first
Hard gate before implementing any API endpoint or service interface. Requires a written, reviewed contract (OpenAPI 3.x, protobuf, or GraphQL schema) before any implementation code is written. Prevents breaking changes, misaligned clients, and undocumented behaviour.
data-migration
Hard gate before any database schema change or data transformation in production. Requires a written migration plan with rollback strategy, dry run, and verification steps before execution. Prevents data loss, downtime, and irreversible schema changes.
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies. Dispatches one focused agent per problem domain, runs them concurrently, then integrates.
five-whys
Root cause analysis using the Five Whys technique. Use when a bug persists despite surface fixes, a failure recurs, or a process keeps breaking. Ensures the fix targets the root, not the symptom.
performance-audit
Systematic performance investigation workflow. Use when performance regressions are suspected, before and after optimisation work, or as a pre-release gate for performance-critical features. Produces a baseline, identifies the real bottleneck, and validates improvement with hard numbers.
smart-init
Conversational onboarding for A Team. Detects ROADMAP.md, extracts context, generates INIT.md without requiring technical knowledge. Invoked automatically by the orchestrator when INIT.md is missing.
subagent-driven-development
Use when executing implementation plans with independent tasks in the current session. Dispatches a fresh subagent per task with two-stage review (spec compliance, then code quality).
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior. Enforces root-cause investigation before fixes. The Iron Law — no fixes without understanding why.
test-driven-development
Enforce RED-GREEN-REFACTOR discipline for every implementation task. Use for all new features, bug fixes, and refactors. The core rule — if you didn't watch the test fail, you don't know if it tests the right thing.
using-a-team
The meta-skill. Loaded at every session start. Defines which A Team skills and agents MUST be used for which situations. If a skill or agent applies, you do not have a choice — you must use it.
using-git-worktrees
Create or verify an isolated git worktree before starting any development work. Prevents main branch contamination, enables parallel feature development, and gives subagents a clean baseline. Use at the start of every feature branch.
verification-before-completion
Use before claiming ANY task is complete. Requires you to run actual verification commands, read real output, and confirm it matches expectations — before stating the task is done. Blocks "should work" rationalizations.
writing-plans
Create a detailed, phased implementation plan from an approved spec. Use after brainstorming produces an approved spec. Produces a plan file that executing-plans or subagent-driven-development can consume.
writing-skills
Create new A Team skills using TDD for documentation. Write a bad skill, watch agents fail at the gap, improve, iterate. Use when the team needs a new capability that no existing skill covers.
executing-plans
Use when you have a written implementation plan to execute in the current session. Loads the plan, reviews critically, executes all tasks, and reports when complete.
finishing-a-development-branch
Complete a development branch before merge — verify tests pass, update documentation, ensure quality gate passes, and prepare a clean PR.
ai-cost-audit
Use before launching any LLM feature or when monthly API costs are growing unexpectedly. Requires token count measurement, call volume analysis, and cost projection at 10× scale. Blocks "it's cheap enough now" completions.
ai-safety-review
Use before shipping any LLM feature that touches users. Reviews prompt injection, hallucination risk, output misuse, agentic scope, and abuse vectors. Blocks "nobody will try that" completions.
eval-before-ship
Use before merging, deploying, or demo'ing any LLM feature. Requires documented eval results — pass rate, failure analysis, baseline comparison. Blocks "it looked good when I tested it" completions.
fallback-required
Use before merging any PR that adds an LLM API call. Every call must handle timeout, malformed output, low confidence, and refusal — with a defined, user-safe fallback for each. Blocks "add error handling later" completions.
model-benchmarking
Use when selecting a model for any production feature, or evaluating whether to switch models. Requires task-specific benchmarking — not leaderboard lookup. Blocks "GPT-4 is the best model" decisions.
prompt-versioning
Use whenever writing or modifying a prompt that will run in production. Enforces version-controlled prompts in prompts/<feature>/v<x.y.z>.md. Blocks "the prompt is in the code somewhere" completions.
rag-pipeline-design
Use when designing or auditing a retrieval-augmented generation pipeline. Requires data audit and query audit before any design decision. Blocks "I'll use the standard setup" completions.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.