[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MD8J30WR9GGM0M8APY30WC":3,"skill-same:01M6MD8J30WR9GGM0M8APY30WC":94},{"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":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":63,"ownerHtmlUrl":64,"ownerBlogUrl":65,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M6MD8J30WR9GGM0M8APY30WC","8d-problem-solving",null,"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.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"MIT","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FRBraga01\u002FQuality-Engineering-Skills\u002Fskills\u002Fproblem-solving\u002F8d-problem-solving\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"8d problem solving","problem solving","problem","iso","2026","automotive","root cause","for","with","electronics","respond","PCA","medical","customer","problem-solving","general","gate","oem","quality","team","open","validation","run","2026-11-10 10:12:30",false,"---\nname: 8d-problem-solving\ndescription: >-\n  Open an 8D, run a G8D or TOPS-8D investigation, respond to a warranty complaint, or handle\n  a customer quality escape with the 8 Disciplines methodology. Covers D0 emergency response\n  through D8 team recognition with gate validation. Required for automotive OEM complaints —\n  Ford, BMW, VW, Stellantis — and any quality escape needing documented root cause and PCA.\nlicense: MIT\nmetadata:\n  author: RBraga01\n  version: \"1.1\"\n  iso-9001: \"10.2\"\n  iatf-16949: \"10.2.3\"\n  domain: quality-engineering\n  subdomain: problem-solving\n  industries: automotive,electronics,aerospace,medical,general\n  status: approved\n  created: \"2026-06-01\"\n  last_updated: \"2026-06-03\"\n  updated_by: RBraga01\n  reviewed_by: RBraga01\n  standard_edition: \"ISO 9001:2015 \u002F IATF 16949:2016\"\n---\n\n# 8D Problem Solving\n\n## Goal\n\nProduce a validated, audit-ready 8D report with proven root causes and effective corrective actions that prevent recurrence — accepted by the customer and filed in the quality system.\n\n## Required Execution Checklist\n\nQuick-reference for agents and practitioners. All items must be complete before D8 closure.\n\n- [ ] D0: Safety and regulatory risk assessed and documented\n- [ ] D0: Suspect material identified and physically segregated\n- [ ] D1: Cross-functional team assembled with champion identified\n- [ ] D2: Problem described with measured values, part number, quantity, and Is\u002FIs-Not\n- [ ] D3: Containment implemented (past tense) with date and effectiveness evidence\n- [ ] D4: Root cause of **occurrence** identified and validated with data or experiment\n- [ ] D4: Root cause of **escape** identified and validated with data or experiment\n- [ ] D5: One PCA per root cause selected, with verification plan\n- [ ] D6: PCA implemented; verification data confirms zero recurrence; ICA formally removed\n- [ ] D7: PFMEA, Control Plan, and Work Instructions updated (revision numbers documented)\n- [ ] D7: Horizontal deployment assessed and actioned\n- [ ] D8: Champion sign-off obtained; customer notified of closure\n\n---\n\n## When to use\n\nUse 8D for customer-reported defects, internal escapes reaching downstream processes, field failures, or any non-conformance requiring documented root cause analysis. Mandatory for most automotive OEM customer complaints (Ford 8D, BMW G8D, VW QMSS, Stellantis).\n\n## Prerequisites\n\n- Defect or failure clearly identified and quantified\n- Access to affected parts, process records, and measurement data\n- Cross-functional team availability (quality, production, engineering minimum)\n\n## Workflow\n\n### D0 — Emergency Response (before the team is assembled)\n\nAsk these questions first:\n1. Is this a safety or regulatory issue? If yes → escalate immediately, notify customer\n2. **Is there any potential for a product recall or regulatory event (safety, emissions, homologation compliance)?**\n   - If yes → **STOP the standard 8D timeline. Escalate immediately to management and regulatory owner.** Do not proceed without documented management awareness. The 8D continues only with their authorisation.\n3. Are suspect parts already at the customer or in the field? If yes → launch containment now (D3) before completing D1-D2\n4. Capture initial evidence: photos, batch numbers, lot traceability, measurement data\n\nD0 is complete when: safety is assessed, regulatory escalation decision documented, suspect material is identified and flagged.\n\n---\n\n### D1 — Team Formation\n\nBuild a cross-functional team. Required functions:\n- **Champion** (sponsor, authority to release resources)\n- **Team leader** (owns the 8D, drives completion)\n- **Quality engineer** (methodology, documentation)\n- **Production \u002F process owner** (process knowledge)\n- **Engineering** (design or process engineering)\n\nOptional: supplier quality, logistics, customer representative.\n\nDocument: names, functions, team leader, start date, target closure date.\n\n**Validation:** Is every affected process step represented? Does someone have authority to change the process?\n\n---\n\n### D2 — Problem Description\n\nDefine the problem precisely using Is\u002FIs-Not and 5W2H. A weak D2 produces a weak D4.\n\n**Is\u002FIs-Not scoping (see [is-is-not-scoping](..\u002Fis-is-not-scoping\u002F) skill):**\n\n| Question | IS | IS NOT |\n|----------|----|--------|\n| What is the problem? | e.g., dimensional out-of-spec | cosmetic scratch |\n| What object\u002Fpart? | Part number X, revision B | Part number Y |\n| Where is it found? | Station 3, incoming inspection | Final test |\n| When did it start? | Batch from 2026-05-12 | Earlier batches |\n| How many? | 47 of 200 inspected (23.5%) | — |\n| Trend? | Consistent since batch date | No spike |\n\n**5W2H:**\n- Who detected it? When? Where?\n- What is the exact non-conformance (measured value vs. specification)?\n- Why is it a problem (customer impact)?\n- How was it detected? How many are affected?\n\nD2 is complete when: a stranger could read it and know exactly what is wrong, on what, when, how many, and where in the supply chain.\n\n---\n\n### D3 — Interim Containment Actions (ICA)\n\nICA must **stop the non-conforming product from reaching the customer** while D4-D5 are in progress.\n\nTypical ICAs:\n- Sort \u002F 100% inspection of suspect stock (in-process + field + customer)\n- Ship-hold on all batches in the date range\n- Add a specific inspection step at outgoing QC\n- Customer notification and stock recovery (if product escaped)\n\n**ICA validation — ask:**\n- Does this ICA physically prevent the defect from escaping? (Yes\u002FNo — not \"we will try\")\n- What is the evidence it is working? (inspection records, zero escapes since ICA date)\n- Is it documented with an implementation date and responsible person?\n- Is it temporary? (an ICA is not a permanent fix)\n\nD3 is complete when: suspect product is contained with objective evidence, customer notified if applicable.\n\n---\n\n### D4 — Root Cause Analysis\n\nFind TWO root causes:\n1. **Root cause of occurrence** — why did the defect happen?\n2. **Root cause of escape (detection failure)** — why was it not detected before reaching the customer\u002Fnext process?\n\nUse these tools (see referenced skills):\n- [5-Why](..\u002F5why-root-cause\u002F) for each root cause\n- [Fishbone \u002F Ishikawa](..\u002Ffishbone-analysis\u002F) for brainstorming categories\n- [Is\u002FIs-Not](..\u002Fis-is-not-scoping\u002F) to scope the problem boundaries\n\n**Root cause validation:**\n- Can you reproduce the defect by deliberately creating the root cause?\n- Does removing the root cause prevent the defect in a trial run?\n- Is it backed by data, not opinion?\n\n**Reject these as final root causes:**\n- \"Human error\" (not systemic — ask WHY the error was possible)\n- \"Operator didn't follow instructions\" (ask WHY they didn't, or couldn't)\n- \"Supplier delivered bad parts\" (ask WHY your incoming inspection did not catch it)\n\n**Evidence rule:** A root cause must be proven by data or physical experiment — not by logical reasoning alone. If you can only argue it is plausible, it is a hypothesis. Reproduce the defect by triggering the root cause; eliminate the defect by removing it. Both tests required.\n\nD4 is complete when: both root causes are validated with objective evidence, not opinion.\n\n---\n\n### D5 — Choose Permanent Corrective Actions (PCA)\n\nFor each root cause from D4, select a permanent corrective action that:\n- Directly addresses that specific root cause (not a symptom)\n- Can be verified as effective\n- Is feasible within the available time and resources\n\n**Evaluation matrix (for each candidate PCA):**\n- Does it address the root cause? (Yes\u002FNo)\n- Can effectiveness be measured? (metric + target)\n- Is it risk-free to implement? (FMEA check)\n- Timeline: realistic?\n\nDocument: PCA description, responsible owner, target implementation date, verification method.\n\nD5 is complete when: one PCA per root cause is selected and documented with verification plan.\n\n---\n\n### D6 — Implement and Verify Effectiveness\n\nImplement the PCAs. After implementation:\n\n**Verification requirements:**\n- Run sufficient production volume to achieve statistical confidence — **define sample size based on the observed defect rate and risk level** (higher defect rate or safety-related defect → larger sample required). Do not use fixed generic numbers; align the sample with the detection probability needed.\n  - Guidance: if pre-PCA defect rate was p, the verification sample should be large enough that the probability of observing zero defects if p is still present is below 5%. Formula: n ≥ log(0.05) \u002F log(1 − p).\n- Measure the original defect metric before and after\n- Confirm zero recurrence of the exact defect mode\n\n**Verification evidence to capture:**\n- Process control charts or inspection data after PCA\n- Before\u002Fafter comparison (defect rate or measurement data)\n- Signed-off by quality and production\n\nICA (D3) can only be removed **after** D6 verification is complete with objective evidence.\n\nD6 is complete when: data confirms the defect is eliminated, ICA formally removed.\n\n---\n\n### D7 — Prevent Recurrence (Systemisation)\n\nThe most valuable — and most skipped — discipline. Prevents the same root cause from appearing elsewhere.\n\n**Required updates:**\n- [ ] PFMEA updated: add\u002Frevise failure mode, update occurrence and detection ratings\n- [ ] Control Plan updated: add control for root cause and escape\n- [ ] Work Instructions \u002F SOPs updated and re-issued\n- [ ] Incoming inspection updated (if supplier or material related)\n- [ ] Lessons learned documented and shared with similar product lines\n- [ ] Training conducted for affected operators \u002F inspectors\n\n**Horizontal deployment:**\n- Are there similar part numbers, processes, or product families that could have the same root cause?\n- If yes → extend PCAs to those areas and document\n\nD7 is complete when: all process documents are updated and changes are live in production.\n\n---\n\n### D8 — Team Recognition\n\nFormally close the 8D:\n- Team leader presents the completed 8D to the champion\n- Champion validates all disciplines are complete with evidence\n- Team is formally recognised (acknowledgement — not necessarily financial)\n- 8D report is filed in the quality records system\n- Closure communicated to the customer (if customer-initiated complaint)\n\nD8 is complete when: champion signs off, customer notified of closure.\n\n---\n\n## Validation — is the 8D complete?\n\nBefore closing, verify:\n- [ ] D2 problem description is objective and quantified\n- [ ] D3 ICA has implementation date and verification evidence\n- [ ] D4 has two root causes (occurrence + escape), both validated with evidence\n- [ ] D5 PCAs directly address D4 root causes\n- [ ] D6 verification data shows zero recurrence after PCA\n- [ ] D7: FMEA, control plan, and work instructions are all updated\n- [ ] D8: champion sign-off and customer notification (if applicable)\n\n## Common mistakes\n\n- **Skipping D0:** jumping to D2 before confirming the customer has no more suspect stock\n- **Weak D2:** vague problem description leads to wrong root cause\n- **D3 as D6:** treating containment as the permanent fix (\"we added 100% inspection\" is not a PCA)\n- **Symptom as root cause:** \"machine was miscalibrated\" — why? \"supplier sent wrong material\" — why wasn't it caught?\n- **Not updating D7 documents:** the most common audit finding\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## Reference files\n\n- [D0–D8 detailed guide](references\u002Fd0-d8-guide.md)\n- [8D report template](assets\u002F8d-template.md)\n\n## Changelog\n\n| Version | Date | Author | Change |\n|---------|------|--------|--------|\n| 1.0 | 2026-06-01 | @RBraga01 | Initial release |\n| 1.1 | 2026-06-03 | @RBraga01 | Added Required Execution Checklist, D-level validation criteria, OEM gate rules |\n","# 8D Problem Solving\n\n## Goal\n\nProduce a validated, audit-ready 8D report with proven root causes and effective corrective actions that prevent recurrence — accepted by the customer and filed in the quality system.\n\n## Required Execution Checklist\n\nQuick-reference for agents and practitioners. All items must be complete before D8 closure.\n\n- [ ] D0: Safety and regulatory risk assessed and documented\n- [ ] D0: Suspect material identified and physically segregated\n- [ ] D1: Cross-functional team assembled with champion identified\n- [ ] D2: Problem described with measured values, part number, quantity, and Is\u002FIs-Not\n- [ ] D3: Containment implemented (past tense) with date and effectiveness evidence\n- [ ] D4: Root cause of **occurrence** identified and validated with data or experiment\n- [ ] D4: Root cause of **escape** identified and validated with data or experiment\n- [ ] D5: One PCA per root cause selected, with verification plan\n- [ ] D6: PCA implemented; verification data confirms zero recurrence; ICA formally removed\n- [ ] D7: PFMEA, Control Plan, and Work Instructions updated (revision numbers documented)\n- [ ] D7: Horizontal deployment assessed and actioned\n- [ ] D8: Champion sign-off obtained; customer notified of closure\n\n---\n\n## When to use\n\nUse 8D for customer-reported defects, internal escapes reaching downstream processes, field failures, or any non-conformance requiring documented root cause analysis. Mandatory for most automotive OEM customer complaints (Ford 8D, BMW G8D, VW QMSS, Stellantis).\n\n## Prerequisites\n\n- Defect or failure clearly identified and quantified\n- Access to affected parts, process records, and measurement data\n- Cross-functional team availability (quality, production, engineering minimum)\n\n## Workflow\n\n### D0 — Emergency Response (before the team is assembled)\n\nAsk these questions first:\n1. Is this a safety or regulatory issue? If yes → escalate immediately, notify customer\n2. **Is there any potential for a product recall or regulatory event (safety, emissions, homologation compliance)?**\n   - If yes → **STOP the standard 8D timeline. Escalate immediately to management and regulatory owner.** Do not proceed without documented management awareness. The 8D continues only with their authorisation.\n3. Are suspect parts already at the customer or in the field? If yes → launch containment now (D3) before completing D1-D2\n4. Capture initial evidence: photos, batch numbers, lot traceability, measurement data\n\nD0 is complete when: safety is assessed, regulatory escalation decision documented, suspect material is identified and flagged.\n\n---\n\n### D1 — Team Formation\n\nBuild a cross-functional team. Required functions:\n- **Champion** (sponsor, authority to release resources)\n- **Team leader** (owns the 8D, drives completion)\n- **Quality engineer** (methodology, documentation)\n- **Production \u002F process owner** (process knowledge)\n- **Engineering** (design or process engineering)\n\nOptional: supplier quality, logistics, customer representative.\n\nDocument: names, functions, team leader, start date, target closure date.\n\n**Validation:** Is every affected process step represented? Does someone have authority to change the process?\n\n---\n\n### D2 — Problem Description\n\nDefine the problem precisely using Is\u002FIs-Not and 5W2H. A weak D2 produces a weak D4.\n\n**Is\u002FIs-Not scoping (see [is-is-not-scoping](..\u002Fis-is-not-scoping\u002F) skill):**\n\n| Question | IS | IS NOT |\n|----------|----|--------|\n| What is the problem? | e.g., dimensional out-of-spec | cosmetic scratch |\n| What object\u002Fpart? | Part number X, revision B | Part number Y |\n| Where is it found? | Station 3, incoming inspection | Final test |\n| When did it start? | Batch from 2026-05-12 | Earlier batches |\n| How many? | 47 of 200 inspected (23.5%) | — |\n| Trend? | Consistent since batch date | No spike |\n\n**5W2H:**\n- Who detected it? When? Where?\n- What is the exact non-conformance (measured value vs. specification)?\n- Why is it a problem (customer impact)?\n- How was it detected? How many are affected?\n\nD2 is complete when: a stranger could read it and know exactly what is wrong, on what, when, how many, and where in the supply chain.\n\n---\n\n### D3 — Interim Containment Actions (ICA)\n\nICA must **stop the non-conforming product from reaching the customer** while D4-D5 are in progress.\n\nTypical ICAs:\n- Sort \u002F 100% inspection of suspect stock (in-process + field + customer)\n- Ship-hold on all batches in the date range\n- Add a specific inspection step at outgoing QC\n- Customer notification and stock recovery (if product escaped)\n\n**ICA validation — ask:**\n- Does this ICA physically prevent the defect from escaping? (Yes\u002FNo — not \"we will try\")\n- What is the evidence it is working? (inspection records, zero escapes since ICA date)\n- Is it documented with an implementation date and responsible person?\n- Is it temporary? (an ICA is not a permanent fix)\n\nD3 is complete when: suspect product is contained with objective evidence, customer notified if applicable.\n\n---\n\n### D4 — Root Cause Analysis\n\nFind TWO root causes:\n1. **Root cause of occurrence** — why did the defect happen?\n2. **Root cause of escape (detection failure)** — why was it not detected before reaching the customer\u002Fnext process?\n\nUse these tools (see referenced skills):\n- [5-Why](..\u002F5why-root-cause\u002F) for each root cause\n- [Fishbone \u002F Ishikawa](..\u002Ffishbone-analysis\u002F) for brainstorming categories\n- [Is\u002FIs-Not](..\u002Fis-is-not-scoping\u002F) to scope the problem boundaries\n\n**Root cause validation:**\n- Can you reproduce the defect by deliberately creating the root cause?\n- Does removing the root cause prevent the defect in a trial run?\n- Is it backed by data, not opinion?\n\n**Reject these as final root causes:**\n- \"Human error\" (not systemic — ask WHY the error was possible)\n- \"Operator didn't follow instructions\" (ask WHY they didn't, or couldn't)\n- \"Supplier delivered bad parts\" (ask WHY your incoming inspection did not catch it)\n\n**Evidence rule:** A root cause must be proven by data or physical experiment — not by logical reasoning alone. If you can only argue it is plausible, it is a hypothesis. Reproduce the defect by triggering the root cause; eliminate the defect by removing it. Both tests required.\n\nD4 is complete when: both root causes are validated with objective evidence, not opinion.\n\n---\n\n### D5 — Choose Permanent Corrective Actions (PCA)\n\nFor each root cause from D4, select a permanent corrective action that:\n- Directly addresses that specific root cause (not a symptom)\n- Can be verified as effective\n- Is feasible within the available time and resources\n\n**Evaluation matrix (for each candidate PCA):**\n- Does it address the root cause? (Yes\u002FNo)\n- Can effectiveness be measured? (metric + target)\n- Is it risk-free to implement? (FMEA check)\n- Timeline: realistic?\n\nDocument: PCA description, responsible owner, target implementation date, verification method.\n\nD5 is complete when: one PCA per root cause is selected and documented with verification plan.\n\n---\n\n### D6 — Implement and Verify Effectiveness\n\nImplement the PCAs. After implementation:\n\n**Verification requirements:**\n- Run sufficient production volume to achieve statistical confidence — **define sample size based on the observed defect rate and risk level** (higher defect rate or safety-related defect → larger sample required). Do not use fixed generic numbers; align the sample with the detection probability needed.\n  - Guidance: if pre-PCA defect rate was p, the verification sample should be large enough that the probability of observing zero defects if p is still present is below 5%. Formula: n ≥ log(0.05) \u002F log(1 − p).\n- Measure the original defect metric before and after\n- Confirm zero recurrence of the exact defect mode\n\n**Verification evidence to capture:**\n- Process control charts or inspection data after PCA\n- Before\u002Fafter comparison (defect rate or measurement data)\n- Signed-off by quality and production\n\nICA (D3) can only be removed **after** D6 verification is complete with objective evidence.\n\nD6 is complete when: data confirms the defect is eliminated, ICA formally removed.\n\n---\n\n### D7 — Prevent Recurrence (Systemisation)\n\nThe most valuable — and most skipped — discipline. Prevents the same root cause from appearing elsewhere.\n\n**Required updates:**\n- [ ] PFMEA updated: add\u002Frevise failure mode, update occurrence and detection ratings\n- [ ] Control Plan updated: add control for root cause and escape\n- [ ] Work Instructions \u002F SOPs updated and re-issued\n- [ ] Incoming inspection updated (if supplier or material related)\n- [ ] Lessons learned documented and shared with similar product lines\n- [ ] Training conducted for affected operators \u002F inspectors\n\n**Horizontal deployment:**\n- Are there similar part numbers, processes, or product families that could have the same root cause?\n- If yes → extend PCAs to those areas and document\n\nD7 is complete when: all process documents are updated and changes are live in production.\n\n---\n\n### D8 — Team Recognition\n\nFormally close the 8D:\n- Team leader presents the completed 8D to the champion\n- Champion validates all disciplines are complete with evidence\n- Team is formally recognised (acknowledgement — not necessarily financial)\n- 8D report is filed in the quality records system\n- Closure communicated to the customer (if customer-initiated complaint)\n\nD8 is complete when: champion signs off, customer notified of closure.\n\n---\n\n## Validation — is the 8D complete?\n\nBefore closing, verify:\n- [ ] D2 problem description is objective and quantified\n- [ ] D3 ICA has implementation date and verification evidence\n- [ ] D4 has two root causes (occurrence + escape), both validated with evidence\n- [ ] D5 PCAs directly address D4 root causes\n- [ ] D6 verification data shows zero recurrence after PCA\n- [ ] D7: FMEA, control plan, and work instructions are all updated\n- [ ] D8: champion sign-off and customer notification (if applicable)\n\n## Common mistakes\n\n- **Skipping D0:** jumping to D2 before confirming the customer has no more suspect stock\n- **Weak D2:** vague problem description leads to wrong root cause\n- **D3 as D6:** treating containment as the permanent fix (\"we added 100% inspection\" is not a PCA)\n- **Symptom as root cause:** \"machine was miscalibrated\" — why? \"supplier sent wrong material\" — why wasn't it caught?\n- **Not updating D7 documents:** the most common audit finding\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## Reference files\n\n- [D0–D8 detailed guide](references\u002Fd0-d8-guide.md)\n- [8D report template](assets\u002F8d-template.md)\n\n## Changelog\n\n| Version | Date | Author | Change |\n|---------|------|--------|--------|\n| 1.0 | 2026-06-01 | @RBraga01 | Initial release |\n| 1.1 | 2026-06-03 | @RBraga01 | Added Required Execution Checklist, D-level validation criteria, OEM gate rules |\n",{"name":5,"license":15,"metadata":47,"description":7},{"author":48,"domain":49,"status":50,"created":51,"version":52,"iso-9001":53,"subdomain":33,"iatf-16949":54,"industries":55,"updated_by":48,"reviewed_by":48,"last_updated":56,"standard_edition":57},"RBraga01","quality-engineering","approved","2026-06-01","1.1","10.2","10.2.3","automotive,electronics,aerospace,medical,general","2026-06-03","ISO 9001:2015 \u002F IATF 16949:2016","main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002FRBraga01\u002FQuality-Engineering-Skills\u002Fskills\u002Fproblem-solving\u002F8d-problem-solving",491,"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-14 14:06:13",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill 8d-problem-solving",{"tool":74,"command":75},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill 8d-problem-solving",{"tool":77,"command":78},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill 8d-problem-solving","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FRBraga01\u002FQuality-Engineering-Skills\u002Fskills\u002Fproblem-solving\u002F8d-problem-solving\u002FSKILL.md",true,[82,88],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"assets\u002F8d-template.md","ASSET","资产文件",2832,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FRBraga01\u002FQuality-Engineering-Skills\u002Fskills\u002Fproblem-solving\u002F8d-problem-solving\u002Fassets\u002F8d-template.md",{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fd0-d8-guide.md","REFERENCE","参考文档",10843,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FRBraga01\u002FQuality-Engineering-Skills\u002Fskills\u002Fproblem-solving\u002F8d-problem-solving\u002Freferences\u002Fd0-d8-guide.md",[95,104,111,118,145,169],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":99,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":103},"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":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":99,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":103},"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":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":99,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":103},"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":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":99,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":42},"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",[],[125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","when","you","done","reviewer","io","change","cli","merge","past",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":99,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":42},"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",[],[152,153,154,140,27,155,156,157,158,159,160,161,162,163,130,164,165,166,167,168],"deja reflect","reflect","review","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":99,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":186,"publishedAt":42},"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",[175,180,183],{"categoryNo":176,"categoryName":177,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":181,"categoryName":182,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":184,"categoryName":185,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000010","后端与接口",[171,187,188,189,190,191,192,165,193,131,194,195,196,197,136,198,199,200,201,202],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]