@defai.digital/automatosx 12.8.7 → 13.1.3

package/examples/abilities/code-review.md

@@ -1,51 +0,0 @@
-# Code Review Ability
-
-Perform thorough code reviews focusing on quality, security, and maintainability.
-
-## Review Areas
-
-1. **Correctness**
-   - Logic errors and bugs
-   - Edge case handling
-   - Error handling and validation
-
-2. **Security**
-   - Input validation
-   - SQL injection, XSS vulnerabilities
-   - Secrets and credentials exposure
-   - Authentication and authorization
-
-3. **Performance**
-   - Algorithm complexity (Big O)
-   - Resource usage (memory, CPU)
-   - Database query optimization
-   - Caching opportunities
-
-4. **Maintainability**
-   - Code clarity and readability
-   - Documentation quality
-   - Test coverage
-   - Modularity and coupling
-
-5. **Style**
-   - Coding standards compliance
-   - Naming conventions
-   - Code organization
-   - Consistent formatting
-
-## Review Process
-
-1. Understand the context and requirements
-2. Review code systematically (file by file)
-3. Identify issues and improvements
-4. Prioritize findings (critical/major/minor)
-5. Provide actionable, constructive feedback
-
-## Application Hints
-
-When reviewing code:
-- Focus on correctness and security first; style issues are secondary
-- Verify edge cases and error paths are handled, not just the happy path
-- Check that tests cover the changed behavior, not just line coverage
-- Prioritize feedback by severity (critical/major/minor) to respect author's time
-- Provide specific improvements with code examples rather than vague criticism

package/examples/abilities/component-architecture.md

