investigate-capa-root-cause
정보
이 스킬은 개발자들이 규정 준수 이탈에 대한 구조화된 근본 원인 분석과 CAPA 관리를 수행하도록 안내하며, 5-Why 분석과 어골대 다이어그램 같은 방법을 지원합니다. 이는 감사 결과, 시스템 사고 또는 데이터 무결성 문제 발생 후 시정 조치를 설계하고 그 효과를 검증하기 위해 사용되도록 설계되었습니다. 이 도구는 검증된 환경에서 규제 대응을 처리하고 시스템적 문제를 해결하는 데 목적을 두고 있습니다.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/investigate-capa-root-causeClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
察 CAPA 根因
為合規偏差行結構化根因之察,發效糾正與預防之行。
用時
- 審計之發現需 CAPA
- 已驗證系統生偏或事件
- 法規察之觀察需正式應
- 數據完整性之異常需察
- 屢發之疑示系統性根因
入
- 必要:偏、發現、或事件之述
- 必要:嚴重度分類(嚴、重、輕)
- 必要:審計或察中所集之證
- 可選:先前相關之 CAPA 或察
- 可選:相關 SOP、驗證文件、系統日誌
- 可選:涉員訪談筆記
法
第一步:啟察
# Root Cause Investigation
## Document ID: RCA-[CAPA-ID]
## CAPA Reference: CAPA-[YYYY]-[NNN]
### 1. Trigger
| Field | Value |
|-------|-------|
| Source | [Audit finding / Deviation / Inspection observation / Monitoring alert] |
| Reference | [Finding ID, deviation ID, or observation number] |
| System | [Affected system name and version] |
| Date discovered | [YYYY-MM-DD] |
| Severity | [Critical / Major / Minor] |
| Investigator | [Name, Title] |
| Investigation deadline | [Date — per severity: Critical 15 days, Major 30 days, Minor 60 days] |
### 2. Problem Statement
[Objective, factual description of what happened, what should have happened, and the gap between the two. No blame, no assumptions.]
### 3. Immediate Containment (if required)
| Action | Owner | Completed |
|--------|-------|-----------|
| [e.g., Restrict system access pending investigation] | [Name] | [Date] |
| [e.g., Quarantine affected batch records] | [Name] | [Date] |
| [e.g., Implement manual workaround] | [Name] | [Date] |
**得:**察啟,具清之問題述與含控之行;嚴重發現於 24 小時內。 **敗則:**若含控不可立施,升至 QA 總監,並記延含控之險。
第二步:擇察之法
依問題之複擇法:
### Investigation Method Selection
| Method | Best For | Complexity | Output |
|--------|----------|-----------|--------|
| **5-Why Analysis** | Single-cause problems, straightforward failures | Low | Linear cause chain |
| **Fishbone (Ishikawa)** | Multi-factor problems, process failures | Medium | Cause-and-effect diagram |
| **Fault Tree Analysis** | System failures, safety-critical events | High | Boolean logic tree |
**Selected method:** [5-Why / Fishbone / Fault Tree / Combination]
**Rationale:** [Why this method is appropriate for this problem]
**得:**所擇之法配問題之複——勿為簡程序之訛用故障樹,勿為複雜系統敗用 5-Why。 **敗則:**若首法未至可信之根因,施二法。諸法所得之合固結論。
第三步:行根因析
甲:5-Why 析
### 5-Why Analysis
| Level | Question | Answer | Evidence |
|-------|----------|--------|----------|
| Why 1 | Why did [the problem] occur? | [Immediate cause] | [Evidence reference] |
| Why 2 | Why did [immediate cause] occur? | [Contributing factor] | [Evidence reference] |
| Why 3 | Why did [contributing factor] occur? | [Deeper cause] | [Evidence reference] |
| Why 4 | Why did [deeper cause] occur? | [Systemic cause] | [Evidence reference] |
| Why 5 | Why did [systemic cause] occur? | [Root cause] | [Evidence reference] |
**Root cause:** [Clear statement of the fundamental cause]
乙:魚骨(Ishikawa)圖
### Fishbone Analysis
Analyse causes across six standard categories:
| Category | Potential Causes | Confirmed? | Evidence |
|----------|-----------------|------------|----------|
| **People** | Inadequate training, unfamiliarity with SOP, staffing shortage | [Y/N] | [Ref] |
| **Process** | SOP unclear, missing step, wrong sequence | [Y/N] | [Ref] |
| **Technology** | System misconfiguration, software bug, interface failure | [Y/N] | [Ref] |
| **Materials** | Incorrect input data, wrong version of reference document | [Y/N] | [Ref] |
| **Measurement** | Wrong metric, inadequate monitoring, missed threshold | [Y/N] | [Ref] |
| **Environment** | Organisational change, regulatory change, resource constraints | [Y/N] | [Ref] |
**Contributing causes:** [List confirmed causes]
**Root cause(s):** [The fundamental cause(s) — may be more than one]
丙:故障樹析
### Fault Tree Analysis
**Top event:** [The undesired event]
Level 1 (OR gate — any of these could cause the top event):
├── [Cause A]
│ Level 2 (AND gate — both needed):
│ ├── [Sub-cause A1]
│ └── [Sub-cause A2]
├── [Cause B]
│ Level 2 (OR gate):
│ ├── [Sub-cause B1]
│ └── [Sub-cause B2]
└── [Cause C]
**Minimal cut sets:** [Smallest combinations of events that cause the top event]
**Root cause(s):** [Fundamental failures identified in the tree]
**得:**根因析至基本之因(非僅症狀),每步有證為支。 **敗則:**若析僅得症狀(「用者誤」),深推之。問:「彼何以能誤?何控當阻之?」
第四步:設糾正與預防之行
明別糾正、糾正行、預防行:
### CAPA Plan
| Category | Definition | Action | Owner | Deadline |
|----------|-----------|--------|-------|----------|
| **Correction** | Fix the immediate problem | [e.g., Re-enable audit trail for batch module] | [Name] | [Date] |
| **Corrective Action** | Eliminate the root cause | [e.g., Remove admin ability to disable audit trail; require change control for all audit trail configuration changes] | [Name] | [Date] |
| **Preventive Action** | Prevent recurrence in other areas | [e.g., Audit all systems for audit trail disable capability; add monitoring alert for audit trail configuration changes] | [Name] | [Date] |
### CAPA Details
**CAPA-[YYYY]-[NNN]-CA1: [Corrective Action Title]**
- **Root cause addressed:** [Specific root cause from Step 3]
- **Action description:** [Detailed description of what will be done]
- **Success criteria:** [Measurable outcome that proves the action worked]
- **Verification method:** [How effectiveness will be checked]
- **Verification date:** [When effectiveness will be verified — typically 3-6 months after implementation]
**CAPA-[YYYY]-[NNN]-PA1: [Preventive Action Title]**
- **Risk addressed:** [What recurrence or spread this prevents]
- **Action description:** [Detailed description]
- **Success criteria:** [Measurable outcome]
- **Verification method:** [How effectiveness will be checked]
- **Verification date:** [Date]
**得:**每 CAPA 行溯至具體根因,具可量成功準則,含有效性驗之計。 **敗則:**若成功準則曖(「改合規」),重書之以具體可量(「六連月審計軌配置變動於變更控制外為零」)。
第五步:驗有效
CAPA 施後,驗行果真奏效:
### Effectiveness Verification
**CAPA-[YYYY]-[NNN] — Verification Record**
| CAPA Action | Verification Date | Method | Evidence | Result |
|-------------|------------------|--------|----------|--------|
| CA1: [Action] | [Date] | [Method: audit, sampling, metric review] | [Evidence reference] | [Effective / Not Effective] |
| PA1: [Action] | [Date] | [Method] | [Evidence reference] | [Effective / Not Effective] |
### Effectiveness Criteria Check
- [ ] The original problem has not recurred since CAPA implementation
- [ ] The corrective action eliminated the root cause (evidence: [reference])
- [ ] The preventive action has been applied to similar systems/processes
- [ ] No new issues were introduced by the CAPA actions
### CAPA Closure
| Field | Value |
|-------|-------|
| Closure decision | [Closed — Effective / Closed — Not Effective / Extended] |
| Closed by | [Name, Title] |
| Closure date | [YYYY-MM-DD] |
| Next review | [If recurring, when to re-check] |
**得:**有效性驗示根因果真除,非僅行已成。 **敗則:**若驗示 CAPA 無效,重啟察並發修訂之行。勿閉無效之 CAPA。
第六步:析 CAPA 之勢
### CAPA Trend Analysis
| Period | Total CAPAs | By Source | Top 3 Root Cause Categories | Recurring? |
|--------|------------|-----------|---------------------------|------------|
| Q1 20XX | [N] | Audit: [n], Deviation: [n], Monitoring: [n] | [Cat1], [Cat2], [Cat3] | [Y/N] |
| Q2 20XX | [N] | Audit: [n], Deviation: [n], Monitoring: [n] | [Cat1], [Cat2], [Cat3] | [Y/N] |
### Systemic Issues
| Issue | Frequency | Systems Affected | Recommended Action |
|-------|-----------|-----------------|-------------------|
| [e.g., Training gaps] | [N occurrences in 12 months] | [Systems] | [Systemic programme improvement] |
**得:**勢之析辨個 CAPA 所遺之系統性問。 **敗則:**若趨勢示屢發之根因雖有 CAPA 而仍在,則 CAPA 治症。升至管理層審以行系統性介入。
驗
- 察於所需時限內啟(嚴 24 小時、重 72 小時)
- 問題述事實而不歸咎
- 察之法配問題之複
- 根因析至基本之因(非僅症狀)
- 每根因步有證為支
- CAPA 別糾正、糾正行、預防行
- 每 CAPA 具可量成功準則與驗計
- CAPA 閉前以證驗有效
- 勢之析至少每季審之
陷
- 止於症狀:「用者誤」非根因。根因乃何以系統或流程容此誤
- CAPA = 重訓:重訓僅治一可能根因(知識)。若真根因為系統設計之瑕或 SOP 之曖,重訓不阻再發
- 閉而未驗:行已成不同於驗其效。閉而未驗有效之 CAPA 乃法規引述之患
- 歸咎式察:究何人誤而非何事容誤之察,毀質之文化,阻報告
- 無趨勢:個 CAPA 或似無關,然趨勢常揭系統性問(如多系統之「訓練」根因或示訓練計畫之破)
參
conduct-gxp-audit— 審計生需 CAPA 之發現monitor-data-integrity— 監測察觸發察之異常manage-change-control— CAPA 驅之改歷變更控制prepare-inspection-readiness— 開而逾期之 CAPA 為察之首要目標design-training-program— 根因若與訓相關,改訓練計畫
GitHub 저장소
연관 스킬
executing-plans
디자인executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.
requesting-code-review
디자인이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.
connect-mcp-server
디자인이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.
web-cli-teleport
디자인이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.
