Multiple Repos              Capability Map              New Vision
   ┌─────────┐                                            ┌─────────────┐
   │ Repo A   │──┐            ┌──────────────┐            │ Reimagined  │
   │ 11 docs  │  │            │ Auth: A, C   │            │ System      │
   ├─────────┤  ├──Extract──→│ Payments: B  │──Brainstorm→│             │
   │ Repo B   │  │            │ Users: A, B  │   with     │ New specs   │
   │ 11 docs  │  │            │ Reporting: C │   user     │ New arch    │
   ├─────────┤  │            │ Overlap: 40% │            │ New epics   │
   │ Repo C   │──┘            └──────────────┘            └─────────────┘
   │ 11 docs  │
   └─────────┘

undefined

**Option B: Manual Repo List**

Ask the user to provide paths to repos or their reverse-engineering docs:

**Option C: From Active Directory**

If in a monorepo, scan for subdirectories with reverse-engineering docs:
```bash

**Validate:** Each repo should have at minimum:
- `functional-specification.md` (required)
- `integration-points.md` (required)
- `data-architecture.md` (required)
- Additional docs improve analysis quality

Business Capability Map
═══════════════════════

Authentication & Identity
  ├── user-service: User registration, login, password reset, OAuth
  ├── admin-dashboard: Admin login, role management, SSO
  └── billing-api: API key authentication, webhook signatures
  Overlap: 3 separate auth implementations

Payment & Billing
  ├── billing-api: Stripe integration, invoicing, subscription management
  └── user-service: Basic payment method storage
  Overlap: Payment data in 2 services

Notifications
  ├── notification-hub: Email, SMS, push notifications
  ├── user-service: Welcome emails, password reset emails
  └── billing-api: Invoice emails, payment receipts
  Overlap: 3 services send emails independently

Data & Reporting
  ├── admin-dashboard: Usage reports, user analytics
  └── billing-api: Revenue reports, churn metrics
  Overlap: Separate analytics in 2 services

User Management
  ├── user-service: CRUD, profiles, preferences
  └── admin-dashboard: User search, impersonation, bulk operations
  Overlap: User data accessed from 2 services

Technical Overlap Analysis
══════════════════════════

Shared Data Models:
  User model: user-service (primary), admin-dashboard (read), billing-api (ref)
  → 3 different representations of the same entity

Duplicated Logic:
  Email sending: user-service (SendGrid), notification-hub (SendGrid), billing-api (SES)
  → 3 separate email implementations, 2 different providers

Inconsistent APIs:
  user-service: REST with camelCase
  billing-api: REST with snake_case
  notification-hub: GraphQL
  → 3 different API styles

Shared Dependencies:
  PostgreSQL: user-service, billing-api (separate databases)
  Redis: user-service (sessions), notification-hub (queue)
  → Could consolidate or keep separate based on domain boundaries

Cross-Repo Pain Points
══════════════════════

1. Authentication Fragmentation (3 repos affected)
   Each service implements its own auth. No SSO. Inconsistent session handling.

2. Data Consistency Issues (2 repos affected)
   User data modified in user-service but admin-dashboard has stale cache.

3. Notification Sprawl (3 repos affected)
   Three services send emails independently. No unified template system.
   Users sometimes get duplicate notifications.

4. No Shared API Standards (all repos)
   Different naming conventions, error formats, pagination styles.

5. Operational Complexity (all repos)
   Each service deployed independently with different CI/CD pipelines.
   No shared observability. Debugging cross-service issues is painful.

graph LR
    US[User Service] --> DB1[(User DB)]
    BA[Billing API] --> DB2[(Billing DB)]
    BA --> US
    NH[Notification Hub] --> US
    NH --> BA
    AD[Admin Dashboard] --> US
    AD --> BA
    AD --> NH

    style US fill:#f9f,stroke:#333
    style BA fill:#bbf,stroke:#333
    style NH fill:#bfb,stroke:#333
    style AD fill:#fbb,stroke:#333

I've analyzed [N] repositories and extracted the capability map above.

Key findings:
- [X] distinct business capabilities identified
- [Y]% functional overlap between services
- [Z] pain points spanning multiple repos
- [W] different tech stacks in use

What would you like to explore?

A) Consolidation — Merge overlapping services into fewer, better ones
B) Platform — Build a unified platform that replaces all services
C) Evolution — Keep services but fix pain points and standardize
D) Hybrid — Some consolidation + some new capabilities
E) Free-form — Let's discuss what makes sense

Reimagined Vision
═════════════════

Name: [New System Name]
Vision: [One-sentence description]

Architecture Style: [Monolith / Microservices / Modular Monolith / ...]

New Service Boundaries:
1. [Service A] — combines capabilities from [repo1, repo2]
2. [Service B] — new service for [capability]
3. [Service C] — evolved from [repo3]

Unified Data Model:
- [Entity 1] — single source of truth (replaces 3 separate models)
- [Entity 2] — new entity for [purpose]

Eliminated Duplication:
- Auth: Single shared auth service (saves ~X hours/month)
- Email: Unified notification service (eliminates 3 implementations)
- API: Consistent REST standards across all services

New Capabilities:
- [Capability that emerges from combining repos]
- [Capability enabled by shared infrastructure]

Migration Strategy:
- Phase 1: Shared infrastructure (auth, notifications, API gateway)
- Phase 2: Data model unification
- Phase 3: Service consolidation
- Phase 4: New capabilities

reimagined-system/
├── VISION.md                           # The reimagined vision document
├── CAPABILITY_MAP.md                   # Full capability map from all repos
├── docs/
│   └── reverse-engineering/            # Synthesized from all repos
│       ├── functional-specification.md # Unified functional spec
│       ├── integration-points.md       # New integration architecture
│       ├── data-architecture.md        # Unified data model
│       ├── business-context.md         # Combined business context
│       └── decision-rationale.md       # New architectural decisions
├── .specify/                           # If Spec Kit format chosen
│   └── memory/
│       ├── constitution.md
│       └── specifications/
│           ├── 001-shared-auth/
│           ├── 002-unified-notifications/
│           └── ...
└── _bmad-output/                       # If BMAD format chosen
    └── planning-artifacts/
        ├── prd.md
        ├── architecture.md
        └── epics.md

Input: 12 microservices from batch processing

Capability Map reveals:
- 4 services handle user data (fragmented)
- 3 services send notifications (duplicated)
- 2 services implement payment logic (inconsistent)
- Authentication is reimplemented 5 times
- 12 separate CI/CD pipelines
- 4 different API styles

Brainstorming converges on:
- Modular monolith replacing 12 microservices
- 5 modules: Identity, Commerce, Communication, Analytics, Admin
- Shared PostgreSQL with schema-per-module
- Single deployment pipeline
- Unified API gateway with consistent REST

Output:
- VISION.md: "Unified Commerce Platform"
- CAPABILITY_MAP.md: Full analysis
- 5 feature specs (one per module)
- Architecture doc with ADRs explaining consolidation decisions
- Migration plan: 4 phases over 6 months

Input: 3 related tools (CRM, email marketing, analytics)

Capability Map reveals:
- All 3 tools share customer data
- Email tool duplicates CRM contact management
- Analytics pulls from both CRM and email
- No unified customer journey view

Brainstorming converges on:
- Single "Customer Intelligence Platform"
- Core: Unified customer profile + event stream
- Modules: Outreach (email+), Insights (analytics+), Relationships (CRM+)
- New capability: AI-powered customer journey prediction (emerges from combining data)

Output:
- New PRD for "Customer Intelligence Platform"
- Architecture: Event-sourced, with unified customer event stream
- 4 epics: Core Platform, Outreach Module, Insights Module, Relationships Module