multirepo-plan

# Multi-Repository Planning

Skill for planning features that require coordinated changes across multiple repositories, generating flow documentation and independent implementation plans.

## Prerequisites

Before starting, gather from user:

1. **Path to second repository** (cwd is the first)
2. **Feature description** to implement

Do not assume roles (backend/frontend). Roles are determined by analysis.

## Workflow

### Phase 1: Shallow Indexing

Apply LSP Chain directly (without subagents) on both repositories. The goal is to identify integration candidates, not to deep dive.

Follow the flow described in [`references/lsp-chain-multirepo.md`](references/lsp-chain-multirepo.md), applying search patterns on each repo sequentially.

**Expected output:**

| Repo | Producer Candidates | Consumer Candidates |
|------|---------------------|---------------------|
| A (cwd) | [file:symbol, ...] | [file:symbol, ...] |
| B ({path}) | [...] | [...] |

### Phase 2: Selective Deep Dive

With identified candidates, determine if deeper analysis is needed. Invoke `explore-lsp` agents only when:

- Request/response types are unclear from documentSymbol
- Multiple abstraction layers exist (services calling other services)
- Data flow is not evident

**Invocation criteria:**

| Situation | Action |
|-----------|--------|
| Simple endpoint with clear types | Do not invoke, use hover/goToDefinition directly |
| Internal call chain | Invoke explore-lsp to trace flow |
| Generic types or any | Invoke explore-lsp to resolve actual types |
| Legacy code without types | Invoke explore-lsp + selective Read |

**Prompt for explore-lsp (when invoked):**

```text
Deep dive into {repo-path} for the following symbols: {candidate-list}.

Goal: Obtain concrete request/response types and trace internal dependencies.

Apply LSP Chain:
1. hover on each candidate symbol
2. goToDefinition for types
3. findReferences/incomingCalls if intermediate layers exist
4. Selective Read only if context is insuf