perform-csv-assessment
Acerca de
Esta habilidad realiza evaluaciones de Validación de Sistemas Informáticos (CSV) siguiendo la metodología GAMP 5. Maneja requisitos de usuario, evaluación de riesgos, planificación IQ/OQ/PQ, matrices de trazabilidad e informes resumidos de validación. Úsela para nuevas implementaciones de sistemas GxP, cambios significativos en sistemas validados, revalidación periódica o análisis de brechas regulatorias.
Instalación rápida
Claude Code
Recomendadonpx 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/perform-csv-assessmentCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
name: perform-csv-assessment description: > Realizar una evaluación de Validación de Sistemas Informatizados (CSV) siguiendo la metodología GAMP 5. Cubre requisitos de usuario, evaluación de riesgo, planificación IQ/OQ/PQ, creación de matrices de trazabilidad e informes de resumen de validación. Usar cuando se introduce un nuevo sistema informatizado en un entorno GxP, cuando un sistema validado existente experimenta un cambio significativo, cuando se requiere revalidación periódica, o cuando una inspección regulatoria exige un análisis de brechas de validación. locale: es source_locale: en source_commit: 6f65f316 translator: claude-sonnet-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: compliance complexity: advanced language: multi tags: csv, gamp-5, validation, risk-assessment, iq-oq-pq, traceability
Realizar Evaluación CSV
Llevar a cabo una evaluación de Validación de Sistemas Informatizados usando la metodología basada en riesgo GAMP 5 para entornos regulados.
Cuándo Usar
- Se introduce un nuevo sistema informatizado en un entorno GxP
- Un sistema validado existente experimenta un cambio significativo
- Se requiere revalidación periódica
- La preparación para una inspección regulatoria exige un análisis de brechas de validación
Entradas
- Requerido: Descripción del sistema (nombre, propósito, proveedor, versión)
- Requerido: Declaración de uso previsto y contexto regulatorio (alcance GxP)
- Requerido: Categoría de software GAMP 5 (1–5)
- Opcional: Especificación de requisitos de usuario (URS) existente
- Opcional: Documentación del proveedor (especificaciones de diseño, notas de versión, SOPs)
- Opcional: Documentación de validación previa
Procedimiento
Paso 1: Determinar la Categoría de Software GAMP 5
Clasificar el sistema:
| Categoría | Tipo | Ejemplo | Esfuerzo de Validación |
|---|---|---|---|
| 1 | Software de infraestructura | SO, firmware | Bajo — verificar instalación |
| 3 | Producto no configurado | COTS tal como está | Bajo-Medio — verificar funcionalidad |
| 4 | Producto configurado | LIMS con configuración | Medio-Alto — verificar configuración |
| 5 | Aplicación personalizada | App R/Shiny a medida | Alto — validación completa del ciclo de vida |
Esperado: Categoría claramente asignada con fundamento documentado. En caso de fallo: Si la categoría es ambigua, usar la categoría superior y documentar el fundamento.
Paso 2: Redactar la Especificación de Requisitos de Usuario (URS)
Crear un documento URS con requisitos numerados:
# User Requirements Specification
## System: [System Name] v[Version]
## Document ID: URS-[SYS]-[NNN]
### 1. Purpose
[Intended use statement]
### 2. Functional Requirements
| ID | Requirement | Priority | Source |
|----|-------------|----------|--------|
| URS-001 | System shall calculate BMI from height and weight inputs | Must | Regulatory SOP-xxx |
| URS-002 | System shall generate audit trail entries for all data changes | Must | 21 CFR 11.10(e) |
| URS-003 | System shall export results in PDF format | Should | User request |
### 3. Non-Functional Requirements
| ID | Requirement | Priority | Source |
|----|-------------|----------|--------|
| URS-010 | System shall respond within 3 seconds for standard queries | Should | Usability |
| URS-011 | System shall restrict access via role-based authentication | Must | 21 CFR 11.10(d) |
### 4. Data Integrity Requirements
[ALCOA+ requirements: Attributable, Legible, Contemporaneous, Original, Accurate]
### 5. Regulatory Requirements
[Specific 21 CFR Part 11, EU Annex 11, or other applicable requirements]
Esperado: Todos los requisitos tienen IDs únicos, prioridades y trazabilidad a la fuente. En caso de fallo: Señalar para revisión de las partes interesadas los requisitos sin fuente o prioridad clara.
Paso 3: Realizar la Evaluación de Riesgo
Aplicar el enfoque basado en riesgo GAMP 5 usando un Análisis de Modos de Fallo y Efectos (FMEA):
# Risk Assessment
## Document ID: RA-[SYS]-[NNN]
| Req ID | Failure Mode | Severity (1-5) | Probability (1-5) | Detectability (1-5) | RPN | Risk Level | Mitigation |
|--------|-------------|----------------|-------------------|---------------------|-----|------------|------------|
| URS-001 | Incorrect BMI calculation | 4 | 2 | 1 | 8 | Low | OQ test case |
| URS-002 | Audit trail entries missing | 5 | 3 | 3 | 45 | High | IQ + OQ + monitoring |
| URS-011 | Unauthorized access | 5 | 2 | 2 | 20 | Medium | OQ test + periodic review |
Número de Prioridad de Riesgo (RPN) = Severidad x Probabilidad x Detectabilidad.
| Rango RPN | Nivel de Riesgo | Requisito de Prueba |
|---|---|---|
| 1–12 | Bajo | Verificación básica |
| 13–36 | Medio | Caso de prueba documentado |
| 37+ | Alto | IQ/OQ/PQ completo con reprueba |
Esperado: Cada requisito URS tiene una fila correspondiente en la evaluación de riesgo. En caso de fallo: Escalar al responsable de validación los requisitos sin evaluar antes de proceder.
Paso 4: Definir la Estrategia de Validación (Plan de Validación)
# Validation Plan
## Document ID: VP-[SYS]-[NNN]
### Scope
- System: [Name] v[Version]
- GAMP Category: [N]
- Validation approach: [Prospective / Retrospective / Concurrent]
### Qualification Stages
| Stage | Scope | Applies? | Rationale |
|-------|-------|----------|-----------|
| IQ | Installation correctness | Yes | Verify installation, dependencies, configuration |
| OQ | Operational requirements | Yes | Verify functional requirements from URS |
| PQ | Performance under real conditions | [Yes/No] | [Rationale] |
### Roles and Responsibilities
| Role | Name | Responsibility |
|------|------|---------------|
| Validation Lead | [Name] | Plan, coordinate, approve |
| Tester | [Name] | Execute test scripts |
| System Owner | [Name] | Approve for production use |
| QA | [Name] | Review and sign-off |
### Acceptance Criteria
- All critical test cases pass
- No unresolved critical or major deviations
- Traceability matrix complete
Esperado: Plan de validación aprobado por todas las partes interesadas antes de la ejecución de pruebas. En caso de fallo: No proceder a la ejecución de pruebas sin un plan de validación aprobado.
Paso 5: Crear Protocolos de Prueba (IQ/OQ/PQ)
Redactar scripts de prueba para cada etapa de calificación:
# Operational Qualification Protocol
## Test Case: TC-OQ-001
## Traces to: URS-001
**Objective:** Verify BMI calculation accuracy
**Prerequisites:**
- System installed per IQ protocol
- Test data set prepared
**Test Steps:**
| Step | Action | Expected Result | Actual Result | Pass/Fail |
|------|--------|-----------------|---------------|-----------|
| 1 | Enter height=180cm, weight=75kg | BMI displayed as 23.15 | | |
| 2 | Enter height=160cm, weight=90kg | BMI displayed as 35.16 | | |
| 3 | Enter height=0, weight=75kg | Error message displayed | | |
**Tester:** _________ Date: _________
**Reviewer:** _________ Date: _________
Esperado: Cada requisito de riesgo medio y alto tiene al menos un caso de prueba. En caso de fallo: Añadir los casos de prueba faltantes antes de que comience la ejecución.
Paso 6: Construir la Matriz de Trazabilidad
Crear una Matriz de Trazabilidad de Requisitos (RTM) que vincule cada requisito a través de la evaluación de riesgo hasta los casos de prueba:
# Traceability Matrix
## Document ID: TM-[SYS]-[NNN]
| URS ID | Requirement | Risk Level | Test Case(s) | Test Result | Status |
|--------|-------------|------------|--------------|-------------|--------|
| URS-001 | BMI calculation | Low | TC-OQ-001 | Pass | Verified |
| URS-002 | Audit trail | High | TC-IQ-003, TC-OQ-005 | Pass | Verified |
| URS-003 | PDF export | Low | TC-OQ-008 | Pass | Verified |
| URS-011 | Role-based access | Medium | TC-OQ-010, TC-OQ-011 | Pass | Verified |
Esperado: El 100% de los requisitos URS aparece en la matriz de trazabilidad con resultados de prueba vinculados. En caso de fallo: Cualquier requisito sin resultado de prueba vinculado se señala como una brecha de validación.
Paso 7: Redactar el Informe de Resumen de Validación
# Validation Summary Report
## Document ID: VSR-[SYS]-[NNN]
### 1. Executive Summary
[System name] v[version] has been validated in accordance with [VP document ID].
### 2. Validation Activities Performed
| Activity | Document ID | Status |
|----------|-------------|--------|
| User Requirements | URS-SYS-001 | Approved |
| Risk Assessment | RA-SYS-001 | Approved |
| Validation Plan | VP-SYS-001 | Approved |
| IQ Protocol/Report | IQ-SYS-001 | Executed — Pass |
| OQ Protocol/Report | OQ-SYS-001 | Executed — Pass |
| Traceability Matrix | TM-SYS-001 | Complete |
### 3. Deviations
| Dev ID | Description | Impact | Resolution |
|--------|-------------|--------|------------|
| DEV-001 | [Description] | [Impact assessment] | [Resolution and rationale] |
### 4. Conclusion
The system meets all user requirements as documented in [URS ID]. The validation is considered [Successful / Successful with conditions].
### 5. Approval
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Validation Lead | | | |
| System Owner | | | |
| Quality Assurance | | | |
Esperado: El informe hace referencia a todos los entregables de validación con una conclusión clara de aprobado/fallido. En caso de fallo: Si las desviaciones no están resueltas, el informe debe indicar el estado "condicional" con referencias CAPA.
Validación
- Categoría GAMP 5 asignada con fundamento documentado
- La URS tiene requisitos numerados con prioridades y trazabilidad a la fuente
- La evaluación de riesgo cubre cada requisito URS
- El plan de validación aprobado antes de la ejecución de pruebas
- Los protocolos de prueba tienen campos de prerrequisito, paso, resultado esperado y firma
- La matriz de trazabilidad vincula cada requisito con el riesgo y los resultados de prueba
- El informe de resumen de validación documenta todas las actividades, desviaciones y conclusión
- Todos los documentos tienen IDs únicos y control de versiones
Errores Comunes
- Sobrevalidación: Aplicar el esfuerzo de Categoría 5 al software de Categoría 3 desperdicia recursos. Ajustar el esfuerzo al riesgo.
- Trazabilidad faltante: Los requisitos que no se vinculan hasta los casos de prueba son brechas invisibles.
- Probar sin un plan: Ejecutar pruebas antes de que el plan de validación esté aprobado invalida los resultados.
- Ignorar los requisitos no funcionales: Los requisitos de seguridad, rendimiento e integridad de datos a menudo se pasan por alto.
- Validación estática: Tratar la validación como un evento único. Los cambios requieren reevaluación.
Habilidades Relacionadas
setup-gxp-r-project— estructura del proyecto para entornos R validadoswrite-validation-documentation— redacción de protocolos e informes IQ/OQ/PQimplement-audit-trail— implementación de registro de auditoría para registros electrónicosvalidate-statistical-output— metodología de verificación de salida estadísticaconduct-gxp-audit— auditoría de sistemas validados
Repositorio GitHub
Habilidades relacionadas
executing-plans
DiseñoUtilice la habilidad executing-plans cuando tenga un plan de implementación completo para ejecutar en lotes controlados con puntos de revisión. Esta habilidad carga y revisa críticamente el plan, luego ejecuta tareas en pequeños lotes (por defecto 3 tareas) mientras reporta el progreso entre cada lote para la revisión del arquitecto. Esto asegura una implementación sistemática con puntos de control de calidad integrados.
requesting-code-review
DiseñoEsta habilidad despacha un subagente revisor de código para analizar los cambios en el código frente a los requisitos antes de proceder. Debe usarse después de completar tareas, implementar funciones principales o antes de fusionar con la rama principal. La revisión ayuda a detectar problemas de forma temprana al comparar la implementación actual con el plan original.
connect-mcp-server
DiseñoEsta habilidad proporciona una guía integral para que los desarrolladores conecten servidores MCP a Claude Code mediante transportes HTTP, stdio o SSE. Cubre la instalación, configuración, autenticación y seguridad para integrar servicios externos como GitHub, Notion y APIs personalizadas. Úsala al configurar integraciones MCP, al configurar herramientas externas o al trabajar con el Protocolo de Contexto del Modelo de Claude.
web-cli-teleport
DiseñoEsta habilidad ayuda a los desarrolladores a elegir entre las interfaces web y CLI de Claude Code mediante el análisis de tareas, y luego permite la teletransportación fluida de sesiones entre estos entornos. Optimiza el flujo de trabajo gestionando el estado y el contexto de la sesión al cambiar entre web, CLI o móvil. Úsala para proyectos complejos que requieren diferentes herramientas en varias etapas.
