reimagine

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Reimagine

系统重构

Take specs from multiple repos. Reimagine them as something new.

Estimated Time: 30-60 minutes (depending on repo count and depth) Prerequisites: Batch processing completed on 2+ repos, OR manually prepared reverse-engineering docs from multiple repos Output: Capability map, reimagined vision, new specifications (Spec Kit or BMAD format)

从多个仓库提取规格说明，将其重构为全新系统。

预估时间： 30-60分钟（取决于仓库数量和分析深度） 前置条件： 已完成2个及以上仓库的批量处理，或已手动准备好多个仓库的逆向工程文档 输出： 能力映射图、重构愿景、新规格说明（Spec Kit或BMAD格式）

When to Use This Skill

何时使用该Skill

Use this skill when:

You've batch-processed multiple related repos with StackShift
You want to consolidate or redesign multiple services/apps
You're planning a major platform modernization
You want to explore how existing capabilities could work together differently
You have reverse-engineering docs from several codebases and want a fresh perspective

Trigger Phrases:

"Reimagine these services as a unified platform"
"How could these apps work together better?"
"Consolidate these microservices"
"Design a new system from these existing capabilities"
"Synthesize a new vision from multiple repos"

在以下场景使用该Skill：

您已通过StackShift批量处理多个相关仓库
您希望整合或重新设计多个服务/应用
您正在规划重大平台现代化项目
您希望探索现有能力如何以不同方式协同工作
您拥有多个代码库的逆向工程文档，想要获得全新视角

触发短语：

"将这些服务重构为统一平台"
"这些应用如何能更好地协同工作？"
"整合这些微服务"
"基于现有能力设计新系统"
"从多个仓库合成新愿景"

What This Skill Does

该Skill的功能

   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  │
   └─────────┘

Loads reverse-engineering docs from multiple repos
Extracts a unified capability map (what each repo does)
Identifies duplication, overlap, inconsistency, and gaps
Brainstorms with you to reimagine the system
Generates new specifications for the reimagined system

   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  │
   └─────────┘

加载多个仓库的逆向工程文档
提取统一的能力映射图（记录每个仓库的功能）
识别重复功能、重叠部分、不一致性与缺口
与用户协作研讨，重新构想系统
生成重构后系统的新规格说明

Process

流程

Step 1: Locate Repo Documentation

步骤1：定位仓库文档

Option A: From Batch Results

bash

undefined

选项A：从批量处理结果中获取

bash

undefined

Point to batch results directory

指向批量处理结果目录

BATCH_DIR="~/git/stackshift-batch-results"

OR

或

BATCH_DIR="~/git/my-monorepo"

Find all repos with reverse-engineering docs

查找所有包含逆向工程文档的仓库

find "$BATCH_DIR" -type d -name "reverse-engineering" -path "/docs/"


**Option B: Manual Repo List**

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

Which repos should I analyze?

Provide paths to repos or their docs/reverse-engineering/ directories:

~/git/user-service
~/git/billing-api
~/git/notification-hub
~/git/admin-dashboard ...


**Option C: From Active Directory**

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

find "$BATCH_DIR" -type d -name "reverse-engineering" -path "/docs/"


**选项B：手动提供仓库列表**

请用户提供仓库路径或其逆向工程文档路径：

我应该分析哪些仓库？

请提供仓库路径或其docs/reverse-engineering/目录路径：

~/git/user-service
~/git/billing-api
~/git/notification-hub
~/git/admin-dashboard ...


**选项C：从活动目录中获取**

