Initial commit
This commit is contained in:
@@ -0,0 +1,64 @@
|
||||
# Example: Architecture Diagram
|
||||
|
||||
## Scenario
|
||||
|
||||
A user asks: "Show me how our e-commerce platform components are connected."
|
||||
|
||||
## Generated Diagram
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ E-COMMERCE PLATFORM ARCHITECTURE │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌───────────────────┐ ┌───────────────────┐
|
||||
│ Web Frontend │ │ Mobile Frontend │
|
||||
├───────────────────┤ ├───────────────────┤
|
||||
│ • React SPA │ │ • React Native │
|
||||
│ • Redux state │ │ • Offline sync │
|
||||
│ • Tailwind CSS │ │ • Push notifs │
|
||||
└───────────────────┘ └───────────────────┘
|
||||
│ │
|
||||
└───────────────────┬───────────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────┐
|
||||
│ API Gateway │
|
||||
├───────────────────┤
|
||||
│ • Rate limiting │
|
||||
│ • Auth validation │
|
||||
│ • Request routing │
|
||||
└───────────────────┘
|
||||
│
|
||||
┌───────────────────┼───────────────────┐
|
||||
▼ ▼ ▼
|
||||
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
|
||||
│ Auth Service │ │ Product Service │ │ Order Service │
|
||||
├─────────────────┤ ├─────────────────┤ ├─────────────────┤
|
||||
│ • JWT tokens │ │ • Catalog CRUD │ │ • Cart mgmt │
|
||||
│ • OAuth 2.0 │ │ • Search/filter │ │ • Checkout flow │
|
||||
│ • Session mgmt │ │ • Inventory │ │ • Payment proc │
|
||||
└─────────────────┘ └─────────────────┘ └─────────────────┘
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
|
||||
│ Users DB │ │ Products DB │ │ Orders DB │
|
||||
│ (PostgreSQL) │ │ (PostgreSQL) │ │ (PostgreSQL) │
|
||||
└─────────────────┘ └─────────────────┘ └─────────────────┘
|
||||
```
|
||||
|
||||
## Explanation
|
||||
|
||||
This architecture diagram shows the three-tier structure of the e-commerce platform:
|
||||
|
||||
1. **Presentation Layer**: Web and mobile frontends
|
||||
2. **API Layer**: Gateway with routing to microservices
|
||||
3. **Data Layer**: Dedicated databases per service
|
||||
|
||||
The vertical flow clearly shows how requests travel from clients through the gateway to specific services and their databases.
|
||||
|
||||
## Usage Suggestions
|
||||
|
||||
- Include in architecture documentation
|
||||
- Add to README for new developer onboarding
|
||||
- Reference in technical design documents
|
||||
@@ -0,0 +1,66 @@
|
||||
# Example: Before/After Diagram
|
||||
|
||||
## Scenario
|
||||
|
||||
A user asks: "Show the directory structure before and after our TypeScript migration."
|
||||
|
||||
## Generated Diagram
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ JAVASCRIPT TO TYPESCRIPT MIGRATION │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
BEFORE (JavaScript): AFTER (TypeScript):
|
||||
|
||||
src/ src/
|
||||
├── components/ ├── components/
|
||||
│ ├── Button.js ──► │ ├── Button.tsx ✓
|
||||
│ ├── Button.css ──► │ │ (CSS modules imported)
|
||||
│ ├── Form.js ──► │ ├── Form.tsx ✓
|
||||
│ ├── Form.css ──► │ │ (CSS modules imported)
|
||||
│ └── Modal.js ──► │ └── Modal.tsx ✓
|
||||
├── utils/ ├── utils/
|
||||
│ ├── helpers.js ──► │ ├── helpers.ts ✓
|
||||
│ ├── constants.js ──► │ ├── constants.ts ✓
|
||||
│ └── api.js ──► │ └── api.ts ✓
|
||||
├── hooks/ ├── hooks/
|
||||
│ ├── useAuth.js ──► │ ├── useAuth.ts ✓
|
||||
│ └── useForm.js ──► │ └── useForm.ts ✓
|
||||
├── types/ NEW ├── types/
|
||||
│ │ ├── index.ts ✓
|
||||
│ │ ├── api.d.ts ✓
|
||||
│ │ └── components.d.ts ✓
|
||||
├── App.js ──► ├── App.tsx ✓
|
||||
├── index.js ──► ├── index.tsx ✓
|
||||
└── .eslintrc.js ──► ├── .eslintrc.js (updated)
|
||||
└── tsconfig.json NEW
|
||||
|
||||
Configuration Files:
|
||||
├── package.json ──► ├── package.json (updated deps)
|
||||
├── jest.config.js ──► ├── jest.config.js (ts-jest)
|
||||
└── .babelrc ✗ └── (removed - using tsc)
|
||||
|
||||
Legend:
|
||||
✓ = Conversion complete
|
||||
──► = Transformed/updated
|
||||
✗ = Removed
|
||||
NEW = New file/directory
|
||||
```
|
||||
|
||||
## Explanation
|
||||
|
||||
This before/after diagram shows the complete scope of a TypeScript migration:
|
||||
|
||||
- **File transformations**: .js → .tsx/.ts conversions
|
||||
- **New additions**: types/ directory with type definitions
|
||||
- **Removed files**: Babel config (replaced by TypeScript compiler)
|
||||
- **Updated configs**: ESLint and Jest configurations
|
||||
|
||||
The parallel columns make it easy to trace each file's transformation.
|
||||
|
||||
## Usage Suggestions
|
||||
|
||||
- Include in migration PR description
|
||||
- Add to project README as migration record
|
||||
- Reference in team communication about changes
|
||||
119
skills/ascii-diagram-creator/examples/data-flow-diagram.md
Normal file
119
skills/ascii-diagram-creator/examples/data-flow-diagram.md
Normal file
@@ -0,0 +1,119 @@
|
||||
# Example: Data Flow Diagram
|
||||
|
||||
## Scenario
|
||||
|
||||
A user asks: "Illustrate how user authentication data flows through our system."
|
||||
|
||||
## Generated Diagram
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ USER AUTHENTICATION FLOW │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
┌──────────────┐
|
||||
│ Browser │
|
||||
│ Login Form │
|
||||
└──────────────┘
|
||||
│
|
||||
│ 1. POST /auth/login
|
||||
│ { email, password }
|
||||
▼
|
||||
┌──────────────┐
|
||||
│ API Gateway │
|
||||
│ (Express) │
|
||||
└──────────────┘
|
||||
│
|
||||
│ 2. Route to auth service
|
||||
▼
|
||||
┌──────────────────────────────────────────────────────────────┐
|
||||
│ AUTH SERVICE │
|
||||
├──────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ 3. Validate credentials │
|
||||
│ ┌─────────────┐ │
|
||||
│ │ Hash pwd │──► Compare with stored hash │
|
||||
│ └─────────────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ 4. Query user database │
|
||||
│ ┌─────────────┐ ┌─────────────┐ │
|
||||
│ │ Users DB │────►│ User record │ │
|
||||
│ │ (Postgres) │ │ + roles │ │
|
||||
│ └─────────────┘ └─────────────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ 5. Generate tokens │
|
||||
│ ┌─────────────┐ ┌─────────────┐ │
|
||||
│ │ JWT Access │ │ Refresh │ │
|
||||
│ │ (15 min) │ │ (7 days) │ │
|
||||
│ └─────────────┘ └─────────────┘ │
|
||||
│ │ │ │
|
||||
│ │ ▼ │
|
||||
│ │ 6. Store refresh token │
|
||||
│ │ ┌─────────────┐ │
|
||||
│ │ │ Redis │ │
|
||||
│ │ │ Sessions │ │
|
||||
│ │ └─────────────┘ │
|
||||
│ │ │
|
||||
└────────────┼──────────────────────────────────────────────────┘
|
||||
│
|
||||
│ 7. Return tokens
|
||||
▼
|
||||
┌──────────────┐
|
||||
│ API Gateway │
|
||||
└──────────────┘
|
||||
│
|
||||
│ 8. Set cookies & respond
|
||||
│ { accessToken, user }
|
||||
▼
|
||||
┌──────────────┐
|
||||
│ Browser │
|
||||
│ Store JWT │
|
||||
└──────────────┘
|
||||
│
|
||||
│ 9. Subsequent requests
|
||||
│ Authorization: Bearer <token>
|
||||
▼
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ API Gateway │────►│ Middleware │────►│ Protected │
|
||||
│ │ │ Verify JWT │ │ Resources │
|
||||
└──────────────┘ └──────────────┘ └──────────────┘
|
||||
|
||||
|
||||
TOKEN REFRESH FLOW:
|
||||
|
||||
Access Token Expired
|
||||
│
|
||||
▼
|
||||
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
|
||||
│ Browser │────►│ POST /auth/ │────►│ Redis │
|
||||
│ Refresh Req │ │ refresh │ │ Validate │
|
||||
└──────────────┘ └──────────────┘ └──────────────┘
|
||||
│ │
|
||||
│◄───────────────────┘
|
||||
│ Valid? Issue new tokens
|
||||
▼
|
||||
┌──────────────┐
|
||||
│ New Access │
|
||||
│ Token │
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
## Explanation
|
||||
|
||||
This data flow diagram shows the complete authentication lifecycle:
|
||||
|
||||
1. **Initial login flow**: Steps 1-8 show credential validation and token generation
|
||||
2. **Token storage**: Redis for refresh tokens, browser for access tokens
|
||||
3. **Protected resource access**: JWT verification middleware
|
||||
4. **Token refresh**: Separate flow for getting new access tokens
|
||||
|
||||
The nested structure within the Auth Service box shows internal processing details while maintaining flow clarity.
|
||||
|
||||
## Usage Suggestions
|
||||
|
||||
- Include in security documentation
|
||||
- Add to API documentation for developers
|
||||
- Reference during security audits
|
||||
- Share with new team members during onboarding
|
||||
@@ -0,0 +1,93 @@
|
||||
# Example: Phased Migration Diagram
|
||||
|
||||
## Scenario
|
||||
|
||||
A user asks: "Create a diagram showing our database migration phases with current progress."
|
||||
|
||||
## Generated Diagram
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ DATABASE MIGRATION: MONGODB TO POSTGRESQL │
|
||||
│ Target: Q4 2025 Completion │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
PHASE 1: Schema Design & Setup ✓
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ Status: COMPLETE Duration: 2w │
|
||||
├─────────────────────────────────────────────────────────────────────────┤
|
||||
│ ✓ Analyze MongoDB collections and relationships │
|
||||
│ ✓ Design PostgreSQL schema with proper normalization │
|
||||
│ ✓ Create migration scripts and rollback procedures │
|
||||
│ ✓ Set up staging environment with both databases │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
PHASE 2: Dual-Write Implementation ✓
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ Status: COMPLETE Duration: 3w │
|
||||
├─────────────────────────────────────────────────────────────────────────┤
|
||||
│ ✓ Implement write-through to both MongoDB and PostgreSQL │
|
||||
│ ✓ Add feature flags for gradual rollout │
|
||||
│ ✓ Deploy to staging and validate data consistency │
|
||||
│ ✓ Monitor for performance impact (< 50ms added latency) │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
PHASE 3: Historical Data Migration ⏳
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ Status: IN PROGRESS (60%) Duration: 4w │
|
||||
├─────────────────────────────────────────────────────────────────────────┤
|
||||
│ ✓ Migrate users collection (2.3M records) │
|
||||
│ ✓ Migrate products collection (150K records) │
|
||||
│ ⏳ Migrate orders collection (5.2M records) - 60% complete │
|
||||
│ Migrate reviews collection (890K records) │
|
||||
│ Validate data integrity across all tables │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
PHASE 4: Read Path Migration
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ Status: PENDING Duration: 2w │
|
||||
├─────────────────────────────────────────────────────────────────────────┤
|
||||
│ Switch read operations to PostgreSQL (feature flag) │
|
||||
│ Run parallel queries and compare results │
|
||||
│ Gradually increase PostgreSQL read traffic (10% → 100%) │
|
||||
│ Monitor query performance and optimize indexes │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
│
|
||||
▼
|
||||
PHASE 5: Cutover & Cleanup
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ Status: PENDING Duration: 1w │
|
||||
├─────────────────────────────────────────────────────────────────────────┤
|
||||
│ Disable MongoDB writes │
|
||||
│ Update all application configuration │
|
||||
│ Archive MongoDB data │
|
||||
│ Remove dual-write code and feature flags │
|
||||
│ Document lessons learned │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
|
||||
Summary: Phase 3 of 5 │ Overall Progress: ~55% │ On Track for Q4
|
||||
|
||||
Legend:
|
||||
✓ = Complete ⏳ = In Progress (blank) = Pending
|
||||
```
|
||||
|
||||
## Explanation
|
||||
|
||||
This phased migration diagram provides:
|
||||
|
||||
- **Clear progress visibility**: Status and completion percentage per phase
|
||||
- **Detailed tasks**: Specific actions within each phase
|
||||
- **Time estimates**: Duration for planning purposes
|
||||
- **Overall summary**: Quick status check at the bottom
|
||||
|
||||
The vertical flow shows dependencies between phases while the detailed boxes provide actionable information.
|
||||
|
||||
## Usage Suggestions
|
||||
|
||||
- Include in weekly status updates
|
||||
- Add to project management tools
|
||||
- Share with stakeholders for progress visibility
|
||||
- Update after each milestone completion
|
||||
Reference in New Issue
Block a user