@ikunin/sprintpilot 1.0.0

package/_Sprintpilot/skills/sprintpilot-migrate/workflow.md

@@ -0,0 +1,235 @@
+# Multi-Agent Migration Planning
+
+## Purpose
+
+Plan a full-lifecycle migration from current stack to a target stack. Produces a phased roadmap, BMAD-compatible epics, and tracking artifacts.
+
+## Prerequisites
+
+- `sprintpilot-codebase-map` outputs in `{output_folder}/codebase-analysis/`
+- `sprintpilot-assess` output (`brownfield-assessment.md`) — recommended but not required
+
+## Outputs
+
+| File | Location | Purpose |
+|------|----------|---------|
+| `migration-plan.md` | `{planning_artifacts}/` | Full plan — human reference |
+| `migration-epics.md` | `{planning_artifacts}/` | BMAD-compatible epics for sprint planning |
+| `migration-tracking.yaml` | `{implementation_artifacts}/` | Progress tracking |
+
+---
+
+## Step 1 — Validate Prerequisites and Get Target
+
+<action>Verify codebase analysis exists. Read stack-analysis.md, architecture-analysis.md, concerns-analysis.md.</action>
+<action>Read brownfield-assessment.md if available.</action>
+<action>Ask user for:
+- **Target stack** (required): what to migrate to
+- **Constraints** (required): timeline, downtime tolerance, budget
+- **Risk tolerance** (required): conservative / moderate / aggressive
+If running under autopilot and these aren't derivable from existing artifacts → TRUE BLOCKER.
+</action>
+
+---
+
+## Step 2 — Strategy Selection
+
+<action>Based on analysis, recommend a migration strategy:
+
+| Strategy | When | Risk | Duration |
+|----------|------|------|----------|
+| Strangler Fig | Monolith with clear routing; zero-downtime required | Low | Long |
+| Branch by Abstraction | Internal components; need to swap implementations | Low-Med | Medium |
+| Big Bang | Small codebase, good test coverage | High | Short |
+| Parallel Run | Critical systems requiring verified equivalence | Medium | Long |
+
+Present recommendation with rationale. User confirms or overrides.
+</action>
+
+---
+
+## Step 3 — Compatibility Analysis (PARALLEL: 2 agents)
+
+<critical>Launch both agents in a single message.</critical>
+
+### Agent 1: Stack Mapper
+```
+Agent(
+  description: "Stack compatibility mapping",
+  prompt: <read ./agents/stack-mapper.md, append stack-analysis.md + architecture-analysis.md + target spec>
+)
+```
+Output: old→new component mapping, direct replacements vs rewrites needed.
+
+### Agent 2: Dependency Analyzer
+```
+Agent(
+  description: "Dependency graph and migration order",
+  prompt: <read ./agents/dependency-analyzer.md, append brownfield-assessment.md + concerns-analysis.md>
+)
+```
+Output: dependency graph, migration order, critical path.
+
+<action>Collect results. Merge into compatibility matrix.</action>
+
+---
+
+## Step 4 — Coexistence Design
+
+<action>Based on strategy (step 2) and compatibility (step 3), design how old + new code run together:
+- Proxy/router configuration
+- Adapter/anti-corruption layer design
+- Feature flag strategy
+- Data dual-write approach (if needed)
+- Rollback triggers and mechanism
+</action>
+
+---
+
+## Step 5 — Phased Roadmap
+
+<action>Create ordered phases, each delivering verifiable value:
+```
+Phase 0: Foundation — pipeline, coexistence infra, dual-deploy, test infra
+Phase 1-N: Component migrations — ordered by dependency graph
+Phase N+1: Decommission — remove old code, adapters, coexistence infra
+```
+Each phase has: scope, deliverable, verification criteria, rollback plan.
+</action>
+
+---
+
+## Step 6 — Per-Component Migration Cards
+
+<action>For each component to migrate:
+```markdown
+### [Component Name]: old → new
+- **Strategy**: strangler / rewrite / adapt
+- **Effort**: S/M/L/XL
+- **Risk**: Low/Medium/High
+- **Dependencies**: [components that must migrate first]
+- **Data migration**: yes/no — approach: ...
+- **Test strategy**: ...
+- **Rollback**: ...
+- **Phase**: N
+```
+</action>
+
+---
+
+## Step 7 — Data Migration Plan
+
+<action>If schema changes or data store migration is needed:
+- Schema diff (old vs new)
+- Transform logic
+- Dual-write period design
+- Backfill strategy
+- Rollback plan for data
+- Zero-downtime migration sequence
+</action>
+
+---
+
+## Step 8 — API Compatibility
+
+<action>If APIs change:
+- Versioning strategy (URL path / header / query param)
+- Backward compatibility period
+- Deprecation timeline
+- Client migration guide
+</action>
+
+---
+
+## Step 9 — Test Parity (PARALLEL: 1 agent)
+
+### Agent 3: Test Parity Analyzer
+```
+Agent(
+  description: "Test parity analysis for migration",
+  prompt: <read ./agents/test-parity-analyzer.md, append quality-analysis.md + target test framework>
+)
+```
+Output: old test → new test mapping, gaps, comparison testing strategy.
+
+---
+
+## Step 10 — Risk Assessment (PARALLEL: 1 agent)
+
+### Agent 4: Risk Assessor
+```
+Agent(
+  description: "Migration risk assessment",
+  prompt: <read ./agents/risk-assessor.md, append full plan draft + concerns-analysis.md>
+)
+```
+Output: per-phase risk matrix, mitigation strategies, rollback triggers, canary deployment plan.
+
+---
+
+## Step 11 — Generate BMAD Epics
+
+<action>Transform the migration plan into BMAD-compatible epics:
+```markdown
+# Migration Epics
+
+## Epic 0: Migration Foundation
+- Story 0-1: Set up coexistence infrastructure
+- Story 0-2: Configure dual deployment pipeline
+- Story 0-3: Create migration test harness
+
+## Epic 1: [Phase 1 Name]
+- Story 1-1: [Component] migration
+- Story 1-2: ...
+
+## Epic N+1: Decommission
+- Story N+1-1: Remove old [component]
+- Story N+1-2: Remove adapters and feature flags
+- Story N+1-3: Final validation and cleanup
+```
+
+Each story includes: acceptance criteria, estimated effort, dependencies.
+</action>
+
+<action>Write to `{planning_artifacts}/migration-epics.md`</action>
+
+---
+
+## Step 12 — Finalize
+
+<action>Compile everything into `{planning_artifacts}/migration-plan.md`:
+- Executive summary
+- Strategy and rationale
+- Compatibility matrix
+- Coexistence design
+- Phased roadmap
+- Component migration cards
+- Data migration plan
+- API compatibility plan
+- Test parity analysis
+- Risk matrix
+- Epic summary with links
+</action>
+
+<action>Create `{implementation_artifacts}/migration-tracking.yaml`:
+```yaml
+migration:
+  strategy: strangler-fig
+  target_stack: ...
+  started: null
+  phases:
+    phase-0:
+      name: Foundation
+      status: pending
+      stories: [0-1, 0-2, 0-3]
+    phase-1:
+      name: ...
+      status: pending
+      stories: [...]
+```
+</action>
+
+<action>Report summary and suggest next steps:
+- `bmad-sprint-planning` — plan sprints from migration epics
+- `bmad-create-story` — detail individual migration stories
+</action>

