mcpField
B
bootstrap-brownfield

bootstrap-brownfield

github.com/nextstage-brasilDevelopment036 installsUpdated 4d ago
Repository

About bootstrap-brownfield

A read-only skill for mapping an existing product’s architecture before software-driven development planning. It identifies the stack and modules, optionally checks harness rules, and records findings for later requirements work.

Key features

  1. 01Detects backend and frontend structure
  2. 02Maps modules and product domains
  3. 03Optionally checks harness rule adherence
  4. 04Writes or updates a brownfield map
  5. 05Keeps analysis read-only

Use cases

  1. 01Surveying a legacy codebase before planning
  2. 02Preparing context for requirements generation

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/nextstage-brasil/skills --skill bootstrap-brownfield

After installing, type/bootstrap-brownfieldin Claude Code to confirm it loaded.

Bundled filesevals/evals.json

Details

From the project README

Bootstrap Brownfield

Architectural discovery for existing products before SDD planning.

Harness discovery

See ../nextstage-harness/references/harness-discovery.md. Load rules from {harness_root}/rules/*.md. Read architecture-rules.md first. Legacy: .cursor/rules/*.mdc only if {harness_root} is absent. Compare findings to canonical rules when present — checks are advisory if rules missing.

When to use

  • "Analyze the existing project" / "brownfield bootstrap"
  • First SDD planning on repo with code but no requirements.md
  • Before requirements-generator on legacy code

Workflow

Step 1 — Structure detection

Under {product_root} (and repo root if legacy layout — document inconsistency):

Backend signals: composer.json, artisan, modular app/Modules/, docker-compose.yml, .env.example

Frontend signals: package.json, tsconfig.json, src/modules/, cypress/, bundler config

Layout: monorepo backend/ + frontend/ vs single app

Step 2 — Module mapping

List domains:

  • Backend: modules, controllers, models, migrations per module
  • Frontend: pages, stores, services per module
Step 3 — Rule adherence (optional)

Compare to harness rules when they exist — backend module layout, multitenancy, frontend patterns, tests. Mark ✅ / ⚠️ / ❌ per row.

Use stack-agnostic checks when no harness rules.

Step 4 — Report

Create or update {product_root}/docs/context/brownfield-map.md:

# Architectural map — brownfield bootstrap

**Date:** {date}

## Identified stack

- Backend: ...
- Frontend: ...
- Database, cache, queues, E2E tooling

## Backend modules

| Module | Controllers | Models | Migrations | Tests |

## Frontend modules

| Module | Pages | Stores | E2E |

## Rule adherence

{tables when rules exist}

## Gaps (priority)

1. Critical ...
2. Medium ...

## Recommendations for next planning

- ...
Step 5 — Present

Summarize 3–5 bullets, highlight critical gaps, ask whether to start version planning or review gaps.

Critical rules

  • Read-only — no code changes
  • Report only under {product_root}/docs/context/
  • Pass brownfield-map.md to requirements-generator as context
  • Update existing map rather than duplicate

Related skills

  • codebase-reverse-spec — business behavior extraction (deeper than bootstrap)
  • requirements-generator — next step after bootstrap
  • clarify-requirements — when scope still vague

Comments

Markdown supported