Skill: ivangdavila/enterprise (version 1.0.0)

--- name: Enterprise slug: enterprise version: 1.0.0 description: Navigate enterprise software development with legacy integration, compliance requirements, stakeholder management, and architectural decisions at scale. metadata: {"clawdbot":{"emoji":"🏢","requires":{"bins":[]},"os":["linux","darwin","win32"]}} --- ## When to Use Working in corporate environments where decisions involve legacy systems, formal processes, compliance, multi-team coordination, or architectural trade-offs at scale. ## Quick Reference | Topic | File | |-------|------| | Legacy patterns | `legacy.md` | | Compliance rules | `compliance.md` | | Architecture decisions | `architecture.md` | ## Core Rules ### 1. Legacy First Mindset - Assume existing systems until proven otherwise - Integration cost > development cost in most decisions - "Replace vs wrap" analysis before any architecture change - Document all integration points touched ### 2. Stakeholder Mapping | Role | Cares About | Language | |------|-------------|----------| | Engineering | Technical debt, velocity | Patterns, trade-offs | | Product | Features, timeline | User impact, scope | | Security | Risk, compliance | Threat models, controls | | Finance | Cost, ROI | TCO, licensing | | Legal | Liability, data | Contracts, GDPR | Translate technical decisions into each stakeholder's language. ### 3. Change Management - No breaking changes without migration path - Feature flags before hard switches - Rollback plan for every deployment - Document blast radius of failures ### 4. Compliance Awareness - PCI, SOC2, HIPAA, GDPR implications in every data decision - Audit trail requirements → logging design - Data residency affects architecture - Ask: "Who audits this? What do they need?" ### 5. Documentation as Deliverable Enterprise code without docs = technical debt. - ADRs (Architecture Decision Records) for major choices - Runbooks for operations - API contracts before implementation - Dependency graphs updated with changes ### 6. Security by Default - Principle of least privilege in all designs - Secrets in vault, never in code or config files - Network segmentation assumptions - Zero trust between services ### 7. Observability Investment - Logging, metrics, tracing from day one - Correlation IDs across service boundaries - SLI/SLO definitions before launch - Alert fatigue is a system design failure ## Enterprise Traps - Assuming greenfield when there's always legacy → scope explosion - Optimizing for developer experience over ops burden → 3am pages - Skipping security review for "internal tools" → breach vector - Building before buying → reinventing solved problems - Over-abstracting early → framework nobody understands - Under-documenting decisions → knowledge silos

path: architecture.md
content: # Architecture Decisions — Enterprise

## ADR Template

Every major decision gets an ADR:

```markdown
# ADR-{number}: {Title}

## Status
Proposed | Accepted | Deprecated | Superseded by ADR-X

## Context
What is the issue that we're seeing that is motivating this decision?

## Decision
What is the change that we're proposing and/or doing?

## Consequences
What becomes easier or more difficult because of this change?
```

## Trade-off Matrix

| Factor | Monolith | Microservices | Serverless |
|--------|----------|---------------|------------|
| Initial velocity | ✅ Fast | ⚠️ Slow | ✅ Fast |
| Team independence | ❌ Low | ✅ High | ✅ High |
| Operational cost | ✅ Low | ⚠️ High | ⚠️ Variable |
| Debugging | ✅ Easy | ❌ Hard | ❌ Hard |
| Scaling | ⚠️ All-or-nothing | ✅ Granular | ✅ Auto |

## Decision Frameworks

### Buy vs Build
```
Build when:
- Core differentiator
- Exact fit required
- Long-term ownership viable

Buy when:
- Commodity functionality
- Time-to-market critical
- Expertise gap exists
```

### Synchronous vs Async
```
Sync when:
- User waiting for response
- Transaction semantics needed
- Simple request/response

Async when:
- Long-running operations
- Decoupling required
- Spike handling needed
- At-least-once acceptable
```

## Common Patterns

### API Gateway
Single entry point for all external traffic.
- Authentication centralized
- Rate limiting
- Request transformation
- Analytics collection

### Event Sourcing
Store state as sequence of events.
- Full audit trail built-in
- Temporal queries possible
- Complexity cost: high

### CQRS
Separate read and write models.
- Scale reads independently
- Optimize for query patterns
- Eventual consistency required

## Anti-Patterns

- Distributed monolith → worst of both worlds
- Database per service without data ownership → integration hell
- Synchronous chains across services → cascading failures
- Shared libraries coupling services → deployment lock-step


path: compliance.md
content: # Compliance — Enterprise

## Quick Reference

| Framework | Scope | Key Requirements |
|-----------|-------|------------------|
| SOC 2 | Service orgs | Access control, encryption, monitoring |
| PCI DSS | Payment data | Network segmentation, encryption, audit |
| HIPAA | Health data | Access logs, encryption, BAAs |
| GDPR | EU personal data | Consent, deletion, portability |
| SOX | Public companies | Financial controls, audit trails |

## Design Implications

### Data Classification
Before building, classify data:

| Level | Examples | Requirements |
|-------|----------|--------------|
| Public | Marketing content | None |
| Internal | Employee docs | Authentication |
| Confidential | Customer data | Encryption, audit |
| Restricted | PII, PHI, PCI | All controls, DLP |

### Audit Trail Requirements
Every compliance framework needs:
- Who (authenticated identity)
- What (action performed)
- When (timestamp, timezone)
- Where (source IP, service)
- Result (success/failure)

### Data Residency
GDPR, China, Russia have data localization rules.

```
Before: [Single Global DB]
After:  [EU DB] [US DB] [APAC DB] + routing layer
```

## Common Mistakes

- Logging PII in plaintext → compliance violation
- No retention policy → storing data forever
- Assuming "internal" means "no compliance" → wrong
- Consent buried in ToS → GDPR violation
- Audit logs deletable → defeats purpose


path: legacy.md
content: # Legacy Integration — Enterprise

## Assessment Framework

Before touching legacy systems:

| Question | Why |
|----------|-----|
| Who owns it? | Political cover needed |
| When last deployed? | Deployment risk gauge |
| What depends on it? | Blast radius mapping |
| Any documentation? | Knowledge extraction priority |
| What's the SLA? | Downtime tolerance |

## Integration Patterns

### Strangler Fig
Gradually replace legacy by routing traffic through new system.

```
[Client] → [Router] → [New Service] (growing)
                   ↘ [Legacy] (shrinking)
```

Best when: can intercept traffic, incremental value.

### Anti-Corruption Layer
Translate between legacy and new domain models.

```
[New Domain] ← [ACL] ← [Legacy Domain]
```

Best when: legacy concepts don't map cleanly.

### Database Sync
Keep legacy and new databases in sync during transition.

```
[Legacy DB] ↔ [CDC/ETL] ↔ [New DB]
```

Best when: data migration is the hard part.

## Common Traps

- Assuming legacy is "simple" because it's old → hidden complexity
- Rewriting without understanding → repeating old bugs
- Tight coupling to sync mechanism → new single point of failure
- No rollback plan → one-way door decisions

## Decision Tree

```
Can you wrap it?
├─ Yes → Strangler Fig
└─ No
   ├─ Is the interface stable? → Anti-Corruption Layer
   └─ No → Full migration with parallel run
```


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)