원클릭으로
speckit-brownfield-scan
Auto-discover project structure, tech stack, frameworks, and architecture patterns
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Auto-discover project structure, tech stack, frameworks, and architecture patterns
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Think before building. Use when the user asks to reason about, analyze, evaluate, compare options, make an architecture decision, choose between approaches, think through a problem, or assess trade-offs. Also use when the user asks 'why did we...', 'should we...', 'what are our options', 'is this the right approach', or wants to frame/reframe a problem.
Archive a feature specification into main project memory after merge, resolving gaps and conflicts
Generate spec-kit configuration tailored to the existing codebase
Incrementally adopt SDD for existing features with reverse-engineered specs
Verify bootstrap output matches actual project structure and conventions
Populate GitHub Project from specs/*/tasks.md. Creates one draft issue per feature with a markdown task list. Skips features already in the project. Safe to re-run.
| name | speckit-brownfield-scan |
| description | Auto-discover project structure, tech stack, frameworks, and architecture patterns |
| compatibility | Requires spec-kit project structure with .specify/ directory |
| metadata | {"author":"github-spec-kit","source":"brownfield:commands/speckit.brownfield.scan.md"} |
Analyze an existing codebase to discover its technology stack, architecture patterns, module structure, and coding conventions. This produces a project profile that the bootstrap command uses to generate tailored spec-kit configuration.
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty). The user may specify a subdirectory to scan (e.g., "backend/"), a focus area (e.g., "only frontend"), or request a specific depth of analysis.
Detect tech stack: Identify languages, frameworks, and tools by scanning:
| Signal | What to Check |
|---|---|
| Languages | File extensions (.py, .ts, .go, .java, .rs, etc.) and their relative proportions |
| Package managers | package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, pom.xml, build.gradle |
| Frameworks | Dependencies in package files (React, Django, Spring, Express, Rails, etc.) |
| Build tools | Makefile, webpack.config.js, vite.config.ts, Dockerfile, docker-compose.yml |
| CI/CD | .github/workflows/, .gitlab-ci.yml, .circleci/, Jenkinsfile |
| Testing | Test directories, test frameworks in dependencies (jest, pytest, go test, JUnit) |
Analyze architecture: Identify the project's structural patterns:
| Pattern | Indicators |
|---|---|
| Monolith | Single source tree, one entry point, shared database config |
| Monorepo | Multiple package.json/go.mod files, workspace config, packages/ or apps/ directories |
| Microservices | Multiple Dockerfiles, service directories, API gateway config |
| Frontend + Backend | Separate client//server/ or frontend//backend/ directories |
| Library/Package | setup.py, lib/ directory, published package config |
| MVC | models/, views/, controllers/ directories |
| Layered | domain/, application/, infrastructure/, presentation/ directories |
Map module structure: For monorepos and multi-module projects:
Extract conventions: Detect existing coding patterns:
git branch -agit log --oneline -20__tests__/, *_test.go, test_*.py), test namingDetect existing governance: Check for files that indicate existing project standards:
CONTRIBUTING.md, ARCHITECTURE.md, ADR/ (Architecture Decision Records).editorconfig, linter configs (.eslintrc, .flake8, rustfmt.toml)CLAUDE.md, AGENTS.md, .specify/ (existing spec-kit setup)Output project profile:
# Project Profile
## Tech Stack
| Category | Detected |
|----------|----------|
| **Primary language** | TypeScript (68%), Python (32%) |
| **Frontend** | React 18, Vite, TailwindCSS |
| **Backend** | FastAPI, SQLAlchemy, PostgreSQL |
| **Testing** | Jest (frontend), pytest (backend) |
| **CI/CD** | GitHub Actions |
| **Package manager** | npm (frontend), pip (backend) |
## Architecture
- **Pattern**: Frontend + Backend (separated)
- **Frontend**: `client/` — React SPA
- **Backend**: `server/` — FastAPI REST API
- **Database**: PostgreSQL (via SQLAlchemy ORM)
## Module Map
| Module | Path | Purpose | Dependencies |
|--------|------|---------|-------------|
| Frontend | `client/` | React SPA | Backend API |
| Backend | `server/` | REST API | Database |
| Shared | `shared/` | Type definitions | — |
## Conventions
- **File naming**: kebab-case (frontend), snake_case (backend)
- **Branch pattern**: `feat/*`, `fix/*`, `chore/*`
- **Commit style**: Conventional Commits
- **Test location**: `__tests__/` (frontend), `tests/` (backend)
## Existing Governance
- ✅ CONTRIBUTING.md
- ✅ .eslintrc.json
- ❌ ARCHITECTURE.md
- ❌ .specify/ (no spec-kit setup)
## Recommendations
- Run `/speckit.brownfield.bootstrap` to generate tailored spec-kit configuration
- Constitution should enforce: kebab-case files (frontend), snake_case (backend)
- Feature specs should map to the frontend/backend split
node_modules/, vendor/, dist/, .venv/, or other ignored directories