@emreizzetgmailcom
--- name: agent-organization-expert description: Multi-agent orchestration skill for team assembly, task decomposition, workflow optimization, and coordination strategies to achieve optimal team performance and resource utilization. --- # Agent Organization Assemble and coordinate multi-agent teams through systematic task analysis, capability mapping, and workflow design. ## Configuration - **Agent Count**: 3 - **Task Type**: general - **Orchestration Pattern**: parallel - **Max Concurrency**: 5 - **Timeout (seconds)**: 300 - **Retry Count**: 3 ## Core Process 1. **Analyze Requirements**: Understand task scope, constraints, and success criteria 2. **Map Capabilities**: Match available agents to required skills 3. **Design Workflow**: Create execution plan with dependencies and checkpoints 4. **Orchestrate Execution**: Coordinate 3 agents and monitor progress 5. **Optimize Continuously**: Adapt based on performance feedback ## Task Decomposition ### Requirement Analysis - Break complex tasks into discrete subtasks - Identify input/output requirements for each subtask - Estimate complexity and resource needs per component - Define clear success criteria for each unit ### Dependency Mapping - Document task execution order constraints - Identify data dependencies between subtasks - Map resource sharing requirements - Detect potential bottlenecks and conflicts ### Timeline Planning - Sequence tasks respecting dependencies - Identify parallelization opportunities (up to 5 concurrent) - Allocate buffer time for high-risk components - Define checkpoints for progress validation ## Agent Selection ### Capability Matching Select agents based on: - Required skills versus agent specializations - Historical performance on similar tasks - Current availability and workload capacity - Cost efficiency for the task complexity ### Selection Criteria Priority 1. **Capability fit**: Agent must possess required skills 2. **Track record**: Prefer agents with proven success 3. **Availability**: Sufficient capacity for timely completion 4. **Cost**: Optimize resource utilization within constraints ### Backup Planning - Identify alternate agents for critical roles - Define failover triggers and handoff procedures - Maintain redundancy for single-point-of-failure tasks ## Team Assembly ### Composition Principles - Ensure complete skill coverage for all subtasks - Balance workload across 3 team members - Minimize communication overhead - Include redundancy for critical functions ### Role Assignment - Match agents to subtasks based on strength - Define clear ownership and accountability - Establish communication channels between dependent roles - Document escalation paths for blockers ### Team Sizing - Smaller teams for tightly coupled tasks - Larger teams for parallelizable workloads - Consider coordination overhead in sizing decisions - Scale dynamically based on progress ## Orchestration Patterns ### Sequential Execution Use when tasks have strict ordering requirements: - Task B requires output from Task A - State must be consistent between steps - Error handling requires ordered rollback ### Parallel Processing Use when tasks are independent (parallel): - No data dependencies between tasks - Separate resource requirements - Results can be aggregated after completion - Maximum 5 concurrent operations ### Pipeline Pattern Use for streaming or continuous processing: - Each stage processes and forwards results - Enables concurrent execution of different stages - Reduces overall latency for multi-step workflows ### Hierarchical Delegation Use for complex tasks requiring sub-orchestration: - Lead agent coordinates sub-teams - Each sub-team handles a domain - Results aggregate upward through hierarchy ### Map-Reduce Use for large-scale data processing: - Map phase distributes work across agents - Each agent processes a partition - Reduce phase combines results ## Workflow Design ### Process Structure 1. **Entry point**: Validate inputs and initialize state 2. **Execution phases**: Ordered task groupings 3. **Checkpoints**: State persistence and validation points 4. **Exit point**: Result aggregation and cleanup ### Control Flow - Define branching conditions for alternative paths - Specify retry policies for transient failures (max 3 retries) - Establish timeout thresholds per phase (300s default) - Plan graceful degradation for partial failures ### Data Flow - Document data transformations between stages - Specify data formats and validation rules - Plan for data persistence at checkpoints - Handle data cleanup after completion ## Coordination Strategies ### Communication Patterns - **Direct**: Agent-to-agent for tight coupling - **Broadcast**: One-to-many for status updates - **Queue-based**: Asynchronous for decoupled tasks - **Event-driven**: Reactive to state changes ### Synchronization - Define sync points for dependent tasks - Implement waiting mechanisms with timeouts (300s) - Handle out-of-order completion gracefully - Maintain consistent state across agents ### Conflict Resolution - Establish priority rules for resource contention - Define arbitration mechanisms for conflicts - Document rollback procedures for deadlocks - Prevent conflicts through careful scheduling ## Performance Optimization ### Load Balancing - Distribute work based on agent capacity - Monitor utilization and rebalance dynamically - Avoid overloading high-performing agents - Consider agent locality for data-intensive tasks ### Bottleneck Management - Identify slow stages through monitoring - Add capacity to constrained resources - Restructure workflows to reduce dependencies - Cache intermediate results where beneficial ### Resource Efficiency - Pool shared resources across agents - Release resources promptly after use - Batch similar operations to reduce overhead - Monitor and alert on resource waste ## Monitoring and Adaptation ### Progress Tracking - Monitor completion status per task - Track time spent versus estimates - Identify tasks at risk of delay - Report aggregated progress to stakeholders ### Performance Metrics - Task completion rate and latency - Agent utilization and throughput - Error rates and recovery times - Resource consumption and cost ### Dynamic Adjustment - Reallocate agents based on progress - Adjust priorities based on blockers - Scale team size based on workload - Modify workflow based on learning ## Error Handling ### Failure Detection - Monitor for task failures and timeouts (300s threshold) - Detect agent unavailability promptly - Identify cascade failure patterns - Alert on anomalous behavior ### Recovery Procedures - Retry transient failures with backoff (up to 3 attempts) - Failover to backup agents when needed - Rollback to last checkpoint on critical failure - Escalate unrecoverable issues ### Prevention - Validate inputs before execution - Test agent availability before assignment - Design for graceful degradation - Build redundancy into critical paths ## Quality Assurance ### Validation Gates - Verify outputs at each checkpoint - Cross-check results from parallel tasks - Validate final aggregated results - Confirm success criteria are met ### Performance Standards - Agent selection accuracy target: >95% - Task completion rate target: >99% - Response time target: <5 seconds - Resource utilization: optimal range 60-80% ## Best Practices ### Planning - Invest time in thorough task analysis - Document assumptions and constraints - Plan for failure scenarios upfront - Define clear success metrics ### Execution - Start with minimal viable team (3 agents) - Scale based on observed needs - Maintain clear communication channels - Track progress against milestones ### Learning - Capture performance data for analysis - Identify patterns in successes and failures - Refine selection and coordination strategies - Share learnings across future orchestrations
--- name: accessibility-testing-superpower description: | Performs WCAG compliance audits and accessibility remediation for web applications. Use when: 1) Auditing UI for WCAG 2.1/2.2 compliance 2) Fixing screen reader or keyboard navigation issues 3) Implementing ARIA patterns correctly 4) Reviewing color contrast and visual accessibility 5) Creating accessible forms or interactive components --- # Accessibility Testing Workflow ## Configuration - **WCAG Level**: AA - **Component Under Test**: Page - **Compliance Standard**: WCAG 2.1 - **Minimum Lighthouse Score**: 90 - **Primary Screen Reader**: NVDA - **Test Framework**: jest-axe ## Audit Decision Tree ``` Accessibility request received | +-- New component/page? | +-- Run automated scan first (axe-core, Lighthouse) | +-- Keyboard navigation test | +-- Screen reader announcement check | +-- Color contrast verification | +-- Existing violation to fix? | +-- Identify WCAG success criterion | +-- Check if semantic HTML solves it | +-- Apply ARIA only when HTML insufficient | +-- Verify fix with assistive technology | +-- Compliance audit? +-- Automated scan (catches ~30% of issues) +-- Manual testing checklist +-- Document violations by severity +-- Create remediation roadmap ``` ## WCAG Quick Reference ### Severity Classification | Severity | Impact | Examples | Fix Timeline | |----------|--------|----------|--------------| | Critical | Blocks access entirely | No keyboard focus, empty buttons, missing alt on functional images | Immediate | | Serious | Major barriers | Poor contrast, missing form labels, no skip links | Within sprint | | Moderate | Difficult but usable | Inconsistent navigation, unclear error messages | Next release | | Minor | Inconvenience | Redundant alt text, minor heading order issues | Backlog | ### Common Violations and Fixes **Missing accessible name** ```html <!-- Violation --> <button><svg>...</svg></button> <!-- Fix: aria-label --> <button aria-label="Close dialog"><svg>...</svg></button> <!-- Fix: visually hidden text --> <button><span class="sr-only">Close dialog</span><svg>...</svg></button> ``` **Form label association** ```html <!-- Violation --> <label>Email</label> <input type="email"> <!-- Fix: explicit association --> <label for="email">Email</label> <input type="email" id="email"> <!-- Fix: implicit association --> <label>Email <input type="email"></label> ``` **Color contrast failure** ``` Minimum ratios (WCAG AA): - Normal text (<18px or <14px bold): 4.5:1 - Large text (>=18px or >=14px bold): 3:1 - UI components and graphics: 3:1 Tools: WebAIM Contrast Checker, browser DevTools ``` **Focus visibility** ```css /* Never do this without alternative */ :focus { outline: none; } /* Proper custom focus */ :focus-visible { outline: 2px solid #005fcc; outline-offset: 2px; } ``` ## ARIA Decision Framework ``` Need to convey information to assistive technology? | +-- Can semantic HTML do it? | +-- YES: Use HTML (<button>, <nav>, <main>, <article>) | +-- NO: Continue to ARIA | +-- What type of ARIA needed? +-- Role: What IS this element? (role="dialog", role="tab") +-- State: What condition? (aria-expanded, aria-checked) +-- Property: What relationship? (aria-labelledby, aria-describedby) +-- Live region: Dynamic content? (aria-live="polite") ``` ### ARIA Patterns for Common Widgets **Disclosure (show/hide)** ```html <button aria-expanded="false" aria-controls="content-1"> Show details </button> <div id="content-1" hidden> Content here </div> ``` **Tab interface** ```html <div role="tablist" aria-label="Settings"> <button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1"> General </button> <button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2" tabindex="-1"> Privacy </button> </div> <div role="tabpanel" id="panel-1" aria-labelledby="tab-1">...</div> <div role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>...</div> ``` **Modal dialog** ```html <div role="dialog" aria-modal="true" aria-labelledby="dialog-title"> <h2 id="dialog-title">Confirm action</h2> <p>Are you sure you want to proceed?</p> <button>Cancel</button> <button>Confirm</button> </div> ``` ## Keyboard Navigation Checklist ``` [ ] All interactive elements focusable with Tab [ ] Focus order matches visual/logical order [ ] Focus visible on all elements [ ] No keyboard traps (can always Tab out) [ ] Skip link as first focusable element [ ] Escape closes modals/dropdowns [ ] Arrow keys navigate within widgets (tabs, menus, grids) [ ] Enter/Space activates buttons and links [ ] Custom shortcuts documented and configurable ``` ### Focus Management Patterns **Modal focus trap** ```javascript // On modal open: // 1. Save previously focused element // 2. Move focus to first focusable in modal // 3. Trap Tab within modal boundaries // On modal close: // 1. Return focus to saved element ``` **Dynamic content** ```javascript // After adding content: // - Announce via aria-live region, OR // - Move focus to new content heading // After removing content: // - Move focus to logical next element // - Never leave focus on removed element ``` ## Screen Reader Testing ### Announcement Verification | Element | Should Announce | |---------|-----------------| | Button | Role + name + state ("Submit button") | | Link | Name + "link" ("Home page link") | | Image | Alt text OR "decorative" (skip) | | Heading | Level + text ("Heading level 2, About us") | | Form field | Label + type + state + instructions | | Error | Error message + field association | ### Testing Commands (Quick Reference) **VoiceOver (macOS)** - VO = Ctrl + Option - VO + A: Read all - VO + Right/Left: Navigate elements - VO + Cmd + H: Next heading - VO + Cmd + J: Next form control **NVDA (Windows)** - NVDA + Down: Read all - Tab: Next focusable - H: Next heading - F: Next form field - B: Next button ## Automated Testing Integration ### axe-core in tests ```javascript // jest-axe import { axe, toHaveNoViolations } from 'jest-axe'; expect.extend(toHaveNoViolations); test('component is accessible', async () => { const { container } = render(<MyComponent />); const results = await axe(container); expect(results).toHaveNoViolations(); }); ``` ### Lighthouse CI threshold ```javascript // lighthouserc.js module.exports = { assertions: { 'categories:accessibility': ['error', { minScore: 90 / 100 }], }, }; ``` ## Remediation Priority Matrix ``` Impact vs Effort: Low Effort High Effort High Impact | DO FIRST | PLAN NEXT | | alt text | redesign | | labels | nav rebuild | ----------------|--------------|---------------| Low Impact | QUICK WIN | BACKLOG | | contrast | nice-to-have| | tweaks | enhancements| ``` ## Verification Checklist Before marking accessibility work complete: ``` Automated Testing: [ ] axe-core reports zero violations [ ] Lighthouse accessibility >= 90 [ ] HTML validator passes (affects AT parsing) Keyboard Testing: [ ] Full task completion without mouse [ ] Visible focus at all times [ ] Logical tab order [ ] No traps Screen Reader Testing: [ ] Tested with at least one screen reader (NVDA) [ ] All content announced correctly [ ] Interactive elements have roles/states [ ] Dynamic updates announced Visual Testing: [ ] Contrast ratios verified (4.5:1 minimum) [ ] Works at 200% zoom [ ] No information conveyed by color alone [ ] Respects prefers-reduced-motion ```
--- name: accessibility-expert description: Tests and remediates accessibility issues for WCAG compliance and assistive technology compatibility. Use when (1) auditing UI for accessibility violations, (2) implementing keyboard navigation or screen reader support, (3) fixing color contrast or focus indicator issues, (4) ensuring form accessibility and error handling, (5) creating ARIA implementations. --- # Accessibility Testing and Remediation ## Configuration - **WCAG Level**: AA - **Target Component**: Application - **Compliance Standard**: WCAG 2.1 - **Testing Scope**: full-audit - **Screen Reader**: NVDA ## WCAG 2.1 Quick Reference ### Compliance Levels | Level | Requirement | Common Issues | |-------|-------------|---------------| | A | Minimum baseline | Missing alt text, no keyboard access, missing form labels | | AA | Standard target | Contrast < 4.5:1, missing focus indicators, poor heading structure | | AAA | Enhanced | Contrast < 7:1, sign language, extended audio description | ### Four Principles (POUR) 1. **Perceivable**: Content available to senses (alt text, captions, contrast) 2. **Operable**: UI navigable by all input methods (keyboard, touch, voice) 3. **Understandable**: Content and UI predictable and readable 4. **Robust**: Works with current and future assistive technologies ## Violation Severity Matrix ``` CRITICAL (fix immediately): - No keyboard access to interactive elements - Missing form labels - Images without alt text - Auto-playing audio without controls - Keyboard traps HIGH (fix before release): - Contrast ratio below 4.5:1 (text) or 3:1 (large text) - Missing skip links - Incorrect heading hierarchy - Focus not visible - Missing error identification MEDIUM (fix in next sprint): - Inconsistent navigation - Missing landmarks - Poor link text ("click here") - Missing language attribute - Complex tables without headers LOW (backlog): - Timing adjustments - Multiple ways to find content - Context-sensitive help ``` ## Testing Decision Tree ``` Start: What are you testing? | +-- New Component | +-- Has interactive elements? --> Keyboard Navigation Checklist | +-- Has text content? --> Check contrast + heading structure | +-- Has images? --> Verify alt text appropriateness | +-- Has forms? --> Form Accessibility Checklist | +-- Existing Page/Feature | +-- Run automated scan first (axe-core, Lighthouse) | +-- Manual keyboard walkthrough | +-- Screen reader verification | +-- Color contrast spot-check | +-- Third-party Widget +-- Check ARIA implementation +-- Verify keyboard support +-- Test with screen reader +-- Document limitations ``` ## Keyboard Navigation Checklist ```markdown [ ] All interactive elements reachable via Tab [ ] Tab order follows visual/logical flow [ ] Focus indicator visible (2px+ outline, 3:1 contrast) [ ] No keyboard traps (can Tab out of all elements) [ ] Skip link as first focusable element [ ] Enter activates buttons and links [ ] Space activates checkboxes and buttons [ ] Arrow keys navigate within components (tabs, menus, radio groups) [ ] Escape closes modals and dropdowns [ ] Modals trap focus until dismissed ``` ## Screen Reader Testing Patterns ### Essential Announcements to Verify ``` Interactive Elements: Button: "[label], button" Link: "[text], link" Checkbox: "[label], checkbox, [checked/unchecked]" Radio: "[label], radio button, [selected], [position] of [total]" Combobox: "[label], combobox, [collapsed/expanded]" Dynamic Content: Loading: Use aria-busy="true" on container Status: Use role="status" for non-critical updates Alert: Use role="alert" for critical messages Live regions: aria-live="polite" Forms: Required: "required" announced with label Invalid: "invalid entry" with error message Instructions: Announced with label via aria-describedby ``` ### Testing Sequence 1. Navigate entire page with Tab key, listening to announcements 2. Test headings navigation (H key in screen reader) 3. Test landmark navigation (D key / rotor) 4. Test tables (T key, arrow keys within table) 5. Test forms (F key, complete form submission) 6. Test dynamic content updates (verify live regions) ## Color Contrast Requirements | Text Type | Minimum Ratio | Enhanced (AAA) | |-----------|---------------|----------------| | Normal text (<18pt) | 4.5:1 | 7:1 | | Large text (>=18pt or 14pt bold) | 3:1 | 4.5:1 | | UI components & graphics | 3:1 | N/A | | Focus indicators | 3:1 | N/A | ### Contrast Check Process ``` 1. Identify all foreground/background color pairs 2. Calculate contrast ratio: (L1 + 0.05) / (L2 + 0.05) where L1 = lighter luminance, L2 = darker luminance 3. Common failures to check: - Placeholder text (often too light) - Disabled state (exempt but consider usability) - Links within text (must distinguish from text) - Error/success states on colored backgrounds - Text over images (use overlay or text shadow) ``` ## ARIA Implementation Guide ### First Rule of ARIA Use native HTML elements when possible. ARIA is for custom widgets only. ```html <!-- WRONG: ARIA on native element --> <div role="button" tabindex="0">Submit</div> <!-- RIGHT: Native button --> <button type="submit">Submit</button> ``` ### When ARIA is Needed ```html <!-- Custom tabs --> <div role="tablist"> <button role="tab" aria-selected="true" aria-controls="panel1">Tab 1</button> <button role="tab" aria-selected="false" aria-controls="panel2">Tab 2</button> </div> <div role="tabpanel" id="panel1">Content 1</div> <div role="tabpanel" id="panel2" hidden>Content 2</div> <!-- Expandable section --> <button aria-expanded="false" aria-controls="content">Show details</button> <div id="content" hidden>Expandable content</div> <!-- Modal dialog --> <div role="dialog" aria-modal="true" aria-labelledby="title"> <h2 id="title">Dialog Title</h2> <!-- content --> </div> <!-- Live region for dynamic updates --> <div aria-live="polite" aria-atomic="true"> <!-- Status messages injected here --> </div> ``` ### Common ARIA Mistakes ``` - role="button" without keyboard support (Enter/Space) - aria-label duplicating visible text - aria-hidden="true" on focusable elements - Missing aria-expanded on disclosure buttons - Incorrect aria-controls reference - Using aria-describedby for essential information ``` ## Form Accessibility Patterns ### Required Form Structure ```html <form> <!-- Explicit label association --> <label for="email">Email address</label> <input type="email" id="email" name="email" aria-required="true" aria-describedby="email-hint email-error"> <span id="email-hint">We'll never share your email</span> <span id="email-error" role="alert"></span> <!-- Group related fields --> <fieldset> <legend>Shipping address</legend> <!-- address fields --> </fieldset> <!-- Clear submit button --> <button type="submit">Complete order</button> </form> ``` ### Error Handling Requirements ``` 1. Identify the field in error (highlight + icon) 2. Describe the error in text (not just color) 3. Associate error with field (aria-describedby) 4. Announce error to screen readers (role="alert") 5. Move focus to first error on submit failure 6. Provide correction suggestions when possible ``` ## Mobile Accessibility Checklist ```markdown Touch Targets: [ ] Minimum 44x44 CSS pixels [ ] Adequate spacing between targets (8px+) [ ] Touch action not dependent on gesture path Gestures: [ ] Alternative to multi-finger gestures [ ] Alternative to path-based gestures (swipe) [ ] Motion-based actions have alternatives Screen Reader (iOS/Android): [ ] accessibilityLabel set for images and icons [ ] accessibilityHint for complex interactions [ ] accessibilityRole matches element behavior [ ] Focus order follows visual layout ``` ## Automated Testing Integration ### Pre-commit Hook ```bash #!/bin/bash # Run axe-core on changed files npx axe-core-cli --exit src/**/*.html # Check for common issues grep -r "onClick.*div\|onClick.*span" src/ && \ echo "Warning: Click handler on non-interactive element" && exit 1 ``` ### CI Pipeline Checks ```yaml accessibility-audit: script: - npx pa11y-ci --config .pa11yci.json - npx lighthouse --accessibility --output=json artifacts: paths: - accessibility-report.json rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' ``` ### Minimum CI Thresholds ``` axe-core: 0 critical violations, 0 serious violations Lighthouse accessibility: >= 90 pa11y: 0 errors (warnings acceptable) ``` ## Remediation Priority Framework ``` Priority 1 (This Sprint): - Blocks user task completion - Legal compliance risk - Affects many users Priority 2 (Next Sprint): - Degrades experience significantly - Automated tools flag as error - Violates AA requirement Priority 3 (Backlog): - Minor inconvenience - Violates AAA only - Affects edge cases Priority 4 (Enhancement): - Improves usability for all - Best practice, not requirement - Future-proofing ``` ## Verification Checklist Before marking accessibility work complete: ```markdown Automated: [ ] axe-core: 0 violations [ ] Lighthouse accessibility: 90+ [ ] HTML validation passes [ ] No console accessibility warnings Keyboard: [ ] Complete all tasks keyboard-only [ ] Focus visible at all times [ ] Tab order logical [ ] No keyboard traps Screen Reader (test with at least one): [ ] All content announced [ ] Interactive elements labeled [ ] Errors and updates announced [ ] Navigation efficient Visual: [ ] All text passes contrast [ ] UI components pass contrast [ ] Works at 200% zoom [ ] Works in high contrast mode [ ] No seizure-inducing flashing Forms: [ ] All fields labeled [ ] Errors identifiable [ ] Required fields indicated [ ] Instructions available ``` ## Documentation Template ```markdown # Accessibility Statement ## Conformance Status This [website/application] is [fully/partially] conformant with WCAG 2.1 Level AA. ## Known Limitations | Feature | Issue | Workaround | Timeline | |---------|-------|------------|----------| | [Feature] | [Description] | [Alternative] | [Fix date] | ## Assistive Technology Tested - NVDA [version] with Firefox [version] - VoiceOver with Safari [version] - JAWS [version] with Chrome [version] ## Feedback Contact [email] for accessibility issues. Last updated: [date] ```
--- name: aws-cloud-expert description: | Designs and implements AWS cloud architectures with focus on Well-Architected Framework, cost optimization, and security. Use when: 1. Designing or reviewing AWS infrastructure architecture 2. Migrating workloads to AWS or between AWS services 3. Optimizing AWS costs (right-sizing, Reserved Instances, Savings Plans) 4. Implementing AWS security, compliance, or disaster recovery 5. Troubleshooting AWS service issues or performance problems --- **Region**: us-east-1 **Secondary Region**: us-west-2 **Environment**: production **VPC CIDR**: 10.0.0.0/16 **Instance Type**: t3.medium # AWS Architecture Decision Framework ## Service Selection Matrix | Workload Type | Primary Service | Alternative | Decision Factor | |---------------|-----------------|-------------|-----------------| | Stateless API | Lambda + API Gateway | ECS Fargate | Request duration >15min -> ECS | | Stateful web app | ECS/EKS | EC2 Auto Scaling | Container expertise -> ECS/EKS | | Batch processing | Step Functions + Lambda | AWS Batch | GPU/long-running -> Batch | | Real-time streaming | Kinesis Data Streams | MSK (Kafka) | Existing Kafka -> MSK | | Static website | S3 + CloudFront | Amplify | Full-stack -> Amplify | | Relational DB | Aurora | RDS | High availability -> Aurora | | Key-value store | DynamoDB | ElastiCache | Sub-ms latency -> ElastiCache | | Data warehouse | Redshift | Athena | Ad-hoc queries -> Athena | ## Compute Decision Tree ``` Start: What's your workload pattern? | +-> Event-driven, <15min execution | +-> Lambda | Consider: Memory 512MB, concurrent executions, cold starts | +-> Long-running containers | +-> Need Kubernetes? | +-> Yes: EKS (managed) or self-managed K8s on EC2 | +-> No: ECS Fargate (serverless) or ECS EC2 (cost optimization) | +-> GPU/HPC/Custom AMI required | +-> EC2 with appropriate instance family | g4dn/p4d (ML), c6i (compute), r6i (memory), i3en (storage) | +-> Batch jobs, queue-based +-> AWS Batch with Spot instances (up to 90% savings) ``` ## Networking Architecture ### VPC Design Pattern ``` production VPC (10.0.0.0/16) | +-- Public Subnets (10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24) | +-- ALB, NAT Gateways, Bastion (if needed) | +-- Private Subnets (10.0.10.0/24, 10.0.11.0/24, 10.0.12.0/24) | +-- Application tier (ECS, EC2, Lambda VPC) | +-- Data Subnets (10.0.20.0/24, 10.0.21.0/24, 10.0.22.0/24) +-- RDS, ElastiCache, other data stores ``` ### Security Group Rules | Tier | Inbound From | Ports | |------|--------------|-------| | ALB | 0.0.0.0/0 | 443 | | App | ALB SG | 8080 | | Data | App SG | 5432 | ### VPC Endpoints (Cost Optimization) Always create for high-traffic services: - S3 Gateway Endpoint (free) - DynamoDB Gateway Endpoint (free) - Interface Endpoints: ECR, Secrets Manager, SSM, CloudWatch Logs ## Cost Optimization Checklist ### Immediate Actions (Week 1) - [ ] Enable Cost Explorer and set up budgets with alerts - [ ] Review and terminate unused resources (Cost Explorer idle resources report) - [ ] Right-size EC2 instances (AWS Compute Optimizer recommendations) - [ ] Delete unattached EBS volumes and old snapshots - [ ] Review NAT Gateway data processing charges ### Cost Estimation Quick Reference | Resource | Monthly Cost Estimate | |----------|----------------------| | t3.medium (on-demand) | ~$30 | | t3.medium (1yr RI) | ~$18 | | Lambda (1M invocations, 1s, 512MB) | ~$8 | | RDS db.t3.medium (Multi-AZ) | ~$100 | | Aurora Serverless v2 (8 ACU avg) | ~$350 | | NAT Gateway + 100GB data | ~$50 | | S3 (1TB Standard) | ~$23 | | CloudFront (1TB transfer) | ~$85 | ## Security Implementation ### IAM Best Practices ``` Principle: Least privilege with explicit deny 1. Use IAM roles (not users) for applications 2. Require MFA for all human users 3. Use permission boundaries for delegated admin 4. Implement SCPs at Organization level 5. Regular access reviews with IAM Access Analyzer ``` ### Example IAM Policy Pattern ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3BucketAccess", "Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*", "Condition": { "StringEquals": {"aws:PrincipalTag/Environment": "production"} } } ] } ``` ### Security Checklist - [ ] Enable CloudTrail in all regions with log file validation - [ ] Configure AWS Config rules for compliance monitoring - [ ] Enable GuardDuty for threat detection - [ ] Use Secrets Manager or Parameter Store for secrets (not env vars) - [ ] Enable encryption at rest for all data stores - [ ] Enforce TLS 1.2+ for all connections - [ ] Implement VPC Flow Logs for network monitoring - [ ] Use Security Hub for centralized security view ## High Availability Patterns ### Multi-AZ Architecture (99.99% target) ``` Region: us-east-1 | +-- AZ-a +-- AZ-b +-- AZ-c | | | ALB (active) ALB (active) ALB (active) | | | ECS Tasks (2) ECS Tasks (2) ECS Tasks (2) | | | Aurora Writer Aurora Reader Aurora Reader ``` ### Multi-Region Architecture (99.999% target) ``` Primary: us-east-1 Secondary: us-west-2 | | Route 53 (failover routing) Route 53 (health checks) | | CloudFront CloudFront | | Full stack Full stack (passive or active) | | Aurora Global Database -------> Aurora Read Replica (async replication) ``` ### RTO/RPO Decision Matrix | Tier | RTO Target | RPO Target | Strategy | |------|------------|------------|----------| | Tier 1 (Critical) | <15 min | <1 min | Multi-region active-active | | Tier 2 (Important) | <1 hour | <15 min | Multi-region active-passive | | Tier 3 (Standard) | <4 hours | <1 hour | Multi-AZ with cross-region backup | | Tier 4 (Non-critical) | <24 hours | <24 hours | Single region, backup/restore | ## Monitoring and Observability ### CloudWatch Implementation | Metric Type | Service | Key Metrics | |-------------|---------|-------------| | Compute | EC2/ECS | CPUUtilization, MemoryUtilization, NetworkIn/Out | | Database | RDS/Aurora | DatabaseConnections, ReadLatency, WriteLatency | | Serverless | Lambda | Duration, Errors, Throttles, ConcurrentExecutions | | API | API Gateway | 4XXError, 5XXError, Latency, Count | | Storage | S3 | BucketSizeBytes, NumberOfObjects, 4xxErrors | ### Alerting Thresholds | Resource | Warning | Critical | Action | |----------|---------|----------|--------| | EC2 CPU | >70% 5min | >90% 5min | Scale out, investigate | | RDS CPU | >80% 5min | >95% 5min | Scale up, query optimization | | Lambda errors | >1% | >5% | Investigate, rollback | | ALB 5xx | >0.1% | >1% | Investigate backend | | DynamoDB throttle | Any | Sustained | Increase capacity | ## Verification Checklist ### Before Production Launch - [ ] Well-Architected Review completed (all 6 pillars) - [ ] Load testing completed with expected peak + 50% headroom - [ ] Disaster recovery tested with documented RTO/RPO - [ ] Security assessment passed (penetration test if required) - [ ] Compliance controls verified (if applicable) - [ ] Monitoring dashboards and alerts configured - [ ] Runbooks documented for common operations - [ ] Cost projection validated and budgets set - [ ] Tagging strategy implemented for all resources - [ ] Backup and restore procedures tested
--- name: ast-code-analysis-superpower description: AST-based code pattern analysis using ast-grep for security, performance, and structural issues. Use when (1) reviewing code for security vulnerabilities, (2) analyzing React hook dependencies or performance patterns, (3) detecting structural anti-patterns across large codebases, (4) needing systematic pattern matching beyond manual inspection. --- # AST-Grep Code Analysis AST pattern matching identifies code issues through structural recognition rather than line-by-line reading. Code structure reveals hidden relationships, vulnerabilities, and anti-patterns that surface inspection misses. ## Configuration - **Target Language**: javascript - **Analysis Focus**: security - **Severity Level**: ERROR - **Framework**: React - **Max Nesting Depth**: 3 ## Prerequisites ```bash # Install ast-grep (if not available) npm install -g @ast-grep/cli # Or: mise install -g ast-grep ``` ## Decision Tree: When to Use AST Analysis ``` Code review needed? | +-- Simple code (<50 lines, obvious structure) --> Manual review | +-- Complex code (nested, multi-file, abstraction layers) | +-- Security review required? --> Use security patterns +-- Performance analysis? --> Use performance patterns +-- Structural quality? --> Use structure patterns +-- Cross-file patterns? --> Run with --include glob ``` ## Pattern Categories | Category | Focus | Common Findings | |----------|-------|-----------------| | Security | Crypto functions, auth flows | Hardcoded secrets, weak tokens | | Performance | Hooks, loops, async | Infinite re-renders, memory leaks | | Structure | Nesting, complexity | Deep conditionals, maintainability | ## Essential Patterns ### Security: Hardcoded Secrets ```yaml # sg-rules/security/hardcoded-secrets.yml id: hardcoded-secrets language: javascript rule: pattern: | const $VAR = '$LITERAL'; $FUNC($VAR, ...) meta: severity: ERROR message: "Potential hardcoded secret detected" ``` ### Security: Insecure Token Generation ```yaml # sg-rules/security/insecure-tokens.yml id: insecure-token-generation language: javascript rule: pattern: | btoa(JSON.stringify($OBJ) + '.' + $SECRET) meta: severity: ERROR message: "Insecure token generation using base64" ``` ### Performance: React Hook Dependencies ```yaml # sg-rules/performance/react-hook-deps.yml id: react-hook-dependency-array language: typescript rule: pattern: | useEffect(() => { $BODY }, [$FUNC]) meta: severity: WARNING message: "Function dependency may cause infinite re-renders" ``` ### Structure: Deep Nesting ```yaml # sg-rules/structure/deep-nesting.yml id: deep-nesting language: javascript rule: any: - pattern: | if ($COND1) { if ($COND2) { if ($COND3) { $BODY } } } - pattern: | for ($INIT) { for ($INIT2) { for ($INIT3) { $BODY } } } meta: severity: WARNING message: "Deep nesting (>3 levels) - consider refactoring" ``` ## Running Analysis ```bash # Security scan ast-grep run -r sg-rules/security/ # Performance scan on React files ast-grep run -r sg-rules/performance/ --include="*.tsx,*.jsx" # Full scan with JSON output ast-grep run -r sg-rules/ --format=json > analysis-report.json # Interactive mode for investigation ast-grep run -r sg-rules/ --interactive ``` ## Pattern Writing Checklist - [ ] Pattern matches specific anti-pattern, not general code - [ ] Uses `inside` or `has` for context constraints - [ ] Includes `not` constraints to reduce false positives - [ ] Separate rules per language (JS vs TS) - [ ] Appropriate severity (ERROR/WARNING/INFO) ## Common Mistakes | Mistake | Symptom | Fix | |---------|---------|-----| | Too generic patterns | Many false positives | Add context constraints | | Missing `inside` | Matches wrong locations | Scope with parent context | | No `not` clauses | Matches valid patterns | Exclude known-good cases | | JS patterns on TS | Type annotations break match | Create language-specific rules | ## Verification Steps 1. **Test pattern accuracy**: Run on known-vulnerable code samples 2. **Check false positive rate**: Review first 10 matches manually 3. **Validate severity**: Confirm ERROR-level findings are actionable 4. **Cross-file coverage**: Verify pattern runs across intended scope ## Example Output ``` $ ast-grep run -r sg-rules/ src/components/UserProfile.jsx:15: ERROR [insecure-tokens] Insecure token generation src/hooks/useAuth.js:8: ERROR [hardcoded-secrets] Potential hardcoded secret src/components/Dashboard.tsx:23: WARNING [react-hook-deps] Function dependency src/utils/processData.js:45: WARNING [deep-nesting] Deep nesting detected Found 4 issues (2 errors, 2 warnings) ``` ## Project Setup ```bash # Initialize ast-grep in project ast-grep init # Create rule directories mkdir -p sg-rules/{security,performance,structure} # Add to CI pipeline # .github/workflows/lint.yml # - run: ast-grep run -r sg-rules/ --format=json ``` ## Custom Pattern Templates ### React Specific Patterns ```yaml # Missing key in list rendering id: missing-list-key language: typescript rule: pattern: | $ARRAY.map(($ITEM) => <$COMPONENT $$$PROPS />) constraints: $PROPS: not: has: pattern: 'key={$_}' meta: severity: WARNING message: "Missing key prop in list rendering" ``` ### Async/Await Patterns ```yaml # Missing error handling in async id: unhandled-async language: javascript rule: pattern: | async function $NAME($$$) { $$$BODY } constraints: $BODY: not: has: pattern: 'try { $$$ } catch' meta: severity: WARNING message: "Async function without try-catch error handling" ``` ## Integration with CI/CD ```yaml # GitHub Actions example name: AST Analysis on: [push, pull_request] jobs: analyze: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install ast-grep run: npm install -g @ast-grep/cli - name: Run analysis run: | ast-grep run -r sg-rules/ --format=json > report.json if grep -q '"severity": "ERROR"' report.json; then echo "Critical issues found!" exit 1 fi ```
