write-standard-operating-procedure
Acerca de
Esta habilidad genera Procedimientos Operativos Estándar (SOP) conformes con GxP, con la estructura regulatoria requerida, incluyendo secciones para propósito, alcance y flujos de trabajo de aprobación. Está diseñada para casos de uso como formalizar procesos informales, abordar hallazgos de auditoría o actualizar procedimientos tras cambios en el sistema. Los desarrolladores pueden utilizarla para crear o actualizar documentación operativa validada para sistemas conformes.
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/write-standard-operating-procedureCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
Write Standard Operating Procedure
Create a GxP-compliant Standard Operating Procedure that provides clear, auditable instructions for regulated activities.
When to Use
- A new validated system requires operational procedures
- Existing procedures need formalisation into SOP format
- An audit finding cites missing or inadequate procedures
- A change control triggers SOP updates
- Periodic review identifies outdated procedural content
Inputs
- Required: Process or system the SOP covers
- Required: Regulatory context (GMP, GLP, GCP, 21 CFR Part 11, EU Annex 11)
- Required: Target audience (roles that will follow this SOP)
- Optional: Existing informal procedures, work instructions, or training materials
- Optional: Related SOPs that interface with this procedure
- Optional: Audit findings or regulatory observations driving the SOP creation
Procedure
Step 1: Assign Document Control Metadata
# Standard Operating Procedure
## Document ID: SOP-[DEPT]-[NNN]
## Title: [Descriptive Title of the Procedure]
| Field | Value |
|-------|-------|
| Document ID | SOP-[DEPT]-[NNN] |
| Version | 1.0 |
| Effective Date | [YYYY-MM-DD] |
| Review Date | [YYYY-MM-DD + review period] |
| Department | [Department name] |
| Author | [Name, Title] |
| Reviewer | [Name, Title] |
| Approver | [Name, Title] |
| Classification | [GxP-Critical / GxP-Supporting] |
| Supersedes | [Previous SOP ID or "N/A — New"] |
Got: Every SOP has a unique ID following the organisation's document numbering convention. If fail: If no numbering convention exists, establish one before proceeding: [TYPE]-[DEPT]-[3-digit sequential].
Step 2: Write the Purpose and Scope
### 1. Purpose
This SOP defines the procedure for [specific activity] to ensure [regulatory objective].
### 2. Scope
**In scope:**
- [System, process, or activity covered]
- [Applicable departments or roles]
- [Specific regulatory requirements addressed]
**Out of scope:**
- [Related activities covered by other SOPs — reference them]
- [Systems or departments not covered]
Got: Purpose is one to two sentences. Scope clearly defines boundaries. If fail: If scope overlaps with an existing SOP, either reference the existing SOP for the overlapping section or revise both SOPs to eliminate the overlap.
Step 3: Define Terms and Abbreviations
### 3. Definitions and Abbreviations
| Term | Definition |
|------|-----------|
| ALCOA+ | Attributable, Legible, Contemporaneous, Original, Accurate + Complete, Consistent, Enduring, Available |
| CCB | Change Control Board |
| GxP | Good [Manufacturing/Laboratory/Clinical] Practice — umbrella for all regulated quality standards |
| SOP | Standard Operating Procedure |
| [Add terms specific to this SOP] | [Definition] |
Got: Every abbreviation and technical term used in the SOP is defined. If fail: If a term is ambiguous or domain-specific, consult the organisation's glossary or the relevant regulatory guidance for the authoritative definition.
Step 4: Assign Responsibilities
### 4. Responsibilities
| Role | Responsibilities |
|------|-----------------|
| System Owner | Ensure SOP compliance, approve changes, conduct periodic review |
| System Administrator | Execute daily operations per this SOP, report deviations |
| Quality Assurance | Review SOP for regulatory compliance, approve new versions |
| End Users | Follow procedures as written, report issues to system administrator |
| Training Coordinator | Ensure all affected personnel are trained before SOP effective date |
Got: Every action in the Procedure section can be traced to a responsible role. If fail: If a procedural step has no assigned role, it is an orphaned responsibility. Assign an owner before the SOP is approved.
Step 5: Write the Procedure Section
This is the core of the SOP. Write step-by-step instructions:
### 5. Procedure
#### 5.1 [First Major Activity]
1. [Action verb] [specific instruction]. Reference: [form, system screen, tool].
2. [Action verb] [specific instruction].
- If [condition], then [action].
- If [alternative condition], then [alternative action].
3. [Action verb] [specific instruction].
4. Record the result in [form/system/log].
#### 5.2 [Second Major Activity]
1. [Action verb] [specific instruction].
2. Verify [specific criterion].
3. If verification fails, initiate [deviation procedure — reference SOP-XXX].
#### 5.3 Deviation Handling
1. If any step cannot be performed as written, STOP and document the deviation.
2. Notify [role] within [timeframe].
3. Complete Deviation Form [form reference].
4. Do not proceed until [role] provides disposition.
Writing rules for GxP SOPs:
- Start each step with an action verb (verify, record, enter, approve, notify)
- Be specific enough to be followed by a trained operator without interpretation
- Include decision points with clear criteria for each path
- Reference exact form names, system screens, or tool identifiers
- Include hold points where work must stop pending approval or verification
Got: A trained person unfamiliar with the specific process could follow these steps correctly. If fail: If subject matter experts say the procedure is ambiguous, add detail or break the step into sub-steps. Ambiguity in SOPs is a recurring audit finding.
Step 6: Add References, Attachments, and Revision History
### 6. References
| Document ID | Title |
|-------------|-------|
| SOP-QA-001 | Document Control |
| SOP-IT-015 | User Access Management |
| [Regulation reference] | [e.g., 21 CFR Part 11] |
### 7. Attachments
| Attachment | Description |
|-----------|-------------|
| Form-001 | [Form name and purpose] |
| Template-001 | [Template name and purpose] |
### 8. Revision History
| Version | Date | Author | Change Description |
|---------|------|--------|--------------------|
| 1.0 | [Date] | [Name] | Initial release |
Got: All referenced documents are accessible to users, and revision history starts from version 1.0. If fail: If referenced documents do not exist yet, either create them or remove the reference and note the gap in the SOP review.
Step 7: Route for Review and Approval
### Approval Signatures
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Author | [Name] | | |
| Technical Reviewer | [Name] | | |
| QA Reviewer | [Name] | | |
| Approver (Department Head) | [Name] | | |
### Training Requirement
All personnel listed in Section 4 must complete training on this SOP before the effective date. Training must be documented in the training management system.
### Periodic Review
This SOP must be reviewed at least every [2 years / annually] or when triggered by:
- Change control affecting the covered process or system
- Audit finding related to the covered process
- Regulatory guidance update affecting the covered requirements
Got: SOP is reviewed by a subject matter expert and approved by quality before becoming effective. If fail: If the approval workflow is delayed, the effective date must be pushed back. An SOP cannot be effective without completed approvals.
Validation
- Document ID follows the organisation's numbering convention
- Purpose is specific and concise (1-2 sentences)
- Scope clearly defines in-scope and out-of-scope boundaries
- All abbreviations and technical terms are defined
- Every role in the Responsibilities section maps to procedure steps
- Procedure steps start with action verbs and are specific enough to follow without interpretation
- Decision points have clear criteria for each path
- Deviation handling is defined
- All referenced documents exist and are accessible
- Revision history is complete from version 1.0
- Approval signatures include author, reviewer, and approver
- Periodic review schedule is defined
Pitfalls
- Too vague: "Ensure data quality" is not a procedural step. "Verify that all 15 fields in Form-001 are populated and within range per Appendix A" is.
- Too detailed: Including troubleshooting for every possible error makes the SOP unreadable. Reference a separate work instruction for complex troubleshooting.
- No deviation handling: Every SOP must define what to do when the procedure cannot be followed as written. Silence on deviations implies no deviations are possible.
- Effective before training: An SOP that is effective before all users are trained creates an immediate compliance gap.
- Orphaned SOPs: SOPs that are never reviewed become outdated and unreliable. Set review dates and track them in the document control system.
Related Skills
design-compliance-architecture— identifies which systems and processes need SOPsmanage-change-control— triggers SOP updates when processes changedesign-training-program— ensures users are trained on new and updated SOPsconduct-gxp-audit— audits assess SOP adequacy and adherencewrite-validation-documentation— SOPs and validation docs share approval workflows
Repositorio GitHub
Habilidades relacionadas
content-collections
MetaEsta habilidad proporciona una configuración probada en producción para Content Collections, una herramienta centrada en TypeScript que transforma archivos Markdown/MDX en colecciones de datos con tipado seguro mediante validación Zod. Úsala al construir blogs, sitios de documentación o aplicaciones Vite + React con mucho contenido para garantizar seguridad de tipos y validación automática de contenido. Abarca todo, desde la configuración del plugin de Vite y compilación MDX hasta la optimización de despliegue y validación de esquemas.
polymarket
MetaEsta habilidad permite a los desarrolladores crear aplicaciones con la plataforma de mercados de predicción Polymarket, incluyendo la integración de API para operaciones y datos de mercado. También proporciona transmisión de datos en tiempo real a través de WebSocket para monitorear operaciones en vivo y actividad del mercado. Úsela para implementar estrategias de trading o crear herramientas que procesen actualizaciones de mercado en tiempo real.
creating-opencode-plugins
MetaEsta habilidad ayuda a los desarrolladores a crear complementos de OpenCode que se conectan a más de 25 tipos de eventos, como comandos, archivos y operaciones LSP. Proporciona la estructura del complemento, las especificaciones de la API de eventos y los patrones de implementación para módulos en JavaScript/TypeScript. Úsala cuando necesites interceptar, monitorear o extender el ciclo de vida del asistente de IA de OpenCode con lógica personalizada basada en eventos.
sglang
MetaSGLang es un framework de alto rendimiento para el servicio de LLM que se especializa en generación rápida y estructurada para JSON, expresiones regulares y flujos de trabajo de agentes utilizando su caché de prefijos RadixAttention. Ofrece una inferencia significativamente más rápida, especialmente para tareas con prefijos repetidos, lo que lo hace ideal para salidas complejas y estructuradas, y conversaciones multiturno. Elige SGLang sobre alternativas como vLLM cuando necesites decodificación restringida o estés construyendo aplicaciones con uso extensivo de prefijos compartidos.
