ワンクリックで
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