UNPKG

aiwg

Version:

Cognitive architecture for AI-augmented software development with structured memory, ensemble validation, and closed-loop correction. FAIR-aligned artifacts, 84% cost reduction via human-in-the-loop, standards adopted by 100+ organizations.

309 lines (226 loc) 8.52 kB
# Creating AIWG Extensions Extensions are "expansion packs" that add domain-specific capabilities to existing frameworks. They cannot operate standalone - they require their parent framework. ## When to Create an Extension Create an extension when you need: - Compliance modules (GDPR, HIPAA, SOX, PCI-DSS) - Industry-specific adaptations (healthcare, fintech, government) - Regional/legal variations (EU, US, APAC regulations) - Specialized workflows that build on framework foundations Examples: - `hipaa` extension for `sdlc-complete` - Healthcare compliance - `ftc` extension for `media-marketing-kit` - FTC advertising guidelines - `gdpr` extension for any framework - Data protection requirements ## Extension vs Addon | Aspect | Extension | Addon | |--------|-----------|-------| | Standalone? | No - requires parent | Yes - works anywhere | | Location | `frameworks/{id}/extensions/` | `addons/` | | Manifest | Has `requires` field | No `requires` field | | Deploy | `aiwg -deploy-extension` | `aiwg -deploy-agents` | | Scope | Framework-specific | Universal | ## Quick Start ### Using CLI ```bash # Create extension structure aiwg scaffold-extension hipaa --for sdlc-complete --description "HIPAA compliance templates" # Result: # agentic/code/frameworks/sdlc-complete/extensions/hipaa/ # ├── manifest.json # ├── README.md # ├── templates/ # └── checklists/ # Add components aiwg add-template phi-handling --to sdlc-complete/extensions/hipaa --type checklist aiwg add-agent compliance-reviewer --to sdlc-complete/extensions/hipaa --template complex ``` ### Using In-Session Commands ```bash /devkit-create-extension hipaa --for sdlc-complete --interactive ``` Claude will ask about: 1. **Compliance domain**: What regulations/standards does this cover? 2. **Parent integration**: Which framework phases does this extend? 3. **Artifacts**: What checklists, templates, or agents are needed? 4. **Validation**: How will compliance be verified? ## Extension Structure ``` frameworks/sdlc-complete/extensions/hipaa/ ├── manifest.json # Package metadata with "requires" field ├── README.md # Documentation ├── agents/ # Compliance-focused agents └── phi-reviewer.md ├── commands/ # Compliance workflows └── hipaa-audit.md ├── templates/ # Compliance documents ├── phi-inventory.md ├── baa-template.md └── breach-response.md ├── checklists/ # Audit checklists ├── technical-safeguards.md ├── administrative-safeguards.md └── physical-safeguards.md └── flows/ # Extension-specific workflows (optional) └── compliance-review.md ``` ## Manifest Configuration ```json { "id": "hipaa", "type": "extension", "name": "HIPAA Compliance Extension", "version": "1.0.0", "description": "Healthcare compliance templates and checklists for SDLC", "author": "Your Name", "license": "MIT", "requires": ["sdlc-complete"], "entry": { "agents": "agents", "commands": "commands", "templates": "templates", "checklists": "checklists" }, "agents": ["phi-reviewer"], "commands": ["hipaa-audit"], "templates": ["phi-inventory", "baa-template", "breach-response"], "checklists": ["technical-safeguards", "administrative-safeguards", "physical-safeguards"] } ``` ### Key Fields | Field | Purpose | |-------|---------| | `type` | Must be `"extension"` | | `requires` | Array of parent framework IDs | | `checklists` | Extension-specific component type | ## Creating Compliance Checklists ```bash aiwg add-template security-controls --to sdlc-complete/extensions/hipaa --type checklist ``` ```markdown # HIPAA Security Controls Checklist ## Technical Safeguards (45 CFR 164.312) ### Access Control (§164.312(a)(1)) - [ ] Unique user identification implemented - [ ] Emergency access procedure documented - [ ] Automatic logoff configured - [ ] Encryption and decryption mechanisms in place ### Audit Controls (§164.312(b)) - [ ] Hardware audit mechanisms implemented - [ ] Software audit mechanisms implemented - [ ] Procedural audit mechanisms documented ### Integrity (§164.312(c)(1)) - [ ] Electronic mechanisms to corroborate data integrity - [ ] Transmission security measures in place ## Evidence | Control | Implementation | Evidence Location | |---------|---------------|-------------------| | Access Control | | | | Audit Logging | | | ``` ## Creating Compliance Templates ```bash aiwg add-template risk-assessment --to sdlc-complete/extensions/hipaa --type document ``` Document templates provide structure for compliance artifacts that integrate with parent framework workflows. ## Creating Compliance Agents ```bash aiwg add-agent compliance-auditor --to sdlc-complete/extensions/hipaa --template complex ``` Compliance agents should: 1. Reference parent framework artifacts (requirements, architecture) 2. Apply domain-specific validation rules 3. Generate compliance evidence and reports 4. Integrate with parent framework gates Example agent prompt structure: ```markdown ## Domain Expertise - HIPAA Security Rule (45 CFR 164.302-318) - HIPAA Privacy Rule (45 CFR 164.500-534) - HITECH Act requirements - OCR audit protocols ## Integration Points This agent integrates with parent SDLC framework: - **Requirements phase**: Validate PHI handling requirements - **Architecture phase**: Review security architecture for compliance - **Testing phase**: Verify security control implementation - **Deployment phase**: Validate production security posture ``` ## Integration with Parent Framework Extensions inherit and extend parent framework capabilities: ### Workflow Integration Extensions can hook into parent framework phases: ```markdown # hipaa-audit.md command --- name: hipaa-audit description: HIPAA compliance audit for current phase args: - name: phase description: SDLC phase to audit (inception, elaboration, construction, transition) required: true --- ## Process 1. Read parent framework phase artifacts from `.aiwg/` 2. Apply HIPAA-specific validation rules 3. Generate compliance report 4. Update `.aiwg/security/hipaa/` with audit results ``` ### Template Inheritance Extension templates can reference parent templates: ```markdown <!-- Extends: sdlc-complete/templates/security/threat-model-template.md --> # HIPAA Threat Model This extends the standard threat model with HIPAA-specific threats. ## Standard Threats <!-- Include base threat categories from parent --> ## PHI-Specific Threats ### Unauthorized PHI Access - Threat: Unauthorized access to Protected Health Information - HIPAA Reference: §164.312(a)(1) - Mitigation: [specific controls] ``` ## Deployment ```bash # Deploy extension to project (requires parent framework) aiwg -deploy-extension hipaa --framework sdlc-complete --target ./my-project # This copies: # - Extension agents to .claude/agents/ # - Extension commands to .claude/commands/ # - Extension templates to .aiwg/templates/hipaa/ ``` ## Validation ```bash # Validate extension structure aiwg validate sdlc-complete/extensions/hipaa --verbose # Checks: # - Parent framework exists # - "requires" field is valid # - All referenced components exist # - Extension-specific directories present ``` ## Best Practices 1. **Keep extensions focused** - One compliance domain per extension 2. **Reference parent artifacts** - Don't duplicate, extend 3. **Provide clear traceability** - Map requirements to controls to evidence 4. **Include audit checklists** - Make compliance verification actionable 5. **Document regulatory references** - Cite specific regulations/sections 6. **Version with regulations** - Update when regulations change ## Examples ### Existing Extensions - `sdlc-complete/extensions/gdpr` - GDPR data protection - `sdlc-complete/extensions/legal` - Legal review templates - `media-marketing-kit/extensions/ftc` - FTC advertising compliance ### Common Extension Patterns **Compliance Extension**: - Checklists for each control family - Templates for required documentation - Agents for automated validation - Commands for audit workflows **Industry Extension**: - Domain-specific terminology - Industry workflow variations - Regulatory requirements - Best practice templates **Regional Extension**: - Localized templates - Regional regulatory requirements - Language/cultural considerations