package/_Sprintpilot/skills/sprintpilot-party-mode/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: sprintpilot-party-mode
+description: 'Real parallel multi-agent discussions. Select 2-3 BMad Method agent personas per round, launch them simultaneously with a topic, collect responses as a discussion round. Supports multiple rounds. Use when you need diverse perspectives from BMad personas (architect, PM, QA, etc.) debating in parallel rather than sequentially.'
+---
+
+Follow the instructions in ./workflow.md.

package/_Sprintpilot/skills/sprintpilot-party-mode/workflow.md

@@ -0,0 +1,138 @@
+# Multi-Agent Party Mode
+
+## Purpose
+
+Run real parallel multi-persona discussions. Instead of sequentially role-playing each persona (as stock `bmad-party-mode` does), this launches 2-3 Agent subagents simultaneously, each embodying a different BMAD persona. Results are collected and presented as a discussion round.
+
+---
+
+## Step 1 — Setup
+
+<action>Get from user or context:
+- **Topic/Question**: what to discuss
+- **Personas**: which BMAD personas to include (2-3 per round)
+  Available: analyst, architect, pm, dev, qa, ux-designer, tech-writer, sm
+- **Context files**: any project artifacts to provide as context (PRD, architecture, etc.)
+- **Rounds**: how many discussion rounds (default: 2)
+
+If not specified, recommend a relevant set based on the topic:
+- Architecture decisions → architect, dev, qa
+- Product direction → pm, analyst, ux-designer
+- Implementation approach → dev, architect, qa
+- Process/workflow → sm, pm, dev
+</action>
+
+---
+
+## Step 2 — Load Persona Definitions
+
+<action>For each selected persona, read the agent definition from BMAD:
+- `{project-root}/_bmad/_config/agents/` — look for persona YAML files
+- Or look in the installed skills directory for `bmad-agent-{persona}/SKILL.md`
+
+Extract the persona's:
+- Role description
+- Expertise areas
+- Communication style
+- Key concerns/priorities
+</action>
+
+---
+
+## Step 3 — Run Discussion Rounds
+
+For each round (1 to {{num_rounds}}):
+
+<critical>Launch ALL persona agents for this round in a single message.</critical>
+
+For each persona in this round:
+```
+Agent(
+  description: "{persona_name} perspective on {topic}",
+  prompt: "You are the {persona_name} on a BMAD development team.
+
+  ## Your Role
+  {persona_description}
+
+  ## Your Priorities
+  {persona_priorities}
+
+  ## Discussion Topic
+  {topic}
+
+  ## Context
+  {project_context_files_content}
+
+  ## Previous Round Discussion
+  {previous_round_responses — empty for round 1}
+
+  ## Instructions
+
+  Respond to the topic from your persona's perspective.
+  - State your position clearly
+  - Raise concerns specific to your role
+  - Propose concrete actions
+  - If responding to previous round: agree, disagree, or build on other personas' points
+  - Be direct and specific, not generic
+
+  Cap response at 1000 tokens."
+)
+```
+
+<action>Collect all responses for this round.</action>
+
+<action>Present the round:
+
+```markdown
+## Round {{round_number}}
+
+### {Persona 1 Name} ({role})
+{response}
+
+### {Persona 2 Name} ({role})
+{response}
+
+### {Persona 3 Name} ({role})
+{response}
+```
+</action>
+
+<action>For subsequent rounds, include previous round responses as context so personas can respond to each other.</action>
+
+---
+
+## Step 4 — Synthesis
+
+After all rounds complete:
+
+<action>Produce a synthesis:
+
+```markdown
+## Discussion Summary
+
+### Topic
+{topic}
+
+### Participants
+{persona list with roles}
+
+### Points of Agreement
+- ...
+
+### Points of Disagreement
+- {persona A} vs {persona B}: ...
+  Resolution suggestion: ...
+
+### Action Items
+1. [Owner: {persona}] {action}
+2. ...
+
+### Open Questions
+- ...
+
+### Recommendation
+[Based on the discussion, what is the recommended path forward?]
+```
+</action>
+
+<action>Ask user: "Continue with another topic, or apply these insights to the current workflow?"</action>

