بنقرة واحدة
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 المهني
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
Use for all development work on plugins built with WPBoilerplate/wordpress-plugin-boilerplate: hooks via the Loader singleton, PSR-4 namespace layout, security baseline (nonces/capabilities/escaping), settings API, REST endpoints, lifecycle, i18n, multisite, performance, and the @wordpress/scripts build pipeline.
Use when implementing custom database tables in WordPress plugins with berlindb/core. Covers Schema/Table/Row/Query class wiring, the allow_null gotcha, upsert return-value handling, JSON column encoding, tri-state tinyint columns, and all failure modes discovered in production use.
Audit a WordPress plugin's REST surface and produce a standardized audit document proposing Abilities API registrations. Produces a markdown doc with a YAML schema and prose sections that humans and agents can both consume when planning a registration rollout. Works on any WP plugin.
| 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