Skip to main content

gws detect

Detect project type, framework, language, and port for the current directory (or any directory you point it at). Emits a stable JSON snapshot that the /gws-setup skill — or any other tool — can use to bootstrap gws.json without re-implementing project detection in prose.

Thin wrapper over the ProjectTypeDetector + FrameworkDetector libraries that the rest of the CLI already uses, so detections always agree with what gws up would do.

Usage​

gws detect [--path <dir>] [--json]
FlagDescriptionDefault
--path <dir>Directory to scancurrent working directory
--jsonEmit JSON outputalways on (text mode is reserved for a future release)

Auth: not required. Read-only — no API access.

Behaviour​

  • If the root directory has a project marker (package.json, go.mod, requirements.txt, pyproject.toml, Cargo.toml, Gemfile, mix.exs, …), gws detect emits a single-service result.
  • Otherwise it scans immediate subdirectories for project markers and emits a monorepo result with one entry per detected service. Common build/cache directories (node_modules, dist, .next, target, vendor, .gws, .worktrees, …) are skipped.

Output shape​

{
  "version": "1.0",
  "rootPath": "/abs/path/to/project",
  "monorepo": false,
  "services": [
    {
      "name": "api",
      "path": "./api",
      "projectType": "python",
      "framework": "python-fastapi",
      "language": "python",
      "port": 8000,
      "confidence": "high",
      "detectedFrom": ["requirements.txt"],
      "suggestedDockerfile": "Dockerfile",
      "suggestedManifests": "deployment.yaml,service.yaml",
      "suggestedSyncPatterns": ["**/*.py"]
    }
  ]
}

The version field is bumped if the schema ever changes — write your tooling against it.

Examples​

# Detect the current repo
gws detect | jq '.services[].framework'

# Scope to one subdirectory
gws detect --path ./services/api

# Pipe into /gws-setup's loop manually
gws detect > .gws/detect.json

See also​