stack-detect

النجوم٠

التفرعات٠

آخر تحديث٦ يوليو ٢٠٢٦ في ٠٦:٢٧

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.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

المصدر

jhlee0409

jhlee0409/zcode-glm-fleet

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

المزيد من هذا المستودع

نفس المستودع

work-pattern-memory

jhlee0409/zcode-glm-fleet

The knowledge layer for the learning loop. Explains how to read and act on the work-pattern snapshot that glm-learning-loop injects at SessionStart — what the verification ratio means, what tool over-reliance signals, how to adapt behavior based on past-session telemetry. ROUTE BY INTENT — load when the model receives a work-pattern snapshot and needs to interpret it, when the user asks "how do I work?" / "내 작업 패턴 뭐야" / "am I verifying enough?", or when adapting this session based on past behavior. Also load when the user wants to inspect or clear the telemetry that drives the loop. NOT a stats viewer (that's /session-stats) — this is the interpretive layer that turns numbers into behavioral change.

2026-07-060

design-craft-rubric

jhlee0409/zcode-glm-fleet

JUDGE whether an already-rendered UI surface is good enough to ship — quality evaluation of something that EXISTS, not creation of something new. GLM-5.2 has no vision, so judgment runs on Playwright-MCP computed-style probes (getComputedStyle JSON: fontSize / color / padding / gap / contrast), not on eyeballing pixels. Scores 7 dimensions PASS/FAIL (visual hierarchy / spacing-rhythm / alignment / contrast+WCAG / density / design-token conformance / DESIGN.md-tone) + runs a 13-tell "AI-slop" gate (warm-cream hero, near-black+neon, Inter-only, white+purple, uniform sizing, vague headlines, scattered motion…). ROUTE BY INTENT, NOT KEYWORDS — load this whenever the intent is to evaluate quality of a built surface, including indirect signals: a shared screenshot the user reacts to with dissatisfaction, hesitation, or silence; "이거 이상하지 않아?", "괜찮아?", "어때"; a ship/no-ship decision moment ("출시해도 돼?", "이대로 갈까?"); any qualitative complaint about a rendered screen ("AI스러워", "올드해", "트렌디하지 않아", "이탈하고 싶어져"); explicit revie

2026-07-060

ui-iterate

jhlee0409/zcode-glm-fleet

CONVERGE an EXISTING rendered UI surface to good craft through a closed measured loop — judge → fix-list → edit code → HMR re-render → re-judge → repeat until PROCEED or a 3-round cap. Probe-driven (Playwright-MCP computed-style JSON), not eyeballing, because GLM-5.2 has no vision. Inlines the 7-dim rubric + 13-tell slop gate so a surface can be converged in-loop. ROUTE BY INTENT, NOT KEYWORDS — load this whenever the intent is to REPEATEDLY IMPROVE a built surface until it is good, including indirect signals: "이거 계속 비슷해" (a prior one-shot fix did not land), "쓰레기 UI 고쳐", "UI 다듬어", "개선 루프 돌려", "craft 올려", "make this converge", any vibe that one-shot review is not enough and the user wants to iterate to satisfaction. NOT for designing a new screen from JTBD (that is ux-design-baseline). NOT for a single quality verdict (that is design-craft-rubric — judge once). NOT for runtime mechanics.

2026-07-060

ux-design-baseline

jhlee0409/zcode-glm-fleet

PRODUCE the design intent for a UI feature that does not yet exist — the design thinking BEFORE code. Frames the job-to-be-done (what user behavior change, measured how), grounds in the repo's DESIGN.md + FLOWMAP, audits the current-state surfaces with a severity-scored findings table + cognitive walkthrough, DECIDES craft forks with conviction (north-star default shown — never dumps an a/b menu on the user), and produces a durable design.md (9-section template, slim/full tier). Repo-agnostic: each repo's DESIGN.md owns tone, each repo's FLOWMAP owns the flow map. ROUTE BY INTENT, NOT KEYWORDS — load this whenever the intent is to FIGURE OUT the design for something to be built, including indirect signals: a feature request that needs design thinking before code ("이 기능 만들어줘", "이 화면 추가하자"), a "how should this work?" question about user flow, a request for a wireframe or design doc, any moment where the user wants to decide what to build before building it. NOT for judging an already-rendered surface (that is d

2026-07-060

verify-before-claim

jhlee0409/zcode-glm-fleet

Enforce the "no premature done" discipline. Before claiming a task is complete, the model MUST produce real evidence — a test run with passing output, a real DB query result, a rendered screenshot, a build that compiles, a command's actual stdout. "200 OK" alone, fake fixtures (fake JWT, synthetic audio), or code-inference without execution are NOT evidence. ROUTE BY INTENT, NOT KEYWORDS — load this whenever the model is about to say "done", "complete", "fixed", "finished", "완료", "구현 완료", or any completion claim, OR when the user asks "did it work?", "are you sure?", "진짜야?", or expresses doubt about a claim. Also load when a conclusion lacks a quantitative basis (test count, response time, measured value). Returns either evidence (command + output / test result) or an explicit "확인 불가" (cannot verify) verdict with the missing evidence named. NOT a code editor — it produces or demands evidence, never edits code.

2026-07-060

adr-template

jhlee0409/zcode-glm-fleet

Architecture Decision Record template + when to write one. An ADR is a short markdown record of a significant architectural decision, its context, and its consequences — durable history that answers "why is it like this?" months later. ROUTE BY INTENT — load when making a non-obvious architectural decision ("이걸 왜 이렇게 했지?" later, "should we use X or Y for..."), when a decision is hard to reverse, or when you need to look up why a past choice was made. NOT for implementation details (that's code comments) or ephemeral task notes (that's a spec).

2026-07-060

name

stack-detect

description

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.