Brownfield Analyzer

Brownfield Analyzer

Self-contained brownfield project analysis for ANY existing codebase.

---

Purpose

Analyze existing projects and create migration plan to SpecWeave structure. Two paths supported: Quick Start (incremental) or Comprehensive (upfront).

---

Two Migration Paths

Path 1: Quick Start (Recommended for Large Projects)

Best for: 50k+ LOC, fast iteration, small teams

Process:

1. Initial scan: Document core architecture (1-3 hours)
2. Start working immediately
3. Per increment: Document → Modify → Update docs
4. Documentation grows with changes

Benefits:

• Start in days, not weeks
• Focus where it matters
• No analysis paralysis

Path 2: Comprehensive Upfront

Best for: <50k LOC, teams, regulated industries

Process:

1. Full analysis (1-4 weeks)
2. Document all modules, business rules
3. Create baseline tests
4. Then start increments

Benefits:

• Complete context upfront
• Full regression coverage
• Team coordination
• Compliance ready

Automatic Recommendation

---

Analysis Workflow

Step 1: Project Assessment

# Scan project
find . -type f -name "*.ts" -o -name "*.js" -o -name "*.py" | wc -l
find . -type f \( -name "*.ts" -o -name "*.js" \) -exec wc -l {} + | awk '{sum+=$1} END {print sum}'

Calculate:

• Total files
• Total LOC
• Module count
• Test coverage (if exists)

Output:

📊 Project Analysis
   Files: 1,245
   LOC: 45,678
   Modules: 23
   Tests: 45% coverage

💡 Recommendation: Medium project → User choice (Quick Start or Comprehensive)

Step 2: Document Classification

Scan for documentation:

PRD Candidates (Product Requirements):

• requirements.md, PRD.md, product-spec.md
• docs/​product/, specs/​requirements/

HLD Candidates (High-Level Design):

• architecture.md, design.md, ARCHITECTURE.md
• docs/​architecture/, docs/​design/

ADR Candidates (Architecture Decision Records):

• adr/, decisions/, docs/​decisions/
• Files with "ADR-" prefix or "decision" in name

Spec Candidates (Technical Specs):

• spec.md, technical-spec.md
• docs/​specs/, docs/​technical/

Runbook Candidates (Operations):

• runbook.md, operations.md, deployment.md
• docs/​ops/, docs/​runbooks/

Diagrams:

• *.png, *.svg, *.drawio, *.mmd
• diagrams/, docs/​diagrams/

Step 3: External Tool Detection

Jira Integration:

# Search for Jira references
grep -r "JIRA" . --include="*.md" --include="*.txt"
grep -r "jira.atlassian" . --include="*.md"

Azure DevOps:

grep -r "dev.azure.com" . --include="*.md"
grep -r "visualstudio.com" . --include="*.md"

GitHub Issues:

grep -r "github.com/​.*/​issues" . --include="*.md"

Step 4: Coding Standards Discovery

Auto-detect:

• ESLint config (.eslintrc, eslint.config.js)
• Prettier config (.prettierrc)
• TypeScript config (tsconfig.json)
• Test config (vitest.config, jest.config)

Analyze patterns:

# Naming conventions
grep -rh "^export function" src/ | head -20
grep -rh "^export class" src/ | head -20

# Import patterns
grep -rh "^import" src/ | sort | uniq -c | sort -rn | head -10

Step 5: Generate Migration Plan

Quick Start Plan:

# Migration Plan: Quick Start Path

## Phase 1: Initial Setup (1-2 hours)
- [ ] Run `specweave init`
- [ ] Document core architecture only
- [ ] Create 1-2 ADRs for critical decisions

## Phase 2: First Increment (1-3 days)
- [ ] Select first feature to modify
- [ ] Document module before touching
- [ ] Create increment with /​sw:increment
- [ ] Implement changes
- [ ] Update docs

## Phase 3: Iterate
- [ ] Repeat per feature
- [ ] Documentation grows organically

Comprehensive Plan:

# Migration Plan: Comprehensive Path

## Phase 1: Documentation Baseline (1-2 weeks)
- [ ] Map all modules to .specweave/​docs/​internal/​modules/
- [ ] Create ADRs for major architectural decisions
- [ ] Document business rules
- [ ] Identify technical debt

## Phase 2: Test Baseline (1 week)
- [ ] Add baseline tests for core functionality
- [ ] Target 60-70% coverage
- [ ] Document test strategy

## Phase 3: Structure Migration (2-3 days)
- [ ] Run `specweave init`
- [ ] Migrate existing docs
- [ ] Organize by SpecWeave structure

## Phase 4: Ready for Increments
- [ ] Start feature work with full context

---

Migration Checklist

Before SpecWeave Init