如果是单体仓库，扫描包含逆向工程文档的子目录：
```bash

Find all services in current monorepo

查找当前单体仓库中的所有服务

for dir in */; do if [ -d "$dir/docs/reverse-engineering" ]; then echo "Found: $dir" fi done


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

for dir in */; do if [ -d "$dir/docs/reverse-engineering" ]; then echo "Found: $dir" fi done


**验证：** 每个仓库至少应包含：
- `functional-specification.md`（必填）
- `integration-points.md`（必填）
- `data-architecture.md`（必填）
- 额外文档可提升分析质量

Step 2: Load and Parse All Docs

步骤2：加载并解析所有文档

For each repo, read the key documents using parallel Task agents:

Per-repo extraction targets:

From
```
functional-specification.md
```
: All FRs, user stories, personas, business rules
From
```
integration-points.md
```
: External services, APIs consumed/exposed, data flows
From
```
data-architecture.md
```
: Data models, API contracts, domain boundaries
From
```
business-context.md
```
: Product vision, personas, business goals (if available)
From
```
decision-rationale.md
```
: Tech stack, ADRs, design principles (if available)
From
```
technical-debt-analysis.md
```
: Pain points, migration priorities (if available)
From
```
configuration-reference.md
```
: Shared config patterns (if available)
From
```
operations-guide.md
```
: Deployment model, infrastructure (if available)

Parallel processing: Use Task agents to read docs from multiple repos concurrently.

使用并行Task代理读取每个仓库的关键文档：

每个仓库的提取目标：

从
```
functional-specification.md
```
：所有功能需求（FR）、用户故事、用户角色、业务规则
从
```
integration-points.md
```
：外部服务、调用/暴露的API、数据流
从
```
data-architecture.md
```
：数据模型、API契约、领域边界
从
```
business-context.md
```
：产品愿景、用户角色、业务目标（若存在）
从
```
decision-rationale.md
```
：技术栈、架构决策记录（ADR）、设计原则（若存在）
从
```
technical-debt-analysis.md
```
：痛点、迁移优先级（若存在）
从
```
configuration-reference.md
```
：共享配置模式（若存在）
从
```
operations-guide.md
```
：部署模型、基础设施（若存在）

并行处理： 使用Task代理同时读取多个仓库的文档。

Step 3: Generate Capability Map

步骤3：生成能力映射图

Synthesize all extracted information into a unified capability map:

将所有提取的信息合成为统一的能力映射图：

3.1 Business Capability Inventory

3.1 业务能力清单

Group all functional requirements across repos by business domain:

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

按业务领域对所有仓库的功能需求进行分组：

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

3.2 Technical Overlap Analysis

3.2 技术重叠分析

Identify where repos duplicate functionality:

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

识别仓库间重复的功能：

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

3.3 Pain Points & Opportunities

3.3 痛点与改进机会

Extract from technical debt analyses across repos:

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.

从所有仓库的技术债务分析中提取痛点：

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.

3.4 Dependency Graph

3.4 依赖关系图

Show how repos depend on each other:

mermaid

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

展示仓库间的依赖关系：

mermaid

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

Step 4: Present Capability Map to User

步骤4：向用户展示能力映射图

Display the capability map and ask for the user's reaction:

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

展示能力映射图并询问用户反馈：

我已分析[N]个仓库并提取了上述能力映射图。

关键发现：
- 识别出[X]个不同的业务能力
- 服务间功能重叠率达[Y]%
- 跨仓库存在[Z]个痛点
- 使用了[W]种不同的技术栈

您希望探索哪种方向？

A) 整合 — 将重叠服务合并为更少、更优的服务
B) 平台化 — 构建统一平台替代所有服务
C) 演进 — 保留现有服务，但解决痛点并标准化
D) 混合模式 — 部分整合 + 新增部分能力
E) 自由讨论 — 探讨最适合的方案

Step 5: Brainstorming Session

步骤5：协作研讨环节

This is the collaborative, creative phase. Based on the user's direction:

这是协作创意阶段，根据用户选择的方向推进：

Consolidation Path

整合方向

Propose which services to merge and which to keep separate
Show data model unification strategy
Identify shared infrastructure opportunities
Estimate effort vs. benefit for each consolidation

提议合并哪些服务、保留哪些服务
展示数据模型统一策略
识别共享基础设施的机会
评估每项整合工作的投入与收益

Platform Path

平台化方向

Propose a unified domain model spanning all capabilities
Design new service boundaries based on business domains (not existing code)
Identify the core platform vs. optional modules
Show how current capabilities map to new architecture

提议覆盖所有能力的统一领域模型
基于业务领域（而非现有代码）设计新的服务边界
识别核心平台与可选模块
展示现有能力如何映射到新架构

Evolution Path

演进方向

Propose shared libraries and standards
Design API gateway for consistent external interface
Plan shared auth, notification, and observability services
Keep existing services but connect them better

提议共享库与标准
设计API网关以提供一致的外部接口
规划共享认证、通知与可观测性服务
保留现有服务，但优化它们之间的连接

Free-form Path

自由讨论方向

Open discussion guided by capability map
Ask probing questions: "What if auth was a shared service?"
Explore non-obvious combinations: "What if billing + notifications were one service?"
Challenge assumptions: "Do you need 3 separate databases?"

Throughout brainstorming:

Reference specific capabilities from the map
Quantify overlap and duplication
Propose concrete architectural patterns
Draw Mermaid diagrams for proposed architectures
Keep the user engaged with questions and options

基于能力映射图展开开放式讨论
提出探索性问题：“如果认证是共享服务会怎样？”
探索非显而易见的组合：“如果计费+通知合并为一个服务会怎样？”
挑战现有假设：“您真的需要3个独立数据库吗？”

研讨全程注意：

参考映射图中的具体能力
量化重叠与重复程度
提议具体的架构模式
绘制Mermaid图展示提议的架构
通过问题与选项保持用户参与度

Step 6: Define the Reimagined Vision

步骤6：定义重构愿景

Once the brainstorming converges on a direction, formalize it:

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 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

Step 7: Generate New Specifications

步骤7：生成新规格说明

Based on the reimagined vision, generate specifications in the user's preferred format:

Ask: "Generate specs in Spec Kit or BMAD format?"

基于重构愿景，以用户偏好的格式生成规格说明：

询问： “以Spec Kit还是BMAD格式生成规格说明？”

Spec Kit Output

Spec Kit输出

Create
```
.specify/
```
structure for the reimagined system
Generate constitution with new principles and tech stack
Create feature specs for each service/module
Include migration specs (from current → new)

为重构后的系统创建
```
.specify/
```
目录结构
生成包含新原则与技术栈的章程
为每个服务/模块创建功能规格
包含从当前系统到新系统的迁移规格

BMAD Output

BMAD输出

Generate
```
prd.md
```
for the reimagined system
Generate
```
architecture.md
```
with new service boundaries
Generate
```
epics.md
```
with migration + new capability epics
Generate
```
ux-design-specification.md
```
if applicable

为重构后的系统生成
```
prd.md
```
生成包含新服务边界的
```
architecture.md
```
生成包含迁移与新增能力史诗的
```
epics.md
```
若适用，生成
```
ux-design-specification.md
```

Both

同时生成两种格式

Generate both formats (Spec Kit for implementation, BMAD for planning)

Output location:

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

同时生成两种格式（Spec Kit用于实施，BMAD用于规划）

输出位置：

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

Example: Enterprise Microservices Consolidation

示例：企业微服务整合

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

输入：批量处理的12个微服务

能力映射图显示：
- 4个服务处理用户数据（碎片化）
- 3个服务发送通知（重复实现）
- 2个服务实现支付逻辑（不一致）
- 认证功能被重复实现5次
- 12条独立的CI/CD流水线
- 4种不同的API风格

研讨达成的方向：
- 用模块化单体架构替代12个微服务
- 5个模块：身份认证、商务、通信、分析、管理
- 共享PostgreSQL，每个模块对应独立schema
- 单一部署流水线
- 统一API网关，采用一致的REST标准

输出：
- VISION.md："统一商务平台"
- CAPABILITY_MAP.md：完整分析报告
- 5个功能规格（每个模块一个）
- 包含ADR的架构文档，解释整合决策
- 迁移计划：6个月分4个阶段完成

Example: Startup App Reimagination

示例：初创企业应用重构

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

输入：3个相关工具（CRM、邮件营销、分析）

能力映射图显示：
- 3个工具共享客户数据
- 邮件工具重复实现了CRM的联系人管理功能
- 分析工具从CRM和邮件工具获取数据
- 缺乏统一的客户旅程视图

研讨达成的方向：
- 构建单一的"客户智能平台"
- 核心：统一客户档案 + 事件流
- 模块：触达（邮件+）、洞察（分析+）、关系（CRM+）
- 新增能力：AI驱动的客户旅程预测（整合数据后实现）

输出：
- "客户智能平台"的新PRD
- 架构：事件溯源，统一客户事件流
- 4个史诗：核心平台、触达模块、洞察模块、关系模块

Integration with Other Skills

与其他Skill的集成

With Batch Processing (

/stackshift.batch

)

与批量处理（

/stackshift.batch

）集成

Run batch first to generate reverse-engineering docs for all repos
Reimagine reads the batch results
Natural workflow: batch → reimagine → architect → implement

先运行批量处理为所有仓库生成逆向工程文档
系统重构Skill读取批量处理结果
自然工作流：批量处理 → 系统重构 → 架构生成 → 实施

With Architecture Generator (

/stackshift.architect

)

与架构生成器（

/stackshift.architect

）集成

After reimagining, use
```
/stackshift.architect
```
with user constraints
Architecture Generator creates detailed architecture for the new vision
Constraint questions informed by the capability map

完成重构后，使用
```
/stackshift.architect
```
并结合用户约束
架构生成器为新愿景创建详细架构
约束问题基于能力映射图制定

With BMAD Synthesize (

/stackshift.bmad-synthesize

)

与BMAD合成（

/stackshift.bmad-synthesize

）集成

Reimagine can generate initial BMAD artifacts
Then hand off to BMAD Synthesize for refinement
Or hand off to full BMAD for collaborative refinement

系统重构Skill可生成初始BMAD工件
随后转交BMAD合成Skill进行优化
或转交完整BMAD工具进行协作优化

Success Criteria

成功标准

✅ All repo docs loaded and parsed
✅ Capability map generated with business domains identified
✅ Overlap analysis shows duplication percentage and specifics
✅ Pain points extracted from cross-repo technical debt
✅ Dependency graph visualized (Mermaid)
✅ Brainstorming session produces a clear direction
✅ Reimagined vision document generated
✅ New specifications generated in chosen format
✅ Migration path from current → reimagined state included

✅ 所有仓库文档已加载并解析
✅ 生成能力映射图并识别业务领域
✅ 重叠分析显示重复率与具体重复内容
✅ 从跨仓库技术债务中提取痛点
✅ 可视化依赖关系图（Mermaid）
✅ 协作研讨产生明确方向
✅ 生成重构愿景文档
✅ 以选定格式生成新规格说明
✅ 包含从当前系统到重构后系统的迁移路径

Technical Notes

技术说明

Use parallel Task agents to read docs from multiple repos simultaneously
For large batches (10+ repos), process capability extraction in batches of 5
Mermaid diagrams may need to be simplified for 10+ service dependency graphs
Domain clustering for capability grouping: analyze FR titles, data models, and integration points for common themes
The brainstorming session should be genuinely interactive — don't just present a predetermined answer
Migration phases should be ordered by: risk (low first), value (high first), dependency (prerequisites first)
If batch results include AST analysis, use function-level data for more precise overlap detection

使用并行Task代理同时读取多个仓库的文档
对于大型批量处理（10个及以上仓库），将能力提取分为每5个仓库一组进行处理
对于10个及以上服务的依赖关系图，可能需要简化Mermaid图
能力分组的领域聚类：分析功能需求标题、数据模型与集成点以识别共同主题
协作研讨环节应具备真正的互动性 — 不要仅展示预设答案
迁移阶段应按以下顺序排列：风险（先低风险）、价值（先高价值）、依赖关系（先前置条件）
如果批量处理结果包含AST分析，使用函数级数据进行更精确的重复检测