ワンクリックで
stack-detection
Detect the language, framework, and tooling stack of a project or set of files to load the right engineering skills.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Detect the language, framework, and tooling stack of a project or set of files to load the right engineering skills.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Behavioral rules that make AI coding agents more reliable — verification, self-correction, and scope discipline.
Debugging guidance and structured report template for thorough bug investigation, evidence gathering, and root cause documentation.
Cold-audit a completed delivery — verify the spec was actually delivered, challenge performative claims, and produce a what-landed report.
Guidelines for generating self-contained HTML mockups that look professional and are easy to iterate on.
Shared implementation guidance for making minimal, correct, maintainable code changes that fit existing systems.
The doctrine for `/roadmap-review` — interactive triage of roadmap-shape drift, walked one item at a time, with paste-ready resolution phrasing for the active sizing lens.
| name | stack-detection |
| description | Detect the language, framework, and tooling stack of a project or set of files to load the right engineering skills. |
| compatibility | opencode |
| metadata | {"audience":"engineers","purpose":"skill-routing"} |
Guide the engineer agent in detecting the technology stack of the code being worked on, so the correct language and framework skills are loaded automatically.
Load this skill at the start of any engineering task before loading stack-specific skills. Use it to determine which of the available stack skills to load.
Detect the stack by examining the files involved in the current task, the project root, and build configuration. Use the most specific signal available.
Look at the file extensions and import statements in the files listed in the spec's Changes section:
| Extension / pattern | Stack skill to load |
|---|---|
.java | java-stack |
.groovy, .gradle, .gradle.kts | groovy-stack |
.go | go-stack |
.rs, Cargo.toml | rust-stack |
.py, .pyi | python-stack |
.js, .mjs, .cjs, .ts, .mts | javascript-stack |
.jsx, .tsx | javascript-stack + react-stack |
.swift | Swift project (mockup renderer hint: swiftui-mockup-renderer) |
.sql, migration files | database-stack |
If the files being changed don't make the stack obvious, check the project root:
| Marker | Stack skill |
|---|---|
pom.xml, build.gradle, build.gradle.kts | java-stack (and/or groovy-stack for Gradle/Spock) |
go.mod | go-stack |
Cargo.toml, Cargo.lock | rust-stack |
pyproject.toml, setup.py, requirements.txt, Pipfile | python-stack |
package.json | javascript-stack |
package.json with react dependency | javascript-stack + react-stack |
tsconfig.json | javascript-stack |
Package.swift, *.xcodeproj, *.xcworkspace | Swift project (mockup renderer hint: swiftui-mockup-renderer) |
If the task spans multiple stacks (e.g., a Go backend API + React frontend), load all relevant stack skills. There is no conflict — each skill covers its own domain.
Regardless of stack detection, always load these skills for any engineering task:
implementation-principlestesting-and-validationjava-stack — Java, JVM conventions, Spring, service designgroovy-stack — Groovy, Gradle, DSLs, Spock testinggo-stack — Go packages, concurrency, operational correctnessrust-stack — Rust ownership, error handling, crate designpython-stack — Python project structure, type safety, dependency management, testingjavascript-stack — JavaScript, TypeScript, Node runtime safetyreact-stack — React components, state management, accessibilitydatabase-stack — Schema, migrations, queries, rollout safetyLoad these when the task involves their domain, regardless of language:
api-design-and-contracts — when API endpoints or contracts are involvedintegration-boundaries — when external service integrations are involvedperformance-optimization — when performance work is the goalsecurity-review — when security-sensitive code is being written