ns-harness-bootstrap-brownfield
About ns-harness-bootstrap-brownfield
An agent skill for mapping an existing codebase before SDD planning. It produces a compact module and gap report, reads application code without changing it, and links to architecture rules rather than duplicating them.
Key features
- 01Detects frontend, backend, and layout signals
- 02Maps domains and files by module
- 03Optionally checks adherence to harness rules
- 04Produces a compact brownfield map
- 05Writes reports only in the context directory
Use cases
- 01Start SDD planning for a legacy project without requirements
- 02Review modules and gaps before generating requirements
- 03Refresh an existing brownfield map
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ nextstage-brasil/ skills --skill ns-harness-bootstrap-brownfieldAfter installing, type/ns-harness-bootstrap-brownfieldin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
evals/evals.jsonreferences/agent-dense.mdbrownfield-map.template.mdDetails
From the project READMEBootstrap Brownfield
Architectural discovery for existing products before SDD planning.
Output is agent-dense (tables, counts, gap list) — not a human essay. See references/agent-dense.md and pre-save ../ns-harness/references/agent-artifact-compress.md.
Harness discovery
See ../ns-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. Do not copy the constitution stack into the map — link it.
When to use
- "Analyze the existing project" / "brownfield bootstrap"
- First SDD planning on repo with code but no
requirements.md - Before
ns-sdd-requirements-generatoron 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
Draft {product_root}/docs/context/brownfield-map.md from references/brownfield-map.template.md and references/agent-dense.md.
Writing rules:
- Tables / one-liners only — no overview paragraphs.
- Stack = pointer to
architecture-rules.md(+ optional one-line delta). - Gaps = priority table; Next planning ≤3 bullets.
Pre-save (mandatory): apply ../ns-harness/references/agent-artifact-compress.md (caveman ultra), then write the compressed file.
Step 5 — Present
Chat summary only (3–5 bullets: date, critical gaps, next skill). Do not paste the map body into chat.
Critical rules
- Read-only — no code changes
- Report only under
{product_root}/docs/context/ - Pass
brownfield-map.mdtons-sdd-requirements-generatoras context - Update existing map rather than duplicate
- Never duplicate full stack from
architecture-rules.md
Related skills
ns-harness-architecture-rules— constitution (stack/layout source of truth)ns-harness-codebase-reverse-spec— business behavior extraction (deeper than bootstrap)ns-sdd-requirements-generator— next step after bootstrapns-sdd-clarify-requirements— when scope still vague
References
| File | When |
|---|---|
references/brownfield-map.template.md | Step 4 skeleton |
references/agent-dense.md | Writing constraints |
../ns-harness/references/agent-artifact-compress.md | Pre-save compress (mandatory) |