atlas-full

# Atlas Full Workflow ## When to Use This Skill **Perfect for (complex tasks, ~5% of work):** - Major features (6+ files affected) - New modules or services - Security-critical changes - Cross-platform features requiring coordination - Epic-level work requiring formal requirements - Architectural changes affecting multiple systems - Features requiring comprehensive testing strategy **Time estimate**: 2-4 hours **Success criteria**: - 100% of acceptance criteria met - Zero defects in production first week - Complete documentation and evidence - Full test coverage for critical paths - Security audit passed (if applicable) - Cross-platform validation complete (if applicable) ## The 9 Phases ``` Phase 1: Research → Deep exploration, feasibility analysis Phase 2: Story Creation → Formal requirements, acceptance criteria Phase 3: Planning → Technical design, architecture Phase 4: Adversarial Review → Security audit, edge case analysis Phase 5: Implementation → Parallel coding, incremental builds Phase 6: Testing → Comprehensive validation, all platforms Phase 7: Validation → Acceptance criteria verification Phase 8: Clean-up → Documentation, artifacts, debt log Phase 9: Deployment → Full quality gates, staged rollout ``` --- ## Phase 1: Research **Goal**: Deep understanding of requirements, feasibility, and technical landscape. **Time allocation**: 20-30 minutes ### Steps: 1. **Define the problem space** - What problem are we solving? - Who are the users? - What are the business requirements? - What are the technical constraints? 2. **Explore current implementation** ```bash # Find all related code grep -r "related_feature" src/ # Find similar patterns find src/ -name "*similar*" # Check git history for similar features git log --grep="similar feature" --oneline ``` 3. **Research dependencies and integrations** - What external services/APIs are involved? - What internal modules will be affected? - What platform-specific considerations exist? - What are the data flow implications? 4. **Identify risks and constraints** - Technical risks (performance, compatibility, security) - Timeline constraints - Resource constraints - Platform limitations 5. **Evaluate alternatives** - What are different approaches to solve this? - What are the trade-offs? - What's the recommended approach? ### Research Checklist: **Problem Understanding:** - [ ] Clear problem statement - [ ] User stories identified - [ ] Success metrics defined - [ ] Constraints documented **Technical Research:** - [ ] Current implementation mapped - [ ] Similar patterns found - [ ] Dependencies identified - [ ] Platform considerations noted **Risk Analysis:** - [ ] Technical risks listed - [ ] Security implications assessed - [ ] Performance implications considered - [ ] Migration/rollback strategy outlined **Feasibility:** - [ ] Technically feasible - [ ] Timeline realistic - [ ] Resources available - [ ] No blockers identified ### Research Output Template: ```markdown ## Research Findings: [Feature Name] ### Problem Statement: [Clear description of what we're solving] ### Users Affected: - [User type 1]: [how they benefit] - [User type 2]: [how they benefit] ### Technical Approach: [High-level approach, alternatives considered] ### Files to Create/Modify: - /path/to/new/file.js - [purpose] - /path/to/existing/file.js - [what changes] - /path/to/test/file.test.js - [test coverage] ### Dependencies: - External: [external packages, APIs] - Internal: [internal modules, services] ### Platform Considerations: - **Platform A**: [specific notes] - **Platform B**: [specific notes] - **Platform C**: [specific notes] ### Risks: 1. [Risk 1] - Mitigation: [strategy] 2. [Risk 2] - Mitigation: [strategy] ### Success Metrics: - [Metric 1]: [target] - [Metric 2]: [target] ### Timeline Estimate: - Research: [time] - Implementation: [time] - Testing: [time] - Total: [time] ``` --- ## Phase 2: Story Creation **Goal**: Create formal user stories with acceptance criteria and success metrics. **Time allocation**: 15-20 minutes ### Steps: 1. **Write user stories** - Use standard format: "As a [user], I want [goal], so that [benefit]" - Break down complex features into multiple stories - Prioritize stories (must-have, should-have, nice-to-have) 2. **Define acceptance criteria** - Specific, measurable, testable criteria - Cover happy path and edge cases - Include performance requirements - Include platform-specific criteria (if applicable) 3. **Set success metrics** - How will we measure success? - What are the targets? - How will we collect data? 4. **Create testing scenarios** - Manual testing checklist - Automated test requirements - Cross-platform testing plan (if applicable) ### Story Template: Use the template in `resources/story-template.md` for consistent formatting. ### Story Validation Checklist: - [ ] User story follows "As a...I want...So that" format - [ ] Acceptance criteria are specific and testable - [ ] Edge cases covered - [ ] Platform-specific requirements included (if applicable) - [ ] Success metrics defined with targets - [ ] Testing scenarios documented - [ ] Dependencies identified - [ ] Risks documented with mitigation --- ## Phase 3: Planning **Goal**: Create detailed technical design and implementation plan. **Time allocation**: 20-30 minutes ### Steps: 1. **Architecture design** - How will components interact? - What's the data flow? - Where does state live? - How does it integrate with existing systems? 2. **File-by-file implementation plan** - What files to create? - What files to modify? - What changes in each file? - What order to implement? 3. **Data schema design** - What new fields/structures? - How to migrate existing data? - How does synchronization handle it (if applicable)? - What validations needed? 4. **Testing strategy** - Unit tests for each module - Integration tests for workflows - Platform-specific tests (if applicable) - Performance tests 5. **Rollout strategy** - Phased rollout plan - Feature flags needed? - Rollback plan - Monitoring strategy ### Planning Template: ```markdown ## Implementation Plan: [Feature Name] ### Architecture #### Component Structure: ``` [Describe component hierarchy or architecture] ``` #### Data Flow: ``` User Action → Component → Service → State → UI Update [Detailed flow description] ``` #### State Management: - **State location**: [where state lives] - **State shape**: [schema] - **Update methods**: [new methods needed] ### File-by-File Plan #### New Files: 1. **/src/services/newService.js** - Purpose: [what it does] - Functions: - `function1()`: [description] - `function2()`: [description] - Dependencies: [what it imports] 2. **/src/components/NewComponent.js** - Purpose: [what it does] - Props: [prop schema] - State: [local state] #### Modified Files: 1. **/src/existing/file.js** - Add: [new functionality] - Modify: [existing behavior] #### Test Files: 1. **/tests/services/newService.test.js** - Test coverage: - [ ] Unit tests for all functions - [ ] Edge cases - [ ] Error handling ### Data Schema #### New Fields: ```javascript entity: { // ... existing fields newField: { type: [type], required: [boolean], default: [default value], validation: [validation rules] } } ``` #### Migration Strategy: ```javascript // How to handle existing data const migrateOldData = (item) => { return { ...item, newField: item.legacyField || defaultValue } } ``` ### Testing Strategy #### Unit Tests: - [ ] `newService.function1()` - happy path - [ ] `newService.function1()` - error cases - [ ] `newService.function2()` - edge cases #### Integration Tests: - [ ] Full workflow: [user action → result] - [ ] Error recovery - [ ] Network failure handling #### Performance Tests: - [ ] Load time < [threshold] - [ ] Memory usage < [threshold] - [ ] No memory leaks ### Implementation Order **Iteration 1: Core functionality** 1. Create newService.js with basic functions 2. Add tests for newService 3. Add state management 4. Test integration **Iteration 2: UI integration** 1. Create new components 2. Integrate with existing UI 3. Test user interactions **Iteration 3: Edge cases** 1. Add error handling 2. Add loading states 3. Test all edge cases **Iteration 4: Polish** 1. Performance optimization 2. Accessibility improvements 3. Documentation 4. Final testing ### Rollout Strategy **Development Testing**: - Deploy to development environment - Test all functionality - Validate performance - Fix any issues **Staging/Internal Testing**: - Deploy to staging environment - Internal team testing - Gather feedback - Refine based on feedback **Beta/Canary Testing** (if applicable): - Deploy to subset of users (feature flag) - Monitor usage metrics - Monitor error rates - Collect user feedback **Production Release**: - Gradual rollout (if possible) - Monitor success metrics - Monitor error rates - Rollback plan ready ### Rollback Plan If critical issues arise: 1. Disable feature flag (immediate) 2. Or: Revert to previous deployment 3. Notify users if data affected 4. Fix issues in development 5. Re-test before re-enabling ### Monitoring **Metrics to track**: - Success rate - Error rate - Performance (load time, memory) - User adoption - User engagement **Alerts**: - Error rate > [threshold]% - Performance degradation > [threshold]% - Crash rate increase ``` ### Planning Validation Checklist: - [ ] Architecture clearly defined - [ ] File-by-file plan complete - [ ] Implementation order logical - [ ] Testing strategy comprehensive - [ ] Rollout strategy defined - [ ] Rollback plan ready - [ ] Monitoring plan in place --- ## Phase 4: Adversarial Review **Goal**: Security audit, edge case analysis, and critical evaluation. **Time allocation**: 15-20 minutes ### Steps: 1. **Security audit** - Use checklist in `resources/adversarial-checklist.md` - Identify vulnerabilities - Assess attack vectors - Validate data security - Check authentication/authorization 2. **Edge case analysis** - What can go wrong? - What assumptions might break? - What happens under load? - What if external dependencies fail? 3. **Performance analysis** - Memory usage implications - Network bandwidth usage - Resource utilization - Startup time impact 4. **Cross-platform compatibility** (if applicable) - Platform-specific issues? - Version compatibility? - Consistent UX across platforms? 5. **Maintainability review** - Code complexity reasonable? - Test coverage sufficient? - Documentation clear? - Technical debt acceptable? ### Adversarial Review Checklist: Use the comprehensive checklist in `resources/adversarial-checklist.md`. ### Adversarial Questions: Ask yourself tough questions: 1. **"What's the worst that could happen?"** - User loses data? - App crashes? - Security breach? - How do we prevent it? 2. **"What if this becomes popular?"** - Can it scale? - Cost implications? - Performance under load? 3. **"What if external service fails?"** - Service down? - Network offline? - API timeout? - Graceful degradation? 4. **"What if user does unexpected thing?"** - Spams button? - Enters invalid data? - Uses old app version? 5. **"What will break in 6 months?"** - Technical debt? - Deprecated APIs? - Maintenance burden? - Future compatibility? ### Red Flags: **Stop and reconsider if:** - 🚩 Security concerns unaddressed - 🚩 Performance implications unclear - 🚩 Rollback plan not feasible - 🚩 Testing strategy inadequate - 🚩 Technical debt too high - 🚩 Edge cases not handled ### Adversarial Review Output: ```markdown ## Adversarial Review: [Feature Name] ### Security Assessment: ✅ PASS / ⚠️ CONCERNS / ❌ FAIL [Details of security review] **Concerns found**: 1. [Concern 1] - Mitigation: [plan] 2. [Concern 2] - Mitigation: [plan] ### Edge Case Analysis: ✅ COVERED / ⚠️ PARTIAL / ❌ GAPS [Details of edge case analysis] **Edge cases to address**: 1. [Case 1] - Plan: [how to handle] 2. [Case 2] - Plan: [how to handle] ### Performance Assessment: ✅ GOOD / ⚠️ ACCEPTABLE / ❌ CONCERNING [Details of performance analysis] **Optimizations needed**: 1. [Optimization 1] 2. [Optimization 2] ### Maintainability: ✅ GOOD / ⚠️ ACCEPTABLE / ❌ HIGH DEBT [Details of maintainability review] **Debt to address**: 1. [Debt item 1] 2. [Debt item 2] ### Overall Verdict: ✅ PROCEED / ⚠️ PROCEED WITH CAUTION / ❌ REVISE PLAN **Blocking issues** (must fix before proceeding): 1. [Issue 1]