package/_Sprintpilot/skills/sprintpilot-research/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: sprintpilot-research
+description: 'Multi-agent research fan-out. Launch parallel research agents for technical, domain, and market topics simultaneously. Each agent uses WebSearch/WebFetch for live research. Collects and synthesizes results into a unified research report. Use when you need to research multiple topics quickly.'
+---
+
+Follow the instructions in ./workflow.md.

package/_Sprintpilot/skills/sprintpilot-research/workflow.md

@@ -0,0 +1,128 @@
+# Multi-Agent Research
+
+## Purpose
+
+Fan out research across multiple topics in parallel. Each research agent gets a topic and type (technical/domain/market), uses WebSearch and WebFetch, and returns structured findings. Results are collected and synthesized.
+
+---
+
+## Step 1 — Gather Research Topics
+
+<action>Get research topics from user or from the current workflow context.
+
+Expected input format:
+```
+Topics:
+1. [type: technical] How does Prisma handle migrations compared to TypeORM?
+2. [type: domain] Healthcare HIPAA compliance requirements for SaaS
+3. [type: market] Competitor analysis for API gateway products
+```
+
+If no topics provided, ask the user. Each topic needs:
+- **Topic text** — what to research
+- **Type** — `technical` (implementation approaches), `domain` (industry knowledge), or `market` (competitive landscape)
+</action>
+
+<action>Set `{{topics}}` = list of topics with types</action>
+
+---
+
+## Step 2 — Launch Research Agents in Parallel
+
+<critical>
+Launch ALL agents in a single message.
+Max parallel agents: 3 (from config). If more than 3 topics, batch into rounds.
+Each agent gets the topic, type, and instructions for that research type.
+</critical>
+
+For each topic, launch:
+```
+Agent(
+  description: "Research: {topic_summary}",
+  prompt: "You are a research agent. Your task:
+
+  **Topic**: {topic_text}
+  **Type**: {type}
+
+  ## Instructions
+
+  Use WebSearch to find current, authoritative information.
+  Use WebFetch to read promising results in detail.
+
+  ### For 'technical' topics:
+  - Find official documentation, blog posts, benchmarks
+  - Compare approaches with pros/cons
+  - Include code examples if relevant
+  - Cite sources with URLs
+
+  ### For 'domain' topics:
+  - Find regulatory documents, industry standards, expert analyses
+  - Identify key terminology and requirements
+  - Note recent changes or trends
+  - Cite authoritative sources
+
+  ### For 'market' topics:
+  - Identify competitors and alternatives
+  - Compare features, pricing, market position
+  - Note trends and market direction
+  - Cite data sources
+
+  ## Output Format
+
+  ```markdown
+  ## Research: {topic_summary}
+
+  ### Key Findings
+  1. ...
+  2. ...
+  3. ...
+
+  ### Details
+  [Structured analysis based on type]
+
+  ### Sources
+  - [Title](URL) — brief note on relevance
+  ```
+
+  Cap response at 2000 tokens. Be concise and factual."
+)
+```
+
+---
+
+## Step 3 — Collect and Synthesize
+
+<action>Collect all agent results.</action>
+
+<action>Produce unified research report:
+
+```markdown
+# Research Report
+
+## Topics Researched
+| # | Type | Topic | Status |
+|---|------|-------|--------|
+| 1 | technical | ... | complete |
+| 2 | domain | ... | complete |
+| 3 | market | ... | complete |
+
+## Findings
+
+### Topic 1: {title}
+[Agent 1's findings]
+
+### Topic 2: {title}
+[Agent 2's findings]
+
+### Topic 3: {title}
+[Agent 3's findings]
+
+## Cross-Topic Insights
+[Any connections or conflicts between findings across topics]
+
+## Sources
+[Consolidated list of all sources cited]
+```
+</action>
+
+<action>If this was triggered by a BMAD workflow (e.g., during architecture or PRD creation), save to `{planning_artifacts}/research-{topic-slug}.md`</action>