• Assess project size (LOC, files)
• Choose path (Quick Start or Comprehensive)
• Backup existing docs
• Identify external tool integrations
• Check coding standards exist

During Migration

Quick Start:

• Document core architecture only
• Create 1-2 critical ADRs
• Set up external tool sync (optional)
• Start first increment immediately

Comprehensive:

• Scan all documentation
• Classify and organize docs
• Create complete module docs
• Document all business rules
• Create ADRs for decisions
• Add baseline tests
• Set up external tool sync

After Migration

• Verify .specweave/ structure exists
• Test increment workflow
• Train team on SpecWeave
• Document migration decisions

---

Document Mapping

Map existing docs to SpecWeave structure:

Existing Structure          SpecWeave Structure
─────────────────          ───────────────────
docs/​product/              .specweave/​docs/​internal/​strategy/
docs/​architecture/         .specweave/​docs/​internal/​architecture/
docs/​decisions/            .specweave/​docs/​internal/​architecture/​adr/
docs/​specs/                .specweave/​docs/​internal/​specs/
docs/​runbooks/             .specweave/​docs/​public/​runbooks/
docs/​api/                  .specweave/​docs/​public/​api-docs/
README.md                  .specweave/​docs/​public/​README.md
CONTRIBUTING.md            .specweave/​docs/​public/​CONTRIBUTING.md

---

External Tool Migration

Jira → SpecWeave

1. Detect Jira usage:

grep -r "jira" . --include="*.md" | head -5

2. Map Jira structure:

• Epic → Feature (FS-XXX)
• Story → User Story (US-XXX)
• Task → Task (T-XXX)

3. Sync strategy:

# Option 1: Import existing Jira items
/​sw-jira:sync --import

# Option 2: Start fresh, sync new work only
# (Use SpecWeave as source of truth)

Azure DevOps → SpecWeave

Map work items:

• Feature → Feature (FS-XXX)
• User Story → User Story (US-XXX)
• Task → Task (T-XXX)

Sync:

/​sw-ado:sync --import

GitHub Issues → SpecWeave

Map issues:

• Milestone → Feature (FS-XXX)
• Issue → User Story (US-XXX)
• Task list → Tasks (T-XXX)

Sync:

/​sw-github:sync --import

---

Best Practices

✅ DO:

• Choose appropriate path (Quick Start for large projects)
• Document before modifying code
• Migrate incrementally (don't big-bang)
• Preserve existing docs (don't delete)
• Use external tool sync for existing items
• Train team on SpecWeave workflow

❌ DON'T:

• Force Comprehensive for 100k+ LOC projects
• Delete existing documentation
• Migrate all features upfront (Quick Start)
• Skip coding standards discovery
• Ignore external tool integrations
• Over-analyze in Quick Start mode

---

Example: Large Project Migration

Scenario: 85k LOC Node.js backend, Jira, 15% test coverage

Recommended: Quick Start

Plan:

Week 1: Setup (2 hours)
- Run specweave init
- Document core architecture (5 modules)
- Create 2 ADRs (database, API design)
- Configure Jira sync

Week 1-2: First Increment
- Select first feature: "Add rate limiting"
- Document rate-limiting module
- Create increment with /​sw:increment
- Implement with TDD
- Update docs

Week 3+: Iterate
- Repeat per feature
- Documentation grows to 40% over 3 months
- Eventually covers critical paths

Result: Started working in 2 hours, documentation grows naturally.

---

Example: Small Project Migration

Scenario: 8k LOC Python app, GitHub Issues, 60% test coverage

Recommended: Comprehensive Upfront

Plan:

Week 1: Full Documentation (8 hours)
- Document all 5 modules
- Create 8 ADRs
- Map business rules
- Document API contracts

Week 1: Test Baseline (4 hours)
- Add missing unit tests (80% coverage)
- Document test strategy

Week 1: Structure Migration (2 hours)
- Run specweave init
- Migrate existing docs
- Configure GitHub sync

Week 2+: Start Increments
- Full context available
- High confidence changes

Result: 2 weeks to full documentation, then smooth increment workflow.

---

Troubleshooting

Issue: Can't find existing documentation Solution: Check common locations: docs/, wiki/, .github/, Notion exports

Issue: Too many documents to classify Solution: Focus on architecture docs first, skip implementation details

Issue: Conflicting documentation Solution: Use git history to find latest/​canonical version

Issue: External tool API limits Solution: Use throttled sync, batch imports

---

This skill is self-contained and works for ANY brownfield project.

Project-Specific Learnings

Before starting work, check for project-specific learnings:

# Check if skill memory exists for this skill
cat .specweave/​skill-memories/​brownfield-analyzer.md 2>/​dev/​null || echo "No project learnings yet"

Project learnings are automatically captured by the reflection system when corrections or patterns are identified during development. These learnings help you understand project-specific conventions and past decisions.