stack-detect

name

stack-detect

description

Detect the current repo's tech stack from its manifest files and recommend which ZCode skills, MCP servers, and plugins fit. Reads package.json (Node: React/Next.js/Vue/Svelte/Express/Nest), pyproject.toml + requirements.txt (Python: FastAPI/Django/Flask), go.mod (Go: echo/gin/fiber), Cargo.toml (Rust: axum/actix/tokio), pom.xml + build.gradle (Java: Spring/Maven/Gradle), composer.json (PHP: Laravel/Symfony), Gemfile (Ruby: Rails/Sinatra). ROUTE BY INTENT, NOT KEYWORDS — load when the user starts a new project ("이 레포 스택 뭐야", "what stack is this", "어떤 기술 쓰지", "set up for this repo"), asks for tooling recommendations, or when a fresh session needs to orient on an unfamiliar repo. Also load proactively at session start on an unfamiliar repo — orienting on the stack is step zero. Returns a stack fingerprint (language + framework + package manager + test runner + notable deps) + a recommendation table (skill/MCP/plugin → why it fits → install hint). Does NOT auto-enable anything — it recommends, the user decides. Industry precedent is user-select (pre-commit, ESLint shareable configs); this detector narrows the choice but never removes it.

Stack detect — orient on any repo

The first thing to do on an unfamiliar repo: figure out the stack. This skill reads the manifest files at the repo root (and one level of apps/* / packages/* for monorepos) and produces a fingerprint + recommendations.

Why this exists

Most AI coding tools punt on explicit stack detection — Aider, Cursor, Supermaven, pre-commit, and ESLint all make the user select their stack. IDEs like VSCode read manifests for extension recommendations, but do not surface that as a ZCode/Claude skill. This skill reads the manifests and recommends which ZCode resources fit, narrowing the user's choice without removing it: the detector recommends, the user decides.

The detection procedure

Step 1 — Find the manifests

At the repo root, look for (check all that apply; a polyglot repo has several):

File	Ecosystem
package.json	Node / JS / TS
pyproject.toml, requirements.txt, setup.py, Pipfile	Python
go.mod	Go
Cargo.toml	Rust
pom.xml, build.gradle, build.gradle.kts	Java / JVM
composer.json	PHP
Gemfile	Ruby
mix.exs	Elixir
Package.swift	Swift
go.work	Go workspace (monorepo)
pnpm-workspace.yaml, lerna.json, turbo.json, nx.json	JS monorepo
apps/*/, packages/*/, services/*/	monorepo layout — recurse one level

Use Glob and Read — do not infer the stack from file extensions alone (a .ts file could be a Node server, a Deno script, or a frontend component; the manifest tells you which).

Step 2 — Extract the fingerprint

For each ecosystem present, extract:

Node (package.json):

• dependencies + devDependencies → framework signal:
  • next → Next.js (React SSR/SSG)
  • react, react-dom → React (SPA)
  • vue → Vue
  • svelte, @sveltejs/kit → Svelte / SvelteKit
  • express, fastify, koa, hapi → Node server
  • @nestjs/core → NestJS
  • electron → Electron desktop
  • vite → Vite bundler (often frontend)
  • playwright, puppeteer → browser automation present
• packageManager → npm / pnpm / yarn / bun
• scripts.test → test runner (jest / vitest / mocha / playwright test)

Python (pyproject.toml):

• [project] dependencies / [tool.poetry] dependencies / requirements.txt:
  • fastapi, uvicorn → FastAPI
  • django → Django
  • flask → Flask
  • torch, tensorflow → ML
  • pandas, numpy → data
  • motor, pymongo → MongoDB
  • sqlalchemy → SQL ORM
  • pytest → test runner
• [tool.uv] / [tool.poetry] / [tool.pdm] → package manager

Go (go.mod):

• module path → module name
• require block → framework signal:
  • github.com/labstack/echo → Echo
  • github.com/gin-gonic/gin → Gin
  • github.com/gofiber/fiber → Fiber
  • google.golang.org/grpc → gRPC
  • github.com/spf13/cobra → CLI

Rust (Cargo.toml):

• [dependencies] → framework signal:
  • axum, actix-web, rocket → web
  • tokio → async runtime
  • serde → serialization
  • clap → CLI
  • tauri → Tauri desktop

Java (pom.xml / build.gradle):

• spring-boot-starter-* → Spring Boot
• groupId / artifactId → Maven coordinates
• Gradle plugins (org.springframework.boot, org.jetbrains.kotlin) → Kotlin?

Step 3 — Produce the recommendation table

Map detected stack → ZCode resources. Be concrete about WHY each resource fits.

Stack detected	Recommend	Why
Any frontend (React/Vue/Svelte/Next)	glm-design-fleet plugin	Design rubric + slop gate for the UI surface
Any frontend	Playwright MCP (if not installed)	The "eyes" for GLM-5.2 — computed-style probes for design-craft judgment
Any frontend	context7 plugin (if not installed)	Fetch current framework docs (React/Vue/Svelte)
Python + MongoDB	MongoDB MCP server	Direct DB query for verify-before-claim evidence
Any backend with an HTTP API	42crunch-api-security-testing plugin (if present)	API security audit
Any git repo	glm-verify-spine plugin	bash-guard + verify-before-claim (universal)
Any git repo	session-telemetry plugin	Know how you work (universal)
Monorepo (multiple stacks)	All applicable above, scoped per sub-dir	Note which stack lives where (apps/web = React, apps/api = FastAPI)

Do NOT recommend stack-specific resources that aren't installed — name them as "consider installing" with the install hint, but keep the recommendation table focused on what helps NOW.

Step 4 — Output format

Stack fingerprint
- Languages: <list>
- Frameworks: <list with version if available>
- Package manager: <list>
- Test runner: <list>
- Monorepo: <yes/no, layout>
- Notable deps: <top 5-10 by signal>

Recommendations
| Resource | Why it fits this stack | Status |
|---|---|---|
| glm-design-fleet | Frontend surface (Next.js) → design rubric applies | already installed ✓ / consider installing |
| Playwright MCP | GLM-5.2 needs computed-style probes for UI judgment | already connected ✓ / not connected — /mcp connect playwright |
| ... | ... | ... |

Next steps
- <concrete first action based on the stack, e.g. "dev server: npm run dev (Next.js on :3000)">
- <if verify-spine not installed: "consider installing for bash-guard + verify-before-claim">

Honesty limits

• Detection is heuristic — react in devDependencies might be a tooling dep, not the app framework. Cross-check with the entry point (pages/ for Next.js Pages Router, app/ for App Router, src/main.tsx for Vite React).
• A manifest can lie (stale deps, commented-out, monorepo hoist). If the manifest and the code disagree, trust the code (read the entry point).
• This skill does NOT install or enable anything. It recommends. The user decides. Auto-enabling would violate the user-select precedent and risk enabling the wrong thing on a misread.
• For a totally unfamiliar stack (no recognized manifests), say so: "stack = 확인 불가 (no recognized manifests at root)". Do not guess.