package/_Sprintpilot/skills/sprintpilot-reverse-architect/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: sprintpilot-reverse-architect
+description: 'Extract architecture from existing code (bottom-up) via 3 parallel agents. Produces BMad Method-compatible architecture document from Component Mapper, Data Flow Tracer, and Pattern Extractor. Use on brownfield projects where no architecture doc exists. Run after sprintpilot-codebase-map.'
+---
+
+Follow the instructions in ./workflow.md.

package/_Sprintpilot/skills/sprintpilot-reverse-architect/agents/component-mapper.md

@@ -0,0 +1,53 @@
+# Component Mapper Agent
+
+You are extracting module boundaries and component contracts from an existing codebase.
+
+## Task
+
+Using the architecture-analysis.md analysis as a starting point, go deeper: trace actual imports, identify public APIs, and map the internal dependency graph.
+
+## Method
+
+1. For each module/directory identified in architecture-analysis.md:
+   - Read index/barrel files (index.ts, __init__.py, mod.rs, etc.)
+   - Identify exported symbols (public API)
+   - Grep for imports of this module from other modules
+   - Map which modules depend on which
+
+2. For each component:
+   - Identify its responsibility (from code, not guessing)
+   - List its public interface (functions, classes, routes, events)
+   - List what it depends on
+   - Note any circular dependencies
+
+## Output Format
+
+```markdown
+## Components
+
+### [Component Name]
+- **Path**: src/components/auth/
+- **Responsibility**: Authentication and session management
+- **Public API**:
+  - `authenticate(credentials) → Session`
+  - `validateToken(token) → User`
+- **Internal dependencies**: Database, Config
+- **Depended on by**: API Routes, Middleware
+- **Evidence**: src/components/auth/index.ts:1-15
+
+## Dependency Graph
+```
+[Component A] → [Component B] → [Component C]
+                                → [Component D]
+[Component E] → [Component B]
+```
+
+## Circular Dependencies
+- [list any found, or "None detected"]
+
+## Boundary Assessment
+- Clean boundaries: [list well-encapsulated components]
+- Leaky boundaries: [list components with tight coupling]
+```
+
+## Context (architecture-analysis.md)

package/_Sprintpilot/skills/sprintpilot-reverse-architect/agents/data-flow-tracer.md

