[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MD8Q8B0CDYXASB086J8JCM":3,"skill-same:01M6MD8Q8B0CDYXASB086J8JCM":87},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6MD8Q8B0CDYXASB086J8JCM","dmaic",null,"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.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1566,"MIT","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FRBraga01\u002FQuality-Engineering-Skills\u002Fskills\u002Fproblem-solving\u002Fdmaic\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"iso","2026","automotive","when","capability","reactive","data-driven","quality improvement","problem","systematic","medical","customer","incident","problem-solving","analyze","projects","improve","analysis","sigma","data","actions","issues","2026-11-10 10:12:30",false,"---\nname: dmaic\ndescription: >-\n  DMAIC (Define-Measure-Analyze-Improve-Control) — Six Sigma structured problem-solving for\n  chronic, data-driven quality improvement projects. Use when a problem recurs despite corrective\n  actions, when a process needs systematic capability improvement, or when a customer requests\n  a Six Sigma approach. Use 8D for reactive single-incident problems; use DMAIC for recurring\n  systemic issues requiring statistical analysis. Covers IATF 16949 §10.1 and ISO 9001 §10.3.\nlicense: MIT\nmetadata:\n  author: RBraga01\n  version: \"1.1\"\n  iso-9001: \"10.3\"\n  iatf-16949: \"10.1\"\n  domain: quality-engineering\n  subdomain: problem-solving\n  industries: automotive,electronics,aerospace,medical,general\n  status: approved\n  created: \"2026-06-06\"\n  last_updated: \"2026-06-06\"\n  updated_by: migmcc\n  reviewed_by: RBraga01\n  standard_edition: \"Six Sigma DMAIC \u002F ISO 9001:2015 §10.3 \u002F IATF 16949:2016 §10.1\"\n---\n\n# DMAIC (Six Sigma Problem Solving)\n\n## When to use\n\nUse DMAIC when:\n- A problem has recurred multiple times despite previous corrective actions\n- The process needs measurable, data-driven capability improvement (Cpk improvement target)\n- The root cause is unknown and requires statistical analysis to identify\n- A customer requires a Six Sigma approach or asks for a DMAIC report\n- The improvement opportunity involves eliminating chronic waste (rework, scrap, test failures)\n\n**Use 8D instead when:** The problem is a single customer complaint, an escape to the field, or requires immediate containment. 8D is reactive and fast. DMAIC is proactive and thorough — it takes weeks to months.\n\n**Use PDCA instead when:** The improvement is incremental and the root cause is already known or assumed.\n\n## Prerequisites\n\n- A defined problem with measurable impact (reject rate, Cpk, scrap cost, defect count)\n- Baseline data available or collectable\n- Process owner and cross-functional team assigned\n- Management support and a time budget (minimum 4–12 weeks depending on project scope)\n\n## Workflow\n\n### Phase 1 — DEFINE\n\n**Objective:** Define the problem, the scope, the team, and the goal in measurable terms.\n\n**Key tools and deliverables:**\n\n**Project Charter** — The DMAIC starts and ends here. Contains:\n- Problem statement: what is happening, where, since when, how much (measured impact)\n- Goal statement: specific, measurable target (e.g., \"Reduce connector reject rate from 3.2% to 0.5% by Q3\")\n- Scope: what is IN and OUT of scope (use Is\u002FIs-Not to define boundaries)\n- Business case: financial or customer impact ($, PPM, warranty cost)\n- Team: Champion, Black Belt\u002FGreen Belt, process owner, operators, engineering\n\n**SIPOC diagram:**\n- Suppliers → Inputs → Process → Outputs → Customers\n- Defines the process at a high level before diving into detail\n- Identifies all inputs that could affect the output (Y)\n\n**Voice of the Customer (VOC) → CTQ:**\n- What does the customer care about? (VOC)\n- Translate to a measurable Critical to Quality (CTQ) characteristic\n- The CTQ becomes the Y (output) the project will improve\n\n**Gate criteria to exit Define:**\n- Problem is specific and measurable\n- Goal is agreed with the Champion\n- Scope is bounded\n- Team is assigned and available\n\n---\n\n### Phase 2 — MEASURE\n\n**Objective:** Establish the current baseline and validate the measurement system.\n\n**Key tools and deliverables:**\n\n**Process map (detailed):**\n- Map every step of the process as it IS (not as it should be)\n- Identify where defects are created or detected\n- Mark each step: Value-Added (VA), Non-Value-Added (NVA), or Required Non-Value-Added\n\n**Data collection plan:**\n- What will be measured? (the Y and key process inputs Xs)\n- How will it be measured? (gauge, method)\n- How many samples? (for capability: minimum 100 pieces)\n- Who will collect data? When? Where?\n\n**MSA (Gauge R&R):**\n- Validate the measurement system for the CTQ before collecting data\n- %GRR \u003C 30% required; \u003C10% preferred\n- If measurement system is inadequate: fix it before proceeding\n\n**Baseline capability:**\n- Calculate current Cpk\u002FPpk for the CTQ\n- Establish current defect rate (PPM or %)\n- This baseline is the MEASURE gate deliverable — do not proceed without it\n\n**Gate criteria to exit Measure:**\n- Baseline Cpk\u002FPPM established with statistical confidence\n- MSA complete and measurement system adequate\n- Data collection plan executed with sufficient data\n\n---\n\n### Phase 3 — ANALYZE\n\n**Objective:** Identify and confirm the root cause(s) of the problem using data.\n\n**Key tools and deliverables:**\n\n**Fishbone \u002F Cause & Effect diagram:**\n- Brainstorm potential causes using 6M (Man, Machine, Method, Material, Measurement, Mother Nature)\n- All potential causes are hypotheses at this stage — none are confirmed\n\n**Is\u002FIs-Not analysis:**\n- Scope the problem precisely — what IS affected vs. what IS NOT\n- Narrows the hypothesis list before investing in analysis\n\n**Multi-Vari study:**\n- Understand whether variation is: positional (within-part), cyclical (part-to-part), or temporal (time-based)\n- Identifies the dominant family of variation — directs the investigation\n\n**Hypothesis testing:**\nConfirm or reject hypotheses statistically. Selection guide:\n\n| Situation | Tool |\n|-----------|------|\n| Compare means of 2 groups (continuous Y, e.g., Shift A vs. B) | t-test (paired if same parts measured twice) |\n| Compare means of 3+ groups (e.g., 3 machines, 4 operators) | One-way ANOVA |\n| Categorical Y (pass\u002Ffail) vs. categorical X (supplier, shift) | Chi-square test |\n| Continuous Y vs. continuous X (does temperature predict dimension?) | Pearson correlation; then regression to quantify |\n| Multiple Xs affecting one Y | Multiple regression; confirm no multicollinearity |\n\nUse p \u003C 0.05 as the significance threshold unless a different risk level is warranted. Always check the test's assumptions (normality for t-test\u002FANOVA; independence for chi-square).\n\n**Root cause confirmation:**\n- A root cause is NOT confirmed until data proves it\n- Reject \"human error\" as a root cause — it is a symptom; ask why the error was possible\n- Confirmed root causes: demonstrate that when the Xs change, the Y changes predictably\n\n**Gate criteria to exit Analyze:**\n- Root cause(s) confirmed with data (not assumed)\n- Cause-and-effect quantified (Y = f(X) relationship established)\n- Team agrees on which Xs to improve\n\n---\n\n### Phase 4 — IMPROVE\n\n**Objective:** Develop, test, and implement solutions that address the confirmed root causes.\n\n**Key tools and deliverables:**\n\n**Solution generation:**\n- Brainstorm solutions for each confirmed root cause\n- Evaluate solutions: impact vs. effort vs. risk\n- Do NOT select solutions based on opinion — test them\n\n**Pilot \u002F Design of Experiment (DOE):**\n- Test the proposed solution on a small scale before full implementation\n- DOE: systematically vary multiple factors to find the optimal process settings\n- Simple experiments: OFAT (One Factor At A Time) for straightforward improvements\n\n**Solution validation:**\n- Run a production pilot with the solution in place\n- Collect data: does the Y improve as predicted?\n- Calculate new Cpk\u002FPPM — compare to baseline and goal\n\n**Implementation plan:**\n- Who does what, by when, to implement the solution at full scale\n- Change management: update Process Flow, PFMEA, Control Plan, Work Instructions, training\n\n**Gate criteria to exit Improve:**\n- Solution tested and statistically validated (not just \"it seems better\")\n- Cpk\u002FPPM improvement demonstrated in pilot data\n- Implementation plan complete and approved\n\n---\n\n### Phase 5 — CONTROL\n\n**Objective:** Sustain the gains — prevent the process from reverting to the old state.\n\n**Key tools and deliverables:**\n\n**Updated Control Plan:**\n- Add new controls for the Xs identified in Analyze\n- Define monitoring frequency and reaction plan for out-of-control conditions\n\n**SPC \u002F Statistical monitoring:**\n- Install control charts on the critical Xs and the Y\n- Set control limits from the improved process data\n- Define who monitors and how often\n\n**Updated PFMEA:**\n- New failure modes identified during the project must be added\n- Controls added in Improve must be reflected in the PFMEA current controls column\n\n**Updated Work Instructions:**\n- Document the new process steps, settings, or behaviours required\n- Train operators and verify understanding\n\n**Mistake-proofing (Poka-yoke):**\n- For any root cause that was behavioural or procedural: add error-proofing to prevent recurrence\n- Error-proofing is the highest-reliability control — prefer it over inspection or SPC alone\n\n**Project handover:**\n- Transfer ownership from the project team to the process owner\n- Establish a 3–6 month monitoring period with defined Cpk targets; specify the minimum Cpk that constitutes \"sustained improvement\" (e.g., Cpk ≥ 1.33 for a minimum of 3 consecutive months of production data — not 3 months of calendar time)\n- Close the project only when the monitoring criterion is met with actual production data — not lab data or pilot data\n\n**Final project report:**\n- Before and after: Cpk, PPM, financial savings\n- Lessons learned for future projects\n\n**Gate criteria to close the project:**\n- Cpk\u002FPPM goal achieved and sustained for minimum 3 months post-implementation\n- All documents updated (PFMEA, CP, WIs)\n- Process ownership transferred to process owner\n- Financial benefits validated by Finance (if business case required it)\n\n---\n\n### DMAIC vs. 8D — quick reference\n\n| Dimension | 8D | DMAIC |\n|-----------|-----|-------|\n| Trigger | Customer complaint, single escape | Recurring problem, capability gap |\n| Timeline | Days to weeks | Weeks to months |\n| Root cause method | 5-Why, Fishbone | Hypothesis testing, statistical analysis |\n| Output | Corrective action to prevent recurrence | Optimised process with sustained capability |\n| Standards | ISO 9001 §10.2, IATF 16949 §10.2.3 | ISO 9001 §10.3, IATF 16949 §10.1 |\n\n## Validation criteria\n\nA DMAIC project is complete when:\n- Baseline and improved Cpk\u002FPPM both quantified with data\n- Root causes confirmed statistically (not assumed)\n- Solution validated in a pilot before full implementation\n- PFMEA, Control Plan, and Work Instructions updated\n- Improved Cpk sustained for minimum 3 months post-implementation\n- Financial or quality benefit measured and reported\n\n## Common mistakes\n\n- Jumping to Improve before confirming root cause (the most common DMAIC failure)\n- Not performing MSA before collecting baseline data — baseline may be measurement noise\n- Selecting the solution in Define before data analysis — biases the entire project\n- Closing the project at Implementation without monitoring for sustainability\n- Not updating PFMEA and Control Plan — process reverts within months\n- Using DMAIC for a single-event problem that needs 8D containment first\n\n## Output Format\n\nAt the start of each use, ask the user:\n\n> \"How would you like to receive the output?\n> **A** — Structured Markdown (formatted tables and sections, ready to copy)\n> **B** — Plain tables (simplified structure for Excel or Word)\n> **C** — Narrative report (flowing text for a formal document or email)\n>\n> Default: A.\"\n\nAdapt all output sections to the chosen format. If the platform or session context already defines a format preference, skip this question.\n\n## Changelog\n\n| Version | Date | Author | Change |\n|---------|------|--------|--------|\n| 1.0 | 2026-06-06 | @RBraga01 | Initial release |\n| 1.1 | 2026-06-06 | @migmcc | Added hypothesis test selection guide in Phase 3; added monitoring period closure criteria in Phase 5 (Cpk sustained on production data, not pilot) |\n","# DMAIC (Six Sigma Problem Solving)\n\n## When to use\n\nUse DMAIC when:\n- A problem has recurred multiple times despite previous corrective actions\n- The process needs measurable, data-driven capability improvement (Cpk improvement target)\n- The root cause is unknown and requires statistical analysis to identify\n- A customer requires a Six Sigma approach or asks for a DMAIC report\n- The improvement opportunity involves eliminating chronic waste (rework, scrap, test failures)\n\n**Use 8D instead when:** The problem is a single customer complaint, an escape to the field, or requires immediate containment. 8D is reactive and fast. DMAIC is proactive and thorough — it takes weeks to months.\n\n**Use PDCA instead when:** The improvement is incremental and the root cause is already known or assumed.\n\n## Prerequisites\n\n- A defined problem with measurable impact (reject rate, Cpk, scrap cost, defect count)\n- Baseline data available or collectable\n- Process owner and cross-functional team assigned\n- Management support and a time budget (minimum 4–12 weeks depending on project scope)\n\n## Workflow\n\n### Phase 1 — DEFINE\n\n**Objective:** Define the problem, the scope, the team, and the goal in measurable terms.\n\n**Key tools and deliverables:**\n\n**Project Charter** — The DMAIC starts and ends here. Contains:\n- Problem statement: what is happening, where, since when, how much (measured impact)\n- Goal statement: specific, measurable target (e.g., \"Reduce connector reject rate from 3.2% to 0.5% by Q3\")\n- Scope: what is IN and OUT of scope (use Is\u002FIs-Not to define boundaries)\n- Business case: financial or customer impact ($, PPM, warranty cost)\n- Team: Champion, Black Belt\u002FGreen Belt, process owner, operators, engineering\n\n**SIPOC diagram:**\n- Suppliers → Inputs → Process → Outputs → Customers\n- Defines the process at a high level before diving into detail\n- Identifies all inputs that could affect the output (Y)\n\n**Voice of the Customer (VOC) → CTQ:**\n- What does the customer care about? (VOC)\n- Translate to a measurable Critical to Quality (CTQ) characteristic\n- The CTQ becomes the Y (output) the project will improve\n\n**Gate criteria to exit Define:**\n- Problem is specific and measurable\n- Goal is agreed with the Champion\n- Scope is bounded\n- Team is assigned and available\n\n---\n\n### Phase 2 — MEASURE\n\n**Objective:** Establish the current baseline and validate the measurement system.\n\n**Key tools and deliverables:**\n\n**Process map (detailed):**\n- Map every step of the process as it IS (not as it should be)\n- Identify where defects are created or detected\n- Mark each step: Value-Added (VA), Non-Value-Added (NVA), or Required Non-Value-Added\n\n**Data collection plan:**\n- What will be measured? (the Y and key process inputs Xs)\n- How will it be measured? (gauge, method)\n- How many samples? (for capability: minimum 100 pieces)\n- Who will collect data? When? Where?\n\n**MSA (Gauge R&R):**\n- Validate the measurement system for the CTQ before collecting data\n- %GRR \u003C 30% required; \u003C10% preferred\n- If measurement system is inadequate: fix it before proceeding\n\n**Baseline capability:**\n- Calculate current Cpk\u002FPpk for the CTQ\n- Establish current defect rate (PPM or %)\n- This baseline is the MEASURE gate deliverable — do not proceed without it\n\n**Gate criteria to exit Measure:**\n- Baseline Cpk\u002FPPM established with statistical confidence\n- MSA complete and measurement system adequate\n- Data collection plan executed with sufficient data\n\n---\n\n### Phase 3 — ANALYZE\n\n**Objective:** Identify and confirm the root cause(s) of the problem using data.\n\n**Key tools and deliverables:**\n\n**Fishbone \u002F Cause & Effect diagram:**\n- Brainstorm potential causes using 6M (Man, Machine, Method, Material, Measurement, Mother Nature)\n- All potential causes are hypotheses at this stage — none are confirmed\n\n**Is\u002FIs-Not analysis:**\n- Scope the problem precisely — what IS affected vs. what IS NOT\n- Narrows the hypothesis list before investing in analysis\n\n**Multi-Vari study:**\n- Understand whether variation is: positional (within-part), cyclical (part-to-part), or temporal (time-based)\n- Identifies the dominant family of variation — directs the investigation\n\n**Hypothesis testing:**\nConfirm or reject hypotheses statistically. Selection guide:\n\n| Situation | Tool |\n|-----------|------|\n| Compare means of 2 groups (continuous Y, e.g., Shift A vs. B) | t-test (paired if same parts measured twice) |\n| Compare means of 3+ groups (e.g., 3 machines, 4 operators) | One-way ANOVA |\n| Categorical Y (pass\u002Ffail) vs. categorical X (supplier, shift) | Chi-square test |\n| Continuous Y vs. continuous X (does temperature predict dimension?) | Pearson correlation; then regression to quantify |\n| Multiple Xs affecting one Y | Multiple regression; confirm no multicollinearity |\n\nUse p \u003C 0.05 as the significance threshold unless a different risk level is warranted. Always check the test's assumptions (normality for t-test\u002FANOVA; independence for chi-square).\n\n**Root cause confirmation:**\n- A root cause is NOT confirmed until data proves it\n- Reject \"human error\" as a root cause — it is a symptom; ask why the error was possible\n- Confirmed root causes: demonstrate that when the Xs change, the Y changes predictably\n\n**Gate criteria to exit Analyze:**\n- Root cause(s) confirmed with data (not assumed)\n- Cause-and-effect quantified (Y = f(X) relationship established)\n- Team agrees on which Xs to improve\n\n---\n\n### Phase 4 — IMPROVE\n\n**Objective:** Develop, test, and implement solutions that address the confirmed root causes.\n\n**Key tools and deliverables:**\n\n**Solution generation:**\n- Brainstorm solutions for each confirmed root cause\n- Evaluate solutions: impact vs. effort vs. risk\n- Do NOT select solutions based on opinion — test them\n\n**Pilot \u002F Design of Experiment (DOE):**\n- Test the proposed solution on a small scale before full implementation\n- DOE: systematically vary multiple factors to find the optimal process settings\n- Simple experiments: OFAT (One Factor At A Time) for straightforward improvements\n\n**Solution validation:**\n- Run a production pilot with the solution in place\n- Collect data: does the Y improve as predicted?\n- Calculate new Cpk\u002FPPM — compare to baseline and goal\n\n**Implementation plan:**\n- Who does what, by when, to implement the solution at full scale\n- Change management: update Process Flow, PFMEA, Control Plan, Work Instructions, training\n\n**Gate criteria to exit Improve:**\n- Solution tested and statistically validated (not just \"it seems better\")\n- Cpk\u002FPPM improvement demonstrated in pilot data\n- Implementation plan complete and approved\n\n---\n\n### Phase 5 — CONTROL\n\n**Objective:** Sustain the gains — prevent the process from reverting to the old state.\n\n**Key tools and deliverables:**\n\n**Updated Control Plan:**\n- Add new controls for the Xs identified in Analyze\n- Define monitoring frequency and reaction plan for out-of-control conditions\n\n**SPC \u002F Statistical monitoring:**\n- Install control charts on the critical Xs and the Y\n- Set control limits from the improved process data\n- Define who monitors and how often\n\n**Updated PFMEA:**\n- New failure modes identified during the project must be added\n- Controls added in Improve must be reflected in the PFMEA current controls column\n\n**Updated Work Instructions:**\n- Document the new process steps, settings, or behaviours required\n- Train operators and verify understanding\n\n**Mistake-proofing (Poka-yoke):**\n- For any root cause that was behavioural or procedural: add error-proofing to prevent recurrence\n- Error-proofing is the highest-reliability control — prefer it over inspection or SPC alone\n\n**Project handover:**\n- Transfer ownership from the project team to the process owner\n- Establish a 3–6 month monitoring period with defined Cpk targets; specify the minimum Cpk that constitutes \"sustained improvement\" (e.g., Cpk ≥ 1.33 for a minimum of 3 consecutive months of production data — not 3 months of calendar time)\n- Close the project only when the monitoring criterion is met with actual production data — not lab data or pilot data\n\n**Final project report:**\n- Before and after: Cpk, PPM, financial savings\n- Lessons learned for future projects\n\n**Gate criteria to close the project:**\n- Cpk\u002FPPM goal achieved and sustained for minimum 3 months post-implementation\n- All documents updated (PFMEA, CP, WIs)\n- Process ownership transferred to process owner\n- Financial benefits validated by Finance (if business case required it)\n\n---\n\n### DMAIC vs. 8D — quick reference\n\n| Dimension | 8D | DMAIC |\n|-----------|-----|-------|\n| Trigger | Customer complaint, single escape | Recurring problem, capability gap |\n| Timeline | Days to weeks | Weeks to months |\n| Root cause method | 5-Why, Fishbone | Hypothesis testing, statistical analysis |\n| Output | Corrective action to prevent recurrence | Optimised process with sustained capability |\n| Standards | ISO 9001 §10.2, IATF 16949 §10.2.3 | ISO 9001 §10.3, IATF 16949 §10.1 |\n\n## Validation criteria\n\nA DMAIC project is complete when:\n- Baseline and improved Cpk\u002FPPM both quantified with data\n- Root causes confirmed statistically (not assumed)\n- Solution validated in a pilot before full implementation\n- PFMEA, Control Plan, and Work Instructions updated\n- Improved Cpk sustained for minimum 3 months post-implementation\n- Financial or quality benefit measured and reported\n\n## Common mistakes\n\n- Jumping to Improve before confirming root cause (the most common DMAIC failure)\n- Not performing MSA before collecting baseline data — baseline may be measurement noise\n- Selecting the solution in Define before data analysis — biases the entire project\n- Closing the project at Implementation without monitoring for sustainability\n- Not updating PFMEA and Control Plan — process reverts within months\n- Using DMAIC for a single-event problem that needs 8D containment first\n\n## Output Format\n\nAt the start of each use, ask the user:\n\n> \"How would you like to receive the output?\n> **A** — Structured Markdown (formatted tables and sections, ready to copy)\n> **B** — Plain tables (simplified structure for Excel or Word)\n> **C** — Narrative report (flowing text for a formal document or email)\n>\n> Default: A.\"\n\nAdapt all output sections to the chosen format. If the platform or session context already defines a format preference, skip this question.\n\n## Changelog\n\n| Version | Date | Author | Change |\n|---------|------|--------|--------|\n| 1.0 | 2026-06-06 | @RBraga01 | Initial release |\n| 1.1 | 2026-06-06 | @migmcc | Added hypothesis test selection guide in Phase 3; added monitoring period closure criteria in Phase 5 (Cpk sustained on production data, not pilot) |\n",{"name":5,"license":15,"metadata":46,"description":7},{"author":47,"domain":48,"status":49,"created":50,"version":51,"iso-9001":52,"subdomain":32,"iatf-16949":53,"industries":54,"updated_by":55,"reviewed_by":47,"last_updated":50,"standard_edition":56},"RBraga01","quality-engineering","approved","2026-06-06","1.1","10.3","10.1","automotive,electronics,aerospace,medical,general","migmcc","Six Sigma DMAIC \u002F ISO 9001:2015 §10.3 \u002F IATF 16949:2016 §10.1","main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002FRBraga01\u002FQuality-Engineering-Skills\u002Fskills\u002Fproblem-solving\u002Fdmaic",483,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-13 02:16:32",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill dmaic",{"tool":73,"command":74},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill dmaic",{"tool":76,"command":77},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill dmaic","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FRBraga01\u002FQuality-Engineering-Skills\u002Fskills\u002Fproblem-solving\u002Fdmaic\u002FSKILL.md",true,[81],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fstatistical-tools.md","REFERENCE","参考文档",21000,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FRBraga01\u002FQuality-Engineering-Skills\u002Fskills\u002Fproblem-solving\u002Fdmaic\u002Freferences\u002Fstatistical-tools.md",[88,97,104,111,137,162],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":92,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":96},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":92,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":96},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":92,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":96},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":92,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":41},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[118,119,120,121,122,123,124,125,126,127,128,22,129,130,131,132,133,134,135,136],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":92,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":41},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[144,145,146,132,147,148,149,150,151,152,153,154,155,156,123,157,158,159,160,161],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":92,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":179,"publishedAt":41},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[168,173,176],{"categoryNo":169,"categoryName":170,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":174,"categoryName":175,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":177,"categoryName":178,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000010","后端与接口",[164,180,181,182,183,184,185,158,186,124,187,188,189,190,22,191,192,193,194,195],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]