@@ -1,112 +0,0 @@
-# Component Architecture
-
-## Overview
-Design and implement reusable, maintainable component structures following modern frontend architecture patterns. Focus on composition, separation of concerns, and clear component hierarchies.
-
-## Core Principles
-
-### 1. Single Responsibility
-Each component should have one clear purpose. Avoid components that try to do too much.
-
-### 2. Composition Over Inheritance
-Build complex UIs by composing smaller, focused components rather than creating deep inheritance chains.
-
-### 3. Container/Presentational Pattern
-- **Container components**: Handle logic, state, and side effects
-- **Presentational components**: Focus purely on rendering UI based on props
-
-### 4. Props Design
-- Keep props interfaces simple and explicit
-- Use TypeScript for type safety
-- Avoid prop drilling—use context or state management for deep data
-
-## Component Structure
-
-```
-/components
-  /Button
-    Button.tsx          # Component implementation
-    Button.test.tsx     # Tests
-    Button.stories.tsx  # Storybook stories
-    index.ts            # Public exports
-```
-
-## Atomic Design
-
-Organize components by complexity:
-- **Atoms**: Button, Input, Label
-- **Molecules**: FormField (Input + Label), SearchBar
-- **Organisms**: LoginForm, Header, Card
-- **Templates**: Page layouts
-- **Pages**: Complete pages
-
-## Best Practices
-
-### Component Design
-- Single responsibility principle
-- TypeScript interfaces for props
-- Proper error boundaries
-- Clear naming conventions
-
-### Performance
-- Memoization where appropriate (React.memo, useMemo)
-- Callback memoization (useCallback)
-- Code splitting for heavy components
-- Lazy loading with Suspense
-
-### Testing
-- Unit tests for component logic
-- Integration tests for user interactions
-- Accessibility testing
-- Visual regression tests
-
-## Anti-Patterns to Avoid
-
-### 1. God Components
-Components that handle too many responsibilities
-
-### 2. Prop Drilling
-Passing props through many levels—use Context API or state management
-
-### 3. Tight Coupling
-Components depending on specific parent or child implementations
-
-### 4. Mixed Concerns
-Mixing business logic, API calls, and rendering in one component
-
-## Component Checklist
-
-- [ ] Single responsibility
-- [ ] TypeScript interfaces for props
-- [ ] Proper error boundaries
-- [ ] Memoization where appropriate
-- [ ] Accessibility attributes (ARIA)
-- [ ] Unit tests for logic
-- [ ] Integration tests for interactions
-- [ ] Storybook documentation
-- [ ] Performance optimized
-- [ ] Code split if heavy
-
-## Performance Considerations
-
-### Memoization
-- Memoize expensive computations (useMemo)
-- Memoize callback functions (useCallback)
-- Memoize components that render often (React.memo)
-
-### Code Splitting
-- Lazy load heavy components
-- Use Suspense for loading states
-- Route-based code splitting
-
-### Optimization Techniques
-- Virtual scrolling for long lists
-- Debounce/throttle for frequent events
-- Avoid unnecessary re-renders
-- Use production builds
-
-## Resources
-
-- [React Component Patterns](https://reactpatterns.com/)
-- [Atomic Design Methodology](https://atomicdesign.bradfrost.com/)
-- [Testing Library Best Practices](https://testing-library.com/docs/react-testing-library/intro)

package/examples/abilities/content-creation.md

@@ -1,97 +0,0 @@
-# Content Creation Ability
-
-Create engaging, informative content for various audiences.
-
-## Content Types
-
-1. **Blog Posts**
-   - Catchy title
-   - Hook in first paragraph
-   - Clear structure (intro, body, conclusion)
-   - Scannable (headings, bullets, short paragraphs)
-   - Call to action
-
-2. **Tutorials**
-   - Clear learning objectives
-   - Prerequisites listed
-   - Step-by-step instructions
-   - Code examples
-   - Screenshots/diagrams
-   - What you learned / next steps
-
-3. **Documentation**
-   - Purpose and overview
-   - Installation/setup
-   - Usage examples
-   - API reference
-   - Troubleshooting
-   - FAQ
-
-4. **Presentations**
-   - One idea per slide
-   - Visual > text
-   - Tell a story
-   - Practice delivery
-   - End with key takeaways
-
-## Writing Process
-
-1. **Research**
-   - Understand the topic
-   - Know your audience
-   - Check existing content
-   - Gather examples
-
-2. **Outline**
-   - Main points
-   - Logical flow
-   - Supporting details
-   - Conclusion
-
-3. **Draft**
-   - Get ideas down
-   - Don't self-edit yet
-   - Write more than needed
-   - Focus on clarity
-
-4. **Edit**
-   - Cut unnecessary content
-   - Improve clarity
-   - Fix grammar/spelling
-   - Check flow and structure
-
-5. **Review**
-   - Read aloud
-   - Get feedback
-   - Check accuracy
-   - Final polish
-
-## Writing Tips
-
-**Clarity:**
-
-- Use simple words
-- Short sentences
-- Active voice
-- Concrete examples
-
-**Engagement:**
-
-- Hook readers early
-- Use stories and examples
-- Ask questions
-- Vary sentence length
-
-**Structure:**
-
-- Clear headings
-- Logical progression
-- Bullet points for lists
-- White space for readability
-
-**Credibility:**
-
-- Cite sources
-- Use data and statistics
-- Show expertise
-- Acknowledge limitations

package/examples/abilities/data-modeling.md

@@ -1,171 +0,0 @@
-# Data Modeling
-
-## Overview
-Design efficient, scalable data models for relational and NoSQL databases. Focus on normalization, relationships, and schema design that supports business requirements while maintaining data integrity.
-
-## Core Principles
-
-### 1. Normalization (Relational)
-Eliminate data redundancy through normal forms (1NF, 2NF, 3NF, BCNF).
-
-### 2. Denormalization (When Needed)
-Strategic denormalization for read-heavy workloads and performance optimization.
-
-### 3. Schema Design Patterns
-- **Star Schema**: Dimensional modeling for analytics (fact + dimension tables)
-- **Snowflake Schema**: Normalized dimensional model
-- **Data Vault**: Flexible, auditable data warehouse modeling
-
-## Do's ✅
-
-### Relational Data Model
-```sql
--- ✅ Good: Normalized design
-CREATE TABLE users (
-  id SERIAL PRIMARY KEY,
-  email VARCHAR(255) UNIQUE NOT NULL,
-  created_at TIMESTAMP DEFAULT NOW()
-);
-
-CREATE TABLE orders (
-  id SERIAL PRIMARY KEY,
-  user_id INTEGER REFERENCES users(id),
-  total_amount DECIMAL(10,2),
-  status VARCHAR(50),
-  created_at TIMESTAMP DEFAULT NOW()
-);
-
-CREATE TABLE order_items (
-  id SERIAL PRIMARY KEY,
-  order_id INTEGER REFERENCES orders(id),
-  product_id INTEGER REFERENCES products(id),
-  quantity INTEGER,
-  price DECIMAL(10,2)
-);
-```
-
-### Indexes
-```sql
--- ✅ Good: Index frequently queried columns
-CREATE INDEX idx_orders_user_id ON orders(user_id);
-CREATE INDEX idx_orders_created_at ON orders(created_at);
-CREATE INDEX idx_order_items_order_id ON order_items(order_id);
-
--- ✅ Good: Composite index for multi-column queries
-CREATE INDEX idx_orders_user_status ON orders(user_id, status);
-```
-
-### NoSQL Data Model (MongoDB)
-```javascript
-// ✅ Good: Embedded documents for one-to-few
-{
-  _id: ObjectId("..."),
-  user_email: "user@example.com",
-  addresses: [
-    { type: "home", street: "123 Main St", city: "NYC" },
-    { type: "work", street: "456 Office Ave", city: "LA" }
-  ]
-}
-
-// ✅ Good: References for one-to-many
-// User document
-{
-  _id: ObjectId("user123"),
-  email: "user@example.com"
-}
-
-// Order documents (separate collection)
-{
-  _id: ObjectId("order456"),
-  user_id: ObjectId("user123"),
-  items: [...],
-  total: 99.99
-}
-```
-
-## Don'ts ❌
-
-### Over-Normalization
-```sql
--- ❌ Bad: Excessive normalization
-CREATE TABLE user_first_names (
-  user_id INTEGER REFERENCES users(id),
-  first_name VARCHAR(100)
-);
-
-CREATE TABLE user_last_names (
-  user_id INTEGER REFERENCES users(id),
-  last_name VARCHAR(100)
-);
-
--- ✅ Good: Appropriate normalization
-CREATE TABLE users (
-  id SERIAL PRIMARY KEY,
-  first_name VARCHAR(100),
-  last_name VARCHAR(100),
-  email VARCHAR(255) UNIQUE
-);
-```
-
-### Missing Constraints
-```sql
--- ❌ Bad: No constraints
-CREATE TABLE orders (
-  id INTEGER,
-  user_id INTEGER,
-  total DECIMAL
-);
-
--- ✅ Good: Proper constraints
-CREATE TABLE orders (
-  id SERIAL PRIMARY KEY,
-  user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
-  total DECIMAL(10,2) CHECK (total >= 0),
-  status VARCHAR(50) DEFAULT 'pending',
-  created_at TIMESTAMP NOT NULL DEFAULT NOW()
-);
-```
-
-### Embedding Large Arrays (NoSQL)
-```javascript
-// ❌ Bad: Unbounded array growth
-{
-  user_id: "user123",
-  orders: [ /* Could grow to thousands */ ]
-}
-
-// ✅ Good: Reference pattern
-{
-  user_id: "user123",
-  recent_orders: [ /* Last 5 orders */ ],
-  total_order_count: 1247
-}
-// Store full orders in separate collection
-```
-
-## Best Practices
-
-### 1. Use Appropriate Data Types
-- `TIMESTAMP` for dates (not VARCHAR)
-- `DECIMAL` for money (not FLOAT)
-- `ENUM` or `CHECK` constraints for fixed options
-- `UUID` for distributed primary keys
-
-### 2. Plan for Growth
-- Partition large tables by date/region
-- Use sharding for horizontal scalability
-- Implement archival strategy for old data
-
-### 3. Document Relationships
-```
-Users (1) ← (M) Orders (1) ← (M) OrderItems (M) → (1) Products
-```
-
-### 4. Version Schema Changes
-Use migration tools (Flyway, Liquibase, Alembic) for schema versioning.
-
-## Resources
-
-- [Database Normalization](https://en.wikipedia.org/wiki/Database_normalization)
-- [MongoDB Schema Design Patterns](https://www.mongodb.com/blog/post/building-with-patterns-a-summary)
-- [PostgreSQL Documentation](https://www.postgresql.org/docs/)

package/examples/abilities/data-validation.md

@@ -1,50 +0,0 @@
-# Data Validation
-
-Implement comprehensive data quality checks to ensure accuracy, completeness, and consistency. Catch data issues early before they impact downstream systems.
-
-## Do's ✅
-
-```python
-# ✅ Good: Schema validation with Pydantic
-from pydantic import BaseModel, validator
-
-class UserRecord(BaseModel):
-    id: int
-    email: str
-    age: int
-
-    @validator('email')
-    def email_must_be_valid(cls, v):
-        if '@' not in v:
-            raise ValueError('Invalid email')
-        return v
-
-# ✅ Good: Data quality checks
-def validate_data(df):
-    checks = [
-        ('No nulls', df[['id', 'email']].notnull().all().all()),
-        ('Unique IDs', df['id'].is_unique),
-        ('Valid ages', df['age'].between(0, 150).all()),
-    ]
-    failed = [check for check, passed in checks if not passed]
-    if failed:
-        raise ValueError(f"Validation failed: {failed}")
-```
-
-## Don'ts ❌
-
-```python
-# ❌ Bad: No validation
-df = pd.read_csv('data.csv')
-df.to_sql('users', engine)  # Hope for the best!
-
-# ❌ Bad: Silent failures
-df = df.dropna()  # What was dropped? Why?
-```
-
-## Best Practices
-- Define data quality SLAs
-- Implement continuous monitoring
-- Document validation rules
-- Use validation frameworks (Great Expectations, Pandera)
-- Create data quality dashboards

package/examples/abilities/db-modeling.md

@@ -1,167 +0,0 @@
-# Database Modeling
-
-## Overview
-Design efficient, scalable, and maintainable database schemas for relational and NoSQL databases, focusing on data integrity, performance, and evolution.
-
-## Core Principles
-
-### 1. Normalization & Denormalization
-- 3NF for transactional systems
-- Strategic denormalization for read-heavy workloads
-- Balance between data integrity and query performance
-
-### 2. Data Integrity
-- Primary keys on all tables
-- Foreign key constraints
-- Check constraints for data validation
-- Unique constraints for business rules
-
-### 3. Indexing Strategy
-- Primary key indexes (clustered)
-- Secondary indexes for frequent queries
-- Composite indexes for multi-column filters
-- Index maintenance and statistics
-
-### 4. Schema Evolution
-- Migration strategy (forward-only)
-- Backward compatibility during deploys
-- Column additions vs. breaking changes
-- Versioning for schema changes
-
-## Relational Database Design
-
-### Table Design Essentials
-- Primary key (BIGSERIAL, UUID)
-- Timestamps (created_at, updated_at)
-- Soft delete (deleted_at)
-- Proper data types
-
-### Relationship Patterns
-- One-to-Many: Foreign key in child table
-- Many-to-Many: Junction table with composite primary key
-- One-to-One: Rare; consider column addition instead
-
-### Partitioning Strategies
-- Range partitioning (dates, IDs)
-- List partitioning (regions, categories)
-- Hash partitioning (even distribution)
-- When to partition: >10M rows, predictable access patterns
-
-## NoSQL Design Patterns
-
-### Document Stores (MongoDB, DynamoDB)
-- Embed vs. reference decision tree
-- Avoid unbounded arrays
-- Duplicate data strategically
-- Query pattern drives schema
-
-### Key-Value Stores (Redis, DynamoDB)
-- Compound key design
-- TTL for expiring data
-- Secondary indexes trade-offs
-
-### Graph Databases (Neo4j)
-- Node and relationship properties
-- Index on frequently queried properties
-- Cypher query optimization
-
-## Performance Optimization
-
-### Query Performance
-- EXPLAIN ANALYZE for execution plans
-- Index usage verification
-- Avoid N+1 queries (eager loading)
-- Connection pooling configuration
-
-### Write Optimization
-- Batch inserts for bulk data
-- Async writes for non-critical data
-- Write-ahead logging (WAL) tuning
-
-### Read Optimization
-- Read replicas for scaling
-- Query result caching
-- Materialized views for complex aggregations
-
-## Data Types Best Practices
-
-### Choosing Types
-- VARCHAR vs. TEXT vs. CHAR
-- INTEGER vs. BIGINT (consider growth)
-- DECIMAL for money (never FLOAT)
-- TIMESTAMPTZ for dates (always use timezone)
-- JSON/JSONB for semi-structured data
-
-### Type Performance
-- Smaller types = better performance
-- Fixed-length types for indexes
-- Avoid TEXT in WHERE clauses without indexes
-
-## Migration Strategies
-
-### Safe Migration Patterns
-1. Add nullable column → Backfill → Add NOT NULL
-2. Create new table → Dual write → Swap → Drop old
-3. Add index CONCURRENTLY (PostgreSQL)
-4. Rename via view (zero-downtime)
-
-### Rollback Strategies
-- Idempotent migrations
-- Reversible changes
-- Feature flags for data migrations
-- Separate schema and data migrations
-
-## Security & Compliance
-
-### Access Control
-- Principle of least privilege
-- Row-level security (RLS)
-- Column-level permissions
-- Audit logging for sensitive data
-
-### Data Encryption
-- Encryption at rest
-- Encryption in transit (SSL/TLS)
-- Column-level encryption for PII
-- Key rotation policies
-
-### GDPR/Privacy
-- Soft delete vs. hard delete
-- Data retention policies
-- PII identification and protection
-- Right to be forgotten implementation
-
-## Common Patterns
-
-### Soft Delete
-Use `deleted_at` timestamp with partial index
-
-### Audit Trails
-Track created_at, created_by, updated_at, updated_by
-
-### Status/State Machine
-Use CHECK constraints for valid states
-
-## Design Checklist
-
-- [ ] All tables have primary keys
-- [ ] Foreign key constraints defined
-- [ ] Indexes cover frequent query patterns
-- [ ] Data types appropriately sized
-- [ ] Nullable columns justified
-- [ ] Constraints enforce business rules
-- [ ] Migration scripts tested
-- [ ] Rollback plan documented
-- [ ] Performance testing completed
-- [ ] Schema documented
-- [ ] Backup/restore verified
-- [ ] Security audit completed
-
-## Application Hints
-
-When modeling databases:
-- Choose data types for expected growth; BIGINT for IDs that may exceed 2 billion
-- Use TIMESTAMPTZ (not TIMESTAMP) for all date/time columns to avoid timezone bugs
-- Never use FLOAT/DOUBLE for money; use DECIMAL or store as integer cents
-- Design migrations to be reversible and test rollback before deploying
-- Add indexes based on actual query patterns, not theoretical access needs

package/examples/abilities/debugging.md

@@ -1,52 +0,0 @@
-# Debugging Ability
-
-Systematically identify and fix bugs in code.
-
-## Debugging Process
-
-1. **Reproduce** the issue
-   - Understand error messages
-   - Identify conditions that trigger the bug
-   - Create minimal reproduction case
-
-2. **Investigate** the problem
-   - Read stack traces carefully
-   - Add logging and breakpoints
-   - Check recent changes (git diff)
-   - Verify assumptions
-
-3. **Isolate** the root cause
-   - Use binary search (comment out code blocks)
-   - Test components individually
-   - Check inputs and outputs
-   - Trace execution flow
-
-4. **Fix** the bug
-   - Implement targeted fix
-   - Avoid introducing new bugs
-   - Update related code if needed
-   - Add regression test
-
-5. **Verify** the solution
-   - Test the fix thoroughly
-   - Check for side effects
-   - Run full test suite
-   - Document the fix
-
-## Common Bug Types
-
-- Off-by-one errors
-- Null/undefined reference errors
-- Race conditions and timing issues
-- Type mismatches
-- Resource leaks (memory, file handles)
-- Logic errors in conditionals
-
-## Application Hints
-
-When debugging:
-- Reproduce the issue first; never attempt to fix what you cannot reliably reproduce
-- Isolate to the smallest failing case before investigating root cause
-- Verify the fix doesn't introduce regressions by running the full test suite
-- Document the root cause in the commit message, not just the symptom
-- Check for similar patterns elsewhere in the codebase that may have the same bug