@@ -0,0 +1,54 @@
+# Data Flow Tracer Agent
+
+You are tracing how data flows through the system — from entry points to storage and back.
+
+## Task
+
+Using architecture-analysis.md and integrations-analysis.md as context, trace the actual request/data paths through the code.
+
+## Method
+
+1. Start from entry points (routes, CLI handlers, event listeners)
+2. Follow the call chain: handler → service → repository → database
+3. Track data transformations at each step
+4. Identify async flows (queues, events, callbacks, promises)
+5. Map state management patterns
+
+## Output Format
+
+```markdown
+## Primary Data Flows
+
+### Flow 1: [Name] (e.g., "User Authentication")
+```
+Entry: POST /api/auth/login (routes/auth.ts:15)
+  → AuthController.login (controllers/auth.ts:30)
+    → AuthService.authenticate (services/auth.ts:45)
+      → UserRepository.findByEmail (repos/user.ts:20)
+        → Database query
+      ← User record
+    → TokenService.generate (services/token.ts:10)
+    ← { token, user }
+  ← 200 { token, user }
+```
+
+### Flow 2: [Name]
+...
+
+## State Management
+- Pattern: [Redux/Zustand/Context/MobX/server-side sessions/...]
+- Store location: ...
+- Key state shapes: ...
+
+## Async Flows
+| Trigger | Queue/Event | Handler | Side Effects |
+|---------|------------|---------|-------------|
+| ... | ... | ... | ... |
+
+## Data Transformation Points
+| Location | Input Shape | Output Shape | Validation |
+|----------|------------|-------------|------------|
+| ... | ... | ... | yes/no |
+```
+
+## Context (architecture-analysis.md + integrations-analysis.md)

package/_Sprintpilot/skills/sprintpilot-reverse-architect/agents/pattern-extractor.md

@@ -0,0 +1,67 @@
+# Pattern Extractor Agent
+
+You are identifying design patterns, conventions, and architectural decisions embedded in the code.
+
+## Task
+
+Using architecture-analysis.md and stack-analysis.md as context, identify the actual patterns the codebase follows (not what it claims to follow).
+
+## Method
+
+1. Look for structural patterns: Factory, Repository, Observer, Middleware, Decorator
+2. Check naming conventions across files (camelCase, snake_case, kebab-case)
+3. Analyze error handling: try/catch strategy, error types, error propagation
+4. Check testing patterns: arrange-act-assert, given-when-then, mocking strategy
+5. Look for logging patterns: structured logging, log levels, what gets logged
+6. Check configuration patterns: env vars, config objects, feature flags
+
+## Output Format
+
+```markdown
+## Design Patterns
+
+### Structural Patterns
+| Pattern | Where | Example |
+|---------|-------|---------|
+| Repository | Data access layer | `UserRepository` at repos/user.ts |
+| Factory | ... | ... |
+| Middleware | Request pipeline | Express middleware at middleware/ |
+
+### Naming Conventions
+| Context | Convention | Example | Consistency |
+|---------|-----------|---------|-------------|
+| Files | kebab-case | user-service.ts | 95% consistent |
+| Classes | PascalCase | UserService | 100% |
+| Functions | camelCase | getUserById | 90% |
+| DB columns | snake_case | created_at | 100% |
+
+### Error Handling Strategy
+- Pattern: [custom error classes / error codes / HTTP status mapping]
+- Propagation: [throw/catch at boundaries / result types / error events]
+- Logging: [errors are logged at: ...]
+- Gaps: [where error handling is missing or inconsistent]
+
+### Testing Patterns
+- Framework: ...
+- Style: [unit + integration / mostly e2e / mixed]
+- Mocking: [jest mocks / dependency injection / test doubles]
+- Fixtures: [factory functions / JSON fixtures / database seeds]
+
+### Logging & Observability
+- Logger: [winston / pino / built-in / console]
+- Structure: [structured JSON / plain text]
+- Levels used: [info, warn, error — debug?]
+
+### Configuration Pattern
+- Method: [env vars / config files / both]
+- Validation: [validated at startup? / no validation?]
+- Secrets: [how are secrets handled?]
+
+## Architectural Decisions (Inferred)
+| # | Decision | Evidence | Likely Rationale |
+|---|----------|----------|-----------------|
+| 1 | Use TypeScript strict mode | tsconfig.json:3 | Type safety |
+| 2 | ... | ... | ... |
+```
+
+## Context (architecture-analysis.md + stack-analysis.md)