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
Markdown
# 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